From: john stultz <johnstul@us.ibm.com>
To: Vojtech Pavlik <vojtech@suse.cz>
Cc: Andrew Morton <akpm@osdl.org>,
lkml <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org
Subject: Re: keyboard and USB problems (Re: 2.6.2-rc1-mm2)
Date: Fri, 23 Jan 2004 12:15:03 -0800 [thread overview]
Message-ID: <1074888902.12442.51.camel@localhost> (raw)
In-Reply-To: <20040123195439.GA7878@ucw.cz>
On Fri, 2004-01-23 at 11:54, Vojtech Pavlik wrote:
> On Fri, Jan 23, 2004 at 11:27:41AM -0800, john stultz wrote:
> > Well, loops_per_jiffy is actually being measured correctly as we're
> > using the acpi pm timesource to time udelay(). However there is a loss
> > of resolution using the slower time source, so udelay(1) might take
> > longer then 1 us.
>
> Longer udelay shouldn't cause trouble. Shorter one definitely would.
Hmm.
> > If that is going to cause problems, then we'll need to pull out the
> > use-pmtmr-for-delay_pmtmr patch. I guess our only option is then to use
> > the TSC for delay_pmtrm() (as a loop based delay fails in other cases).
> > I'll write that up and send it your way, Andrew.
>
> I've seen the PM timer breaking the mouse operation rather badly in the
> past, the lost-sync check was triggering for many people when the PM
> timer was used. This implies time inacurracy in the range of 0.5
> seconds. Could that happen somehow?
Not in a way that I yet understand. Do you see similar problems with
folks using clock=pit?
thanks
-john
WARNING: multiple messages have this Message-ID (diff)
From: john stultz <johnstul@us.ibm.com>
To: Vojtech Pavlik <vojtech@suse.cz>
Cc: Andrew Morton <akpm@osdl.org>,
lkml <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org
Subject: Re: keyboard and USB problems (Re: 2.6.2-rc1-mm2)
Date: Fri, 23 Jan 2004 12:15:03 -0800 [thread overview]
Message-ID: <1074888902.12442.51.camel@localhost> (raw)
In-Reply-To: <20040123195439.GA7878@ucw.cz>
On Fri, 2004-01-23 at 11:54, Vojtech Pavlik wrote:
> On Fri, Jan 23, 2004 at 11:27:41AM -0800, john stultz wrote:
> > Well, loops_per_jiffy is actually being measured correctly as we're
> > using the acpi pm timesource to time udelay(). However there is a loss
> > of resolution using the slower time source, so udelay(1) might take
> > longer then 1 us.
>
> Longer udelay shouldn't cause trouble. Shorter one definitely would.
Hmm.
> > If that is going to cause problems, then we'll need to pull out the
> > use-pmtmr-for-delay_pmtmr patch. I guess our only option is then to use
> > the TSC for delay_pmtrm() (as a loop based delay fails in other cases).
> > I'll write that up and send it your way, Andrew.
>
> I've seen the PM timer breaking the mouse operation rather badly in the
> past, the lost-sync check was triggering for many people when the PM
> timer was used. This implies time inacurracy in the range of 0.5
> seconds. Could that happen somehow?
Not in a way that I yet understand. Do you see similar problems with
folks using clock=pit?
thanks
-john
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2004-01-23 20:16 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-23 9:37 2.6.2-rc1-mm2 Andrew Morton
2004-01-23 9:37 ` 2.6.2-rc1-mm2 Andrew Morton
2004-01-23 13:30 ` 2.6.2-rc1-mm2 Thomas Schlichter
2004-01-23 17:59 ` 2.6.2-rc1-mm2 john stultz
2004-01-23 17:59 ` 2.6.2-rc1-mm2 john stultz
2004-01-23 15:12 ` 2.6.2-rc1-mm2 Ed Tomlinson
2004-01-23 15:12 ` 2.6.2-rc1-mm2 Ed Tomlinson
2004-01-23 18:43 ` 2.6.2-rc1-mm2 Andrew Morton
2004-01-23 18:43 ` 2.6.2-rc1-mm2 Andrew Morton
2004-01-24 0:46 ` 2.6.2-rc1-mm2 Ed Tomlinson
2004-01-24 0:46 ` 2.6.2-rc1-mm2 Ed Tomlinson
2004-01-23 16:01 ` keyboard and USB problems (Re: 2.6.2-rc1-mm2) Rudo Thomas
2004-01-23 16:19 ` Vojtech Pavlik
2004-01-23 16:19 ` Vojtech Pavlik
2004-01-23 18:46 ` Andrew Morton
2004-01-23 18:46 ` Andrew Morton
2004-01-23 22:16 ` More timer/bogomip damage (was " Valdis.Kletnieks
2004-01-23 19:27 ` john stultz
2004-01-23 19:27 ` john stultz
2004-01-23 19:54 ` Vojtech Pavlik
2004-01-23 19:54 ` Vojtech Pavlik
2004-01-23 20:15 ` john stultz [this message]
2004-01-23 20:15 ` john stultz
2004-01-23 21:10 ` Vojtech Pavlik
2004-01-23 21:10 ` Vojtech Pavlik
2004-01-24 0:26 ` [PATCH] use-tsc-for-delay_pmtmr.patch john stultz
2004-01-24 0:26 ` john stultz
2004-01-23 17:08 ` 2.6.2-rc1-mm2 (compile stats) John Cherry
2004-01-23 17:08 ` John Cherry
2004-01-23 23:29 ` 2.6.2-rc1-mm2 J.A. Magallon
2004-01-24 6:59 ` 2.6.2-rc1-mm2 Greg KH
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=1074888902.12442.51.camel@localhost \
--to=johnstul@us.ibm.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=vojtech@suse.cz \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.