Peter Osterlund wrote:
Larry Finger [EMAIL PROTECTED] writes:
Peter - does the interface work for a while, or does this transmit
timeout happen immediately?
It works perfectly for a few hours, then it stops working. Stressing
the network doesn't seem to make a difference. The only
On Tuesday 05 September 2006 15:18, Larry Finger wrote:
Emanuele Giaquinta wrote:
Raising BADNESS_LIMIT to 20 bcm43xx_voluntary_preempt produces a lot of
bcm43xx: ASSERTION FAILED (!in_atomic() !in_irq() !in_interrupt()
!irqs_disabled()) at:
Michael Buesch wrote:
Simple: increasing badness limit makes the whole periodic work
non-preemptible. And we all know what happens if we call
schedule() in non-preemptible code (we hold the IRQ spinlock).
This assert() was added to prevent incorrect BADNESS_LIMIT tunings ;)
I wonder
On Monday 04 September 2006 05:09, Larry Finger wrote:
Emanuele Giaquinta wrote:
I can confirm the very same behaviour using a bcm4306 on linux-2.6.18-rc4
with the bcm43xx patches queued for 2.6.19 applied; when a hard reset
occurs ksoftirqd begins using 100% CPU indefinitely, and in one
Michael Buesch [EMAIL PROTECTED] writes:
On Monday 04 September 2006 05:09, Larry Finger wrote:
Emanuele Giaquinta wrote:
I can confirm the very same behaviour using a bcm4306 on linux-2.6.18-rc4
with the bcm43xx patches queued for 2.6.19 applied; when a hard reset
occurs ksoftirqd
Peter Osterlund wrote:
Michael Buesch [EMAIL PROTECTED] writes:
On Monday 04 September 2006 05:09, Larry Finger wrote:
This sounds as if there may be a deadlock when a restart occurs. Do you
have the lock debugging
options set in your configuration? I used to get the NETDEV WATCHDOG
On Monday 04 September 2006 21:55, Peter Osterlund wrote:
Michael Buesch [EMAIL PROTECTED] writes:
On Monday 04 September 2006 05:09, Larry Finger wrote:
Emanuele Giaquinta wrote:
I can confirm the very same behaviour using a bcm4306 on
linux-2.6.18-rc4
with the bcm43xx
Peter Osterlund wrote:
Larry Finger [EMAIL PROTECTED] writes:
Peter - does the interface work for a while, or does this transmit
timeout happen immediately?
It works perfectly for a few hours, then it stops working. Stressing
the network doesn't seem to make a difference. The only
Peter Osterlund wrote:
Peter Osterlund [EMAIL PROTECTED] writes:
Michael Buesch [EMAIL PROTECTED] writes:
On Friday 04 August 2006 01:31, Peter Osterlund wrote:
Ivan Matveich [EMAIL PROTECTED] writes:
[interface works fine for a few hours, then this spontaneously
Emanuele Giaquinta wrote:
I can confirm the very same behaviour using a bcm4306 on linux-2.6.18-rc4
with the bcm43xx patches queued for 2.6.19 applied; when a hard reset
occurs ksoftirqd begins using 100% CPU indefinitely, and in one case the
controller restart failed:
NETDEV WATCHDOG:
On Friday 04 August 2006 01:31, Peter Osterlund wrote:
Ivan Matveich [EMAIL PROTECTED] writes:
[interface works fine for a few hours, then this spontaneously happens]
[note: the computer does nothing but compile stuff, etc during this time]
NETDEV WATCHDOG: wireless: transmit timed out
Peter Osterlund [EMAIL PROTECTED] writes:
Michael Buesch [EMAIL PROTECTED] writes:
On Friday 04 August 2006 01:31, Peter Osterlund wrote:
Ivan Matveich [EMAIL PROTECTED] writes:
[interface works fine for a few hours, then this spontaneously happens]
[note: the computer does
Ivan Matveich [EMAIL PROTECTED] writes:
[interface works fine for a few hours, then this spontaneously happens]
[note: the computer does nothing but compile stuff, etc during this time]
NETDEV WATCHDOG: wireless: transmit timed out
bcm43xx: Controller RESET (TX timeout) ...
bcm43xx:
13 matches
Mail list logo
