On Tuesday, July 7, 2020 3:24pm, "Sean Christopherson"
said:
> On Tue, Jul 07, 2020 at 03:09:38PM -0400, David P. Reed wrote:
>>
>> On Tuesday, July 7, 2020 1:09am, "Sean Christopherson"
>> said:
>> Sean, are you the one who would get this par
On Tuesday, July 7, 2020 1:09am, "Sean Christopherson"
said:
> On Sat, Jul 04, 2020 at 04:38:08PM -0400, David P. Reed wrote:
>> Fix: Mask undefined operation fault during emergency VMXOFF that must be
>> attempted to force cpu exit from VMX root operation.
>>
On Sunday, July 5, 2020 4:55pm, "Andy Lutomirski" said:
> On Sun, Jul 5, 2020 at 12:52 PM David P. Reed wrote:
>>
>> Thanks, will handle these. 2 questions below.
>>
>> On Sunday, July 5, 2020 2:22pm, "Andy Lutomirski" said:
>>
>
On Sunday, July 5, 2020 2:26pm, "Andy Lutomirski" said:
> On Sat, Jul 4, 2020 at 1:38 PM David P. Reed wrote:
>>
>> Fix the logic during crash/panic reboot on Intel processors that
>> can support VMX operation to ensure that all processors are not
>> i
Thanks, will handle these. 2 questions below.
On Sunday, July 5, 2020 2:22pm, "Andy Lutomirski" said:
> On Sat, Jul 4, 2020 at 1:38 PM David P. Reed wrote:
>>
>> Fix: Mask undefined operation fault during emergency VMXOFF that must be
>> attempted to force c
race. Can happen
due to certain kinds of bugs in KVM.
Fixes: 208067 <https://bugzilla.kernel.org/show_bug.cgi?id=208067>
Reported-by: David P. Reed
Suggested-by: Thomas Gleixner
Suggested-by: Sean Christopherson
Suggested-by: Andy Lutomirski
Signed-off-by: David P. Reed
---
arch/x86/inclu
fix to the reported bug, and a lurking
error in asm side effects.
David P. Reed (3):
Correct asm VMXOFF side effects
Fix undefined operation fault that can hang a cpu on crash or panic
Force all cpus to exit VMX root operation on crash/panic reliably
arch/x86/include/asm/virtext.h | 24
reboot.
Builds on cpu_ermergency_vmxoff() and __cpu_emergency_vmxoff() created
in a prior patch.
Suggested-by: Sean Christopherson
Signed-off-by: David P. Reed
---
arch/x86/kernel/reboot.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel
Tell gcc that VMXOFF instruction clobbers condition codes
and memory when executed.
Also, correct original comments to remove kernel-doc syntax
per Randy Dunlap's request.
Suggested-by: Randy Dunlap
Signed-off-by: David P. Reed
---
arch/x86/include/asm/virtext.h | 8
1 file chang
On Monday, June 29, 2020 5:49pm, "Sean Christopherson"
said:
> On Mon, Jun 29, 2020 at 02:22:45PM -0700, Andy Lutomirski wrote:
>>
>>
>> > On Jun 29, 2020, at 1:54 PM, David P. Reed wrote:
>> >
>> > Simple question for those on the To:
d v3 if there is any
likelihood of acceptance. I'm wary of doing more radical changes (like
combining emergency and normal paths).
On Thursday, June 25, 2020 10:59am, "David P. Reed" said:
> Correction to my comment below.
> On Thursday, June 25, 2020 10:45am, "
Correction to my comment below.
On Thursday, June 25, 2020 10:45am, "David P. Reed" said:
> [Sorry: this is resent because my mailer included HTML, rejected by LKML]
> Thanks for the response, Sean ... I had thought everyone was too busy to
> follow up
> from the first ve
cceptance. If it's not going to get accepted after doing that,
my motivation is flagging.
On Thursday, June 25, 2020 2:06am, "Sean Christopherson"
said:
> On Thu, Jun 11, 2020 at 03:48:18PM -0400, David P. Reed wrote:
> > -/** Disable VMX on the current CPU
> > +/
o the chip).
Style errors in original file fixed, at request of Randy Dunlap:
eliminate '/**' in non-kernel-doc comments.
Fixes: 208067 <https://bugzilla.kernel.org/show_bug.cgi?id=208067>
Reported-by: David P. Reed
Reported-by: Randy Dunlap
Suggested-by: Thomas Gleixner
Suggest
o the chip).
Style errors in original file fixed, at request of Randy Dunlap:
eliminate '/**' in non-kernel-doc comments.
Fixes: 208067 <https://bugzilla.kernel.org/show_bug.cgi?id=208067>
Reported-by: David P. Reed
Reported-by: Randy Dunlap
Suggested-by: Thomas Gleixner
Suggest
rather than restart, a manual "reset" is the
only way out of this state (or if there is a BMC, it can issue a RESET
to the chip).
Signed-off-by: David P. Reed
---
arch/x86/include/asm/virtext.h | 24
arch/x86/kernel/reboot.c | 13 ++---
arch/x86/kern
Actually, disparaging things as "one idiotic system" doesn't seem like a
long-term thoughtful process - it's not even accurate. There are more
such systems that are running code today than the total number of 486
systems ever manufactured. The production rate is $1M/month.
a) ENE chips are "
esses to the 8253 PIT.
Fix pcspkr driver to use the new outb_pic call properly, use
named PIC port values rather than hex constants, and drop its use of
inb_p and outb_p in accessing port 61h where it has never been needed.
Signed-off-by: David P. Reed <[EMAIL PROTECTED]>
Index: linux-2.6/dr
.
Signed-off-by: David P. Reed <[EMAIL PROTECTED]>
Index: linux-2.6/include/asm-x86/i8259.h
===
--- linux-2.6.orig/include/asm-x86/i8259.h
+++ linux-2.6/include/asm-x86/i8259.h
@@ -29,7 +29,23 @@ extern void enable_8259A_irq(unsig
Alan Cox wrote:
+unsigned char inb_pic(unsigned int port)
+{
+ /* delay for some accesses to PIC on motherboard or in chipset must be
+ at least one microsecond, but be safe here. */
+ unsigned char value = inb(port);
+ udelay(2);
+ return value;
+}
inline
.
Fix pcspkr driver to use the new outb_pic call properly, use
named PIC port values rather than hex constants, and drop its use of
inb_p and outb_p in accessing port 61h where it has never been needed.
Signed-off-by: David P. Reed <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/input/mi
Oops. the patch I just submitted for i8253.c didn't export the symbol
needed by the pcspkr driver to build it as a module. I will send the
revised patch shortly.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majord
been needed.
Signed-off-by: David P. Reed <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/input/misc/pcspkr.c
===
--- linux-2.6.orig/drivers/input/misc/pcspkr.c
+++ linux-2.6/drivers/input/misc/pcspkr.c
@@ -36,6 +36,7 @@
is to use proper delay strategy,
and in particular to fix crashes that can result from using port 80 writes
on machines that have resources on port 80, such as the ENE chips used by Quanta
in latops it designs and sells to, e.g. HP.
Signed-off-by: David P. Reed <[EMAIL PROTECTED]>
Index: lin
Here are the two revised patches based on Alan Cox's NAK's and suggestions
regarding using the _pic and _pit versions of inb/outb. The new patches
use udelay(2) as a conservative delay for pic and pit, and isolate
that usage in the respective i8253.c and i8259_*.c files.
Together with the already
Rene Herman wrote:
On 17-02-08 23:25, Alan Cox wrote:
On Sun, 17 Feb 2008 16:56:28 -0500 (EST)
"David P. Reed" <[EMAIL PROTECTED]> wrote:
fix init_8259A() which initializes the 8259 PIC to not use outb_pic,
which is a renamed version of outb_p, and delete outb_pic define.
o react to input. Since udelay is correctly
calibrated by the time the pcspkr driver is initialized, we use 1 microsecond
as the timing.
Also shorten lines to less than 80 characters.
Signed-off-by: David P. Reed <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/inp
fix crashes that can result from using port 80 writes
on machines that have resources on port 80, such as the ENE chips used by Quanta
in latops it designs and sells to, e.g. HP.
Signed-off-by: David P. Reed <[EMAIL PROTECTED]>
Index: linux-2.6/arch/x86/kernel/
Signed-off-by: David P. Reed <[EMAIL PROTECTED]>
Index: linux-2.6/arch/x86/kernel/rtc.c
===
--- linux-2.6.orig/arch/x86/kernel/rtc.c
+++ linux-2.6/arch/x86/kernel/rtc.c
@@ -151,8 +151,8 @@ unsigned char rtc_cmos_read(unsigned cha
cleanup motherboard chip io port delays. inb_p and outb_p have traditionally
used a write to port 80 (a non-existent port) as a delay. Though there is an
argument that that is a good delay for devices on the ISA or PCI expansion buses
it is not a good mechanism for devices in the processor chipse
David Woodhouse wrote:
On Fri, 2008-01-11 at 09:35 -0500, David P. Reed wrote:
Using any "unused port" for a delay means that the machine check
feature is wasted and utterly unusable.
Not entirely unusable. You can recover silently from the machine check
if it was one of
Alan Cox wrote:
bus abort on the LPC bus". More problematic is that I would think some
people might want to turn on the AMD feature that generates machine
checks if a bus timeout happens. The whole point of machine checks is
An ISA/LPC bus timeout is fulfilled by the bridge so doesn'
Rene Herman wrote:
On 11-01-08 02:36, Zachary Amsden wrote:
FWIW, I fixed the problem locally by recompiling, changing port 80 to
port 84 in io.h; works great, and doesn't conflict with any occupied
ports.
Might not give you a "proper" delay though. 0xed should be a better
choice...
I d
Rene Herman wrote:
On 10-01-08 01:37, Robert Hancock wrote:
I agree. In this case the BIOS on these laptops is trying to tell us
"port 80 is used for our purposes, do not touch it". We should be
listening.
Listening is fine but what are you going to do after you have
listened? Right, not
Zachary Amsden wrote:
According to Phoenix Technologies book "System BIOS for IBM PCs,
Compatibles and EISA Computers, 2nd Edition", the I/O port list gives
port 0080h R/W Extra page register (temporary storage)
Despite looking, I've never seen it documented anywhere else, but I
believe it
Christer Weinigel wrote:
Did I miss anyting?
Nothing that seems *crucial* going forward for Linux. The fate of
"legacy machines" is really important to get right.
I have a small suggestion in mind that might be helpful in the future:
the "motherboard resources" discovered as PNP0C02 devi
Christer Weinigel wrote:
Argument by personal authority. Thats good.
There is no other kind of argument. Are you claiming supernatural
authority drives your typing fingers, or is your argument based on what
you think you know? I have piles of code that I wrote, spec sheets (now
that I'm bac
Christer Weinigel wrote:
There is no need to use io writes to supposedly/theoretically "unused
ports" to make drivers work on any bus.
ISA included! You can, for example, wait for an ISA bus serial
adapter to put out its next character by looping reading the port
that has the output buffer ful
Alan -
I dug up a DP83901A SNIC datasheet in a quick Google search, while that
wasn't the only such chip, it was one of them. I can forward the PDF
(the www.alldatasheet.com site dynamically creates the download URL), if
anyone wants it.
The relevant passage says, in regard to delaying betwee
Alan Cox wrote:
The natsemi docs here say otherwise. I trust them not you.
As well you should. I am honestly curious (for my own satisfaction) as
to what the natsemi docs say the delay code should do (can't imagine
they say "use io port 80 because it is unused"). I don't have any
copies a
Ondrej Zary wrote:
On Tuesday 08 January 2008 18:24:02 David P. Reed wrote:
Windows these days does delays with timing loops or the scheduler. It
doesn't use a "port". Also, Windows XP only supports machines that tend
not to have timing problems that use delays. Inste
or memory slot that
can be tested.
Almost all of the issues in Linux where _p operations are used are (or
should be) historical - IMO.
Ondrej Zary wrote:
On Tuesday 08 January 2008 02:38:15 David P. Reed wrote:
H. Peter Anvin wrote:
And shoot the designer of this particular
The last time I heard of a 12 MHz bus in a PC system was in the days of
the PC-AT, when some clone makers sped up their buses (pre PCI!!!) in an
attempt to allow adapter card *memory* to run at the 12 MHz speed.
This caused so many industry-wide problems with adapter cards that
couldn't be ins
H. Peter Anvin wrote:
And shoot the designer of this particular microcontroller firmware.
Well, some days I want to shoot the "designer" of the entire Wintel
architecture... it's not exactly "designed" by anybody of course, and
today it's created largely by a collection of Taiwanese and Ch
On another topic. I have indeed determined what device uses port 80 on
Quanta AMD64 laptops from HP.
I had lunch with Jim Gettys of OLPC a week ago; he's an old friend since
he worked on the original X windows system. After telling him my story
about port 80, he mentioned that the OLPC XO m
H. Peter Anvin wrote:
Rene Herman wrote:
Is this only about the ones then left for things like legacy PIC and
PIT? Does anyone care about just sticking in a udelay(2) (or 1) there
as a replacement and call it a day?
PIT is problematic because the PIT may be necessary for udelay setup.
FYI - another quirky Quanta motherboard from HP, with DMI readings
reported to me.
Original Message
Date: Wed, 2 Jan 2008 16:23:27 +1030
From: Joel Stanley <[EMAIL PROTECTED]>
To: David P. Reed <[EMAIL PROTECTED]>
Subject:Re: [PATCH] Option to dis
Alan Cox wrote:
That does imply some muppet 'extended' the debug interface for power
management on your laptop. Also pretty much proves that for such systems
we do have to move from port 0x80 to another delay approach.
Alan - in googling around the net yesterday looking for SuperIO chipsets
Pavel Machek wrote:
2. there is some "meaning" to certain byte values being written (the
_PTS and _WAK use of arguments that come from callers to store into port
80 makes me suspicious.) That might mean that the freeze happens only
when certain values are written, or when they are written close
Alan Cox wrote:
responds to reads differently than "unused" ports. In particular, an
inb takes 1/2 the elapsed time compared to a read to "known" unused port
0xed - 792 tsc ticks for port 80 compared to about 1450 tsc ticks for
port 0xed and other unused ports (tsc at 800 MHz).
Well at
H. Peter Anvin wrote:
Now, I think there is a specific reason to believe that EGA/VGA (but
perhaps not CGA/MDA) didn't need these kinds of hacks: the video cards
of the day was touched, directly, by an interminable number of DOS
applications. CGA/MDA generally *were not*, due to the unsynchr
Richard Harman wrote:
I think I may have a monkey wrench to throw into this, I finally got
around to testing the C1E patch, and the port80 patch. End result:
port80 patch has zero effect on this laptop, and the C1E patch makes
it stable.
Stating that your system is "stable" is not very
Alan Cox wrote:
Now what's interesting is that the outb to port 80 is *faster* than an
outb to an unused port, on my machine. So there's something there -
actually accepting the bus transaction. In the ancient 5150 PC, 80 was
Yes and I even told you a while back how to verify where it
I am so happy that there will be a way for people who don't build their
own kernels to run Linux on their HP and Compaq laptops that have
problems with gazillions of writes to port 80, and I'm also happy that
some of the strange driver code will be cleaned up over time. Thank you
all. Some th
rt" 0xed (as used by some BIOSes as well) for these.
David P. Reed confirmed that port 0xed works for him and provides a
proper delay. The symptoms of _not_ working are a hanging machine,
with "hwclock" use being a direct trigger.
Earlier versions of this att
Besides the two reports of freezes on bugzilla.kernel.org (9511, 6307),
the following two bug reports on bugzilla.redhat.com are almost
certainly due to the same cause (imo, of course): 245834, 227234.
Ubuntu launchpad bug 158849 also seems to report the same problem, for
an HP dv6258se 64-bit
H. Peter Anvin wrote:
David P. Reed wrote:
As support: port 80 on the reporter's (my) HP dv9000z laptop clearly
responds to reads differently than "unused" ports. In particular, an
inb takes 1/2 the elapsed time compared to a read to "known" unused
port 0xed -
H. Peter Anvin wrote:
Rene Herman wrote:
I do not know how universal that is, but _reading_ port 0xf0 might in
fact be sensible then? And should even work on a 386/387 pair? (I
have a 386/387 in fact, although I'd need to dig it up).
No. Someone might have used 0xf0 as a readonly port fo
Ingo -
I finished testing the rolled up patch that you provided. It seems to
work just fine. Thank you for putting this all together and persevering
in this long and complex discussion.
Here are the results, on the offending laptop, using 2.6.24-rc5 plus
that one patch.
First: booted wit
About to start building and testing. It will take a few hours.
Ingo Molnar wrote:
here's an updated rollup patch, against 2.6.24-rc4. David, could you
please try this? This should work out of box on your system, without any
boot option or other tweak needed.
--
To unsubscribe from this
Rene Herman wrote:
No, most definitely not. Having the user select udelay or none through
the kernel config and then the kernel deciding "ah, you know what,
I'll know better and use port access anyway" is _utterly_ broken
behaviour. Software needs to listen to its master.
When acting as an or
Rene Herman wrote:
David: I've plugged in your DMI values in this. Could you perhaps test
this to confirm that it works for you?
Will test it by tomorrow morning.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More maj
The process of safely making delicate changes here is beyond my
responsibility as just a user - believe me, I'm not suggesting that a
risky fix be put in .24. I can patch my own kernels, and I can even
share an unofficial patch with others for now, or suggest that Fedora
and Ubuntu add it to
Allen Martin wrote:
Nothing inside the chipset should be decoding port 80 writes. It's
possible this board has a port 80 decoder wired onto the board that's
misbehaving. I've seen other laptop boards with port 80 decoders
wired onto the board, even if the 7 segment display is only populated
o
ays but with all the pre-calibratin trouble, this might
be the lowest risk method in the short run.
This is partly based on previous patches by Pavel Machek and David P.
Reed.
I hope this is considered half-way correct/sane (note by the way that
it's not a good idea to switch a "nat
H. Peter Anvin wrote:
David P. Reed wrote:
Just a thought for a way to fix the "very early" timing needed to set
up udelay to work in a way that works on all machines. Perhaps we
haven't exploited the BIOS enough: The PC BIOS since the PC AT
(286) has always had a stan
I understand the risks of such a fundamental change, and it may be only
a minor concern, but I did also point out that using an unused port
causes the bus to be tied up for a microsecond or two, which matters on
a fast SMP machine.
Of course all the other concerns you guys are worrying about a
Just a thought for a way to fix the "very early" timing needed to set up
udelay to work in a way that works on all machines. Perhaps we haven't
exploited the BIOS enough: The PC BIOS since the PC AT (286) has
always had a standard "countdown timer" way to delay for n microseconds,
which as f
Avi Kivity wrote:
kvm will forward a virtual machine's writes to port 0x80 to the real
port. The reason is that the write is much faster than exiting and
emulating it; the difference is measurable when compiling kernels.
Now if the cause is simply writing to port 0x80, then we must stop
doin
Andi Kleen wrote:
"
With the additional call this should be completely out of line now to save
code size. Similar for the in variant.
Sure. Want me to make a new patch with the _p croutines out-of-line?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
es.
Signed-off-by: David P. Reed <[EMAIL PROTECTED]>
Index: linux-2.6/arch/x86/boot/compressed/misc_64.c
===
--- linux-2.6.orig/arch/x86/boot/compressed/misc_64.c
+++ linux-2.6/arch/x86/boot/compressed/misc_64.c
@@ -269,10 +269
at I
live in.
Alan Cox wrote:
On Thu, 13 Dec 2007 08:13:29 -0500
"David P. Reed" <[EMAIL PROTECTED]> wrote:
Perhaps what was meant is that ISA-tuned timings make little sense on
devices that are part of the chipset or on the PCI or PCI-X buses?
No.
ISA as LPC bus is
Perhaps what was meant is that ISA-tuned timings make little sense on
devices that are part of the chipset or on the PCI or PCI-X buses?
On the other hand, since we don't know in many cases whether the "_p"
was supposed to mean "the time it takes to execute an "out al,80h" on
whatever bus stru
Port 0xED, just FYI:
cycles: out 1430, in 1370
cycles: out 1429, in 1370
(800 Mhz)
Rene Herman wrote:
On 12-12-07 21:07, David P. Reed wrote:
Sadly, I've been busy with other crises in my day job for the last
few days. I did modify Rene's test program and ran it on my
"p
Sadly, I've been busy with other crises in my day job for the last few
days. I did modify Rene's test program and ran it on my "problem"
machine, with the results below.
The interesting part of this is that port 80 seems to respond to "in"
instructions faster than the presumably "unused" por
Who has attitude problems here? I have indeed learned a lot about assholes.
linux-os (Dick Johnson) wrote:
Yep. We are all wrong. You come out of nowhere and claim to
be right. Goodbye.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
I have been having a fun time testing this on my AMD64x2 system.
Since out's to port 80 hang the system hard after a while, I can run a
test just after booting, but the next run will typically hang it.
I did also test two ports thought to be unused. They do *not* hang the
system. Thus appa
1) I found in a book, the Undocumented PC, that I have lying around that
the "pause" recommended for some old adapter chips on the ISA bus was 1
usec. The book carefully points out on various models of PCs how many
short jumps are required to implement 1 usec, and suggests that for
faster mach
Dick - I didn't work for Don in Boca. I did know him, having met with
him several times when he was still alive. I worked from 1979-1985 as a
consultant and eventually VP R&D, at Software Arts in Cambridge, MA, and
there was a machine we developed the first IBM Visicalc for, in a locked
room
Alan Cox wrote:
The vga driver is somewhat misnamed. In console mode we handle everything
back to MDA/HGA and some HGA adapters do need delays.
No they don't. I really, really, really know this for a fact. I wrote
ASM drivers for every early video adapter and ran them all through Lotus
Which port do you want me to test? Also, I can run the timing test on
my machine if you share the source code so I can build it.
Rene Herman wrote:
On 11-12-07 17:30, Andi Kleen wrote:
Anyways it looks like the discussion here is going in a
a loop. I had hoped David would post his test resul
As the person who started this thread, I'm still puzzled by two things:
1) is there anyone out there who wrote one of these drivers (most listed
below, from a list of those I needed to patch to eliminate refs to _b
calls) or arch specific code (also listed below), who might know why the
_p mac
I am going to do a test on another "unused" port.
However, I realized as I was thinking about this. 0x80 is the
"diagnostic device" port. It is not an "unused" port.
Normally, Linux would support a device like the diagnostic device by
providing a character device, called /dev/post-diagnosis
Alan Cox wrote:
0x80 should be fine for anything PC compatible anyway, its specifically
reserved as a debug port and supported for *exactly* that purpose by
many chipsets.
Disagree. The definitions of PC compatible are quite problematic. I
have the advantage over some of you young guys,
Andi Kleen wrote:
Changing the delay instruction sequence from the outb to short jumps
might be the safe thing.
I don't think that makes sense to do on anything modern. The trouble
is that the jumps will effectively execute near "infinitely fast" on any
modern CPU compared to the bus. But the de
07-12-07 01:23, Robert Hancock wrote:
David P. Reed wrote:
After much, much testing (months, off and on, pursuing hypotheses),
I've discovered that the use of "outb al,0x80" instructions to
"delay" after inb and outb instructions causes solid freezes on my
HP dv9000z la
After much, much testing (months, off and on, pursuing hypotheses), I've
discovered that the use of "outb al,0x80" instructions to "delay" after
inb and outb instructions causes solid freezes on my HP dv9000z laptop,
when ACPI is enabled.
It takes a fair number of out's to 0x80, but the hard f
e
cleanup here makes sense, lest someone copy the bad technique as if it
were good.
Thanks,
tglx
Signed-off-by: David P. Reed <[EMAIL PROTECTED]>
---
Index: linux-2.6/arch/x86/kernel/time_64.c
===
--- linux-2.6.orig
e 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.
Signed-off-by
- when
it is called, which is rarely, it may be at any time during the one
second period, rather than close to 500 msec, so the value written is
needlessly incorrect, too.
Signed-off-by: David P. Reed
---
I have thoroughly tested this on several x86_64 machines, and also
on one 32-bit machine. I h
(&rtc_lock) under the assumption (per a bad comment) that
set_rtc_mmss is called only with interrupts disabled. The call from
ntp.c to update_persistent_clock is made with interrupts enabled.
Signed-off-by: David P. Reed <[EMAIL PROTECTED]>
---
I have thoroughly tested this patch on a
Cool. More reason to separate this into two.
Matt Mackall wrote:
On Wed, Nov 14, 2007 at 08:10:22AM -0500, David P. Reed wrote:
Will make two patches and resend.
I've already got a set of patches brewing to fix the UIP problem across all
the affected arches (11+).
Will make two patches and resend.
Thomas Gleixner wrote:
David,
On Mon, 12 Nov 2007, David P. Reed wrote:
From: David P. Reed
Fix two bugs in arch/x86/kernel/time_64.c that affect the x86_64 kernel. 1) a
repeatable hard freeze due to interrupts when the ntpd service calls
From: David P. Reed
Fix a typo in ntp.c that has caused updating of the persistent (RTC)
clock when synced to NTP to behave erratically.
Signed-off-by: David P. Reed
---
When debugging a freeze that arises on my AMD64 machines when I run the
ntpd service, I added a number of printk'
From: David P. Reed
Fix two bugs in arch/x86/kernel/time_64.c that affect the x86_64 kernel.
1) a repeatable hard freeze due to interrupts when the ntpd service
calls update_persistent_clock(), 2) potentially unstable PC RTC timer
values when timer is read.
Signed-off-by: David P. Reed
From: David P. Reed
Fix a typo in ntp.c that has caused updating of the persistent (RTC)
clock when synced to NTP to behave erratically.
Signed-off-by: David P. Reed
---
When debugging a freeze that arises on my AMD64 machines when I run the
ntpd service, I added a number of printk'
Alan:
Thanks for the comment. I will code a patch, and include a sanity check
as you suggested, and send it for review. Just to clarify one concern
your note raised:
I understand that SMM/SMI servicing can take a long time, but SMM/SMI
shouldn't happen while interrupts are masked using loca
In trying to track down a bug related to hwclock hanging my x86_64
machine, I found myself reading include/asm-generic/rtc.h carefully with
a chipset spec for several RTC chips (in particular, the granddaddy, the
MC146818A) in my hand.
I found that the code in get_rtc_time() is very, very odd,
98 matches
Mail list logo
