> [5.543416] ieee80211 phy0: Failed to select rate control algorithm
> [5.543993] ieee80211 phy0: Failed to initialize rate control algorithm
> [5.556937] mac80211_hwsim: ieee80211_register_hw failed (-2)
> [5.557669] BUG: unable to handle kernel paging request at cd1aa02c
> [
[5.543416] ieee80211 phy0: Failed to select rate control algorithm
[5.543993] ieee80211 phy0: Failed to initialize rate control algorithm
[5.556937] mac80211_hwsim: ieee80211_register_hw failed (-2)
[5.557669] BUG: unable to handle kernel paging request at cd1aa02c
[
> 3.6.11.9-rc1 stable review patch.
> If anyone has any objections, please let me know.
Yes, this patch is broken and we reverted it upstream.
johannes
--
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer:
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
Yes, this patch is broken and we reverted it upstream.
johannes
--
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer:
> > Yeah, I'm trying to get that, but it's not clear to me how to fix it.
> > Where did you apply it? It was going to need some fixes but when the
> > first objection was raised I figured you were going to drop it for now
> > completely? Sorry for the mess :-(
>
> You're right, I'll drop this for
> + if (need_locking) {
> + /* genl_mutex could be already locked in genl_rcv_msg() */
> + rt = genl_family_find_byid(cb->nlh->nlmsg_type);
> + need_locking = need_locking && rt->parallel_ops;
> + }
This is equivalent to reverting the patch because
> > [ 26/34] genetlink: fix family dump race
>
> Johannes, another strike against this patch :(
>
> Any chance on fixing it upstream and me sucking that fix in?
Yeah, I'm trying to get that, but it's not clear to me how to fix it. Where did
you apply it? It was going to need some fixes but
[ 26/34] genetlink: fix family dump race
Johannes, another strike against this patch :(
Any chance on fixing it upstream and me sucking that fix in?
Yeah, I'm trying to get that, but it's not clear to me how to fix it. Where did
you apply it? It was going to need some fixes but when the
+ if (need_locking) {
+ /* genl_mutex could be already locked in genl_rcv_msg() */
+ rt = genl_family_find_byid(cb-nlh-nlmsg_type);
+ need_locking = need_locking rt-parallel_ops;
+ }
This is equivalent to reverting the patch because parallel_ops
Yeah, I'm trying to get that, but it's not clear to me how to fix it.
Where did you apply it? It was going to need some fixes but when the
first objection was raised I figured you were going to drop it for now
completely? Sorry for the mess :-(
You're right, I'll drop this for 3.4, it
> I think I have this slightly different in wireless-testing. Johannes, please
> review and advise...
> > Today's linux-next merge of the wireless-next tree got a conflict in
> > drivers/net/wireless/iwlwifi/pcie/trans.c between commit eabc4ac5d760
> > ("iwlwifi: pcie: disable L1 Active after
> Some debugfs write() operations of the MVM Firmware will ignore the count
> argument, and will copy more bytes than what was specified.
> Fix this by getting the right count of bytes.
>
> This will also honor restrictions put on the number of bytes to write.
That makes some sense.
> To be
Some debugfs write() operations of the MVM Firmware will ignore the count
argument, and will copy more bytes than what was specified.
Fix this by getting the right count of bytes.
This will also honor restrictions put on the number of bytes to write.
That makes some sense.
To be consitant
I think I have this slightly different in wireless-testing. Johannes, please
review and advise...
Today's linux-next merge of the wireless-next tree got a conflict in
drivers/net/wireless/iwlwifi/pcie/trans.c between commit eabc4ac5d760
(iwlwifi: pcie: disable L1 Active after
Hi Stephen,
> Today's linux-next merge of the wireless-next tree got a conflict in
> net/wireless/nl80211.c between merge commits from the net-next tree and
> commit 86e8cf98de3e ("nl80211: use small state buffer for wiphy_dump")
> from the wireless-next tree.
Looks good, yes.
> I think I fixed
Hi Stephen,
Today's linux-next merge of the wireless-next tree got a conflict in
net/wireless/nl80211.c between merge commits from the net-next tree and
commit 86e8cf98de3e (nl80211: use small state buffer for wiphy_dump)
from the wireless-next tree.
Looks good, yes.
I think I fixed it up
> > > /* and copy the data that needs to be copied */
> > > cmd_pos = offsetof(struct iwl_device_cmd, payload);
> > > + copy_size = sizeof(out_cmd->hdr);
> > > for (i = 0; i < IWL_MAX_CMD_TFDS; i++) {
> > > - if (!cmd->len[i])
> > > + int copy = 0;
> > > +
> > > + if
/* and copy the data that needs to be copied */
cmd_pos = offsetof(struct iwl_device_cmd, payload);
+ copy_size = sizeof(out_cmd-hdr);
for (i = 0; i IWL_MAX_CMD_TFDS; i++) {
- if (!cmd-len[i])
+ int copy = 0;
+
+ if (!cmd-len)
> commit c492db370c17c428a0a58d3673294d4e99634b7d
> Author: Johannes Berg
> Date: Thu Dec 6 16:29:25 2012 +0100
>
> regulatory: use RCU to protect last_request
>
> This will allow making freq_reg_info() lock-free.
>
> Acked-by: Luis R. Rodriguez
> Signed-off-by: Johannes
commit c492db370c17c428a0a58d3673294d4e99634b7d
Author: Johannes Berg johannes.b...@intel.com
Date: Thu Dec 6 16:29:25 2012 +0100
regulatory: use RCU to protect last_request
This will allow making freq_reg_info() lock-free.
Acked-by: Luis R. Rodriguez
> > > BUG: unable to handle kernel NULL pointer dereference at (null)
> > > IP: [] ieee80211_ave_rssi+0xd/0x50 [mac80211]
> >
> > From my debug kernel, sdata is clearly NULL:
> >
> > (gdb) list *0x815b74f8
> > 0x815b74f8 is in ieee80211_ave_rssi (net/mac80211/util.c:1801).
> >
> > When running my Centrino Wireless-N 130 BGN (rev 0xb0) card in nl80211
> > AP mode with hostapd on linux 3.5.0, I immediately hit this fatal
> > pagefault [1].
> >
> > I can cook a debug kernel, reproduce, disassemble the code and do some
> > quick analysis, if that helps get the ball rolling?
When running my Centrino Wireless-N 130 BGN (rev 0xb0) card in nl80211
AP mode with hostapd on linux 3.5.0, I immediately hit this fatal
pagefault [1].
I can cook a debug kernel, reproduce, disassemble the code and do some
quick analysis, if that helps get the ball rolling?
BUG:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [a02e869d] ieee80211_ave_rssi+0xd/0x50 [mac80211]
From my debug kernel, sdata is clearly NULL:
(gdb) list *0x815b74f8
0x815b74f8 is in ieee80211_ave_rssi (net/mac80211/util.c:1801).
24 matches
Mail list logo
