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
On Wed, Jul 16 2003, Dave Jones wrote:
> 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?
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.
--
Jens Axboe
On Wed, Jul 16, 2003 at 07:03:52PM +0200, Jens Axboe wrote:
> > It only happens whilst cdparanoia is reading from the CD.
> > The IDE CD drive is using DMA, and interrupts are unmasked.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 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.
> 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
On Wed, Jul 16 2003, Dave Jones wrote:
> On Wed, Jul 16, 2003 at 07:03:52PM +0200, Jens Axboe wrote:
>
> > > It only happens whilst cdparanoia is reading from the CD.
> > > The IDE CD drive is using DMA, and interrupts are unmasked.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 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.
> > 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.
--
Jens Axboe
On Wed, 16 Jul 2003 19:03:52 +0200, Jens Axboe <[email protected]> said:
> 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. ;)
On Wed, Jul 16 2003, [email protected] wrote:
> On Wed, 16 Jul 2003 19:03:52 +0200, Jens Axboe <[email protected]> said:
>
> > 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).
--
Jens Axboe
On Wed, Jul 16 2003, Alan Cox wrote:
> On Mer, 2003-07-16 at 18:03, Jens Axboe wrote:
> > > 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 :)
> > 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?
--
Jens Axboe
On Mer, 2003-07-16 at 18:03, Jens Axboe wrote:
> > 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
> 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 ?
On Wed, Jul 16, 2003 at 07:13:23PM +0200, Jens Axboe wrote:
> > 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.
Ok. I'll add a note about this to post-halloween-2.5 sometime too
when http://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.].
> 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
On Wed, 16 Jul 2003, Dave Jones wrote:
> 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
On Wed, Jul 16 2003, Dave Jones wrote:
> On Wed, Jul 16, 2003 at 07:13:23PM +0200, Jens Axboe wrote:
>
> > > 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.
>
> Ok. I'll add a note about this to post-halloween-2.5 sometime too
> when http://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? :)
> > 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.
> '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).
--
Jens Axboe
On Wed, Jul 16, 2003 at 07:25:31PM +0200, Jens Axboe wrote:
> > 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..
> > > 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
On Wed, Jul 16 2003, Dave Jones wrote:
> > > > 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.
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 :)
--
Jens Axboe
On Wed, Jul 16, 2003 at 07:16:07PM +0200, Jens Axboe wrote:
> > > 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..
> 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-)
> 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
On Wed, Jul 16 2003, Dave Jones wrote:
> On Wed, Jul 16, 2003 at 07:16:07PM +0200, Jens Axboe wrote:
>
> > > > 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.
> > 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.
> > 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.
--
Jens Axboe
On Wed, Jul 16, 2003 at 07:17:06PM +0200, Jens Axboe wrote:
> > 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
--
Dave Jones http://www.codemonkey.org.uk
On Wed, Jul 16 2003, Dave Jones wrote:
> On Wed, Jul 16, 2003 at 07:17:06PM +0200, Jens Axboe wrote:
> > > 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 :)
--
Jens Axboe
Alan Cox <[email protected]> wrote:
>
> > 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.
On Mer, 2003-07-16 at 18:31, Jens Axboe wrote:
> 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
On Wed, Jul 16, 2003 at 06:10:33PM +0100, Alan Cox wrote:
> On Mer, 2003-07-16 at 18:03, Jens Axboe wrote:
> > > 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
>
> > 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
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Wed, Jul 16, 2003 at 06:23:31PM +0100, Dave Jones wrote:
> On Wed, Jul 16, 2003 at 07:16:07PM +0200, Jens Axboe wrote:
>
> > > > 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..
>
> > 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?
> > 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
>
--
Vojtech Pavlik
SuSE Labs, SuSE CR
Jens Axboe wrote:
>On Wed, Jul 16 2003, Dave Jones wrote:
>
>
>>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
On Wed, 16 Jul 2003 15:03:35 EDT, "Kristofer T. Karas" said:
> 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.
On Wed, Jul 16, 2003 at 09:00:18PM +0200, Vojtech Pavlik wrote:
> 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?
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
On Wed, Jul 16, 2003 at 08:30:02PM +0100, Dave Jones wrote:
> On Wed, Jul 16, 2003 at 09:00:18PM +0200, Vojtech Pavlik wrote:
>
> > 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?
>
> 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.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Wed, Jul 16, 2003 at 06:10:33PM +0100, Alan Cox wrote:
> On Mer, 2003-07-16 at 18:03, Jens Axboe wrote:
> > > 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
On Wed, Jul 16, 2003 at 10:53:19PM +0200, Vojtech Pavlik wrote:
> > > 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?
> >
> > 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
>From 00:01:33 to 00:01:40 the box was having a fit.
Then things returned to normal.
Dave
On Wed, 16 Jul 2003 20:56:19 +0200, Vojtech Pavlik wrote:
>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.
This was interesting: 2.5 programs the mouse differently than 2.4.
I've been having ps2 mouse problems with the 2.5 input layer,
including having to move the mouse much further for a given
cursor movement, and a general jerky/unstable feeling of the mouse.
2.4's pc_keyb.c has (disabled by default) init code which puts the
mouse in 100 samples/s and 2:1 scaling, whereas 2.5 puts it into
200 samples/s and 1:1 scaling. So I hacked psmouse-base.c to mimic
2.4, and VOILA! now my mouse feels A LOT better.
The crude patch below shows what I did. (I have to set psmouse_noext
as well, to avoid misidentification, jerkiness/lost syncs, and
utter mayhem upon resume from suspend.)
Would you accept a cleaned up patch which allows the rate and
scaling to be adjusted, similarly to noext and resolution?
/Mikael
--- linux-2.6.0-test1/drivers/input/mouse/psmouse-base.c.~1~ 2003-06-23 13:07:37.000000000 +0200
+++ linux-2.6.0-test1/drivers/input/mouse/psmouse-base.c 2003-07-17 01:23:57.000000000 +0200
@@ -33,7 +33,7 @@
#define PSMOUSE_LOGITECH_SMARTSCROLL 1
-static int psmouse_noext;
+static int psmouse_noext = 1;
int psmouse_resolution;
int psmouse_smartscroll = PSMOUSE_LOGITECH_SMARTSCROLL;
@@ -435,7 +435,7 @@
param[0] = 100;
psmouse_command(psmouse, param, PSMOUSE_CMD_SETRATE);
- param[0] = 200;
+ param[0] = 100;
psmouse_command(psmouse, param, PSMOUSE_CMD_SETRATE);
/*
@@ -443,7 +443,8 @@
*/
psmouse_set_resolution(psmouse);
- psmouse_command(psmouse, NULL, PSMOUSE_CMD_SETSCALE11);
+#define PSMOUSE_CMD_SETSCALE21 0x00e7
+ psmouse_command(psmouse, NULL, PSMOUSE_CMD_SETSCALE21);
/*
* We set the mouse into streaming mode.
On Thu, Jul 17, 2003 at 12:31:24AM +0100, Dave Jones wrote:
> On Wed, Jul 16, 2003 at 10:53:19PM +0200, Vojtech Pavlik wrote:
> > > > 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?
> > >
> > > 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
>
> >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 ...
--
Vojtech Pavlik
SuSE Labs, SuSE CR
Mikael Pettersson wrote:
> >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.
> This was interesting: 2.5 programs the mouse differently than 2.4.
> I've been having ps2 mouse problems with the 2.5 input layer,
> including having to move the mouse much further for a given
> cursor movement, and a general jerky/unstable feeling of the mouse.
Strange. Here I've got problems with my mouse being actually 'to fast'
(when working with X-Window; I had to slow it down about 2 times via
xset to be able to work 'normally'; Actually -since I could not find
any related bugreports or complains - I thought it was something with
how my version of X works with new layer)
> 2.4's pc_keyb.c has (disabled by default) init code which puts the
> mouse in 100 samples/s and 2:1 scaling, whereas 2.5 puts it into
> 200 samples/s and 1:1 scaling. So I hacked psmouse-base.c to mimic
> 2.4, and VOILA! now my mouse feels A LOT better.
And here it goes even faster than before.
Live is indeed full of suprises :)
[cut]
jk
--
Jacek Kawa
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.
On Thu, Jul 17, 2003 at 08:15:11AM +0200, Martin Schlemmer wrote:
> > 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-)]
> the PS/2 and the ide channel is not maybe sharing an irq,
I answered this in my first mail, no it isn't.
>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
--
Dave Jones http://www.codemonkey.org.uk
On Thu, Jul 17, 2003 at 12:15:04PM +0100, Alan Cox wrote:
> 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.
No joy.
Dave
I wrote:
[...]
> > This was interesting: 2.5 programs the mouse differently than 2.4.
> > I've been having ps2 mouse problems with the 2.5 input layer,
> > including having to move the mouse much further for a given
> Strange. Here I've got problems with my mouse being actually 'to fast'
> (when working with X-Window; I had to slow it down about 2 times via
> xset to be able to work 'normally'; Actually -since I could not find
> any related bugreports or complains - I thought it was something with
> how my version of X works with new layer)
Once I upgraded X to 4.3 and changed /dev/psaux to /dev/input/mice
everything is OK (and I'm quite happy it works :)
I guess (now) that it's not much related to other problems mentioned in this
thread, but if you think it might be helpful I can post some more info.
BTW - For testing purposes I've tested few different combinations:
AC -'another computer' MC- 'my computer'; both: kernel 2.6.0t1, recently
upgraded Debian SID
AC X4.2 and /dev/psaux ->ok
X4.3 and /dev/psaux -> ok (I hope my sister won't
be angry, that I've reconfigured
her system when she's back home 8)
MC with different mouse -> no change
MC with different values of xres, yres, psmouse_resolution parameters -> no change
MC, X4.2 and /dev/psaux -> too fast
X4.2 and /dev/psaux & ACPI off -> too fast
X4.3 and /dev/psaux -> too fast
X4.2 and /dev/input/mice -> too fast
(IIRC - I'm _almost_ sure I tried it with
2.5.75 few days ago [and it did not work])
X4.3 and /dev/input/mice -> ok
[cut]
jk :-)
--
Jacek Kawa