another must-fix: major PS/2 mouse problem
Lots of people (check Google) get this message from the kernel:
psmouse.c: Lost synchronization, throwing 2 bytes away.
(the number of bytes will be 1, 2, or 3)
At work, I get it when there is heavy NFS traffic. The mouse goes crazy, jumping around and doing random cut-and-paste all over everything. This is with a decently fast and modern PC.
I'll guess that NFS and the mouse both have worker threads fighting for CPU time, and neither is RT.
is there a patch for this bug ?
I have the same problem with my laptop, chip sis630, celeron 1.2Ghz, 256MB of RAM (32MB for video), mouse on PS/2 (ImPS/2) abd read mp3 throught nfs partition (ethernet 100MB). I haven't try without traffic on nfs but I will try next time I boot on the 2.5.70 (currently, I'm running a 2.4.20)
Yoann
Quoted 14 lines · Albert Cahalan
Lots of people (check Google) get this message from the kernel:
psmouse.c: Lost synchronization, throwing 2 bytes away.(the number of bytes will be 1, 2, or 3)
At work, I get it when there is heavy NFS traffic. The mouse goes crazy, jumping around and doing random cut-and-paste all over everything. This is with a decently fast and modern PC.
I'll guess that NFS and the mouse both have worker threads fighting for CPU time, and neither is RT.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 2 lines · Andrew Morton
We believe that it may be due to the ethernet driver holding interrupts off for too long when the traffic is heavy.
Note that this doesn't necessarily mean that the ethernet driver disables the interrupts for a too long time, it just means that the computer is only servicing the network interrupts at that time, and since the mouse interrupt does have a lower priority, it's serviced not very often and with huge delays.
In such a case the network driver should either use interrupt mitigation if the cards supports it (reading many packets per one interrupt) or switch to a polled mode.
Quoted 4 lines
Does that seem to match your observations? Does the problem happen when the net traffic is high?
Which ethernet driver are you using?
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Quoted 12 lines · Vojtech Pavlik
Quoted 2 lines · Andrew Morton
We believe that it may be due to the ethernet driver holding interrupts off for too long when the traffic is heavy.
Note that this doesn't necessarily mean that the ethernet driver disables the interrupts for a too long time, it just means that the computer is only servicing the network interrupts at that time, and since the mouse interrupt does have a lower priority, it's serviced not very often and with huge delays.
Quoted 3 lines
In such a case the network driver should either use interrupt mitigation if the cards supports it (reading many packets per one interrupt) or switch to a polled mode.
Has this problem been observed in 2.4 kernels?
Quoted 13 lines · Andrew Morton
Quoted 12 lines · Vojtech Pavlik
Quoted 2 lines · Andrew Morton
We believe that it may be due to the ethernet driver holding interrupts off for too long when the traffic is heavy.
Note that this doesn't necessarily mean that the ethernet driver disables the interrupts for a too long time, it just means that the computer is only servicing the network interrupts at that time, and since the mouse interrupt does have a lower priority, it's serviced not very often and with huge delays.
Quoted 5 lines
Quoted 3 lines
In such a case the network driver should either use interrupt mitigation if the cards supports it (reading many packets per one interrupt) or switch to a polled mode.
Has this problem been observed in 2.4 kernels?
No, since 2.4 doesn't have the re-sync code in the mouse driver which is triggering in this case. But problems with the machine being flooded with interrupts from the NIC so hard that it actually cannot do anything are quite common.
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Quoted 7 lines · Vojtech Pavlik
Quoted 2 lines
Has this problem been observed in 2.4 kernels?
No, since 2.4 doesn't have the re-sync code in the mouse driver which is triggering in this case. But problems with the machine being flooded with interrupts from the NIC so hard that it actually cannot do anything are quite common.
So is the resync code doing more good than harm?
Quoted 8 lines · Andrew Morton
Quoted 6 lines
Quoted 1 line
Has this problem been observed in 2.4 kernels?
No, since 2.4 doesn't have the re-sync code in the mouse driver which is triggering in this case. But problems with the machine being flooded with interrupts from the NIC so hard that it actually cannot do anything are quite common.
So is the resync code doing more good than harm?
Hard to tell. The people for which it does good don't complain.
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Quoted 10 lines · Vojtech Pavlik
Quoted 7 lines · Andrew Morton
Quoted 6 lines
Quoted 1 line
Has this problem been observed in 2.4 kernels?
No, since 2.4 doesn't have the re-sync code in the mouse driver which is triggering in this case. But problems with the machine being flooded with interrupts from the NIC so hard that it actually cannot do anything are quite common.
Quoted 4 lines
Quoted 1 line
So is the resync code doing more good than harm?
Hard to tell. The people for which it does good don't complain.
I didn't reboot my pc yet, so I'm still running a 2.4.20 without any problem with my mouse. but when I will boot on the 2.5.70, what I should do to find where does the bug come from. I'm little but new here, so I never try to locate a bug in a kernel...
thanks for your advice
Yoann
--
Jugglers, like programmers, handle objects which, at first sight, seem complex and difficult to control. Some of them, with time and patience, manage to control one or the other or both at the same time, and thus become aware of what they are doing.
Quoted 10 lines · Andrew Morton
Quoted 6 lines · Vojtech Pavlik
Quoted 1 line
Has this problem been observed in 2.4 kernels?
No, since 2.4 doesn't have the re-sync code in the mouse driver which is triggering in this case. But problems with the machine being flooded with interrupts from the NIC so hard that it actually cannot do anything are quite common.
So is the resync code doing more good than harm?
The log message is useful.
I think the resync code is a bit like the OOM killer. We need it, but something is wrong if it ever gets used. It also doesn't quite work the way it should.
Anyway...
I only get the problem with NFS traffic. It may be that NFS traffic is the only way I've yet found to generate extreme network usage though.
The system with problems is an NFSv3 client that gets abused by an in-house version control system based on SCCS. I suppose this is like running "tar xf foo.tar" or "tar xf foo.tar foo" over NFS.
The hardware is:
Pentium III (Coppermine)
1002.822 MHz
Apollo chipset
# lspci -s 00:0d.0 -v
00:0d.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado]
(rev 74)
Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC
Management NIC
Flags: bus master, medium devsel, latency 32, IRQ 11
I/O ports at ec00 [size=128]
Memory at df000000 (32-bit, non-prefetchable) [size=128]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [dc] Power Management version 2# nfsstat -c Client rpc stats: calls retrans authrefrsh 118380 7843 0 Client nfs v2: null getattr setattr root lookup readlink 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% read wrcache write create remove rename 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% link symlink mkdir rmdir readdir fsstat 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
Client nfs v3:
null getattr setattr lookup access readlink
0 0% 12501 10% 114 0% 68765 58% 25538 21% 4 0%
read write create mkdir symlink mknod
8830 7% 725 0% 377 0% 3 0% 1 0% 0 0%
remove rmdir rename link readdir readdirplus
498 0% 0 0% 367 0% 173 0% 0 0% 10 0%
fsstat fsinfo pathconf commit
2 0% 2 0% 0 0% 470 0%
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 1054681254.22103.3750.camel@cube
A message that is not in the archive (sent off-list or not yet received): [email protected]
I may have found the problem!
Quoted 5 lines · Yoann
I have the same problem with my laptop, chip sis630, celeron 1.2Ghz, 256MB of RAM (32MB for video), mouse on PS/2 (ImPS/2) abd read mp3 throught nfs partition (ethernet 100MB). I haven't try without traffic on nfs but I will try next time I boot on the 2.5.70
Using the lockmeter on a 2.5.75 kernel, I discovered that boomerang_interrupt() grabs a spinlock for over 1/4 second. No joke, 253 ms. Interrupts are off AFAIK.
Mouse behavior is terrible.
It should be no surprise that NTP isn't working too well either. The ntpd daemon keeps complaining about losing sync and having to advance the clock by amounts of over 100 seconds.
Could somebody with the hardware manual take a look at that function?
Quoted 4 lines · Albert Cahalan
Using the lockmeter on a 2.5.75 kernel, I discovered that
boomerang_interrupt()grabs a spinlock for over 1/4 second. No joke, 253 ms. Interrupts are off AFAIK.
boomerang_interrupt() doesn't disable interrupts. Is the NIC sharing the mouse's IRQ line?
boomerang_interrupt() is only used by nasty old NICs and yes, I guess it is possible that something has gone wrong and is causing occasional long spins in there.
But I am more suspecting that you're not really using boomerang_interrupt() at all, and that something has gone wrong with lockmeter. What sort of NIC are you using?
Bear in mind that if some other device generates an interrupt while the CPU is running boomerang_interrupt(), lockmeter will count the time spent in that other device's interrupt as "time spent in boomerand_interrupt()". Which is very true, but it is not much help when one is trying to identify the source of the problem.
Perhaps what you should do is to do an rdtsc on entry and exit of do_IRQ() and print stuff out when "long" periods of time in do_IRQ() are noticed.
Quoted 8 lines · Andrew Morton
Quoted 3 lines · Albert Cahalan
Using the lockmeter on a 2.5.75 kernel, I discovered that
boomerang_interrupt()grabs a spinlock for over 1/4 second. No joke, 253 ms. Interrupts are off AFAIK.
boomerang_interrupt()doesn't disable interrupts. Is the NIC sharing the mouse's IRQ line?
No.
CPU0
0: 746770 XT-PIC timer 1: 936 XT-PIC i8042 2: 0 XT-PIC cascade 4: 9 XT-PIC serial 5: 0 XT-PIC uhci-hcd, uhci-hcd 11: 2417 XT-PIC eth0 12: 60 XT-PIC i8042 14: 13844 XT-PIC ide0 15: 2 XT-PIC ide1 NMI: 0 LOC: 751552 ERR: 0 MIS: 0
Quoted 7 lines
boomerang_interrupt()is only used by nasty old NICs and yes, I guess it is possible that something has gone wrong and is causing occasional long spins in there.But I am more suspecting that you're not really using
boomerang_interrupt()at all, and that something has gone wrong with lockmeter. What sort of NIC are you using?
I hope you don't consider a 100 Mb/s PCI device to be a nasty old NIC. It's not an NE2000 you know! I have this:
00:0d.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 74)
Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC Management NIC
Flags: bus master, medium devsel, latency 32, IRQ 11
I/O ports at ec00 [size=128]
Memory at df001000 (32-bit, non-prefetchable) [size=128] Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Without heavy net usage, boomerang_interrupt can take as long as 1950 microseconds. That would be from mounting an NFS filesystem and receiving broadcast packets. I didn't have an opportunity to hit NFS hard today.
That's from rdtsc on a 1002-MHz Pentium III.
Quoted 5 lines
Bear in mind that if some other device generates an interrupt while the CPU is running
boomerang_interrupt(), lockmeter will count the time spent in that other device's interrupt as "time spent inboomerand_interrupt()". Which is very true, but it is not much help when one is trying to identify the source of the problem.
Do the Intel IRQ controller priority rules play a role here?
Quoted 2 lines
Perhaps what you should do is to do an rdtsc on entry and exit of
do_IRQ()and print stuff out when "long" periods of time indo_IRQ()are noticed.
I added code to the top and bottom of do_IRQ, as well as to the top and bottom of boomerang_interrupt. The lockmeter was compiled into the kernel but never enabled. I record the minimum and maximum time in microseconds.
-------------------------------
IRQ num use min max
--- ------ -------- --- -------
0 746770 timer 40 103595 1 936 i8042 13 389773 2 0 cascade - - 3 - - - - 4 9 serial 28 56 5 0 uhci-hcd - - 6 - - 711 711 7 - - 25 25 8 - - - - 9 - - - - 10 - - - - 11 2417 eth0 87 1535331 12 60 i8042 18 102895 13 - - - - 14 13844 ide0 8 51944 15 2 ide1 7 11
NMI 0
LOC 751552
ERR 0
MIS 0
-------------------------------
Quoted 3 lines · Albert Cahalan
I hope you don't consider a 100 Mb/s PCI device to be a nasty old NIC. It's not an NE2000 you know! I have this:
Sorry, I got my boomerangs and vortices mixed up. Vortex is the ancient one.
Quoted 8 lines
I added code to the top and bottom of
do_IRQ, as well as to the top and bottom ofboomerang_interrupt. The lockmeter was compiled into the kernel but never enabled. I record the minimum and maximum time in microseconds.-------------------------------
IRQ num use min max
--- ------ -------- --- -------
Quoted 16 lines
0 746770 timer 40 103595 1 936 i8042 13 389773 2 0 cascade - - 3 - - - - 4 9 serial 28 56 5 0 uhci-hcd - - 6 - - 711 711 7 - - 25 25 8 - - - - 9 - - - - 10 - - - - 11 2417 eth0 87 1535331 12 60 i8042 18 102895 13 - - - - 14 13844 ide0 8 51944 15 2 ide1 7 11
But did your instrumentation account for nested interrupts? What happens if a slow i8042 interrupt happens in the middle of a 3c59x interrupt?
Still, that probably doesn't account for the stalls.
I don't know what does account for it, frankly. You could try dropping the 2.4 driver into the 2.5 tree just to verify that it is not a driver problem. The driver has hardly changed at all.
Quoted 2 lines · Andrew Morton
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.
Zwane
Signature · 1 line
function.linuxpower.ca
Quoted 7 lines · Zwane Mwaikambo
Quoted 2 lines · Andrew Morton
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_enablefor !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.
Quoted 22 lines · Albert Cahalan
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
Quoted 3 lines
------------------------
boomerang_interruptitself takes 4 to 59 microseconds.
So this looks OK, yes? (Is that instrumentation patch productisable? Looks handly, albeit a subset of microstate accounting)
Quoted 11 lines
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!
Arrrgh! More PS/2 problems!
I think the lost synchronisation is the problem, would you agree?
The person who fixes this gets a Nobel prize.
Quoted 9 lines
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()andsync()activity to ext3. b. Lots of NFSv3 traffic.
ie: lots of interrupt traffic causes the PS2 driver to go whacky?
Quoted 25 lines · Andrew Morton
Quoted 23 lines · Albert Cahalan
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------------------------
Quoted 3 lines
Quoted 1 line
boomerang_interruptitself takes 4 to 59 microseconds.So this looks OK, yes?
I suppose boomerang_interrupt itself is OK. Spending 104 ms in IRQ 0, 31 ms in IRQ 11, and 44 ms in IRQ 14 is not at all OK. I was hoping to get under 200 microseconds for everything.
Quoted 2 lines
(Is that instrumentation patch productisable? Looks handly, albeit a subset of microstate accounting)
Not really. I printk() when a value exceeds the saved maximum, then scan my logs for the first and last values. There's also hard-coded knowledge of my 1-GHz CPU, which lets me convert to microseconds as follows: us = (unsigned)(ns64>>3)/125u;
(that lets me handle up to 32 seconds)
Huh. So the minimum value is really the first value. Later values could be less, but that's not important. I suppose that true min/max via a /proc file would be pretty easy to implement. I like my 1-GHz hack. I like a TSC that measures in nanoseconds too.
Quoted 10 lines
Quoted 10 lines
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.
Quoted 5 lines
Quoted 1 line
Arrrrgh! The TSC is my only good time source!
Arrrgh! More PS/2 problems!
I think the lost synchronisation is the problem, would you agree?
It's one problem. It's a problem other people have seen. My TSC should be good though; I'd like to use it. At times ntpd (the NTP daemon) gets really unhappy with the situation, yanking my clock ahead by up to 10 minutes to compensate for lost time.
Quoted 6 lines
The person who fixes this gets a Nobel prize.
Quoted 4 lines
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.
Quoted 7 lines
Quoted 5 lines
To reproduce, I do some PS/2 mouse movement while
doing one of:a. Lots of concurrent
write()andsync()activity to ext3. b. Lots of NFSv3 traffic.ie: lots of interrupt traffic causes the PS2 driver to go whacky?
I guess so. The ext3+IDE behavior seems to lift the blame from boomerang_interrupt. Using ext3+IDE, I seem to need a couple minutes to reproduce the problem. NFSv3+Ethernet will give me the problem almost instantly.
Quoted 7 lines · Albert Cahalan
Quoted 2 lines
So this looks OK, yes?
I suppose
boomerang_interruptitself is OK. Spending 104 ms in IRQ 0, 31 ms in IRQ 11, and 44 ms in IRQ 14 is not at all OK. I was hoping to get under 200 microseconds for everything.
I misread that.
Last time I checked (which was about 18 months ago) the maximum interrupts-off time on a 500MHz desktop-class machine was 80 microseconds.
Something is broken there. Do you have another machine to sanity check against?
Quoted 9 lines · Andrew Morton
Quoted 7 lines · Albert Cahalan
Quoted 2 lines
So this looks OK, yes?
I suppose
boomerang_interruptitself is OK. Spending 104 ms in IRQ 0, 31 ms in IRQ 11, and 44 ms in IRQ 14 is not at all OK. I was hoping to get under 200 microseconds for everything.
Quoted 4 lines
I misread that.
Last time I checked (which was about 18 months ago) the maximum interrupts-off time on a 500MHz desktop-class machine was 80 microseconds.
IDE has traditionally been a small headache in that department. I need to find out how it fares in 2.5
Signature · 1 line
function.linuxpower.ca
Quoted 2 lines · Andrew Morton
Last time I checked (which was about 18 months ago) the maximum interrupts-off time on a 500MHz desktop-class machine was 80 microseconds.
You might want to bump that up a little bit. Querying carrier signal on a tulip chip is 100usecs with interrupts off.
Doesn't make any difference here though.
Chris
Signature · 4 lines
Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: [email protected]
Hi!
Quoted 6 lines
Quoted 6 lines
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.
Quoted 7 lines
Quoted 1 line
Arrrrgh! The TSC is my only good time source!
Arrrgh! More PS/2 problems!
I think the lost synchronisation is the problem, would you agree?
The person who fixes this gets a Nobel prize.
If you set ps/2 synchronization timeout to 20 seconds, you are going to make vojtech unhappy (he likes that code :-), but at least 2.6.0 will not be worse than 2.4.x...
Do you want me to create a patch?
Signature · 2 lines
Pavel Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
Quoted 13 lines · Pavel Machek
Hi!
Quoted 10 lines
Quoted 7 lines
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!
Arrrgh! More PS/2 problems!
Quoted 7 lines
Quoted 3 lines
I think the lost synchronisation is the problem, would you agree?
The person who fixes this gets a Nobel prize.
If you set ps/2 synchronization timeout to 20 seconds, you are going to make vojtech unhappy (he likes that code :-), but at least 2.6.0 will not be worse than 2.4.x...
2.6 is currently much worse than 2.4: we're buried in what appear to be many different varieties of PS/2 bug reports.
Quoted 1 line
Do you want me to create a patch?
Well I do not know what the problem with synchronisation is, not what solution you propose.
But yeah, I like patches ;)
Quoted 14 lines · Pavel Machek
Hi!
Quoted 12 lines
Quoted 7 lines
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!
Arrrgh! More PS/2 problems!
I think the lost synchronisation is the problem, would you agree?
Quoted 7 lines
Quoted 1 line
The person who fixes this gets a Nobel prize.
If you set ps/2 synchronization timeout to 20 seconds, you are going to make vojtech unhappy (he likes that code :-), but at least 2.6.0 will not be worse than 2.4.x...
Do you want me to create a patch?
No. That will just hide one symptom of the problem, making things more difficult to debug.
It won't fix my clock, which the ntpd program keeps complaining about. Under heavy load, my clock falls behind so much that ntpd gives up on the gentle treatment and just yanks the clock forward by as much as 10 minutes.
It won't make the mouse run well. Maybe you'd stop the mouse from going crazy from time to time, but there'd still temporary freezes from time to time. (not OK!)
It won't convince Linux that my TSC isn't broken.
It won't solve Mikael Pettersson's problem, posted under the subject "[BUG] 2.6.0-test2 loses time on 486". He writes:
"My old 486 test box is losing time at an alarming rate when running 2.6.0-test kernels. It loses almost 2 minutes per hour, less if it sits idle. This problem does not occur when it's running a 2.4 kernel."
Gee, I get that too, on a 1 GHz Pentium III. It seems we're all losing LOTS of clock ticks and other interrupts.
I took the net-related email addresses off the Cc: list. Please leave me on it so I don't have to break threading.