* RaLink 148f:3070 not working since upgrade from 2.6.30 to 2.6.31
From: Bráulio B O Bhavamitra @ 2009-10-11 12:13 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1df1788c0910110455q570ca89fy6edbda3235a7a35e@mail.gmail.com>
Since the upgrade from kernel 2.6.30 to 2.6.31 on archlinux the usb
wireless from Ralink doesn't work anymore.
Please ask for more info if necessary.
dmesg:
phy2 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed
for offset 0x7010 with error -19.
phy2 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed
for offset 0x7010 with error -19.
phy2 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed
for offset 0x7010 with error -19.
phy2 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed
for offset 0x7010 with error -19.
phy2 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed
for offset 0x7010 with error -19.
phy2 -> rt2x00usb_regbusy_read: Error - Indirect register access
failed: offset=0x00007010, value=0xffff8800
phy2 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed
for offset 0x7010 with error -19.
phy2 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed
for offset 0x7010 with error -19.
phy2 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed
for offset 0x7010 with error -19.
phy2 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed
for offset 0x7010 with error -19.
phy2 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed
for offset 0x7010 with error -19.
phy2 -> rt2x00usb_regbusy_read: Error - Indirect register access
failed: offset=0x00007010, value=0xffff8800
phy2 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed
for offset 0x7010 with error -19.
phy2 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed
for offset 0x7010 with error -19.
phy2 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed
for offset 0x7010 with error -19.
phy2 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed
for offset 0x7010 with error -19.
phy2 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed
for offset 0x7010 with error -19.
phy2 -> rt2x00usb_regbusy_read: Error - Indirect register access
failed: offset=0x00007010, value=0xffff8800
usb 2-2: new high speed USB device using ehci_hcd and address 6
usb 2-2: configuration #1 chosen from 1 choice
phy3: Selected rate control algorithm 'minstrel'
Registered led device: rt2800usb-phy3::radio
Registered led device: rt2800usb-phy3::assoc
Registered led device: rt2800usb-phy3::quality
rt2800usb 2-2:1.0: firmware: requesting rt2870.bin
phy3 -> rt2x00lib_request_firmware: Error - Failed to request Firmware.
rt2800usb 2-2:1.0: firmware: requesting rt2870.bin
phy3 -> rt2x00lib_request_firmware: Error - Failed to request Firmware.
lsusb -v:
Bus 002 Device 006: ID 148f:3070 Ralink Technology, Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x148f Ralink Technology, Corp.
idProduct 0x3070
bcdDevice 1.01
iManufacturer 1 Ralink
iProduct 2 802.11 n WLAN
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 67
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 450mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 7
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
^ permalink raw reply
* Re: [PATCH] b43: fix ieee80211_rx() context
From: Dave Young @ 2009-10-11 11:53 UTC (permalink / raw)
To: David Miller; +Cc: johannes, linville, kalle.valo, linux-wireless
In-Reply-To: <20091011.033907.35699436.davem@davemloft.net>
On Sun, Oct 11, 2009 at 6:39 PM, David Miller <davem@davemloft.net> wrote:
> From: Johannes Berg <johannes@sipsolutions.net>
> Date: Sun, 11 Oct 2009 12:19:21 +0200
>
>> Due to the way it interacts with the networking
>> stack and other parts of mac80211, ieee80211_rx()
>> must be called with disabled softirqs.
>>
>> Michael, the former maintainer of this driver,
>> has refused to fix the problem this way instead
>> proposing a much more invasive patch that could
>> not even be proved correct wrt. locking inside
>> mac80211. Regardless of that, he believes this
>> to be a bug in mac80211, and has also publicly
>> stated [1] that he does not care about this even
>> though it is a regression introduced by his own
>> patches.
>>
>> Since nobody else seems to be wanting to fix the
>> problem, I'll just fix it for the benefit of the
>> many users of this driver.
>>
>> [1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/39440/focus=40266
>>
>> Reported-by: Dave Young <hidave.darkstar@gmail.com>
>> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
>
> Acked-by: David S. Miller <davem@davemloft.net>
>
Tested-by: Dave Young <hidave.darkstar@gmail.com>
--
Regards
dave
^ permalink raw reply
* Re: NOHZ: local_softirq_pending 08
From: Tilman Schmidt @ 2009-10-11 11:18 UTC (permalink / raw)
To: Johannes Berg
Cc: Dave Young, linux-kernel, tglx, linux-wireless, David S. Miller
In-Reply-To: <1255255735.4095.53.camel@johannes.local>
On Sun, 11 Oct 2009 12:08:55 +0200, Johannes Berg wrote:
> On Sun, 2009-10-11 at 17:52 +0800, Dave Young wrote:
>
>> With kernel 2.6.32-rc3-00052-g0eca52a I got following KERN_ERR
>> messages just while using firefox:
>>
>> [ 130.527399] NOHZ: local_softirq_pending 08
>
>> Any idea? or known issue?
>
> Are you using b43 (or wl12x1)? If so, it's a known issue, but the driver
> was recently left without an active maintainer in a brouhaha about a bug
> fix.
>
> Cf. http://thread.gmane.org/gmane.linux.kernel.wireless.general/39440
Can you explain a bit more what that message is about?
I am encountering it in a completely different context
(PPP over ISDN) and I would like to know where to start
looking for the cause and developing a fix. The thread
on linux.kernel.wireless.general only seems to address
the specific situation in the wireless stack.
Thanks,
Tilman
^ permalink raw reply
* Re: NOHZ: local_softirq_pending 08
From: Johannes Berg @ 2009-10-11 11:40 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Dave Young, linux-kernel, tglx, linux-wireless, David S. Miller
In-Reply-To: <4AD1BF06.3050103@phoenixsoftware.de>
[-- Attachment #1: Type: text/plain, Size: 468 bytes --]
On Sun, 2009-10-11 at 13:18 +0200, Tilman Schmidt wrote:
> Can you explain a bit more what that message is about?
> I am encountering it in a completely different context
> (PPP over ISDN) and I would like to know where to start
> looking for the cause and developing a fix. The thread
> on linux.kernel.wireless.general only seems to address
> the specific situation in the wireless stack.
Basically, calling netif_rx() with softirqs enabled.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: NOHZ: local_softirq_pending 08
From: Dave Young @ 2009-10-11 10:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-kernel, tglx, linux-wireless, David S. Miller
In-Reply-To: <1255255735.4095.53.camel@johannes.local>
On Sun, Oct 11, 2009 at 6:08 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Sun, 2009-10-11 at 17:52 +0800, Dave Young wrote:
>
>> With kernel 2.6.32-rc3-00052-g0eca52a I got following KERN_ERR
>> messages just while using firefox:
>>
>> [ 130.527399] NOHZ: local_softirq_pending 08
>
>> Any idea? or known issue?
>
> Are you using b43 (or wl12x1)? If so, it's a known issue, but the driver
> was recently left without an active maintainer in a brouhaha about a bug
> fix.
Yes, I'm using b43. I will test the patch you posted in another thread.
>
> Cf. http://thread.gmane.org/gmane.linux.kernel.wireless.general/39440
>
> Absent proof that mac80211 is safe to run with BHs enabled, the correct
> solution is disabling tasklets around the RX function, unlike all the
> proposed patches. However, Michael thinks it's such a bad solution that
> he has refused to implement it. So far, nobody has bothered to fix the
> drivers.
>
> FWIW, I believe the bug to be in b43 and wl12x1, and not as Michael
> thinks in the stack.
>
> johannes
>
>
--
Regards
dave
^ permalink raw reply
* Re: [PATCH] b43: fix ieee80211_rx() context
From: David Miller @ 2009-10-11 10:39 UTC (permalink / raw)
To: johannes; +Cc: linville, kalle.valo, hidave.darkstar, linux-wireless
In-Reply-To: <1255256361.4095.56.camel@johannes.local>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Sun, 11 Oct 2009 12:19:21 +0200
> Due to the way it interacts with the networking
> stack and other parts of mac80211, ieee80211_rx()
> must be called with disabled softirqs.
>
> Michael, the former maintainer of this driver,
> has refused to fix the problem this way instead
> proposing a much more invasive patch that could
> not even be proved correct wrt. locking inside
> mac80211. Regardless of that, he believes this
> to be a bug in mac80211, and has also publicly
> stated [1] that he does not care about this even
> though it is a regression introduced by his own
> patches.
>
> Since nobody else seems to be wanting to fix the
> problem, I'll just fix it for the benefit of the
> many users of this driver.
>
> [1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/39440/focus=40266
>
> Reported-by: Dave Young <hidave.darkstar@gmail.com>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: NOHZ: local_softirq_pending 08
From: David Miller @ 2009-10-11 10:38 UTC (permalink / raw)
To: mb; +Cc: johannes, hidave.darkstar, linux-kernel, tglx, linux-wireless
In-Reply-To: <200910111217.31883.mb@bu3sch.de>
From: Michael Buesch <mb@bu3sch.de>
Date: Sun, 11 Oct 2009 12:17:30 +0200
> On Sunday 11 October 2009 12:08:55 Johannes Berg wrote:
>> On Sun, 2009-10-11 at 17:52 +0800, Dave Young wrote:
>>
>> FWIW, I believe the bug to be in b43 and wl12x1, and not as Michael
>> thinks in the stack.
>
> If mac80211 requires BHs disabled, it should do this.
That's overhead, and %99 of drivers do not require it, and therefore
for %99 of drivers it's unnecessary overhead.
In general we avoid doing things like that. Instead, we put the
cost only where it's actually needed.
^ permalink raw reply
* Re: NOHZ: local_softirq_pending 08
From: Johannes Berg @ 2009-10-11 10:37 UTC (permalink / raw)
To: Michael Buesch
Cc: Dave Young, linux-kernel, tglx, linux-wireless, David S. Miller
In-Reply-To: <200910111217.31883.mb@bu3sch.de>
[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]
On Sun, 2009-10-11 at 12:17 +0200, Michael Buesch wrote:
> Ehm, no. That's not exactly true.
> We call the non-_irqsafe functions, which by definition are designed to
> run in non-irq (soft or hard) context. At least that's how I understand the
> documentation, last time I read it.
So maybe the documentation is not entirely accurate. Such happens. From
this and previous threads tt's pretty obvious that these functions
cannot be called with softirqs enabled. And I've also stated before that
I do not believe that we should call them with softirqs enabled without
auditing the code for locking, which historically has been a weak point
of mac80211.
> Why don't you simply do local_bh_disable() in those functions, if they
> require bh disabled, instead of depending on the driver doing it?
>
> > FWIW, I believe the bug to be in b43 and wl12x1, and not as Michael
> > thinks in the stack.
>
> If mac80211 requires BHs disabled, it should do this.
I don't believe adding that into mac80211, even though it nests, is a
good idea for the case of many drivers where mac80211 and/or the driver
knows. It's pretty damn trivial to add two lines of code to the driver,
instead of penalising every other driver. The typical kernel style is
making things provide the required context, not a function take any
possible context.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] iwmc3200top: Add Intel Wireless MultiCom 3200 top driver.
From: David Miller @ 2009-10-11 10:36 UTC (permalink / raw)
To: tomasw
Cc: linville, netdev, linux-wireless, linux-mmc, yi.zhu,
inaky.perez-gonzalez, cindy.h.kao, guy.cohen, ron.rindjunsky
In-Reply-To: <1ba2fa240910110105x33fb251ar3437dd5fee552735@mail.gmail.com>
From: Tomas Winkler <tomasw@gmail.com>
Date: Sun, 11 Oct 2009 10:05:20 +0200
> Just close my eyes and there is new game to play. :)
> It's not in the patchwork, so is there any reason you are not planning
> to add it. The patch intention was for net-next, it looks like
> I didn't mark it as such, my fault.
Because there still seems to be some confusion between which of these
bits go through John Linville as a wireless driver and which bits
go directly through me.
By default I assume John picks up "wireless" drivers and send them
to me in his wireless merges to me.
If that's not the case, explicitly do a fresh submission of this patch
and explicitly ask me to merge it.
^ permalink raw reply
* Re: [PATCH] b43: fix ieee80211_rx() context
From: Michael Buesch @ 2009-10-11 10:35 UTC (permalink / raw)
To: Johannes Berg
Cc: John Linville, David Miller, Kalle Valo, Dave Young,
linux-wireless
In-Reply-To: <1255257066.4095.66.camel@johannes.local>
On Sunday 11 October 2009 12:31:06 Johannes Berg wrote:
> On Sun, 2009-10-11 at 12:26 +0200, Michael Buesch wrote:
> > On Sunday 11 October 2009 12:19:21 Johannes Berg wrote:
> > > Due to the way it interacts with the networking
> > > stack and other parts of mac80211, ieee80211_rx()
> > > must be called with disabled softirqs.
> >
> > Is this stated in the documentation somewhere?
>
> No. However, there are many things that aren't in the documentation, I'm
> working on a patch to add a note.
Ok, thanks a lot.
> I just wanted to provide a
> rationale for me fixing this bug instead of you.
Since when do we require that in commit messages?
> If you disagree that
> this is an accurate representation, I invite you to summarise the thread
> that caused this miserable situation of a known bug not being fixed for
> a very long time despite appropriate fixes being known in your own words
> for the commit message.
If you'd care _that_ much, you could have just reverted my commit.
Yes, I introduced the regression and I was unable to cook up a fix for it. So the logical
reaction to that would be to revert my commit.
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] b43: fix ieee80211_rx() context
From: Johannes Berg @ 2009-10-11 10:31 UTC (permalink / raw)
To: Michael Buesch
Cc: John Linville, David Miller, Kalle Valo, Dave Young,
linux-wireless
In-Reply-To: <200910111226.44778.mb@bu3sch.de>
[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]
On Sun, 2009-10-11 at 12:26 +0200, Michael Buesch wrote:
> On Sunday 11 October 2009 12:19:21 Johannes Berg wrote:
> > Due to the way it interacts with the networking
> > stack and other parts of mac80211, ieee80211_rx()
> > must be called with disabled softirqs.
>
> Is this stated in the documentation somewhere?
No. However, there are many things that aren't in the documentation, I'm
working on a patch to add a note.
> > Michael, the former maintainer of this driver,
> > has refused to fix the problem this way instead
> > proposing a much more invasive patch that could
> > not even be proved correct wrt. locking inside
> > mac80211. Regardless of that, he believes this
> > to be a bug in mac80211, and has also publicly
> > stated [1] that he does not care about this even
> > though it is a regression introduced by his own
> > patches.
>
> What if we leave slander out of the commit messages?
As far as I know, it is an accurate account of what happened in the
other thread, and as such is not slander. I just wanted to provide a
rationale for me fixing this bug instead of you. If you disagree that
this is an accurate representation, I invite you to summarise the thread
that caused this miserable situation of a known bug not being fixed for
a very long time despite appropriate fixes being known in your own words
for the commit message.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] b43: fix ieee80211_rx() context
From: Michael Buesch @ 2009-10-11 10:26 UTC (permalink / raw)
To: Johannes Berg
Cc: John Linville, David Miller, Kalle Valo, Dave Young,
linux-wireless
In-Reply-To: <1255256361.4095.56.camel@johannes.local>
On Sunday 11 October 2009 12:19:21 Johannes Berg wrote:
> Due to the way it interacts with the networking
> stack and other parts of mac80211, ieee80211_rx()
> must be called with disabled softirqs.
Is this stated in the documentation somewhere?
> Michael, the former maintainer of this driver,
> has refused to fix the problem this way instead
> proposing a much more invasive patch that could
> not even be proved correct wrt. locking inside
> mac80211. Regardless of that, he believes this
> to be a bug in mac80211, and has also publicly
> stated [1] that he does not care about this even
> though it is a regression introduced by his own
> patches.
What if we leave slander out of the commit messages?
> Since nobody else seems to be wanting to fix the
> problem, I'll just fix it for the benefit of the
> many users of this driver.
>
> [1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/39440/focus=40266
>
> Reported-by: Dave Young <hidave.darkstar@gmail.com>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> drivers/net/wireless/b43/xmit.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> --- wireless-testing.orig/drivers/net/wireless/b43/xmit.c 2009-10-11 12:11:50.000000000 +0200
> +++ wireless-testing/drivers/net/wireless/b43/xmit.c 2009-10-11 12:12:06.000000000 +0200
> @@ -690,7 +690,10 @@ void b43_rx(struct b43_wldev *dev, struc
> }
>
> memcpy(IEEE80211_SKB_RXCB(skb), &status, sizeof(status));
> +
> + local_bh_disable();
> ieee80211_rx(dev->wl->hw, skb);
> + local_bh_enable();
>
> #if B43_DEBUG
> dev->rx_count++;
--
Greetings, Michael.
^ permalink raw reply
* [PATCH] b43: fix ieee80211_rx() context
From: Johannes Berg @ 2009-10-11 10:19 UTC (permalink / raw)
To: John Linville; +Cc: David Miller, Kalle Valo, Dave Young, linux-wireless
Due to the way it interacts with the networking
stack and other parts of mac80211, ieee80211_rx()
must be called with disabled softirqs.
Michael, the former maintainer of this driver,
has refused to fix the problem this way instead
proposing a much more invasive patch that could
not even be proved correct wrt. locking inside
mac80211. Regardless of that, he believes this
to be a bug in mac80211, and has also publicly
stated [1] that he does not care about this even
though it is a regression introduced by his own
patches.
Since nobody else seems to be wanting to fix the
problem, I'll just fix it for the benefit of the
many users of this driver.
[1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/39440/focus=40266
Reported-by: Dave Young <hidave.darkstar@gmail.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
drivers/net/wireless/b43/xmit.c | 3 +++
1 file changed, 3 insertions(+)
--- wireless-testing.orig/drivers/net/wireless/b43/xmit.c 2009-10-11 12:11:50.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/xmit.c 2009-10-11 12:12:06.000000000 +0200
@@ -690,7 +690,10 @@ void b43_rx(struct b43_wldev *dev, struc
}
memcpy(IEEE80211_SKB_RXCB(skb), &status, sizeof(status));
+
+ local_bh_disable();
ieee80211_rx(dev->wl->hw, skb);
+ local_bh_enable();
#if B43_DEBUG
dev->rx_count++;
^ permalink raw reply
* Re: NOHZ: local_softirq_pending 08
From: Michael Buesch @ 2009-10-11 10:17 UTC (permalink / raw)
To: Johannes Berg
Cc: Dave Young, linux-kernel, tglx, linux-wireless, David S. Miller
In-Reply-To: <1255255735.4095.53.camel@johannes.local>
On Sunday 11 October 2009 12:08:55 Johannes Berg wrote:
> On Sun, 2009-10-11 at 17:52 +0800, Dave Young wrote:
>
> > With kernel 2.6.32-rc3-00052-g0eca52a I got following KERN_ERR
> > messages just while using firefox:
> >
> > [ 130.527399] NOHZ: local_softirq_pending 08
>
> > Any idea? or known issue?
>
> Are you using b43 (or wl12x1)? If so, it's a known issue, but the driver
> was recently left without an active maintainer in a brouhaha about a bug
> fix.
>
> Cf. http://thread.gmane.org/gmane.linux.kernel.wireless.general/39440
>
> Absent proof that mac80211 is safe to run with BHs enabled, the correct
> solution is disabling tasklets around the RX function, unlike all the
> proposed patches. However, Michael thinks it's such a bad solution that
> he has refused to implement it.
Ehm, no. That's not exactly true.
We call the non-_irqsafe functions, which by definition are designed to
run in non-irq (soft or hard) context. At least that's how I understand the
documentation, last time I read it.
Why don't you simply do local_bh_disable() in those functions, if they
require bh disabled, instead of depending on the driver doing it?
> FWIW, I believe the bug to be in b43 and wl12x1, and not as Michael
> thinks in the stack.
If mac80211 requires BHs disabled, it should do this.
--
Greetings, Michael.
^ permalink raw reply
* Re: NOHZ: local_softirq_pending 08
From: Johannes Berg @ 2009-10-11 10:08 UTC (permalink / raw)
To: Dave Young; +Cc: linux-kernel, tglx, linux-wireless, David S. Miller
In-Reply-To: <20091011095217.GA2200@darkstar>
[-- Attachment #1: Type: text/plain, Size: 881 bytes --]
On Sun, 2009-10-11 at 17:52 +0800, Dave Young wrote:
> With kernel 2.6.32-rc3-00052-g0eca52a I got following KERN_ERR
> messages just while using firefox:
>
> [ 130.527399] NOHZ: local_softirq_pending 08
> Any idea? or known issue?
Are you using b43 (or wl12x1)? If so, it's a known issue, but the driver
was recently left without an active maintainer in a brouhaha about a bug
fix.
Cf. http://thread.gmane.org/gmane.linux.kernel.wireless.general/39440
Absent proof that mac80211 is safe to run with BHs enabled, the correct
solution is disabling tasklets around the RX function, unlike all the
proposed patches. However, Michael thinks it's such a bad solution that
he has refused to implement it. So far, nobody has bothered to fix the
drivers.
FWIW, I believe the bug to be in b43 and wl12x1, and not as Michael
thinks in the stack.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [mmotm 2009-10-09-01-07] b43/wireless possible circular locking
From: Johannes Berg @ 2009-10-11 9:51 UTC (permalink / raw)
To: Dave Young; +Cc: akpm, bcm43xx-dev, linux-wireless, linux-kernel
In-Reply-To: <20091011094139.GA2778@darkstar>
[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]
On Sun, 2009-10-11 at 17:41 +0800, Dave Young wrote:
> Hi,
>
> I got lockdep warnings about possible circular lock with
> b43 interface startup. It looks like a real problem.
>
> [ 71.974542] wlan0: deauthenticating from 00:19:e0:db:24:de by local choice (reason=3)
> [ 72.004352] b43-phy0 debug: Removing Interface type 2
> [ 72.005431]
> [ 72.005435] =======================================================
> [ 72.006168] [ INFO: possible circular locking dependency detected ]
> [ 72.006759] 2.6.32-rc3-mm1 #4
> [ 72.007047] -------------------------------------------------------
> [ 72.007617] ifconfig/2175 is trying to acquire lock:
> [ 72.007617] (&(&rfkill->poll_work)->work){+.+...}, at: [<c0239375>] __cancel_work_timer+0x8c/0x18e
> [ 72.007617]
> [ 72.007617] but task is already holding lock:
> [ 72.007617] (&wl->mutex){+.+.+.}, at: [<f8fa5359>] b43_op_stop+0x28/0x6a [b43]
I believe this is already taken care of by Larry.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] mac80211: fix ibss race
From: Johannes Berg @ 2009-10-11 9:47 UTC (permalink / raw)
To: John Linville; +Cc: Felix Fietkau, linux-wireless
When a scan completes, we call ieee80211_sta_find_ibss(),
which is also called from other places. When the scan was
done in software, there's no problem as both run from the
single-threaded mac80211 workqueue and are thus serialised
against each other, but with hardware scan the completion
can be in a different context and race against callers of
this function from the workqueue (e.g. due to beacon RX).
So instead of calling ieee80211_sta_find_ibss() directly,
just arm the timer and have it fire, scheduling the work,
which will invoke ieee80211_sta_find_ibss() (if that is
appropriate in the current state).
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/ibss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- wireless-testing.orig/net/mac80211/ibss.c 2009-10-02 10:41:44.000000000 +0200
+++ wireless-testing/net/mac80211/ibss.c 2009-10-06 14:57:27.000000000 +0200
@@ -831,7 +831,7 @@ void ieee80211_ibss_notify_scan_complete
if (!sdata->u.ibss.ssid_len)
continue;
sdata->u.ibss.last_scan_completed = jiffies;
- ieee80211_sta_find_ibss(sdata);
+ mod_timer(&sdata->u.ibss.timer, 0);
}
mutex_unlock(&local->iflist_mtx);
}
^ permalink raw reply
* Re: [PATCH] mac80211: fix logic error ibss merge bssid check
From: Johannes Berg @ 2009-10-11 9:43 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, John W. Linville
In-Reply-To: <4AD14F26.6030304@openwrt.org>
[-- Attachment #1: Type: text/plain, Size: 623 bytes --]
On Sun, 2009-10-11 at 05:21 +0200, Felix Fietkau wrote:
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>
> --- a/net/mac80211/ibss.c
> +++ b/net/mac80211/ibss.c
> @@ -544,7 +544,7 @@ static void ieee80211_sta_find_ibss(stru
> "%pM\n", bss->cbss.bssid, ifibss->bssid);
> #endif /* CONFIG_MAC80211_IBSS_DEBUG */
>
> - if (bss && memcmp(ifibss->bssid, bss->cbss.bssid, ETH_ALEN)) {
> + if (bss && !memcmp(ifibss->bssid, bss->cbss.bssid, ETH_ALEN)) {
Acked-by: Johannes Berg <johannes@sipsolutions.net>
I'll also send the race fix now, would appreciate you giving it a try.
Thanks,
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [mmotm 2009-10-09-01-07] b43/wireless possible circular locking
From: Dave Young @ 2009-10-11 9:41 UTC (permalink / raw)
To: akpm; +Cc: bcm43xx-dev, linux-wireless, linux-kernel
Hi,
I got lockdep warnings about possible circular lock with
b43 interface startup. It looks like a real problem.
[ 71.974542] wlan0: deauthenticating from 00:19:e0:db:24:de by local choice (reason=3)
[ 72.004352] b43-phy0 debug: Removing Interface type 2
[ 72.005431]
[ 72.005435] =======================================================
[ 72.006168] [ INFO: possible circular locking dependency detected ]
[ 72.006759] 2.6.32-rc3-mm1 #4
[ 72.007047] -------------------------------------------------------
[ 72.007617] ifconfig/2175 is trying to acquire lock:
[ 72.007617] (&(&rfkill->poll_work)->work){+.+...}, at: [<c0239375>] __cancel_work_timer+0x8c/0x18e
[ 72.007617]
[ 72.007617] but task is already holding lock:
[ 72.007617] (&wl->mutex){+.+.+.}, at: [<f8fa5359>] b43_op_stop+0x28/0x6a [b43]
[ 72.007617]
[ 72.007617] which lock already depends on the new lock.
[ 72.007617]
[ 72.007617]
[ 72.007617] the existing dependency chain (in reverse order) is:
[ 72.007617]
[ 72.007617] -> #1 (&wl->mutex){+.+.+.}:
[ 72.007617] [<c024b251>] __lock_acquire+0x9e2/0xb73
[ 72.007617] [<c024b449>] lock_acquire+0x67/0x84
[ 72.007617] [<c055854d>] __mutex_lock_common+0x35/0x2ca
[ 72.007617] [<c0558880>] mutex_lock_nested+0x30/0x38
[ 72.007617] [<f8fb9bcd>] b43_rfkill_poll+0x26/0xc9 [b43]
[ 72.007617] [<f8f8330e>] ieee80211_rfkill_poll+0x1f/0x21 [mac80211]
[ 72.007617] [<f8396011>] cfg80211_rfkill_poll+0x11/0x13 [cfg80211]
[ 72.007617] [<f826b740>] rfkill_poll+0x14/0x2a [rfkill]
[ 72.007617] [<c0239927>] worker_thread+0x13b/0x1ff
[ 72.007617] [<c023be0c>] kthread+0x58/0x5d
[ 72.007617] [<c0203d07>] kernel_thread_helper+0x7/0x10
[ 72.007617]
[ 72.007617] -> #0 (&(&rfkill->poll_work)->work){+.+...}:
[ 72.007617] [<c024b15c>] __lock_acquire+0x8ed/0xb73
[ 72.007617] [<c024b449>] lock_acquire+0x67/0x84
[ 72.007617] [<c02393a2>] __cancel_work_timer+0xb9/0x18e
[ 72.007617] [<c0239482>] cancel_delayed_work_sync+0xb/0xd
[ 72.007617] [<f826b71b>] rfkill_pause_polling+0x20/0x22 [rfkill]
[ 72.007617] [<f8396328>] wiphy_rfkill_stop_polling+0x10/0x12 [cfg80211]
[ 72.007617] [<f8fa5361>] b43_op_stop+0x30/0x6a [b43]
[ 72.007617] [<f8f895af>] ieee80211_stop_device+0x20/0x53 [mac80211]
[ 72.007617] [<f8f8141d>] ieee80211_stop+0x3d3/0x452 [mac80211]
[ 72.007617] [<c04e0c47>] dev_close+0x74/0x90
[ 72.007617] [<c04e082c>] dev_change_flags+0x96/0x144
[ 72.007617] [<c05262fd>] devinet_ioctl+0x212/0x468
[ 72.007617] [<c052814d>] inet_ioctl+0x8e/0xa7
[ 72.007617] [<c04d3e16>] sock_ioctl+0x1d3/0x1f7
[ 72.007617] [<c02a6b49>] vfs_ioctl+0x22/0x67
[ 72.007617] [<c02a707d>] do_vfs_ioctl+0x45f/0x493
[ 72.007617] [<c02a70f1>] sys_ioctl+0x40/0x5a
[ 72.007617] [<c020325d>] syscall_call+0x7/0xb
[ 72.007617]
[ 72.007617] other info that might help us debug this:
[ 72.007617]
[ 72.007617] 2 locks held by ifconfig/2175:
[ 72.007617] #0: (rtnl_mutex){+.+.+.}, at: [<c04e8b90>] rtnl_lock+0xf/0x11
[ 72.007617] #1: (&wl->mutex){+.+.+.}, at: [<f8fa5359>] b43_op_stop+0x28/0x6a [b43]
[ 72.007617]
[ 72.007617] stack backtrace:
[ 72.007617] Pid: 2175, comm: ifconfig Not tainted 2.6.32-rc3-mm1 #4
[ 72.007617] Call Trace:
[ 72.007617] [<c024a863>] print_circular_bug+0x8a/0x96
[ 72.007617] [<c024b15c>] __lock_acquire+0x8ed/0xb73
[ 72.007617] [<c024b449>] lock_acquire+0x67/0x84
[ 72.007617] [<c0239375>] ? __cancel_work_timer+0x8c/0x18e
[ 72.007617] [<c02393a2>] __cancel_work_timer+0xb9/0x18e
[ 72.007617] [<c0239375>] ? __cancel_work_timer+0x8c/0x18e
[ 72.007617] [<c05587c8>] ? __mutex_lock_common+0x2b0/0x2ca
[ 72.007617] [<c0248233>] ? debug_mutex_free_waiter+0x45/0x48
[ 72.007617] [<c05587d8>] ? __mutex_lock_common+0x2c0/0x2ca
[ 72.007617] [<c0239482>] cancel_delayed_work_sync+0xb/0xd
[ 72.007617] [<f826b71b>] rfkill_pause_polling+0x20/0x22 [rfkill]
[ 72.007617] [<f8396328>] wiphy_rfkill_stop_polling+0x10/0x12 [cfg80211]
[ 72.007617] [<f8fa5361>] b43_op_stop+0x30/0x6a [b43]
[ 72.007617] [<f8f895af>] ieee80211_stop_device+0x20/0x53 [mac80211]
[ 72.007617] [<f8f8141d>] ieee80211_stop+0x3d3/0x452 [mac80211]
[ 72.007617] [<c0249d42>] ? trace_hardirqs_on+0xb/0xd
[ 72.007617] [<c022fd77>] ? _local_bh_enable_ip+0x9d/0xa6
[ 72.007617] [<c022fd88>] ? local_bh_enable_ip+0x8/0xa
[ 72.007617] [<c05592a8>] ? _spin_unlock_bh+0x25/0x28
[ 72.007617] [<c04e0c47>] dev_close+0x74/0x90
[ 72.007617] [<c04e082c>] dev_change_flags+0x96/0x144
[ 72.007617] [<c05262fd>] devinet_ioctl+0x212/0x468
[ 72.007617] [<c052814d>] inet_ioctl+0x8e/0xa7
[ 72.007617] [<c04d3e16>] sock_ioctl+0x1d3/0x1f7
[ 72.007617] [<c04d3c43>] ? sock_ioctl+0x0/0x1f7
[ 72.007617] [<c02a6b49>] vfs_ioctl+0x22/0x67
[ 72.007617] [<c02a707d>] do_vfs_ioctl+0x45f/0x493
[ 72.007617] [<c0221652>] ? need_resched+0x14/0x1e
[ 72.007617] [<c0557e29>] ? schedule+0x6ed/0x6fd
[ 72.007617] [<c055b24e>] ? do_page_fault+0x29d/0x2a5
[ 72.007617] [<c02a70f1>] sys_ioctl+0x40/0x5a
[ 72.007617] [<c020325d>] syscall_call+0x7/0xb
[ 73.122930] b43-phy0 debug: Wireless interface stopped
[ 73.131557] ifconfig used greatest stack depth: 5660 bytes left
[ 73.310494] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
[ 73.329042] b43-phy0 debug: b2062: Using crystal tab entry 19200 kHz.
[ 77.923855] b43-phy0 debug: Chip initialized
[ 77.924695] b43-phy0 debug: PIO initialized
[ 77.925410] b43-phy0 debug: QoS enabled
[ 77.941415] b43-phy0 debug: Wireless interface started
[ 77.942164] b43-phy0 debug: Adding Interface type 2
[ 77.961969] wlan0: direct probe to AP 00:19:e0:db:24:de (try 1)
[ 78.160198] wlan0: direct probe to AP 00:19:e0:db:24:de (try 2)
[ 78.164241] wlan0: direct probe responded
[ 78.164649] wlan0: authenticate with AP 00:19:e0:db:24:de (try 1)
[ 78.167341] wlan0: authenticated
[ 78.167791] wlan0: associate with AP 00:19:e0:db:24:de (try 1)
[ 78.170935] wlan0: RX ReassocResp from 00:19:e0:db:24:de (capab=0x421 status=0 aid=4)
[ 78.171690] wlan0: associated
--
Regards
dave
^ permalink raw reply
* Re: [PATCH 1/3] iwmc3200top: Add Intel Wireless MultiCom 3200 top driver.
From: Tomas Winkler @ 2009-10-11 8:05 UTC (permalink / raw)
To: David Miller
Cc: linville, netdev, linux-wireless, linux-mmc, yi.zhu,
inaky.perez-gonzalez, cindy.h.kao, guy.cohen, ron.rindjunsky
In-Reply-To: <20091010.185852.133969433.davem@davemloft.net>
On Sun, Oct 11, 2009 at 3:58 AM, David Miller <davem@davemloft.net> wrote:
> From: Tomas Winkler <tomasw@gmail.com>
> Date: Sat, 10 Oct 2009 11:38:50 +0200
>
>> On Wed, Sep 23, 2009 at 1:38 AM, Tomas Winkler <tomas.winkler@intel.com> wrote:
>>> This patch adds Intel Wireless MultiCom 3200 top driver.
>>> IWMC3200 is 4Wireless Com CHIP (GPS/BT/WiFi/WiMAX).
>>> Top driver is responsible for device initialization and firmware download.
>>> Firmware handled by top is responsible for top itself and
>>> as well as bluetooth and GPS coms. (Wifi and WiMax provide their own
>>> firmware)
>>> In addition top driver is used to retrieve firmware logs
>>> and supports other debugging features
>>>
>>> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
>>
>> Dave,
>> are you going to merge this one?
>> iwmc3200wifi and i200m-sdio which are already merged are usless without it
>
> If it's not in netdev patchwork, I don't plan to add it.
>
> If it is in patchwork, then it's in my backlog and I'll get to it.
>
> People should never really have to ask me these questions, that's one
> of the main points of:
>
> http://patchwork.ozlabs.org/project/netdev/list/
>
> You can always see there what's "pending".
Just close my eyes and there is new game to play. :)
It's not in the patchwork, so is there any reason you are not planning
to add it. The patch intention was for net-next, it looks like
I didn't mark it as such, my fault.
My primary concern is that the driver lies under misc directory so
it's not clear it should be in netdev.
This chip has 4 coms, with drivers under wireless, wimax, serial,
bluetooth. and misc. Eech of them
handled by different mailing list and sub tree. The major problem is
the top driver as other 4 comps depends
on it so I'm looking for place to refer to. Please if you have no
intention to handle it or have more concern please let me know.
Thanks
Tomas
^ permalink raw reply
* Re: [PATCH 1/3] iwmc3200top: Add Intel Wireless MultiCom 3200 top driver.
From: Eric Dumazet @ 2009-10-11 7:40 UTC (permalink / raw)
To: David Miller
Cc: tomasw, linville, netdev, linux-wireless, linux-mmc, yi.zhu,
inaky.perez-gonzalez, cindy.h.kao, guy.cohen, ron.rindjunsky,
tomas.winkler, Joe Perches
In-Reply-To: <20091010.185852.133969433.davem@davemloft.net>
David Miller a écrit :
>
> If it's not in netdev patchwork, I don't plan to add it.
>
> If it is in patchwork, then it's in my backlog and I'll get to it.
>
> People should never really have to ask me these questions, that's one
> of the main points of:
>
> http://patchwork.ozlabs.org/project/netdev/list/
>
> You can always see there what's "pending".
Me wondering if this information could be put in MAINTAINERS or Documentation/ something...
I know it only because I caught one of your answer a while ago :)
Either a per project info, or a global ref to http://patchwork.ozlabs.org/
diff --git a/MAINTAINERS b/MAINTAINERS
index e1da925..18244ad 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3654,6 +3654,7 @@ NETWORKING [GENERAL]
M: "David S. Miller" <davem@davemloft.net>
L: netdev@vger.kernel.org
W: http://www.linuxfoundation.org/en/Net
+W: http://patchwork.ozlabs.org/project/netdev/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
S: Maintained
F: net/
^ permalink raw reply related
* [PATCH] mac80211: fix logic error ibss merge bssid check
From: Felix Fietkau @ 2009-10-11 3:21 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, John W. Linville
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -544,7 +544,7 @@ static void ieee80211_sta_find_ibss(stru
"%pM\n", bss->cbss.bssid, ifibss->bssid);
#endif /* CONFIG_MAC80211_IBSS_DEBUG */
- if (bss && memcmp(ifibss->bssid, bss->cbss.bssid, ETH_ALEN)) {
+ if (bss && !memcmp(ifibss->bssid, bss->cbss.bssid, ETH_ALEN)) {
printk(KERN_DEBUG "%s: Selected IBSS BSSID %pM"
" based on configured SSID\n",
sdata->dev->name, bss->cbss.bssid);
^ permalink raw reply
* Re: [PATCH 1/3] iwmc3200top: Add Intel Wireless MultiCom 3200 top driver.
From: David Miller @ 2009-10-11 1:59 UTC (permalink / raw)
To: tomasw
Cc: marcel, linville, netdev, linux-wireless, linux-mmc, yi.zhu,
inaky.perez-gonzalez, cindy.h.kao, guy.cohen, ron.rindjunsky
In-Reply-To: <1ba2fa240910101105y77171591j32e6759f28556566@mail.gmail.com>
PLEASE!
Don't quote all of a big huge driver patch like that. Just quote the
parts you want to comment on!
Thank you.
^ permalink raw reply
* Re: [PATCH 1/3] iwmc3200top: Add Intel Wireless MultiCom 3200 top driver.
From: David Miller @ 2009-10-11 1:58 UTC (permalink / raw)
To: tomasw
Cc: linville, netdev, linux-wireless, linux-mmc, yi.zhu,
inaky.perez-gonzalez, cindy.h.kao, guy.cohen, ron.rindjunsky,
tomas.winkler
In-Reply-To: <1ba2fa240910100238s709c31d3s6cb612f502b1086f@mail.gmail.com>
From: Tomas Winkler <tomasw@gmail.com>
Date: Sat, 10 Oct 2009 11:38:50 +0200
> On Wed, Sep 23, 2009 at 1:38 AM, Tomas Winkler <tomas.winkler@intel.com> wrote:
>> This patch adds Intel Wireless MultiCom 3200 top driver.
>> IWMC3200 is 4Wireless Com CHIP (GPS/BT/WiFi/WiMAX).
>> Top driver is responsible for device initialization and firmware download.
>> Firmware handled by top is responsible for top itself and
>> as well as bluetooth and GPS coms. (Wifi and WiMax provide their own
>> firmware)
>> In addition top driver is used to retrieve firmware logs
>> and supports other debugging features
>>
>> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
>
> Dave,
> are you going to merge this one?
> iwmc3200wifi and i200m-sdio which are already merged are usless without it
If it's not in netdev patchwork, I don't plan to add it.
If it is in patchwork, then it's in my backlog and I'll get to it.
People should never really have to ask me these questions, that's one
of the main points of:
http://patchwork.ozlabs.org/project/netdev/list/
You can always see there what's "pending".
^ permalink raw reply
* Re: BUG? I can reproduce "Association request to the driver failed" at will
From: Johannes Berg @ 2009-10-10 18:40 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless, hostap
In-Reply-To: <200909211309.40476.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 2636 bytes --]
Sorry to warm this up ...
> 1253527140.795498: State: COMPLETED -> AUTHENTICATING
> 1253527140.795515: EAPOL: External notification - EAP success=0
> 1253527140.795530: EAPOL: External notification - EAP fail=0
> 1253527140.795542: EAPOL: External notification - portControl=Auto
> 1253527140.795559: nl80211: Authenticate (ifindex=34)
> 1253527140.795572: * bssid=00:13:19:80:da:30
> 1253527140.795587: * freq=2412
> 1253527140.795598: * SSID - hexdump_ascii(len=5):
> 4d 4e 57 50 41 MNWPA
> 1253527140.795630: * IEs - hexdump(len=0): [NULL]
> 1253527140.795643: * Auth Type 0
> 1253527140.795683: nl80211: Authentication request send successfully
> 1253527140.795707: RTM_NEWLINK: operstate=1 ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP])
> 1253527140.795725: RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added
> 1253527140.953161: nl80211: Event message available
> 1253527140.953200: nl80211: MLME event 37
> 1253527140.953216: SME: Authentication response: peer=00:13:19:80:da:30 auth_type=0 status_code=0
> 1253527140.953243: Trying to associate with 00:13:19:80:da:30 (SSID='MNWPA' freq=2412 MHz)
> 1253527140.953257: State: AUTHENTICATING -> ASSOCIATING
> 1253527140.953270: wpa_driver_nl80211_set_operstate: operstate 1->0 (DORMANT)
> 1253527140.953284: nl80211: Operstate: linkmode=-1, operstate=5
> 1253527140.953901: nl80211: Associate (ifindex=34)
> 1253527140.953919: * bssid=00:13:19:80:da:30
> 1253527140.953934: * freq=2412
> 1253527140.953945: * SSID - hexdump_ascii(len=5):
> 4d 4e 57 50 41 MNWPA
> 1253527140.953977: * IEs - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02
> 1253527140.954064: nl80211: MLME command failed: ret=-114 (Operation already in progress)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 1253527140.954086: Association request to the driver failed
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 1253527140.954113: RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> 1253527140.954131: RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added
>
>
> The "Association request to the driver failed" will
> be shown even without "-d". Also note that the association
> seems to actually work, e.g. I can ping throught the
> connection.
Could this be related to the problem Maxim has been seeing? I'm not sure
how else this could happen since you seem to auth but then assoc doesn't
work, but I can't see how that could possibly happen.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox