From: Albert Cahalan <albert@users.sf.net>
To: Andrew Morton <akpm@osdl.org>
Cc: Albert Cahalan <albert@users.sourceforge.net>,
zwane@arm.linux.org.uk, linux-yoann@ifrance.com,
linux-kernel mailing list <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@digeo.com>,
vortex@scyld.com, jgarzik@pobox.com
Subject: Re: another must-fix: major PS/2 mouse problem
Date: 29 Jul 2003 08:40:11 -0400 [thread overview]
Message-ID: <1059482410.3862.120.camel@cube> (raw)
In-Reply-To: <20030728201459.78c8c7c6.akpm@osdl.org>
On Mon, 2003-07-28 at 23:14, Andrew Morton wrote:
> Albert Cahalan <albert@users.sourceforge.net> wrote:
> > 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.
>
> 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.
> (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.
> > 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?
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.
> The person who fixes this gets a Nobel prize.
>
> > 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.
>
> 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.
next prev parent reply other threads:[~2003-07-29 12:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-01 1:46 another must-fix: major PS/2 mouse problem Albert Cahalan
2003-06-04 5:47 ` Yoann
[not found] ` <20030603232155.1488c02f.akpm@digeo.com>
2003-06-04 7:47 ` Vojtech Pavlik
2003-06-04 7:53 ` Andrew Morton
2003-06-04 8:00 ` Vojtech Pavlik
2003-06-04 8:14 ` Andrew Morton
2003-06-04 8:40 ` Vojtech Pavlik
2003-06-04 19:20 ` Yoann
2003-06-04 23:09 ` Albert Cahalan
[not found] ` <3EDCF47A.1060605@ifrance.com>
[not found] ` <1054681254.22103.3750.camel@cube>
[not found] ` <3EDD8850.9060808@ifrance.com>
2003-07-23 0:44 ` Albert Cahalan
2003-07-24 17:30 ` Andrew Morton
2003-07-25 1:46 ` Albert Cahalan
2003-07-26 3:19 ` Andrew Morton
2003-07-26 15:16 ` Zwane Mwaikambo
2003-07-29 2:55 ` Albert Cahalan
2003-07-29 3:14 ` Andrew Morton
2003-07-29 12:40 ` Albert Cahalan [this message]
2003-07-29 18:58 ` Andrew Morton
2003-07-29 19:36 ` Zwane Mwaikambo
2003-07-29 19:43 ` Chris Friesen
2003-07-30 5:08 ` Pavel Machek
2003-07-30 6:32 ` Andrew Morton
2003-07-30 12:29 ` Albert Cahalan
2003-07-30 19:18 Mikael Pettersson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1059482410.3862.120.camel@cube \
--to=albert@users.sf.net \
--cc=akpm@digeo.com \
--cc=akpm@osdl.org \
--cc=albert@users.sourceforge.net \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-yoann@ifrance.com \
--cc=vortex@scyld.com \
--cc=zwane@arm.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).