Re: another must-fix: major PS/2 mouse problem
Albert Cahalan <[email protected]>
| Newsgroups | gmane.linux.kernel,gmane.linux.drivers.vortex.devel |
|---|---|
| Message-ID | <1059447325.3862.86.camel@cube> |
On Sat, 2003-07-26 at 11:16, Zwane Mwaikambo wrote: > On Fri, 25 Jul 2003, Andrew Morton wrote: > > > But did your instrumentation account for nested interrupts? What happens > > if a slow i8042 interrupt happens in the middle of a 3c59x interrupt? > > Just to verify that, he could remove the local_irq_enable for > !SA_INTERRUPT. OK, I did this. Now, in microseconds, I get: ------------------------ IRQ use min max --- -------- --- ------- 0 timer 40 103968 1 i8042 14 1138 (was 389773) 2 cascade - - 3 - - - 4 serial 29 56 5 uhci-hcd - - 6 - 690 690 7 - 40 40 8 - - - 9 - - - 10 - - - 11 eth0 73 31332 (was 1535331) 12 i8042 18 215 (was 102895) 13 - - - 14 ide0 7 43846 15 ide1 7 12 ------------------------ boomerang_interrupt itself takes 4 to 59 microseconds. Then I switched to 2.6.0-test2. Testing more, I get the problem with or without SMP and with or without preemption. Here's a chunk of my log file: Loosing too many ticks! TSC cannot be used as a timesource. (Are you running with SpeedStep?) Falling back to a sane timesource. psmouse.c: Lost synchronization, throwing 3 bytes away. psmouse.c: Lost synchronization, throwing 1 bytes away. Arrrrgh! The TSC is my only good time source! Remember that this is a pretty normal system. I have a Red Hat 8 install w/ required upgrades, ext3, IDE, a 1-GHz Pentium III, a boring VIA chipset, etc. To reproduce, I do some PS/2 mouse movement while doing one of: a. Lots of concurrent write() and sync() activity to ext3. b. Lots of NFSv3 traffic.