[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48889C14.4070408@fujitsu-siemens.com>
Date: Thu, 24 Jul 2008 17:13:24 +0200
From: Martin Wilck <martin.wilck@...itsu-siemens.com>
To: Cyrill Gorcunov <gorcunov@...il.com>
CC: Thomas Gleixner <tglx@...utronix.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...or.com>,
"Wichert, Gerhard" <Gerhard.Wichert@...itsu-siemens.com>,
"Maciej W. Rozycki" <macro@...ux-mips.org>
Subject: Re: [PATCH] x86 (64): make calibrate_APIC_clock() SMI-safe
Hi Cyrill,
> btw, Martin, don't get me wrong please - i'm not just complaining :)
> The changes you propose is important enough _but_ it could introduce
> regression. Look, with situation of miscalibrated apic timer kernel
> was working before but with the patch it could stop to work. So if
> user has a such screwed motherboard he could be shocked if it stop
> booting with message about SMI happened. we defenitely have to provide
> some workaround for this. And your max iteration counter solution
> would be fine I think.
Let's see what other people think about this. I am fine with both
solutions. Currently only the first one has been tested though (testing
these patches thoroughly needs long-time reboot tests).
One more remark: There are similar calibration routines around in the
kernel which suffer from similar problems as calibrate_APIC_clock().
AFAIK, only calibrate_delay() was made SMI-safe by Venkatesh Pallipadi
years ago.
Martin
--
Martin Wilck
PRIMERGY System Software Engineer
FSC IP ESP DEV 6
Fujitsu Siemens Computers GmbH
Heinz-Nixdorf-Ring 1
33106 Paderborn
Germany
Tel: ++49 5251 8 15113
Fax: ++49 5251 8 20209
Email: mailto:martin.wilck@...itsu-siemens.com
Internet: http://www.fujitsu-siemens.com
Company Details: http://www.fujitsu-siemens.com/imprint.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists