Bug 8553

Summary:	bcm43xx driver causes touchpad instability and system freezes
Product:	Drivers	Reporter:	Ben Collins (bcollins)
Component:	network-wireless	Assignee:	drivers_network-wireless (drivers_network-wireless)
Status:	REJECTED INSUFFICIENT_DATA
Severity:	normal	CC:	aleander, Larry.Finger, mb
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.22-rc2	Subsystem:
Regression:	---	Bisected commit-id:

Description Ben Collins 2007-05-30 09:02:32 UTC

Most recent kernel where this bug did *NOT* occur: None
Distribution: Ubuntu Dapper thru Gutsy (2.6.15 -> 2.6.22)
Hardware Environment: Lenovo 3000 N100 laptop w/bcm 4310
Software Environment: N/A
Problem Description:

Seems high interrupt latency caused by bcm43xx driver causes irqs shared with
bcm43xx to miss and hang.

Steps to reproduce: Use bcm43xx with touchpad on mentioned hardware. Probably
reproducible with any driver sharing interrupts with bcm43xx.

Comment 1 Ben Collins 2007-05-30 09:04:20 UTC

Original bug report (with lots of details): https://launchpad.net/bugs/63919

Comment 2 Larry Finger 2007-08-28 11:27:14 UTC

I just added a Q&D debugfs file to see how long the bcm43xx interrupt routine takes. On an x86_64 dual-processor system with 1.66 GHz processors and a 1000 Hz system clock, the maximum jiffies used in the interrupt routine is 1, which I think means the routine takes less than 2 ms. This latency shouldn't interfere with a touchpad, even for a slower processor. For those interrupts on the shared IRQ and not caused by bcm43xx, the return is much quicker.

Which driver is used by that touchpad?

Comment 3 Michael Buesch 2007-08-28 12:13:51 UTC

It might have latency issues in the IRQ tasklet handler, as we call into softmac without deferring it. So the call is synchronous and the softmac work runs while IRQs are disabled on the device and the CPU.
If that's the case, though, nobody is going to fix it, as softmac will likely die in 2.6.24-rc.

Larry, please make also sure your jiffies counting thing works. Althoguh you are running on SMP, someone might block the timer IRQ while we are executing in the bcm43xx IRQ handler with local IRQs disabled. Some systems glue IRQs to the first CPU to do some cache optimization.
So simply add a huge mdelay() and see if your measured values increase correctly.

Comment 4 Larry Finger 2007-08-28 12:59:35 UTC

I did have a bug someplace. I switched to using do_gettimeofday to get more precision on the interval. After running for about 30 minutes, the maximum interval on my SMP system has increased from 8018 to 8030 usecs in several steps. I think it is working, and that the worst-case interval on that interrupt routine is about 8 msec.

Comment 5 John W. Linville 2007-09-05 06:50:15 UTC

Any chance this can be replicated with the current b43 and/or b43legacy drivers?

Comment 6 John W. Linville 2007-10-30 13:32:37 UTC

Ping?  Is this still a problem?

Comment 7 Aleksander Kamil Modzelewski 2007-11-14 04:26:30 UTC

Umh, original reporter here, and in *Ubuntu* kernel it is still a problem. But that would be 2.6.22-14, not 2.6.23-anything.