* d80211: ieee80211_hw handlers in atomic context
@ 2006-10-04 15:59 Jan Kiszka
2006-10-04 16:07 ` Ivo van Doorn
2006-10-04 16:11 ` Jiri Benc
0 siblings, 2 replies; 18+ messages in thread
From: Jan Kiszka @ 2006-10-04 15:59 UTC (permalink / raw)
To: Jiri Benc; +Cc: netdev, Ivo Van Doorn
Hello Jiri,
Ivo suggested to bring this issue to a broader audience, specifically to
the stack maintainer.
Trying to run my Asus WL167G with rt2500usb I faced the following:
BUG: scheduling while atomic: swapper/0x00000102/0
<c0103055> show_trace+0x12/0x14
<c01035e0> dump_stack+0x1c/0x1e
<c025fad1> schedule+0x5f/0x652
<c0260324> wait_for_completion+0xb8/0x134
<d0988fa1> usb_start_wait_urb+0x89/0xcb [usbcore]
<d0989192> usb_control_msg+0xb2/0xcc [usbcore]
<d089d127> rt2x00_vendor_request+0x85/0xbb [rt2500usb]
<d08a1350> rt2500usb_config+0x5e/0x3d7 [rt2500usb]
<d0823496> ieee80211_hw_config+0x2c/0x93 [80211]
<d0829950> ieee80211_ioctl_siwfreq+0x132/0x141 [80211]
<d082ee8b> ieee80211_sta_join_ibss+0xcc/0x5af [80211]
<d082f698> ieee80211_sta_find_ibss+0x32a/0x374 [80211]
<d08317f8> ieee80211_sta_timer+0x81/0x1b4 [80211]
<c011ac50> run_timer_softirq+0x171/0x205
<c0117536> __do_softirq+0x41/0x90
<c01175bc> do_softirq+0x37/0x4a
<c01176b7> irq_exit+0x2d/0x45
<c0104316> do_IRQ+0x53/0x5f
The reason is the invocation of rt2500usb's config handler in atomic
context (timer handler). But this service requires schedulable context
to submit and wait for some URBs.
That raises the question how to resolve the conflict best, at stack
level by pushing such work into thread context (workqueues?) or at
driver level by deferring these requests (if feasible at all without
breaking the stack's timing)? What other callback handlers in
ieee80211_hw can currently be called in atomic context? Given that all
USB WLAN adapters will have to cope with this issue in some way, it may
be wise to find a common solution.
Ivo told me about a patch for d80211 that moved certain timers to thread
context, effectively avoiding to call config from timer handlers, but I
didn't find any trace yet. Is there some modification in this direction
already scheduled? I'm not necessarily looking for work, at best I would
just enjoy to use it. ;)
Jan
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: d80211: ieee80211_hw handlers in atomic context
2006-10-04 15:59 d80211: ieee80211_hw handlers in atomic context Jan Kiszka
@ 2006-10-04 16:07 ` Ivo van Doorn
2006-10-04 16:31 ` Jan Kiszka
2006-10-04 16:11 ` Jiri Benc
1 sibling, 1 reply; 18+ messages in thread
From: Ivo van Doorn @ 2006-10-04 16:07 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Jiri Benc, netdev
Hi,
> Ivo told me about a patch for d80211 that moved certain timers to thread
> context, effectively avoiding to call config from timer handlers, but I
> didn't find any trace yet. Is there some modification in this direction
> already scheduled? I'm not necessarily looking for work, at best I would
> just enjoy to use it. ;)
I have found the actual patch:
[PATCH 1/5] d80211: make sleeping in hw->config possible
And was send on august 1st by Jiri to the netdev list.
It was based on a patch by Michael Buesch.
Ivo
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: d80211: ieee80211_hw handlers in atomic context
2006-10-04 15:59 d80211: ieee80211_hw handlers in atomic context Jan Kiszka
2006-10-04 16:07 ` Ivo van Doorn
@ 2006-10-04 16:11 ` Jiri Benc
1 sibling, 0 replies; 18+ messages in thread
From: Jiri Benc @ 2006-10-04 16:11 UTC (permalink / raw)
To: Jan Kiszka; +Cc: netdev, Ivo Van Doorn
On Wed, 04 Oct 2006 17:59:57 +0200, Jan Kiszka wrote:
> The reason is the invocation of rt2500usb's config handler in atomic
> context (timer handler). But this service requires schedulable context
> to submit and wait for some URBs.
Hm, I thought it had been fixed
(http://kernel.org/git/?p=linux/kernel/git/linville/wireless-dev.git;a=commit;h=d0d2b7a8ddc378ddea499f1537f6aea83d96d003).
We'll need to make something similar with sta_timer.
> That raises the question how to resolve the conflict best, at stack
> level by pushing such work into thread context (workqueues?) or at
> driver level by deferring these requests (if feasible at all without
> breaking the stack's timing)? What other callback handlers in
> ieee80211_hw can currently be called in atomic context? Given that all
> USB WLAN adapters will have to cope with this issue in some way, it may
> be wise to find a common solution.
It needs to be solved in the stack. ieee80211_hw->config callback should
return proper error code in a case of problems and this is not possible
when the work is deferred in the driver.
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: d80211: ieee80211_hw handlers in atomic context
2006-10-04 16:07 ` Ivo van Doorn
@ 2006-10-04 16:31 ` Jan Kiszka
2006-10-04 16:34 ` Ivo van Doorn
0 siblings, 1 reply; 18+ messages in thread
From: Jan Kiszka @ 2006-10-04 16:31 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Jiri Benc, netdev
Ivo van Doorn wrote:
> Hi,
>
>> Ivo told me about a patch for d80211 that moved certain timers to thread
>> context, effectively avoiding to call config from timer handlers, but I
>> didn't find any trace yet. Is there some modification in this direction
>> already scheduled? I'm not necessarily looking for work, at best I would
>> just enjoy to use it. ;)
>
> I have found the actual patch:
> [PATCH 1/5] d80211: make sleeping in hw->config possible
> And was send on august 1st by Jiri to the netdev list.
> It was based on a patch by Michael Buesch.
Ah, looks like I didn't dug thoroughly enough.
Anyway, this means my BUG proved the patch's claim wrong :o), at least
one atomic gremlin is left:
ieee80211_sta_timer ->
ieee80211_sta_find_ibss ->
ieee80211_sta_join_ibss ->
ieee80211_ioctl_siwfreq ->
ieee80211_hw_config
Anyone already an idea how to fix it?
Jan
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: d80211: ieee80211_hw handlers in atomic context
2006-10-04 16:31 ` Jan Kiszka
@ 2006-10-04 16:34 ` Ivo van Doorn
2006-10-04 16:38 ` Jiri Benc
0 siblings, 1 reply; 18+ messages in thread
From: Ivo van Doorn @ 2006-10-04 16:34 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Jiri Benc, netdev
On Wednesday 04 October 2006 18:31, Jan Kiszka wrote:
> Ivo van Doorn wrote:
> > Hi,
> >
> >> Ivo told me about a patch for d80211 that moved certain timers to thread
> >> context, effectively avoiding to call config from timer handlers, but I
> >> didn't find any trace yet. Is there some modification in this direction
> >> already scheduled? I'm not necessarily looking for work, at best I would
> >> just enjoy to use it. ;)
> >
> > I have found the actual patch:
> > [PATCH 1/5] d80211: make sleeping in hw->config possible
> > And was send on august 1st by Jiri to the netdev list.
> > It was based on a patch by Michael Buesch.
>
> Ah, looks like I didn't dug thoroughly enough.
>
> Anyway, this means my BUG proved the patch's claim wrong :o), at least
> one atomic gremlin is left:
>
> ieee80211_sta_timer ->
> ieee80211_sta_find_ibss ->
> ieee80211_sta_join_ibss ->
> ieee80211_ioctl_siwfreq ->
> ieee80211_hw_config
>
> Anyone already an idea how to fix it?
You could replace the timer with a workqueue, the original patch
also did that, so I think it would be good enough this time as well. :)
Ivo
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: d80211: ieee80211_hw handlers in atomic context
2006-10-04 16:34 ` Ivo van Doorn
@ 2006-10-04 16:38 ` Jiri Benc
2006-10-04 16:51 ` Jan Kiszka
0 siblings, 1 reply; 18+ messages in thread
From: Jiri Benc @ 2006-10-04 16:38 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Jan Kiszka, netdev
On Wed, 4 Oct 2006 18:34:57 +0200, Ivo van Doorn wrote:
> You could replace the timer with a workqueue, the original patch
> also did that, so I think it would be good enough this time as well. :)
Yes, the timing isn't required to be precise here.
Jiri
--
Jiri Benc
SUSE Labs
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: d80211: ieee80211_hw handlers in atomic context
2006-10-04 16:38 ` Jiri Benc
@ 2006-10-04 16:51 ` Jan Kiszka
2006-10-04 17:22 ` Ivo van Doorn
2006-10-05 11:29 ` Jiri Benc
0 siblings, 2 replies; 18+ messages in thread
From: Jan Kiszka @ 2006-10-04 16:51 UTC (permalink / raw)
To: Jiri Benc; +Cc: Ivo van Doorn, netdev
Jiri Benc wrote:
> On Wed, 4 Oct 2006 18:34:57 +0200, Ivo van Doorn wrote:
>> You could replace the timer with a workqueue, the original patch
>> also did that, so I think it would be good enough this time as well. :)
>
> Yes, the timing isn't required to be precise here.
Ok, I'm not promising success and I'm going to duck immediately if
someone else feels like working on it, but I could try to patch in this
direction.
Now there just remains my precautious question if there are other
services in the ieee_80211_hw interface that may conflict with sleeping
USB drivers. What about specifying the possible contexts in
include/net/d80211.h?
Jan
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: d80211: ieee80211_hw handlers in atomic context
2006-10-04 16:51 ` Jan Kiszka
@ 2006-10-04 17:22 ` Ivo van Doorn
2006-10-05 11:37 ` Jiri Benc
2006-10-05 11:29 ` Jiri Benc
1 sibling, 1 reply; 18+ messages in thread
From: Ivo van Doorn @ 2006-10-04 17:22 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Jiri Benc, netdev
Hi,
> > On Wed, 4 Oct 2006 18:34:57 +0200, Ivo van Doorn wrote:
> >> You could replace the timer with a workqueue, the original patch
> >> also did that, so I think it would be good enough this time as well. :)
> >
> > Yes, the timing isn't required to be precise here.
>
> Ok, I'm not promising success and I'm going to duck immediately if
> someone else feels like working on it, but I could try to patch in this
> direction.
If you need testing of the patch for a slightly larger audience,
you can send it to me and I'll place it in the rt2x00 CVS tree which contains
a copy of the current dscape stack for backwards compatibility with older kernels.
> Now there just remains my precautious question if there are other
> services in the ieee_80211_hw interface that may conflict with sleeping
> USB drivers. What about specifying the possible contexts in
> include/net/d80211.h?
Well another point of concern for me is the TSF handling, those handlers are called
from interrupt context as well, and also deliver problems for the USB drivers in case
of adhoc mode.
Ivo
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: d80211: ieee80211_hw handlers in atomic context
2006-10-04 16:51 ` Jan Kiszka
2006-10-04 17:22 ` Ivo van Doorn
@ 2006-10-05 11:29 ` Jiri Benc
2006-10-05 14:52 ` Ivo van Doorn
1 sibling, 1 reply; 18+ messages in thread
From: Jiri Benc @ 2006-10-05 11:29 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Ivo van Doorn, netdev
On Wed, 04 Oct 2006 18:51:40 +0200, Jan Kiszka wrote:
> Ok, I'm not promising success and I'm going to duck immediately if
> someone else feels like working on it, but I could try to patch in this
> direction.
Your patches are welcomed!
> Now there just remains my precautious question if there are other
> services in the ieee_80211_hw interface that may conflict with sleeping
> USB drivers. What about specifying the possible contexts in
> include/net/d80211.h?
Yes, that makes sense. Feel free to send a patch :-)
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: d80211: ieee80211_hw handlers in atomic context
2006-10-04 17:22 ` Ivo van Doorn
@ 2006-10-05 11:37 ` Jiri Benc
2006-10-05 15:00 ` Ivo van Doorn
0 siblings, 1 reply; 18+ messages in thread
From: Jiri Benc @ 2006-10-05 11:37 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Jan Kiszka, netdev
On Wed, 4 Oct 2006 19:22:38 +0200, Ivo van Doorn wrote:
> Well another point of concern for me is the TSF handling, those handlers are called
> from interrupt context as well, and also deliver problems for the USB drivers in case
> of adhoc mode.
Where is a problem with tsf handlers? get_tsf is not called at all
(unless CONFIG_D80211_IBSS_DEBUG is set; well, that raises a question
why the function exists in the first place), reset_tsf returns void.
Jiri
--
Jiri Benc
SUSE Labs
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: d80211: ieee80211_hw handlers in atomic context
2006-10-05 11:29 ` Jiri Benc
@ 2006-10-05 14:52 ` Ivo van Doorn
0 siblings, 0 replies; 18+ messages in thread
From: Ivo van Doorn @ 2006-10-05 14:52 UTC (permalink / raw)
To: Jiri Benc; +Cc: Jan Kiszka, netdev
On Thursday 05 October 2006 13:29, Jiri Benc wrote:
> On Wed, 04 Oct 2006 18:51:40 +0200, Jan Kiszka wrote:
> > Ok, I'm not promising success and I'm going to duck immediately if
> > someone else feels like working on it, but I could try to patch in this
> > direction.
>
> Your patches are welcomed!
>
> > Now there just remains my precautious question if there are other
> > services in the ieee_80211_hw interface that may conflict with sleeping
> > USB drivers. What about specifying the possible contexts in
> > include/net/d80211.h?
>
> Yes, that makes sense. Feel free to send a patch :-)
The patch is currently in testing in the rt2x00 tree.
So it will be shortly send to the netdev list. :)
Ivo
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: d80211: ieee80211_hw handlers in atomic context
2006-10-05 11:37 ` Jiri Benc
@ 2006-10-05 15:00 ` Ivo van Doorn
2006-10-05 15:13 ` Jan Kiszka
2006-10-05 15:13 ` Jiri Benc
0 siblings, 2 replies; 18+ messages in thread
From: Ivo van Doorn @ 2006-10-05 15:00 UTC (permalink / raw)
To: Jiri Benc; +Cc: Jan Kiszka, netdev
On Thursday 05 October 2006 13:37, Jiri Benc wrote:
> On Wed, 4 Oct 2006 19:22:38 +0200, Ivo van Doorn wrote:
> > Well another point of concern for me is the TSF handling, those handlers are called
> > from interrupt context as well, and also deliver problems for the USB drivers in case
> > of adhoc mode.
>
> Where is a problem with tsf handlers? get_tsf is not called at all
> (unless CONFIG_D80211_IBSS_DEBUG is set; well, that raises a question
> why the function exists in the first place), reset_tsf returns void.
Basically it comes down to this:
Sep 13 12:27:34 wz4a kernel: wlan0: Creating new IBSS network, BSSID 7a:b9:60:8a:84:39
Sep 13 12:27:34 wz4a kernel: BUG: scheduling while atomic: swapper/0x00000100/0
Sep 13 12:27:34 wz4a kernel: <b02701e7> schedule+0x43/0xa84 <b01ef8b8> extract_buf+0x97/0xc8
Sep 13 12:27:34 wz4a kernel: <b0270ca8> wait_for_completion+0x6a/0x9f <b0116f2d> default_wake_function+0x0/0xc
Sep 13 12:27:34 wz4a kernel: <c08ac59f> usb_start_wait_urb+0x98/0xdc [usbcore] <c08ac418> timeout_kill+0x0/0x5 [usbcore]
Sep 13 12:27:34 wz4a kernel: <c08ac7d5> usb_control_msg+0xc3/0xde [usbcore] <c0b6c0f1> rt2x00_vendor_request+0x7c/0xa6 [rt73usb]
Sep 13 12:27:34 wz4a kernel: <c0b6fa68> rt73usb_reset_tsf+0x30/0x59 [rt73usb] <c0bdb3e8> ieee80211_sta_join_ibss+0x3a/0x572 [80211]
Sep 13 12:27:34 wz4a kernel: <b011cea9> printk+0x14/0x18 <c0bdaa4a> ieee80211_rx_bss_add+0x88/0x90 [80211]
Sep 13 12:27:34 wz4a kernel: <c0bdbc2e> ieee80211_sta_find_ibss+0x30e/0x366 [80211] <c0bdda17> ieee80211_sta_timer+0x0/0x18f [80211]
Sep 13 12:27:34 wz4a kernel: <c0bdda91> ieee80211_sta_timer+0x7a/0x18f [80211] <c0bdda17> ieee80211_sta_timer+0x0/0x18f [80211]
Sep 13 12:27:34 wz4a kernel: <b01241b1> run_timer_softirq+0x10b/0x153 <b0120a52> __do_softirq+0x58/0xc2
Sep 13 12:27:34 wz4a kernel: <b0120aea> do_softirq+0x2e/0x32 <b0104fe6> do_IRQ+0x1e/0x24
Sep 13 12:27:34 wz4a kernel: <b0103592> common_interrupt+0x1a/0x20 <c0827484> acpi_processor_idle+0x18a/0x39e [processor]
Sep 13 12:27:34 wz4a kernel: <b0101e77> cpu_idle+0x8f/0xa8 <b03026d2> start_kernel+0x355/0x35c
With the compilation of d80211 the CONFIG_D80211_DEBUG is set by default,
so no CONFIG_D80211_IBSS_DEBUG.
This does not happen in rt2500usb driver, since no TSF handling is possible
due to a lack of TSF registers in the device.
Ivo
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: d80211: ieee80211_hw handlers in atomic context
2006-10-05 15:00 ` Ivo van Doorn
@ 2006-10-05 15:13 ` Jan Kiszka
2006-10-05 15:32 ` Ivo van Doorn
2006-10-05 15:13 ` Jiri Benc
1 sibling, 1 reply; 18+ messages in thread
From: Jan Kiszka @ 2006-10-05 15:13 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Jiri Benc, netdev
[-- Attachment #1: Type: text/plain, Size: 2755 bytes --]
Ivo van Doorn wrote:
> On Thursday 05 October 2006 13:37, Jiri Benc wrote:
>> On Wed, 4 Oct 2006 19:22:38 +0200, Ivo van Doorn wrote:
>>> Well another point of concern for me is the TSF handling, those handlers are called
>>> from interrupt context as well, and also deliver problems for the USB drivers in case
>>> of adhoc mode.
>> Where is a problem with tsf handlers? get_tsf is not called at all
>> (unless CONFIG_D80211_IBSS_DEBUG is set; well, that raises a question
>> why the function exists in the first place), reset_tsf returns void.
>
> Basically it comes down to this:
>
> Sep 13 12:27:34 wz4a kernel: wlan0: Creating new IBSS network, BSSID 7a:b9:60:8a:84:39
> Sep 13 12:27:34 wz4a kernel: BUG: scheduling while atomic: swapper/0x00000100/0
> Sep 13 12:27:34 wz4a kernel: <b02701e7> schedule+0x43/0xa84 <b01ef8b8> extract_buf+0x97/0xc8
> Sep 13 12:27:34 wz4a kernel: <b0270ca8> wait_for_completion+0x6a/0x9f <b0116f2d> default_wake_function+0x0/0xc
> Sep 13 12:27:34 wz4a kernel: <c08ac59f> usb_start_wait_urb+0x98/0xdc [usbcore] <c08ac418> timeout_kill+0x0/0x5 [usbcore]
> Sep 13 12:27:34 wz4a kernel: <c08ac7d5> usb_control_msg+0xc3/0xde [usbcore] <c0b6c0f1> rt2x00_vendor_request+0x7c/0xa6 [rt73usb]
> Sep 13 12:27:34 wz4a kernel: <c0b6fa68> rt73usb_reset_tsf+0x30/0x59 [rt73usb] <c0bdb3e8> ieee80211_sta_join_ibss+0x3a/0x572 [80211]
> Sep 13 12:27:34 wz4a kernel: <b011cea9> printk+0x14/0x18 <c0bdaa4a> ieee80211_rx_bss_add+0x88/0x90 [80211]
> Sep 13 12:27:34 wz4a kernel: <c0bdbc2e> ieee80211_sta_find_ibss+0x30e/0x366 [80211] <c0bdda17> ieee80211_sta_timer+0x0/0x18f [80211]
> Sep 13 12:27:34 wz4a kernel: <c0bdda91> ieee80211_sta_timer+0x7a/0x18f [80211] <c0bdda17> ieee80211_sta_timer+0x0/0x18f [80211]
> Sep 13 12:27:34 wz4a kernel: <b01241b1> run_timer_softirq+0x10b/0x153 <b0120a52> __do_softirq+0x58/0xc2
> Sep 13 12:27:34 wz4a kernel: <b0120aea> do_softirq+0x2e/0x32 <b0104fe6> do_IRQ+0x1e/0x24
> Sep 13 12:27:34 wz4a kernel: <b0103592> common_interrupt+0x1a/0x20 <c0827484> acpi_processor_idle+0x18a/0x39e [processor]
> Sep 13 12:27:34 wz4a kernel: <b0101e77> cpu_idle+0x8f/0xa8 <b03026d2> start_kernel+0x355/0x35c
>
> With the compilation of d80211 the CONFIG_D80211_DEBUG is set by default,
> so no CONFIG_D80211_IBSS_DEBUG.
>
> This does not happen in rt2500usb driver, since no TSF handling is possible
> due to a lack of TSF registers in the device.
This path would be fixed by my conversion patch of sta.timer into
sta.work that I sent you yesterday privately. Unfortunately, I don't
have a copy at hand ATM.
What about the other timers? Can they trigger any sleeping service of
rt2x00 drivers? Ok, waiting for a BUG is always possible... ;)
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: d80211: ieee80211_hw handlers in atomic context
2006-10-05 15:00 ` Ivo van Doorn
2006-10-05 15:13 ` Jan Kiszka
@ 2006-10-05 15:13 ` Jiri Benc
2006-10-05 15:35 ` Ivo van Doorn
1 sibling, 1 reply; 18+ messages in thread
From: Jiri Benc @ 2006-10-05 15:13 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Jan Kiszka, netdev
On Thu, 5 Oct 2006 17:00:31 +0200, Ivo van Doorn wrote:
> Basically it comes down to this:
>
> Sep 13 12:27:34 wz4a kernel: wlan0: Creating new IBSS network, BSSID 7a:b9:60:8a:84:39
> Sep 13 12:27:34 wz4a kernel: BUG: scheduling while atomic: swapper/0x00000100/0
> Sep 13 12:27:34 wz4a kernel: <b02701e7> schedule+0x43/0xa84 <b01ef8b8> extract_buf+0x97/0xc8
> Sep 13 12:27:34 wz4a kernel: <b0270ca8> wait_for_completion+0x6a/0x9f <b0116f2d> default_wake_function+0x0/0xc
> Sep 13 12:27:34 wz4a kernel: <c08ac59f> usb_start_wait_urb+0x98/0xdc [usbcore] <c08ac418> timeout_kill+0x0/0x5 [usbcore]
> Sep 13 12:27:34 wz4a kernel: <c08ac7d5> usb_control_msg+0xc3/0xde [usbcore] <c0b6c0f1> rt2x00_vendor_request+0x7c/0xa6 [rt73usb]
> Sep 13 12:27:34 wz4a kernel: <c0b6fa68> rt73usb_reset_tsf+0x30/0x59 [rt73usb] <c0bdb3e8> ieee80211_sta_join_ibss+0x3a/0x572 [80211]
> Sep 13 12:27:34 wz4a kernel: <b011cea9> printk+0x14/0x18 <c0bdaa4a> ieee80211_rx_bss_add+0x88/0x90 [80211]
> Sep 13 12:27:34 wz4a kernel: <c0bdbc2e> ieee80211_sta_find_ibss+0x30e/0x366 [80211] <c0bdda17> ieee80211_sta_timer+0x0/0x18f [80211]
> Sep 13 12:27:34 wz4a kernel: <c0bdda91> ieee80211_sta_timer+0x7a/0x18f [80211] <c0bdda17> ieee80211_sta_timer+0x0/0x18f [80211]
> Sep 13 12:27:34 wz4a kernel: <b01241b1> run_timer_softirq+0x10b/0x153 <b0120a52> __do_softirq+0x58/0xc2
> Sep 13 12:27:34 wz4a kernel: <b0120aea> do_softirq+0x2e/0x32 <b0104fe6> do_IRQ+0x1e/0x24
> Sep 13 12:27:34 wz4a kernel: <b0103592> common_interrupt+0x1a/0x20 <c0827484> acpi_processor_idle+0x18a/0x39e [processor]
> Sep 13 12:27:34 wz4a kernel: <b0101e77> cpu_idle+0x8f/0xa8 <b03026d2> start_kernel+0x355/0x35c
So this will be solved for free when sta_timer is converted to a
workqueue.
Jiri
--
Jiri Benc
SUSE Labs
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: d80211: ieee80211_hw handlers in atomic context
2006-10-05 15:13 ` Jan Kiszka
@ 2006-10-05 15:32 ` Ivo van Doorn
2006-10-05 15:39 ` Jiri Benc
0 siblings, 1 reply; 18+ messages in thread
From: Ivo van Doorn @ 2006-10-05 15:32 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Jiri Benc, netdev
Hi,
> > This does not happen in rt2500usb driver, since no TSF handling is possible
> > due to a lack of TSF registers in the device.
>
> This path would be fixed by my conversion patch of sta.timer into
> sta.work that I sent you yesterday privately. Unfortunately, I don't
> have a copy at hand ATM.
That is what I expect as well, I'll ask confirmation from the person who submitted this bug.
> What about the other timers? Can they trigger any sleeping service of
> rt2x00 drivers? Ok, waiting for a BUG is always possible... ;)
Well I currently have no time to check it, but can
config_interface handler still be called from interrupt context or has this also been fixed?
Ivo
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: d80211: ieee80211_hw handlers in atomic context
2006-10-05 15:13 ` Jiri Benc
@ 2006-10-05 15:35 ` Ivo van Doorn
0 siblings, 0 replies; 18+ messages in thread
From: Ivo van Doorn @ 2006-10-05 15:35 UTC (permalink / raw)
To: Jiri Benc; +Cc: Jan Kiszka, netdev
On Thursday 05 October 2006 17:13, Jiri Benc wrote:
> On Thu, 5 Oct 2006 17:00:31 +0200, Ivo van Doorn wrote:
> > Basically it comes down to this:
> >
> > Sep 13 12:27:34 wz4a kernel: wlan0: Creating new IBSS network, BSSID 7a:b9:60:8a:84:39
> > Sep 13 12:27:34 wz4a kernel: BUG: scheduling while atomic: swapper/0x00000100/0
> > Sep 13 12:27:34 wz4a kernel: <b02701e7> schedule+0x43/0xa84 <b01ef8b8> extract_buf+0x97/0xc8
> > Sep 13 12:27:34 wz4a kernel: <b0270ca8> wait_for_completion+0x6a/0x9f <b0116f2d> default_wake_function+0x0/0xc
> > Sep 13 12:27:34 wz4a kernel: <c08ac59f> usb_start_wait_urb+0x98/0xdc [usbcore] <c08ac418> timeout_kill+0x0/0x5 [usbcore]
> > Sep 13 12:27:34 wz4a kernel: <c08ac7d5> usb_control_msg+0xc3/0xde [usbcore] <c0b6c0f1> rt2x00_vendor_request+0x7c/0xa6 [rt73usb]
> > Sep 13 12:27:34 wz4a kernel: <c0b6fa68> rt73usb_reset_tsf+0x30/0x59 [rt73usb] <c0bdb3e8> ieee80211_sta_join_ibss+0x3a/0x572 [80211]
> > Sep 13 12:27:34 wz4a kernel: <b011cea9> printk+0x14/0x18 <c0bdaa4a> ieee80211_rx_bss_add+0x88/0x90 [80211]
> > Sep 13 12:27:34 wz4a kernel: <c0bdbc2e> ieee80211_sta_find_ibss+0x30e/0x366 [80211] <c0bdda17> ieee80211_sta_timer+0x0/0x18f [80211]
> > Sep 13 12:27:34 wz4a kernel: <c0bdda91> ieee80211_sta_timer+0x7a/0x18f [80211] <c0bdda17> ieee80211_sta_timer+0x0/0x18f [80211]
> > Sep 13 12:27:34 wz4a kernel: <b01241b1> run_timer_softirq+0x10b/0x153 <b0120a52> __do_softirq+0x58/0xc2
> > Sep 13 12:27:34 wz4a kernel: <b0120aea> do_softirq+0x2e/0x32 <b0104fe6> do_IRQ+0x1e/0x24
> > Sep 13 12:27:34 wz4a kernel: <b0103592> common_interrupt+0x1a/0x20 <c0827484> acpi_processor_idle+0x18a/0x39e [processor]
> > Sep 13 12:27:34 wz4a kernel: <b0101e77> cpu_idle+0x8f/0xa8 <b03026d2> start_kernel+0x355/0x35c
>
> So this will be solved for free when sta_timer is converted to a
> workqueue.
Hi,
True, this is what I realized later as well. :)
I have asked for confirmation by the bug submitter.
Ivo
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: d80211: ieee80211_hw handlers in atomic context
2006-10-05 15:32 ` Ivo van Doorn
@ 2006-10-05 15:39 ` Jiri Benc
2006-10-05 15:39 ` Ivo van Doorn
0 siblings, 1 reply; 18+ messages in thread
From: Jiri Benc @ 2006-10-05 15:39 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Jan Kiszka, netdev
On Thu, 5 Oct 2006 17:32:39 +0200, Ivo van Doorn wrote:
> Well I currently have no time to check it, but can
> config_interface handler still be called from interrupt context or has this also been fixed?
Will be fixed by the sta_timer conversion as well.
Jiri
--
Jiri Benc
SUSE Labs
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: d80211: ieee80211_hw handlers in atomic context
2006-10-05 15:39 ` Jiri Benc
@ 2006-10-05 15:39 ` Ivo van Doorn
0 siblings, 0 replies; 18+ messages in thread
From: Ivo van Doorn @ 2006-10-05 15:39 UTC (permalink / raw)
To: Jiri Benc; +Cc: Jan Kiszka, netdev
On Thursday 05 October 2006 17:39, Jiri Benc wrote:
> On Thu, 5 Oct 2006 17:32:39 +0200, Ivo van Doorn wrote:
> > Well I currently have no time to check it, but can
> > config_interface handler still be called from interrupt context or has this also been fixed?
>
> Will be fixed by the sta_timer conversion as well.
Excellent news. :D
Thanks.
Ivo
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2006-10-05 15:40 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-10-04 15:59 d80211: ieee80211_hw handlers in atomic context Jan Kiszka
2006-10-04 16:07 ` Ivo van Doorn
2006-10-04 16:31 ` Jan Kiszka
2006-10-04 16:34 ` Ivo van Doorn
2006-10-04 16:38 ` Jiri Benc
2006-10-04 16:51 ` Jan Kiszka
2006-10-04 17:22 ` Ivo van Doorn
2006-10-05 11:37 ` Jiri Benc
2006-10-05 15:00 ` Ivo van Doorn
2006-10-05 15:13 ` Jan Kiszka
2006-10-05 15:32 ` Ivo van Doorn
2006-10-05 15:39 ` Jiri Benc
2006-10-05 15:39 ` Ivo van Doorn
2006-10-05 15:13 ` Jiri Benc
2006-10-05 15:35 ` Ivo van Doorn
2006-10-05 11:29 ` Jiri Benc
2006-10-05 14:52 ` Ivo van Doorn
2006-10-04 16:11 ` Jiri Benc
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).