I am running Ubuntu Karmic, so I originally reported this as https://bugs.launchpad.net/ubuntu/+source/linux/+bug/334957 I believe this to be a kernel bug and therefore I tried with the Ubuntu-supplied and unpatched mainline kernels (https://wiki.ubuntu.com/KernelTeam/MainlineBuilds) yesterday to make sure this isn't self-inflicted pain. I chose the kernel from the daily build. The effects where the same. So much for the intro, on to the problem. Most of the time I have a wired internet connection, but recently I'm using WLAN a lot and I stumbled on the following. I have a Zonet ZCF1100 802.11b wifi card in the compact flash slot of my Thinkpad X24. The connection is wpa-protected. When WLAN is under heavy load (100KB/sec and more), the mouse pointer starts to drift to the left. Once the load drops, the drifting seems to stop. The drift happens irrespective of whether I have a USB mouse connected or I'm using the internal IBM nipple. It seems that for one reason or another my setup generates a lot of interrupts. It was speculated that may be part of the problem. I've already seen drift today. But so far, IRQ 11 had 0 interrupts. $ uptime 15:56:26 up 1:22, 2 users, load average: 0.15, 0.19, 0.26 $ cat /proc/interrupts CPU0 0: 1127001 XT-PIC-XT timer 1: 11302 XT-PIC-XT i8042 2: 0 XT-PIC-XT cascade 3: 78888 XT-PIC-XT pcmcia1.0 4: 8 XT-PIC-XT 5: 3 XT-PIC-XT 6: 0 XT-PIC-XT uhci_hcd:usb2, uhci_hcd:usb3 7: 0 XT-PIC-XT parport0 8: 0 XT-PIC-XT rtc0 9: 10467 XT-PIC-XT acpi, eth3 10: 88 XT-PIC-XT yenta, Intel 82801CA-ICH3 11: 0 XT-PIC-XT uhci_hcd:usb1, yenta 12: 78759 XT-PIC-XT i8042 14: 126871 XT-PIC-XT ata_piix 15: 0 XT-PIC-XT ata_piix NMI: 0 Non-maskable interrupts LOC: 0 Local timer interrupts SPU: 0 Spurious interrupts CNT: 0 Performance counter interrupts PND: 0 Performance pending work RES: 0 Rescheduling interrupts CAL: 0 Function call interrupts TLB: 0 TLB shootdowns ERR: 0 MIS: 0 I have attached a lot of information to the ticket in Launchpad in the hope that somebody with the right knowledge can pinpoint the problem. So far, I can't. I'm of course happy to supply any necessary information. Thank you for your work.
my wifi connection is wlan2, but there is also a wifi0 interface. The latter does not have an IP associated with it. And frankly, I'm not sure where it comes from and what it's supposed to do. Both wifi0 and wlan2 do disappear when I pull the CF card out of its socket. dmesg has a lot of lines of the form [ 5918.062172] Virtual device wifi0 asks to queue packet!
Out of curiousity, can you revert 5ae4efbcd2611562a8b93596be034e63495706a5 and see if that changes anything?
John, thank you for your comment. I'll compile a kernel later today and see how that goes. FWIW, March does coincide with the time I first experienced this. But I believe, I've also seen this with hardy which would make that commit an unlikely candidate in case this is a regression. I'll let you know about the results. Another observation I made. It seems that both high throughput and low signal strength exacerbate the issue. IOW, it's more likely and will have a stronger effect when the wifi bandwidth to the AP is saturated or close to it.
My compilations weren't so successful, most of the time the compilation would just fail. And if it didn't, there was some other problem with the kernel like it not driving the Zonet Wifi card at all for some reason. Eventually, I gave up compiling but resorted to another solution. Ubuntu mainline kernel go back to February, the commit was made in March. I verified that the effect exists in vmlinuz-2.6.28-02062808-generic and vmlinuz-2.6.27-02062714-generic as well. Both were compiled before 5ae4efbcd2611562a8b93596be034e63495706a5 was committed. If that commit has anything to do with it, there'd have to be at least one other piece to the puzzle. I downloaded the kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline.
It did feel like the effect was not as strong with the two old kernels. But that could be highly subjective and the speed of the drift depends on a lot of factors, it seems.
Hmmm...this is an old one. Does the problem persist with current (i.e. 2.6.33 or later) kernels?
Closing due to lack of response...