PS2 mouse going nuts during cdparanoia session.
I've decided to oggify my CD collection, and every now and again, the mouse pointer goes bezerk is if I had been shaking it around and randomly clicking on things. In the logs are lots of..
psmouse.c: Lost synchronization, throwing 3 bytes away.
It only happens whilst cdparanoia is reading from the CD. The IDE CD drive is using DMA, and interrupts are unmasked. according to the logs, its happened 32 times since I last booted.. /proc/interrupts shows that the i8042 is using a different interrupt to the IDE devices..
Mouse is a logitech wheely PS/2 mouse, using ImPS/2 protocol in X config reading from /dev/psaux.
This is using 2.6test1, I'don't recall ever seeing this happen in 2.4, but it did occur for a while earlier in 2.5, and I forgot about it until now.
Any ideas?
Dave
Quoted 13 lines · Dave Jones
I've decided to oggify my CD collection, and every now and again, the mouse pointer goes bezerk is if I had been shaking it around and randomly clicking on things. In the logs are lots of..
psmouse.c: Lost synchronization, throwing 3 bytes away.It only happens whilst cdparanoia is reading from the CD. The IDE CD drive is using DMA, and interrupts are unmasked. according to the logs, its happened 32 times since I last booted..
/proc/interruptsshows that the i8042 is using a different interrupt to the IDE devices..
Quoted 8 lines
Mouse is a logitech wheely PS/2 mouse, using ImPS/2 protocol in X config reading from
/dev/psaux.This is using 2.6test1, I'don't recall ever seeing this happen in 2.4, but it did occur for a while earlier in 2.5, and I forgot about it until now.
Any ideas?
Yes. You can try and make the situation a little better by unmasking interrupts with -u1. Or you can try and use a ripper that actually uses SG_IO, that way you can use dma (and zero copy) for the rips. That will be lots more smooth.
Signature · 1 line
Jens Axboe
Quoted 2 lines · Jens Axboe
Quoted 2 lines
It only happens whilst cdparanoia is reading from the CD. The IDE CD drive is using DMA, and interrupts are unmasked.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Quoted 2 lines
Yes. You can try and make the situation a little better by unmasking interrupts with -u1.
See above 8-) It was the first thing I tried when I observed this phenomenon.
Quoted 3 lines
Or you can try and use a ripper that actually uses
SG_IO, that way you can use dma (and zero copy) for the rips. That will be lots more smooth.
Ah right, I thought cdparanoia was still ripper de jour.. What's recommended these days?
Dave
Quoted 9 lines · Dave Jones
Quoted 2 lines · Jens Axboe
Quoted 2 lines
It only happens whilst cdparanoia is reading from the CD. The IDE CD drive is using DMA, and interrupts are unmasked.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^Quoted 2 lines
Yes. You can try and make the situation a little better by unmasking interrupts with -u1.
See above 8-) It was the first thing I tried when I observed this phenomenon.
Oh right, sorry.
Quoted 6 lines
Quoted 3 lines
Or you can try and use a ripper that actually uses
SG_IO, that way you can use dma (and zero copy) for the rips. That will be lots more smooth.Ah right, I thought cdparanoia was still ripper de jour.. What's recommended these days?
It is, unfortunately it uses read/write on /dev/sg* directly so cannot be used with "new path" that is so much faster. It's been a while since I looked, I can check for a good cdda ripper that uses SG_IO tomorrow if you don't find one first.
I'm about to cave in and add block emulation of that part, too. It's a bit more code, though.
Signature · 1 line
Jens Axboe
Quoted 7 lines · Jens Axboe
Quoted 2 lines
Ah right, I thought cdparanoia was still ripper de jour.. What's recommended these days?
It is, unfortunately it uses read/write on
/dev/sg*directly so cannot be used with "new path" that is so much faster. It's been a while since I looked, I can check for a good cdda ripper that usesSG_IOtomorrow if you don't find one first.
Ok. I'll add a note about this to post-halloween-2.5 sometime too when www.codemonkey.org.uk reappears again.
[sidenote: please folks, no more mails telling me about this site going away,
it'll be back real soon, it just had to be 'upgraded' to a raq2, which didn't go quite as smoothly as planned.].
Quoted 2 lines
I'm about to cave in and add block emulation of that part, too. It's a bit more code, though.
If it'll make apps like cdparanoia take the fast path without needing rewriting, then that sounds like a good idea, if only to stop the 'dancing mouse' problem, though this does seem to be running away from a bug rather than fixing it. The real question is why are the two interacting with each other like this..
Dave
Quoted 10 lines · Dave Jones
Quoted 7 lines · Jens Axboe
Quoted 2 lines
Ah right, I thought cdparanoia was still ripper de jour.. What's recommended these days?
It is, unfortunately it uses read/write on
/dev/sg*directly so cannot be used with "new path" that is so much faster. It's been a while since I looked, I can check for a good cdda ripper that usesSG_IOtomorrow if you don't find one first.
Quoted 5 lines
Ok. I'll add a note about this to post-halloween-2.5 sometime too when www.codemonkey.org.uk reappears again.
[sidenote: please folks, no more mails telling me about this site going away,
it'll be back real soon, it just had to be 'upgraded' to a raq2, which didn't go quite as smoothly as planned.].
Isn't it always like that? :)
Quoted 5 lines
Quoted 2 lines
I'm about to cave in and add block emulation of that part, too. It's a bit more code, though.
If it'll make apps like cdparanoia take the fast path without needing rewriting, then that sounds like a good idea, if only to stop the
That would be the point, yes. Whether it's worth it depends on how many programs are using sg and not SG_IO that we care about.
Quoted 3 lines
'dancing mouse' problem, though this does seem to be running away from a bug rather than fixing it. The real question is why are the two interacting with each other like this..
The bug wants fixing too, of course. I'm betting it's time spent in the ide interrupt handler that's killing it. So it can be made a little better, but not a lot. non-dma ripping is always going to pull you down. Even if you didn't have problems, you'd spend 80% of the cpu time getting data off the drive leaving only 20% for encoding + the rest. If you get the dma path going, it'll basically leave the system idle when ripping (1-2% sys or something like that, in the noise almost).
Signature · 1 line
Jens Axboe
Quoted 2 lines · Dave Jones
Ah right, I thought cdparanoia was still ripper de jour.. What's recommended these days?
I'd say readcd. It also has a paranoia mode.
regards
Markus
Quoted 4 lines · Jens Axboe
Yes. You can try and make the situation a little better by unmasking interrupts with -u1. Or you can try and use a ripper that actually uses
SG_IO, that way you can use dma (and zero copy) for the rips. That will be lots more smooth.
Dumb user question - which rippers support SG_IO? I've been using cdparanoia mostly for lack of a good reason to migrate - but this sounds like a good reason. ;)
Quoted 10 lines · On Wed, Jul 16 2003, [email protected] wrote:
Quoted 4 lines · Jens Axboe
Yes. You can try and make the situation a little better by unmasking interrupts with -u1. Or you can try and use a ripper that actually uses
SG_IO, that way you can use dma (and zero copy) for the rips. That will be lots more smooth.Dumb user question - which rippers support
SG_IO? I've been using cdparanoia mostly for lack of a good reason to migrate - but this sounds like a good reason. ;)
Not a dumb question at all, see my previous mail :). In short, I don't know. I'm sure a little collective effort could hunt some down (cdda2wav should work, since it uses libscg presumable).
Signature · 1 line
Jens Axboe
Quoted 7 lines · Jens Axboe
Quoted 3 lines
Dumb user question - which rippers support
SG_IO? I've been using cdparanoia mostly for lack of a good reason to migrate - but this sounds like a good reason. ;)Not a dumb question at all, see my previous mail :). In short, I don't know. I'm sure a little collective effort could hunt some down (cdda2wav should work, since it uses libscg presumable).
For info, I just tried cdda2wav, and whilst it used less CPU than cdparanoia, the dancing mouse effect still occurs 8-(
Dave
Signature · 1 line
Dave Jones http://www.codemonkey.org.uk
Quoted 11 lines · Dave Jones
Quoted 7 lines · Jens Axboe
Quoted 3 lines
Dumb user question - which rippers support
SG_IO? I've been using cdparanoia mostly for lack of a good reason to migrate - but this sounds like a good reason. ;)Not a dumb question at all, see my previous mail :). In short, I don't know. I'm sure a little collective effort could hunt some down (cdda2wav should work, since it uses libscg presumable).
For info, I just tried cdda2wav, and whilst it used less CPU than cdparanoia, the dancing mouse effect still occurs 8-(
Can you check whether it uses SG_IO ioctl (0x2285) or read/write on /dev/sg*? Strace please :)
Signature · 1 line
Jens Axboe
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · Martin Schlemmer
Quoted 2 lines
For info, I just tried cdda2wav, and whilst it used less CPU than cdparanoia, the dancing mouse effect still occurs 8-(
Stupid question:
Very stupid. [just kidding.. 8-)]
Quoted 1 line
the PS/2 and the ide channel is not maybe sharing an irq,
I answered this in my first mail, no it isn't.
Quoted 1 line
or some ACPI weirdness of a kind ?
Not tried without ACPI. I'll give it a shot if I get time before heading off to the airport..
Dave
Signature · 1 line
Dave Jones http://www.codemonkey.org.uk
Quoted 5 lines · Jens Axboe
Quoted 2 lines
The IDE CD drive is using DMA, and interrupts are unmasked. according to the logs, its happened 32 times since I last
Yes. You can try and make the situation a little better by unmasking interrupts with -u1. Or you can try and use a ripper that actually uses
He already is
Quoted 2 lines
SG_IO, that way you can use dma (and zero copy) for the rips. That will be lots more smooth.
So why isnt this occuring on 2.4 .. thats the important question here is this a logging thing, a new input layer bug, an ide bug or what ?
Quoted 8 lines · Alan Cox
Quoted 5 lines · Jens Axboe
Quoted 2 lines
The IDE CD drive is using DMA, and interrupts are unmasked. according to the logs, its happened 32 times since I last
Yes. You can try and make the situation a little better by unmasking interrupts with -u1. Or you can try and use a ripper that actually uses
He already is
Yeah I noticed know :)
Quoted 5 lines
Quoted 2 lines
SG_IO, that way you can use dma (and zero copy) for the rips. That will be lots more smooth.So why isnt this occuring on 2.4 .. thats the important question here is this a logging thing, a new input layer bug, an ide bug or what ?
Dave, have you tried 2.4 newest? Some of the newer IDE stuff kept interrupts off for ages, maybe it's on 2.4 also. Also Dave, can you try and do a vmstat 1 while ripping and PS2 dropping out?
Signature · 1 line
Jens Axboe
Quoted 5 lines · Jens Axboe
Quoted 4 lines
Quoted 2 lines
SG_IO, that way you can use dma (and zero copy) for the rips. That will be lots more smooth.So why isnt this occuring on 2.4 .. thats the important question here is this a logging thing, a new input layer bug, an ide bug or what ?
Dave, have you tried 2.4 newest?
I've not booted a 2.4 kernel since 2.4.20..
Quoted 2 lines
Some of the newer IDE stuff kept
interrupts off for ages, maybe it's on 2.4 also.
I can try sometime if you want to know.. (I've got plenty more CDs that need encoding, so I'll have plenty of opportunity to see this bug if its there 8-)
Quoted 2 lines
Also Dave, can you try
and do a vmstat 1 while ripping and PS2 dropping out?
Ok, I just fired that up in another window.
When it happens next, I'll mail off a snapshot..
Dave
Quoted 9 lines · Dave Jones
Quoted 5 lines · Jens Axboe
Quoted 4 lines
Quoted 2 lines
SG_IO, that way you can use dma (and zero copy) for the rips. That will be lots more smooth.So why isnt this occuring on 2.4 .. thats the important question here is this a logging thing, a new input layer bug, an ide bug or what ?
Dave, have you tried 2.4 newest?
I've not booted a 2.4 kernel since 2.4.20..
You should try 2.4.21, basically any 2.4 with the newer ide stuff.
Quoted 6 lines
Quoted 2 lines
Some of the newer IDE stuff kept
interrupts off for ages, maybe it's on 2.4 also.I can try sometime if you want to know.. (I've got plenty more CDs that need encoding, so I'll have plenty of opportunity to see this bug if its there 8-)
Would be interesting to hear how they compare.
Quoted 5 lines
Quoted 2 lines
Also Dave, can you try
and do a vmstat 1 while ripping and PS2 dropping out?Ok, I just fired that up in another window.
When it happens next, I'll mail off a snapshot..
Thanks.
Signature · 1 line
Jens Axboe
Quoted 3 lines · Jens Axboe
Quoted 1 line
I've not booted a 2.4 kernel since 2.4.20..
You should try 2.4.21, basically any 2.4 with the newer ide stuff. Would be interesting to hear how they compare.
Ok, I'll take a look later this evening if time permits..
Quoted 5 lines
Quoted 4 lines
Quoted 2 lines
Also Dave, can you try
and do a vmstat 1 while ripping and PS2 dropping out?Ok, I just fired that up in another window.
When it happens next, I'll mail off a snapshot..Thanks.
Well, that didn't take long..
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa 2 0 109376 9632 2576 44368 0 0 136 28 1636 1304 1 4 90 4 0 0 109376 8036 2588 45852 0 0 1492 0 2166 15874 2 11 82 5 1 0 109376 8036 2588 45852 0 0 0 0 1089 1230 1 1 99 0 1 0 109376 8004 2612 45896 0 0 8 144 2660 1088 1 11 85 4 1 0 109376 5880 2616 46436 0 0 0 0 1338 1263 2 24 74 0 2 0 109376 5512 2576 45320 0 0 0 72 2108 1434 4 35 61 0 2 0 109376 5816 2520 45252 56 0 60 940 1852 2340 6 33 59 2 1 0 109376 4880 2448 45800 0 0 0 520 1940 2930 6 33 60 2 0 0 109376 5468 2412 45300 0 0 16 1672 2504 3077 9 42 44 7 1 0 109376 5532 2396 45792 0 0 0 344 2172 3504 4 33 61 2 1 0 109376 4132 2416 46452 0 0 8 4 2727 3483 5 39 54 1 0 0 109376 4864 2384 45484 0 0 4 1324 2186 3448 5 34 59 4 1 0 109376 5024 2384 46436 0 0 0 600 2484 3533 4 36 58 2
Lost sync here. Mouse dancing. vmstat output stopped for a few seconds.
1 3 109376 5480 2404 45396 88 0 136 1760 2371 3391 6 41 44 10 2 2 109376 4924 2200 43200 340 0 1688 312 2272 5477 19 49 2 29 1 1 109376 4660 2224 45056 568 0 1524 0 2835 3675 15 45 9 31 3 1 109376 17964 2224 31028 720 0 1232 1468 2095 2518 12 43 24 22 2 4 109376 19148 2232 29060 532 0 864 4 2307 5684 22 57 6 15 4 0 109376 18716 2240 29732 68 0 68 1728 2037 6512 26 49 20 6 3 0 109376 18264 2240 29228 164 0 164 0 2078 7674 31 52 11 6 1 0 109376 17208 2452 29816 220 0 416 40 2455 9701 36 61 4 0 cprocs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 5 1 109376 15384 2476 31404 20 0 856 96 1929 10534 29 52 17 2 6 1 109376 17084 2408 28828 28 0 4416 2280 2162 7640 25 60 2 14 1 4 109376 3872 2388 27416 8 0 7864 740 2078 7232 20 53 1 26 7 3 109376 19380 2280 27876 124 0 2560 108 2247 4298 19 52 0 30 2 1 109376 17444 2184 28692 104 0 2412 0 2117 6171 24 52 1 24 8 1 109376 5052 2148 26460 24 0 2848 668 2007 5297 31 61 0 8 4 0 109376 20208 2152 27260 216 0 2520 336 2126 5398 23 55 5 17 2 0 109376 20284 2164 25956 0 0 4 2688 1890 4921 30 47 17 5 3 0 109376 4332 2164 26772 0 0 16 0 2201 6067 39 56 6 0
regained control of mouse here.
2 0 109376 20896 2160 26052 44 0 44 4 2032 5131 37 53 9 0 2 1 109376 4424 2236 26796 200 0 328 0 2160 5662 41 51 7 2 3 0 109376 18596 2264 27616 172 0 428 2824 2067 7553 29 60 4 6 4 2 109376 12576 2280 28540 624 0 832 1136 1956 7002 28 53 4 14 1 1 109376 8768 2288 29660 708 0 1084 0 2278 2027 7 36 15 43 1 1 109376 6308 2400 31004 108 0 836 140 2206 2868 12 37 19 33 3 1 109376 4488 2424 31728 0 0 40 2840 2277 1720 10 42 7 42 1 0 109376 12124 2460 31216 0 0 96 596 1578 1805 7 38 42 12
Dave
Quoted 24 lines · Dave Jones
Quoted 5 lines
Quoted 4 lines
Quoted 2 lines
Also Dave, can you try
and do a vmstat 1 while ripping and PS2 dropping out?Ok, I just fired that up in another window.
When it happens next, I'll mail off a snapshot..Thanks.
Well, that didn't take long..
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa 2 0 109376 9632 2576 44368 0 0 136 28 1636 1304 1 4 90 4 0 0 109376 8036 2588 45852 0 0 1492 0 2166 15874 2 11 82 5 1 0 109376 8036 2588 45852 0 0 0 0 1089 1230 1 1 99 0 1 0 109376 8004 2612 45896 0 0 8 144 2660 1088 1 11 85 4 1 0 109376 5880 2616 46436 0 0 0 0 1338 1263 2 24 74 0 2 0 109376 5512 2576 45320 0 0 0 72 2108 1434 4 35 61 0 2 0 109376 5816 2520 45252 56 0 60 940 1852 2340 6 33 59 2 1 0 109376 4880 2448 45800 0 0 0 520 1940 2930 6 33 60 2 0 0 109376 5468 2412 45300 0 0 16 1672 2504 3077 9 42 44 7 1 0 109376 5532 2396 45792 0 0 0 344 2172 3504 4 33 61 2 1 0 109376 4132 2416 46452 0 0 8 4 2727 3483 5 39 54 1 0 0 109376 4864 2384 45484 0 0 4 1324 2186 3448 5 34 59 4 1 0 109376 5024 2384 46436 0 0 0 600 2484 3533 4 36 58 2
Quoted 1 line
Lost sync here. Mouse dancing. vmstat output stopped for a few seconds.
Doesn't look really bogged down by interrupt load, still half idle. So that looks like a PS2 bug. Unless the irq latencies are really bad, I guess that could be it too. Vojtech knows a hell of a lot more about that than me :)
Signature · 1 line
Jens Axboe
Quoted 4 lines · Jens Axboe
Doesn't look really bogged down by interrupt load, still half idle. So that looks like a PS2 bug. Unless the irq latencies are really bad, I guess that could be it too. Vojtech knows a hell of a lot more about that than me :)
PS/2 has some horrble timing rules but they are the wrong way around for this bug so I'm somewhat baffled - you must do 1mS sized delays between ps/2 reads even on some current chipsets but there isnt really an upper limit
Quoted 9 lines · Jens Axboe
Quoted 3 lines · Dave Jones
Lost sync here. Mouse dancing. vmstat output stopped for a few seconds.
Doesn't look really bogged down by interrupt load, still half idle. So that looks like a PS2 bug. Unless the irq latencies are really bad,
FWIW, this also affects PPP over an async serial line (in my case to a 56Kb modem). During cdparanoia runs, the modem Tx/Rx lights all but stop as the missed packets drop retransmissions into the minute+ timeframe. (Oddly, I don't recall seeing framing errors from ifconfig; must be the lower level ppp substrate or some such...)
I can confirm this with 2.4.20, am mostly certain it affects 2.4.21 (will have to retest to be sure). Similarly to Dave, I'm using an IDE/ATAPI burner with both DMA and UNMASKIRQ enabled.
Kris
Quoted 5 lines · Kristofer T. Karas
FWIW, this also affects PPP over an async serial line (in my case to a 56Kb modem). During cdparanoia runs, the modem Tx/Rx lights all but stop as the missed packets drop retransmissions into the minute+ timeframe. (Oddly, I don't recall seeing framing errors from ifconfig; must be the lower level ppp substrate or some such...)
I remember seeing this in the 2.5.6mumble kernel as well, it got fixed by something around 2.5.70 or so. I wish I could give a more specific release number for it.
Quoted 8 lines · Dave Jones
Quoted 5 lines · Jens Axboe
Quoted 4 lines
Quoted 2 lines
SG_IO, that way you can use dma (and zero copy) for the rips. That will be lots more smooth.So why isnt this occuring on 2.4 .. thats the important question here is this a logging thing, a new input layer bug, an ide bug or what ?
Dave, have you tried 2.4 newest?
Quoted 8 lines
I've not booted a 2.4 kernel since 2.4.20..
Quoted 2 lines
Some of the newer IDE stuff kept
interrupts off for ages, maybe it's on 2.4 also.I can try sometime if you want to know.. (I've got plenty more CDs that need encoding, so I'll have plenty of opportunity to see this bug if its there 8-)
Dave, can you please enable the DEBUG in i8042.c so that I can see whether the bytes really get lost or if the unsync check is just triggering by mistake?
Quoted 8 lines
Quoted 2 lines
Also Dave, can you try
and do a vmstat 1 while ripping and PS2 dropping out?Ok, I just fired that up in another window.
When it happens next, I'll mail off a snapshot..Dave
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Quoted 3 lines · Vojtech Pavlik
Dave, can you please enable the DEBUG in
i8042.cso that I can see whether the bytes really get lost or if the unsync check is just triggering by mistake?
Intriguing. With DEBUG enabled, I get a few gig of logs, but I can't trigger the dancing mouse pointer any more. With it disabled, I can reproduce it within a minute or two.
Seems to be a timing related bug.
Dave
Quoted 11 lines · Dave Jones
Quoted 3 lines · Vojtech Pavlik
Dave, can you please enable the DEBUG in
i8042.cso that I can see whether the bytes really get lost or if the unsync check is just triggering by mistake?Intriguing. With DEBUG enabled, I get a few gig of logs, but I can't trigger the dancing mouse pointer any more. With it disabled, I can reproduce it within a minute or two.
Seems to be a timing related bug.
Ouch.
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Quoted 11 lines · Vojtech Pavlik
Quoted 9 lines
Quoted 3 lines
Dave, can you please enable the DEBUG in
i8042.cso that I can see whether the bytes really get lost or if the unsync check is just triggering by mistake?Intriguing. With DEBUG enabled, I get a few gig of logs, but I can't trigger the dancing mouse pointer any more. With it disabled, I can reproduce it within a minute or two.
Seems to be a timing related bug.
Ouch.
Finally managed to recreate it.
http://www.codemonkey.org.uk/cruft/dancingmouse.txt
Quoted 1 line
From 00:01:33 to 00:01:40 the box was having a fit.
Then things returned to normal.
Dave
Quoted 11 lines · Dave Jones
Quoted 10 lines · Vojtech Pavlik
Quoted 9 lines
Quoted 3 lines
Dave, can you please enable the DEBUG in
i8042.cso that I can see whether the bytes really get lost or if the unsync check is just triggering by mistake?Intriguing. With DEBUG enabled, I get a few gig of logs, but I can't trigger the dancing mouse pointer any more. With it disabled, I can reproduce it within a minute or two.
Seems to be a timing related bug.
Quoted 7 lines
Quoted 1 line
Ouch.
Finally managed to recreate it.
http://www.codemonkey.org.uk/cruft/dancingmouse.txtQuoted 1 line
From 00:01:33 to 00:01:40 the box was having a fit.
Then things returned to normal.
Thanks! This is very interesting. Most likely the problem started with the "aux, 0" byte ...
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Dave just a random pondering looking over the code - does it make any difference if you stick a udelay(50) at the top of wait_read and wait_write in i8042.c. Right now we don't always seem to honour the delays for certain specific patterns of I/O and interrupt.
Ditto the read_status/read_data loop in the _interrupt code path.
Quoted 6 lines · Alan Cox
Dave just a random pondering looking over the code - does it make any difference if you stick a udelay(50) at the top of
wait_readandwait_writeini8042.c. Right now we don't always seem to honour the delays for certain specific patterns of I/O and interrupt.Ditto the read_status/read_data loop in the
_interruptcode path.
No joy.
Dave
Quoted 6 lines · Alan Cox
Quoted 3 lines
SG_IO, that way you can use dma (and zero copy) for the rips. That will be lots more smooth.So why isnt this occuring on 2.4 .. thats the important question here is this a logging thing, a new input layer bug, an ide bug or what ?
input layer, I think. Several people are having problems with the synchronisation loss thing.
Quoted 7 lines · Alan Cox
Quoted 5 lines · Jens Axboe
Quoted 2 lines
The IDE CD drive is using DMA, and interrupts are unmasked. according to the logs, its happened 32 times since I last
Yes. You can try and make the situation a little better by unmasking interrupts with -u1. Or you can try and use a ripper that actually uses
Quoted 7 lines
He already is
Quoted 2 lines
SG_IO, that way you can use dma (and zero copy) for the rips. That will be lots more smooth.So why isnt this occuring on 2.4 .. thats the important question here is this a logging thing, a new input layer bug, an ide bug or what ?
This is basically because the check for lost bytes wasn't present in 2.4. Now that it is there, it works well with real lost bytes, but will fire also in case when the mouse interrupt was delayed for more than half a second, or if indeed a mouse interrupt gets lost. The 2.5 kernel by default programs the mouse to high speed reporting (up to 200 updates per second). This may, possibly make the problem show up easier. There might be real lost bytes on some machines, too. This can be checked by defining DEBUG in i8042.c
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Quoted 6 lines · Alan Cox
Quoted 2 lines · Jens Axboe
Quoted 2 lines
The IDE CD drive is using DMA, and interrupts are unmasked. according to the logs, its happened 32 times since I last
So why isnt this occurring on 2.4 .. thats the important question here is this a logging thing, a new input layer bug, an ide bug or what ?
The default kernel can spend very large amounts of time in IDE code. With DMA it can be seconds.
With PIO it can be minutes.
This means that with PIO one may think that the system crashed, and see (under X) keyboard or mouse actions only after for example two minutes. With DMA things are much better, but still a delay of seconds is very noticeable.
The input code used to have
if (psmouse->pktcnt && time_after(jiffies, psmouse->last + HZ/20)) {
printk(KERN_WARNING "psmouse.c: Lost synchronization, throwing \
%d bytes away.\n", psmouse->pktcnt);
psmouse->pktcnt = 0;
}and I patched it to HZ/2, that helps, but is still not good enough.
Andries