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
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
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!
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
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/0x0100/0
Sep 13 12:27:34 wz4a kernel:
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
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.
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
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
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
-
To
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/0x0102/0
c0103055 show_trace+0x12/0x14
c01035e0 dump_stack+0x1c/0x1e
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
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
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
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
-
To unsubscribe
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
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
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
18 matches
Mail list logo
