From: Max Krasnyansky <maxk@qualcomm.com>
To: george@mvista.com
Cc: john stultz <johnstul@us.ibm.com>, Greg KH <greg@kroah.com>,
ganzinger@mvista.com, lkml <linux-kernel@vger.kernel.org>
Subject: Re: Calibration issues with USB disc present.
Date: Wed, 16 Nov 2005 16:03:34 -0800 [thread overview]
Message-ID: <437BC8D6.4040402@qualcomm.com> (raw)
In-Reply-To: <4379070C.8090709@mvista.com>
George Anzinger wrote:
>>> Oh well, publicly mock the manufacturer for doing horrible things in
>>> their BIOS and then no one will buy the boxes, and we will not have
>>> problems :)
>
> Long term, maybe, but it will not close the bug report I have in hand...
>>
>>
>> I suspect the right fix is in-between. We should try to push hardware
>> makers away from using SMIs recklessly, but we should also do our best
>> to work around those that don't. The same problems crop up w/
>> virtualization where time-based calibration may be interrupted.
>>
>> George, again, there has been some SMI resistant delay calibration code
>> added recently. You mentioned this problem was seen on 2.4 kernel, so
>> you could verify that the new code in 2.6.14 works and if so, try
>> backporting it.
>>
>> If not we need to see what else we can do about improving delay
>> calibration (its a similar tick-based problem to what I'm addressing
>> with the timeofday rework) or reducing the use of delay by using
>> something else.
>>
> I will look at that code, but we also need to address the same problem
> in the TSC calibration area.
I think in the short term your best bet is to globally disable SMI at early
boot stage (ie before TSC calibration).
Some people might argue that it's not the most graceful solution because it might
brake some BIOS features but it's a very common trick that is used by RT folks
(for example RTAI has configurable option to enable SMI workaround) because
on some chipset/BIOS combinations SMIs introduce horrible latencies. And you
cannot do much about that other than disabling SMI.
I have not seen any reports of negative side effects of disabling SMI yet. But
if you're worried about that you could re-enable it later when you're done with
TSC calibration and stuff.
Max
next prev parent reply other threads:[~2005-11-17 0:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-11 21:37 Calibration issues with USB disc present George Anzinger
2005-11-11 21:57 ` john stultz
2005-11-12 5:05 ` Greg KH
2005-11-12 16:06 ` George Anzinger
2005-11-12 21:33 ` Greg KH
2005-11-14 18:56 ` George Anzinger
2005-11-14 18:49 ` Greg KH
2005-11-14 19:46 ` Brad Campbell
2005-11-14 19:43 ` Greg KH
2005-11-14 19:58 ` john stultz
2005-11-14 21:52 ` George Anzinger
2005-11-17 0:03 ` Max Krasnyansky [this message]
2005-11-17 0:30 ` Lee Revell
2005-11-17 17:43 ` Max Krasnyansky
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=437BC8D6.4040402@qualcomm.com \
--to=maxk@qualcomm.com \
--cc=ganzinger@mvista.com \
--cc=george@mvista.com \
--cc=greg@kroah.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
/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