From: "David P. Reed" <dpreed@reed.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org,
Allessandro Zummo <a.zummo@towertech.it>,
Matt Mackall <mpm@selenic.com>
Subject: Re: [PATCH] x86: on x86_64, correct reading of PC RTC when update in progress in time_64.c
Date: Thu, 15 Nov 2007 15:31:37 -0500 [thread overview]
Message-ID: <473CACA9.2090702@reed.com> (raw)
In-Reply-To: <alpine.LFD.0.9999.0711152021270.3112@localhost.localdomain>
There are a couple of things I don't understand on this one. And I
presume you thought the other two bug fixing patches I sent before this
were OK to go, since on my system
Thomas Gleixner wrote:
> Still whitespace wreckage in your patches. I guess the kernel tree you
> made your patches against is already white space wrecked.
>
> I fixed that up manually, but please be more careful about that next
> time.
Um ... I fixed the whitespaces I detected from the first round with
checkpatch.pl. Then for good measure
I ran checkpatch.pl on the patches, then pasted the files directly into
the emails. No problems detected.
And I also just tried checkpatch.pl on the "sent" folder copy. No
problems detected there.
Where was the whitespace? Was it in the patches? Would you mind showing
me the output so I can do a better job in the future?
>
>> Correct potentially unstable PC RTC time register reading in time_64.c
>>
>> Stop the use of an incorrect technique for reading the standard PC RTC
>> timer, which is documented to "disconnect" time registers from the bus
>> while updates are in progress. The use of UIP flag while interrupts
>> are disabled to protect a 244 microsecond window is one of the
>> Motorola spec sheet's documented ways to read the RTC time registers
>> reliably.
>>
>> The patch updates the misleading comments and also minimizes the amount of
>> time that the kernel disables interrupts during the reading.
>>
>
> While I think that the UIP change is correct and a must have, the
> locking change is not really useful. read_persistent_clock is called
> from exactly three places:
>
What locking change? I didn't change how locking works in
read_persistent_clock at all.
I did introduce cpu_relax() because if anyone else ever calls from a hot
path, that would be good practice and its' one line.
> Right after boot, right before suspend and right after resume. None of
> those places is a hot path, where we really care about the interrupt
> enable/disable. IIRC, this is even called with interrupts disabled
> most of the time, so no real gain here.
>
> Another reason not to do the locking change is the paravirt stuff
> which is coming for 64bit. I looked into the existing 32bit code and
> doing the same lock thing would introduce a real nasty hackery, which
> is definitely not worth the trouble.
>
I presume time_64.c and time_32.c will be unified at some point,
discarding time_64.c. There's no arch-specific reason to be separate.
The current time_32.c depends on a different nmi path (that does some
weird stuff saving and restoring the CMOS index register!), and I didn't
dare usurp your long-term plan to unify architectures. But a simple
cleanup here makes sense, lest someone copy the bad technique as if it
were good.
> Thanks,
>
> tglx
>
>
>> Signed-off-by: David P. Reed <dpreed@reed.com>
>> ---
>> Index: linux-2.6/arch/x86/kernel/time_64.c
>> ===================================================================
>> --- linux-2.6.orig/arch/x86/kernel/time_64.c
>> +++ linux-2.6/arch/x86/kernel/time_64.c
>> @@ -160,22 +160,30 @@ unsigned long read_persistent_clock(void
>> unsigned long flags;
>> unsigned century = 0;
>>
>> - spin_lock_irqsave(&rtc_lock, flags);
>> + retry: spin_lock_irqsave(&rtc_lock, flags);
>> + /* if UIP is clear, then we have >= 244 microseconds before RTC
>> + * registers will be updated. Spec sheet says that this is the
>> + * reliable way to read RTC - registers invalid (off bus) during
>> update
>> + */
>> + if ((CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP)) {
>> + spin_unlock_irqrestore(&rtc_lock, flags);
>> + cpu_relax();
>> + goto retry;
>> + }
>>
>> - do {
>> - sec = CMOS_READ(RTC_SECONDS);
>> - min = CMOS_READ(RTC_MINUTES);
>> - hour = CMOS_READ(RTC_HOURS);
>> - day = CMOS_READ(RTC_DAY_OF_MONTH);
>> - mon = CMOS_READ(RTC_MONTH);
>> - year = CMOS_READ(RTC_YEAR);
>> + /* now read all RTC registers while stable with interrupts disabled */
>> +
>> + sec = CMOS_READ(RTC_SECONDS);
>> + min = CMOS_READ(RTC_MINUTES);
>> + hour = CMOS_READ(RTC_HOURS);
>> + day = CMOS_READ(RTC_DAY_OF_MONTH);
>> + mon = CMOS_READ(RTC_MONTH);
>> + year = CMOS_READ(RTC_YEAR);
>> #ifdef CONFIG_ACPI
>> - if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
>> - acpi_gbl_FADT.century)
>> - century = CMOS_READ(acpi_gbl_FADT.century);
>> + if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
>> + acpi_gbl_FADT.century)
>> + century = CMOS_READ(acpi_gbl_FADT.century);
>> #endif
>> - } while (sec != CMOS_READ(RTC_SECONDS));
>> -
>> spin_unlock_irqrestore(&rtc_lock, flags);
>>
>> /*
>>
>>
>>
>
>
next prev parent reply other threads:[~2007-11-15 20:31 UTC|newest]
Thread overview: 184+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <466F0941.9060201@reed.com>
[not found] ` <1181682498.8176.224.camel@chaos>
[not found] ` <469578CD.3080609@reed.com>
[not found] ` <1184216528.12353.203.camel@chaos>
[not found] ` <1184218962.12353.209.camel@chaos>
[not found] ` <46964352.7040301@reed.com>
[not found] ` <1184253339.12353.223.camel@chaos>
[not found] ` <469697C6.50903@reed.com>
[not found] ` <1184274754.12353.254.camel@chaos>
2007-11-12 16:55 ` [PATCH] x86: fix locking and sync bugs in x86_64 RTC code in time_64.c David P. Reed
2007-11-14 7:49 ` Thomas Gleixner
2007-11-14 13:10 ` David P. Reed
2007-11-14 18:26 ` Matt Mackall
2007-11-14 21:22 ` David P. Reed
2007-11-12 17:02 ` [PATCH] time: fix typo that makes sync_cmos_clock erratic David P. Reed
2007-11-14 7:57 ` Thomas Gleixner
2007-11-12 19:19 ` David P. Reed
2007-11-14 22:47 ` [PATCH] x86: fix freeze in x86_64 RTC update code in time_64.c David P. Reed
2007-11-14 22:49 ` [PATCH] time: fix typo that makes sync_cmos_clock erratic David P. Reed
2007-11-15 1:14 ` [PATCH] x86: on x86_64, correct reading of PC RTC when update in progress in time_64.c David P. Reed
2007-11-15 19:33 ` Thomas Gleixner
2007-11-15 20:31 ` David P. Reed [this message]
2007-11-15 22:17 ` Thomas Gleixner
2007-12-14 2:59 ` [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc David P. Reed
2007-12-14 7:49 ` Yinghai Lu
2007-12-14 9:45 ` Rene Herman
2007-12-14 14:23 ` Ingo Molnar
2007-12-14 14:36 ` Rene Herman
2007-12-14 14:46 ` Ingo Molnar
2007-12-14 14:56 ` Rene Herman
2007-12-14 18:36 ` Alan Cox
2007-12-14 18:48 ` H. Peter Anvin
2007-12-14 21:05 ` Pavel Machek
2007-12-15 22:59 ` Pavel Machek
2007-12-14 10:51 ` Andi Kleen
2007-12-14 11:11 ` David P. Reed
2007-12-14 13:15 ` Ingo Molnar
2007-12-14 13:24 ` Ingo Molnar
2007-12-14 13:47 ` Ingo Molnar
2007-12-14 14:41 ` Ingo Molnar
2007-12-14 13:42 ` Rene Herman
2007-12-14 14:03 ` Ingo Molnar
2007-12-14 14:10 ` Rene Herman
2007-12-14 14:21 ` Ingo Molnar
2007-12-14 18:02 ` H. Peter Anvin
2007-12-14 18:23 ` Rene Herman
2007-12-14 21:06 ` Pavel Machek
2007-12-14 22:13 ` H. Peter Anvin
2007-12-14 23:29 ` Alan Cox
2007-12-15 3:04 ` David P. Reed
2007-12-15 5:45 ` H. Peter Anvin
2007-12-15 17:17 ` David P. Reed
2007-12-15 17:46 ` Alan Cox
2007-12-17 22:50 ` Jan Engelhardt
2007-12-17 22:52 ` H. Peter Anvin
2007-12-15 8:08 ` Paul Rolland
2007-12-15 8:13 ` Rene Herman
2007-12-15 20:27 ` H. Peter Anvin
2007-12-15 23:26 ` [PATCH] x86: " Rene Herman
2007-12-15 23:51 ` H. Peter Anvin
2007-12-16 0:05 ` H. Peter Anvin
2007-12-16 13:15 ` [PATCH] x86: provide a DMI based port 0x80 I/O delay override Rene Herman
2007-12-16 15:22 ` Ingo Molnar
2007-12-17 1:43 ` Rene Herman
2007-12-17 2:05 ` H. Peter Anvin
2007-12-17 2:19 ` Rene Herman
2007-12-17 3:35 ` H. Peter Anvin
2007-12-17 13:02 ` Rene Herman
2007-12-17 17:14 ` H. Peter Anvin
2007-12-17 19:43 ` David P. Reed
2007-12-17 19:55 ` H. Peter Anvin
2007-12-17 21:02 ` David P. Reed
2007-12-17 21:17 ` H. Peter Anvin
2007-12-17 21:25 ` Alan Cox
2008-01-01 15:57 ` David P. Reed
2008-01-01 21:16 ` H. Peter Anvin
2008-01-01 15:59 ` David P. Reed
2008-01-01 16:15 ` Alan Cox
2008-01-01 16:43 ` Ingo Molnar
2008-01-01 17:32 ` Alan Cox
2008-01-01 18:45 ` Ingo Molnar
2008-01-01 20:14 ` Christer Weinigel
2008-01-01 21:13 ` Alan Cox
2008-01-01 21:07 ` Alan Cox
2008-01-02 10:04 ` Ingo Molnar
2008-01-02 13:11 ` [linux-kernel] " David P. Reed
2008-01-02 13:21 ` Ingo Molnar
2008-01-02 13:47 ` Alan Cox
2008-01-02 15:35 ` Rene Herman
2008-01-02 15:50 ` Rene Herman
2008-01-01 17:32 ` Christer Weinigel
2008-01-01 18:46 ` Ingo Molnar
2008-01-01 19:35 ` Christer Weinigel
2008-01-01 19:59 ` Rene Herman
2008-01-01 20:55 ` Christer Weinigel
2008-01-01 21:24 ` H. Peter Anvin
2008-01-01 21:01 ` Ingo Molnar
2008-01-01 21:26 ` Alan Cox
2008-01-01 21:42 ` Christer Weinigel
2008-01-01 21:42 ` Rene Herman
2008-01-01 21:50 ` H. Peter Anvin
2008-01-01 21:21 ` H. Peter Anvin
2008-01-01 23:05 ` Christer Weinigel
2008-01-01 23:12 ` Alan Cox
2008-01-02 0:23 ` Christer Weinigel
2008-01-02 10:00 ` Ingo Molnar
2008-01-01 17:32 ` David P. Reed
2008-01-01 17:38 ` Alan Cox
2008-01-01 21:15 ` H. Peter Anvin
2008-01-01 21:35 ` Rene Herman
2008-01-01 21:44 ` H. Peter Anvin
2008-01-01 22:35 ` Rene Herman
2008-01-01 22:39 ` H. Peter Anvin
2008-01-01 23:11 ` Rene Herman
2008-01-02 0:25 ` Rene Herman
2008-01-02 0:55 ` Christer Weinigel
2008-01-02 1:00 ` Rene Herman
2008-01-02 2:27 ` H. Peter Anvin
2008-01-09 17:27 ` Maciej W. Rozycki
2008-01-09 18:18 ` H. Peter Anvin
2008-01-01 17:31 ` Pavel Machek
2008-01-01 17:33 ` David P. Reed
2007-12-17 4:09 ` H. Peter Anvin
2007-12-17 10:57 ` Ingo Molnar
2007-12-17 11:29 ` Ingo Molnar
2007-12-17 13:34 ` David P. Reed
2007-12-17 12:15 ` Rene Herman
2007-12-17 13:09 ` Ingo Molnar
2007-12-17 13:22 ` Rene Herman
2007-12-17 13:31 ` Pavel Machek
2007-12-17 13:31 ` Rene Herman
2007-12-17 13:32 ` David P. Reed
2007-12-17 13:36 ` Rene Herman
2007-12-17 14:39 ` Ingo Molnar
2007-12-17 16:12 ` Alan Cox
2007-12-17 16:48 ` Ingo Molnar
2007-12-17 20:48 ` Rene Herman
2007-12-17 20:57 ` H. Peter Anvin
2007-12-17 21:33 ` Rene Herman
2007-12-17 21:40 ` H. Peter Anvin
2007-12-17 21:46 ` Ingo Molnar
2007-12-17 21:50 ` Rene Herman
2007-12-17 21:41 ` Ingo Molnar
2007-12-17 21:47 ` Rene Herman
2007-12-17 21:56 ` Ingo Molnar
2007-12-17 22:01 ` Rene Herman
2007-12-17 22:18 ` David P. Reed
2007-12-17 19:38 ` David P. Reed
2007-12-17 19:55 ` H. Peter Anvin
2007-12-17 21:28 ` Ingo Molnar
2007-12-16 21:42 ` H. Peter Anvin
2007-12-17 1:48 ` Rene Herman
2007-12-17 1:53 ` H. Peter Anvin
2007-12-16 23:12 ` David P. Reed
2007-12-17 1:56 ` Rene Herman
2007-12-17 2:04 ` H. Peter Anvin
2007-12-17 2:15 ` Rene Herman
2007-12-16 0:23 ` [PATCH] x86: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc David P. Reed
2007-12-15 20:26 ` [PATCH] x86_64: " H. Peter Anvin
2007-12-15 22:55 ` Pavel Machek
2007-12-16 9:27 ` Ingo Molnar
2007-12-17 21:04 ` Rene Herman
2007-12-17 23:20 ` Pavel Machek
2007-12-18 0:06 ` Alan Cox
2007-12-18 15:49 ` Lennart Sorensen
2007-12-17 22:46 ` Jan Engelhardt
2007-12-15 7:43 ` Ingo Molnar
2007-12-15 7:58 ` Rene Herman
2007-12-15 13:27 ` Ingo Molnar
2007-12-15 14:01 ` Rene Herman
2007-12-15 20:25 ` H. Peter Anvin
2007-12-15 14:29 ` Alan Cox
2007-12-15 16:19 ` David P. Reed
2007-12-15 16:48 ` Mark Lord
2007-12-15 17:51 ` Alan Cox
2007-12-15 23:00 ` Pavel Machek
2007-12-15 23:04 ` H. Peter Anvin
2007-12-16 9:40 ` Ingo Molnar
2007-12-16 21:43 ` H. Peter Anvin
2007-12-16 23:06 ` David P. Reed
2007-12-16 23:23 ` Pavel Machek
2007-12-16 23:34 ` H. Peter Anvin
2007-12-26 20:49 ` Pavel Machek
2007-12-17 1:51 ` Rene Herman
2007-12-14 16:08 ` Avi Kivity
2007-12-15 2:13 ` David P. Reed
2007-12-15 2:20 ` H. Peter Anvin
2007-12-15 2:20 ` H. Peter Anvin
2007-12-17 18:14 ` linux-os (Dick Johnson)
2007-12-17 18:54 ` Rene Herman
2007-12-17 18:54 ` Rene Herman
2007-12-19 15:03 ` Avi Kivity
2007-12-19 15:03 ` Avi Kivity
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=473CACA9.2090702@reed.com \
--to=dpreed@reed.com \
--cc=a.zummo@towertech.it \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=tglx@linutronix.de \
/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.