Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Sun 2007-12-16 15:34:58, H. Peter Anvin wrote: > Pavel Machek wrote: >> Hi! >>> 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 their downstream. >>> >>> May I make a small suggestion, though. If the decision is a DMI-keyed >>> switch from out-80 to udelay(2) gets put in, perhaps there should also >>> be a way for people to test their own configuration for the underlying >>> problem made available as a script. Though it is a "hack", all you need >>> to freeze a problem system is to run a loop doing about 1000 "cat >>> /dev/nvram > /dev/null" commands. If that leads to a freeze, one might >>> ask to have the motherboard added to the DMI-key list. >> Can you freeze it by catting /dev/rtc, too? That may be significant, >> because that is readable for group audio (at least on some >> systems)... which would smell like "small security hole" to me. > > Heck, on my system (Fedora 7), it's mode 644... Ok, time to CC security team, I'd say. Problem is, that some AMD64x2 nVidia laptops crash on port 0x80 access... which is easily user-triggerable by using /dev/rtc. If it is 644 on Fedora, I guess we have a problem. Otoh, it is "only" a denial of service, and it can probably be attributed to "buggy hardware". Is that still relevant for security team? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
On Sun 2007-12-16 15:34:58, H. Peter Anvin wrote: Pavel Machek wrote: Hi! 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 their downstream. May I make a small suggestion, though. If the decision is a DMI-keyed switch from out-80 to udelay(2) gets put in, perhaps there should also be a way for people to test their own configuration for the underlying problem made available as a script. Though it is a hack, all you need to freeze a problem system is to run a loop doing about 1000 cat /dev/nvram /dev/null commands. If that leads to a freeze, one might ask to have the motherboard added to the DMI-key list. Can you freeze it by catting /dev/rtc, too? That may be significant, because that is readable for group audio (at least on some systems)... which would smell like small security hole to me. Heck, on my system (Fedora 7), it's mode 644... Ok, time to CC security team, I'd say. Problem is, that some AMD64x2 nVidia laptops crash on port 0x80 access... which is easily user-triggerable by using /dev/rtc. If it is 644 on Fedora, I guess we have a problem. Otoh, it is only a denial of service, and it can probably be attributed to buggy hardware. Is that still relevant for security team? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
David P. Reed wrote: 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 doing that. But if the reason is the back-to-back writes, when we can keep it, since the other writes will be trapped by kvm and emulated. Do you which is the case? As for kvm, I don't have enough info to know anything about that. Is there a test you'd like me to try? I have a test, but I see that it is broken for mainline. I'll update it eventually, but... I think you are also asking if the crash on these laptops is caused only by back-to-back writes. Actually, it doesn't seem to matter if they are back to back. I can cause the crash if the writes to 80 are very much spread out in time - it seems only to matter how many of them get executed - almost as if there is a buffer overflow. (And of course if you do back to back writes to other ports that are apparently fully unused, such as 0xED on my machine, no crash occurs). I believe (though no one seems to have confirming documentation from the chipset or motherboard vendor) that port 80 is actually functional for some unknown function on these machines. (They do respond to "in" instructions faster than a bus cycle abort does - more evidence). That seems to be sufficient evidence for me to remove port 0x80 pass-through from kvm and emulate it instead. Given that port 80 writes take 1 microsecond, and that an in-kernel exit handler takes a similar amount of time, there won't be any significant performance loss. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
David P. Reed wrote: 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 doing that. But if the reason is the back-to-back writes, when we can keep it, since the other writes will be trapped by kvm and emulated. Do you which is the case? As for kvm, I don't have enough info to know anything about that. Is there a test you'd like me to try? I have a test, but I see that it is broken for mainline. I'll update it eventually, but... I think you are also asking if the crash on these laptops is caused only by back-to-back writes. Actually, it doesn't seem to matter if they are back to back. I can cause the crash if the writes to 80 are very much spread out in time - it seems only to matter how many of them get executed - almost as if there is a buffer overflow. (And of course if you do back to back writes to other ports that are apparently fully unused, such as 0xED on my machine, no crash occurs). I believe (though no one seems to have confirming documentation from the chipset or motherboard vendor) that port 80 is actually functional for some unknown function on these machines. (They do respond to in instructions faster than a bus cycle abort does - more evidence). That seems to be sufficient evidence for me to remove port 0x80 pass-through from kvm and emulate it instead. Given that port 80 writes take 1 microsecond, and that an in-kernel exit handler takes a similar amount of time, there won't be any significant performance loss. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Tue, Dec 18, 2007 at 12:06:08AM +, Alan Cox wrote: > 300MHz 486 -> Nat Semi Geode. > > NextGen as you say are 386 - 586 depending on the BIOS hypercode but I > believe lack WP even in > 386 mode. Geode identifies itself as family 5 though. It may prefer 486 code but it's still family 5. Well Geode GX, SCx200 and LX that is. I imagine the Geode NX would be family 6. -- Len Sorensen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
On Tue, Dec 18, 2007 at 12:06:08AM +, Alan Cox wrote: 300MHz 486 - Nat Semi Geode. NextGen as you say are 386 - 586 depending on the BIOS hypercode but I believe lack WP even in 386 mode. Geode identifies itself as family 5 though. It may prefer 486 code but it's still family 5. Well Geode GX, SCx200 and LX that is. I imagine the Geode NX would be family 6. -- Len Sorensen -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
> > By the way, you have a 300 MHz 486? I believe 3 -> 40, 4 -> 133, 5 -> 233 > > would be good? And I'm not really sure about the etc. P6 has a large range > > again... > > Some nexgen 5x86 boxes were pretty fast, still could not do 486... so > family 3 iirc. 300MHz 486 -> Nat Semi Geode. NextGen as you say are 386 - 586 depending on the BIOS hypercode but I believe lack WP even in > 386 mode. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Mon 2007-12-17 22:04:19, Rene Herman wrote: > On 15-12-07 00:29, Alan Cox wrote: > ?? Just initialize bogomips to 6GHz equivalent... and we are fine until 6GHz cpus come out. >>> How long will that take to boot on a 386? >> Well the dumb approach to fix that would seem to be to initialise it to >> cpu->family 3 -> 50MHz 4 -> 300Mhz 5-> etc... > > By the way, you have a 300 MHz 486? I believe 3 -> 40, 4 -> 133, 5 -> 233 > would be good? And I'm not really sure about the etc. P6 has a large range > again... Some nexgen 5x86 boxes were pretty fast, still could not do 486... so family 3 iirc. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Jan Engelhardt wrote: On Dec 15 2007 17:46, Alan Cox wrote: My understanding is that the linux starts in real mode, and uses the BIOS for such things as reading the very first image. Not always. We may enter from 32bit in some cases, and we may also not have a PC BIOS in the first place. Computers without a PC BIOS (I'm trying to think of something, e.g. the typical SUN sparc64 box) should have other means of accessing a clocksource, no? We were talking about x86 here, though. Even on x86 we sometimes run from the 32-bit entrypoint. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Dec 15 2007 17:46, Alan Cox wrote: > >> My understanding is that the linux starts in real mode, and uses the >> BIOS for such things as reading the very first image. > >Not always. We may enter from 32bit in some cases, and we may also not >have a PC BIOS in the first place. Computers without a PC BIOS (I'm trying to think of something, e.g. the typical SUN sparc64 box) should have other means of accessing a clocksource, no? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Dec 14 2007 14:13, H. Peter Anvin wrote: >> >> ?? Just initialize bogomips to 6GHz equivalent... and we are fine >> until 6GHz cpus come out. > > How long will that take to boot on a 386? > Load it up in bochs and have look at the wallclock. I think that is a good estimate when you have no real 386 nearby. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On 15-12-07 00:29, Alan Cox wrote: ?? Just initialize bogomips to 6GHz equivalent... and we are fine until 6GHz cpus come out. How long will that take to boot on a 386? Well the dumb approach to fix that would seem to be to initialise it to cpu->family 3 -> 50MHz 4 -> 300Mhz 5-> etc... By the way, you have a 300 MHz 486? I believe 3 -> 40, 4 -> 133, 5 -> 233 would be good? And I'm not really sure about the etc. P6 has a large range again... Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On 17-12-07 19:14, linux-os (Dick Johnson) wrote: Attached is a patch that changes the outs to ins on port 0x80. No, that isn't useful. Only a write is "guaranteed" to make ISA/LPC meaning the timing for a read varies wildly. See the in/out cycles results posted earlier. Was also reading the Intel PIIX(3) chiset datasheet today which specifically mentions that only writes flow through to ISA, reads do not. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Fri, 14 Dec 2007, David P. Reed wrote:
> 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
>> doing that. But if the reason is the back-to-back writes, when we can
>> keep it, since the other writes will be trapped by kvm and emulated.
>> Do you which is the case?
>>
> As for kvm, I don't have enough info to know anything about that. Is
> there a test you'd like me to try?
>
> I think you are also asking if the crash on these laptops is caused only
> by back-to-back writes. Actually, it doesn't seem to matter if they are
> back to back. I can cause the crash if the writes to 80 are very much
> spread out in time - it seems only to matter how many of them get
> executed - almost as if there is a buffer overflow. (And of course if
> you do back to back writes to other ports that are apparently fully
> unused, such as 0xED on my machine, no crash occurs).
>
> I believe (though no one seems to have confirming documentation from the
> chipset or motherboard vendor) that port 80 is actually functional for
> some unknown function on these machines. (They do respond to "in"
> instructions faster than a bus cycle abort does - more evidence).
>
> I searched the DSDT to see if there is any evidence of an ACPI use for
> this port, but found nothing.
>
>
Attached is a patch that changes the outs to ins on port 0x80.
I did NOT let gcc decide what to do about modified registers.
Instead, the code saves/restores EAX itself so that all of the
times (whatever they are) are the same.
The code works and is running here. I also patched a very early
version (2.4.26) running on a 400 MHz i486 with an real ISA
bus (Adaptec AHA1453). It works too.
David, will you please try it on your machine. Maybe reading
from the port is less harmful than writing.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.27 BogoMips).
My book : http://www.AbominableFirebug.com/
_
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or disclosing them.
Thank you.--- linux-2.6.22.1/include/asm-i386/io.h.orig 2007-07-10 14:56:30.0
-0400
+++ linux-2.6.22.1/include/asm-i386/io.h2007-12-17 12:06:10.0
-0500
@@ -252,7 +252,10 @@
static inline void native_io_delay(void)
{
- asm volatile("outb %%al,$0x80" : : : "memory");
+ asm volatile( "pushl %%eax\n\t"
+ "inb $0x80, %%al\n\t"
+ "popl %%eax\n\t"
+: : : "memory");
}
#if defined(CONFIG_PARAVIRT)
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
* Robert Hancock <[EMAIL PROTECTED]> wrote: >> unfortunately this hack's side-effects are mis-used by an unknown >> number of drivers to mask PCI posting bugs. We want to figure out >> those bugs (safely and carefully) and we want to remove this hack >> from modern machines that dont need it. Doing anything else would be >> superstition. > > Are there any such examples known of such drivers? It doesn't seem to > make much sense.. PCI IO writes are not posted on any known system > (the spec allows them to be posted in the host bus bridge, but if they > were they could only be flushed by a read, not a write) and PCI MMIO > writes are only guaranteed to flush by doing a read from that device, > not by other random port accesses. I suppose using the _p versions of > port accesses might happen to mask such problems on certain machines.. yeah, that's the fear - that timing sensitivities or outright races are hidden via _p() uses. It's a bit like the BKL - nobody really knows why it's still needed in some places but there's "fear" that "stuff might break" so removal is very slow. So we should get rid of all _p() uses, by either removing them (concluding that the _p() was not needed), or by adding in an udelay(2) (documenting that the device indeed relies on the delay from the host side) or by adding whatever posting/flushing is needed. That will gradually reduce the amount of code that uses _p() methods, and will improve the quality of the kernel. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
* Robert Hancock [EMAIL PROTECTED] wrote: unfortunately this hack's side-effects are mis-used by an unknown number of drivers to mask PCI posting bugs. We want to figure out those bugs (safely and carefully) and we want to remove this hack from modern machines that dont need it. Doing anything else would be superstition. Are there any such examples known of such drivers? It doesn't seem to make much sense.. PCI IO writes are not posted on any known system (the spec allows them to be posted in the host bus bridge, but if they were they could only be flushed by a read, not a write) and PCI MMIO writes are only guaranteed to flush by doing a read from that device, not by other random port accesses. I suppose using the _p versions of port accesses might happen to mask such problems on certain machines.. yeah, that's the fear - that timing sensitivities or outright races are hidden via _p() uses. It's a bit like the BKL - nobody really knows why it's still needed in some places but there's fear that stuff might break so removal is very slow. So we should get rid of all _p() uses, by either removing them (concluding that the _p() was not needed), or by adding in an udelay(2) (documenting that the device indeed relies on the delay from the host side) or by adding whatever posting/flushing is needed. That will gradually reduce the amount of code that uses _p() methods, and will improve the quality of the kernel. Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
On Fri, 14 Dec 2007, David P. Reed wrote:
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
doing that. But if the reason is the back-to-back writes, when we can
keep it, since the other writes will be trapped by kvm and emulated.
Do you which is the case?
As for kvm, I don't have enough info to know anything about that. Is
there a test you'd like me to try?
I think you are also asking if the crash on these laptops is caused only
by back-to-back writes. Actually, it doesn't seem to matter if they are
back to back. I can cause the crash if the writes to 80 are very much
spread out in time - it seems only to matter how many of them get
executed - almost as if there is a buffer overflow. (And of course if
you do back to back writes to other ports that are apparently fully
unused, such as 0xED on my machine, no crash occurs).
I believe (though no one seems to have confirming documentation from the
chipset or motherboard vendor) that port 80 is actually functional for
some unknown function on these machines. (They do respond to in
instructions faster than a bus cycle abort does - more evidence).
I searched the DSDT to see if there is any evidence of an ACPI use for
this port, but found nothing.
Attached is a patch that changes the outs to ins on port 0x80.
I did NOT let gcc decide what to do about modified registers.
Instead, the code saves/restores EAX itself so that all of the
times (whatever they are) are the same.
The code works and is running here. I also patched a very early
version (2.4.26) running on a 400 MHz i486 with an real ISA
bus (Adaptec AHA1453). It works too.
David, will you please try it on your machine. Maybe reading
from the port is less harmful than writing.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.27 BogoMips).
My book : http://www.AbominableFirebug.com/
_
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or disclosing them.
Thank you.--- linux-2.6.22.1/include/asm-i386/io.h.orig 2007-07-10 14:56:30.0
-0400
+++ linux-2.6.22.1/include/asm-i386/io.h2007-12-17 12:06:10.0
-0500
@@ -252,7 +252,10 @@
static inline void native_io_delay(void)
{
- asm volatile(outb %%al,$0x80 : : : memory);
+ asm volatile( pushl %%eax\n\t
+ inb $0x80, %%al\n\t
+ popl %%eax\n\t
+: : : memory);
}
#if defined(CONFIG_PARAVIRT)
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
On 17-12-07 19:14, linux-os (Dick Johnson) wrote: Attached is a patch that changes the outs to ins on port 0x80. No, that isn't useful. Only a write is guaranteed to make ISA/LPC meaning the timing for a read varies wildly. See the in/out cycles results posted earlier. Was also reading the Intel PIIX(3) chiset datasheet today which specifically mentions that only writes flow through to ISA, reads do not. Rene. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
On 15-12-07 00:29, Alan Cox wrote: ?? Just initialize bogomips to 6GHz equivalent... and we are fine until 6GHz cpus come out. How long will that take to boot on a 386? Well the dumb approach to fix that would seem to be to initialise it to cpu-family 3 - 50MHz 4 - 300Mhz 5- etc... By the way, you have a 300 MHz 486? I believe 3 - 40, 4 - 133, 5 - 233 would be good? And I'm not really sure about the etc. P6 has a large range again... Rene. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
On Dec 14 2007 14:13, H. Peter Anvin wrote: ?? Just initialize bogomips to 6GHz equivalent... and we are fine until 6GHz cpus come out. How long will that take to boot on a 386? Load it up in bochs and have look at the wallclock. I think that is a good estimate when you have no real 386 nearby. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
On Dec 15 2007 17:46, Alan Cox wrote: My understanding is that the linux starts in real mode, and uses the BIOS for such things as reading the very first image. Not always. We may enter from 32bit in some cases, and we may also not have a PC BIOS in the first place. Computers without a PC BIOS (I'm trying to think of something, e.g. the typical SUN sparc64 box) should have other means of accessing a clocksource, no? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
Jan Engelhardt wrote: On Dec 15 2007 17:46, Alan Cox wrote: My understanding is that the linux starts in real mode, and uses the BIOS for such things as reading the very first image. Not always. We may enter from 32bit in some cases, and we may also not have a PC BIOS in the first place. Computers without a PC BIOS (I'm trying to think of something, e.g. the typical SUN sparc64 box) should have other means of accessing a clocksource, no? We were talking about x86 here, though. Even on x86 we sometimes run from the 32-bit entrypoint. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
On Mon 2007-12-17 22:04:19, Rene Herman wrote: On 15-12-07 00:29, Alan Cox wrote: ?? Just initialize bogomips to 6GHz equivalent... and we are fine until 6GHz cpus come out. How long will that take to boot on a 386? Well the dumb approach to fix that would seem to be to initialise it to cpu-family 3 - 50MHz 4 - 300Mhz 5- etc... By the way, you have a 300 MHz 486? I believe 3 - 40, 4 - 133, 5 - 233 would be good? And I'm not really sure about the etc. P6 has a large range again... Some nexgen 5x86 boxes were pretty fast, still could not do 486... so family 3 iirc. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
By the way, you have a 300 MHz 486? I believe 3 - 40, 4 - 133, 5 - 233 would be good? And I'm not really sure about the etc. P6 has a large range again... Some nexgen 5x86 boxes were pretty fast, still could not do 486... so family 3 iirc. 300MHz 486 - Nat Semi Geode. NextGen as you say are 386 - 586 depending on the BIOS hypercode but I believe lack WP even in 386 mode. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On 16-12-07 22:43, H. Peter Anvin wrote: Again, 24 is "right out". 25 is a "maybe", IMO. Rene's fix could be an exception, since it is a DMI-keyed workaround for a specific machine and doesn't change behaviour in general. I've not much opinion on the schedule as I've not the problem but yes, it's intended as the low risk option. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Ingo Molnar wrote: * H. Peter Anvin <[EMAIL PROTECTED]> wrote: Pavel Machek wrote: this is also something for v2.6.24 merging. As much as I like this patch, I do not think it is suitable for .24. Too risky, I'd say. No kidding! We're talking about removing a hack that has been successful on thousands of pieces of hardware over 15 years because it ^[*] breaks ONE machine. [*] "- none of which needs it anymore -" there, fixed it for you ;-) So lets keep this in perspective: this is a hack that only helps on a very low number of systems. (the PIT of one PII era chipset is known to be affected) unfortunately this hack's side-effects are mis-used by an unknown number of drivers to mask PCI posting bugs. We want to figure out those bugs (safely and carefully) and we want to remove this hack from modern machines that dont need it. Doing anything else would be superstition. Are there any such examples known of such drivers? It doesn't seem to make much sense.. PCI IO writes are not posted on any known system (the spec allows them to be posted in the host bus bridge, but if they were they could only be flushed by a read, not a write) and PCI MMIO writes are only guaranteed to flush by doing a read from that device, not by other random port accesses. I suppose using the _p versions of port accesses might happen to mask such problems on certain machines.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
David P. Reed wrote: PS: If I have time, I may try to build Rene's port 80 test for Windows and run it under WinXP on this machine (I still have a crappy little partition that boots it). If it freezes the same way, it's almost certain a design "feature", and if it doesn't freeze, we might suspect that there is compensating logic in either Windows ACPI code or some way that windows "sets up" the machine. You'd have to replace the iopl call to an equivalent one for Windows (seems like NtSetInformationProcess(ProcessUserModeIOPL) might do what you need). -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Pavel Machek wrote: Hi! 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 their downstream. May I make a small suggestion, though. If the decision is a DMI-keyed switch from out-80 to udelay(2) gets put in, perhaps there should also be a way for people to test their own configuration for the underlying problem made available as a script. Though it is a "hack", all you need to freeze a problem system is to run a loop doing about 1000 "cat /dev/nvram > /dev/null" commands. If that leads to a freeze, one might ask to have the motherboard added to the DMI-key list. Can you freeze it by catting /dev/rtc, too? That may be significant, because that is readable for group audio (at least on some systems)... which would smell like "small security hole" to me. Pavel Heck, on my system (Fedora 7), it's mode 644... -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Hi! > 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 their downstream. > > May I make a small suggestion, though. If the decision is a DMI-keyed > switch from out-80 to udelay(2) gets put in, perhaps there should also be > a way for people to test their own configuration for the underlying problem > made available as a script. Though it is a "hack", all you need to freeze > a problem system is to run a loop doing about 1000 "cat /dev/nvram > > /dev/null" commands. If that leads to a freeze, one might ask to have the > motherboard added to the DMI-key list. Can you freeze it by catting /dev/rtc, too? That may be significant, because that is readable for group audio (at least on some systems)... which would smell like "small security hole" to me. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
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 their downstream. May I make a small suggestion, though. If the decision is a DMI-keyed switch from out-80 to udelay(2) gets put in, perhaps there should also be a way for people to test their own configuration for the underlying problem made available as a script. Though it is a "hack", all you need to freeze a problem system is to run a loop doing about 1000 "cat /dev/nvram > /dev/null" commands. If that leads to a freeze, one might ask to have the motherboard added to the DMI-key list. H. Peter Anvin wrote: Ingo Molnar wrote: * H. Peter Anvin <[EMAIL PROTECTED]> wrote: Pavel Machek wrote: this is also something for v2.6.24 merging. As much as I like this patch, I do not think it is suitable for .24. Too risky, I'd say. No kidding! We're talking about removing a hack that has been successful on thousands of pieces of hardware over 15 years because it ^[*] breaks ONE machine. [*] "- none of which needs it anymore -" there, fixed it for you ;-) So lets keep this in perspective: this is a hack that only helps on a very low number of systems. (the PIT of one PII era chipset is known to be affected) Yes, but the status quo has been *tested* on thousands of systems and is known to work. Thus, changing it puts things into unknown territory, even if only a small number of machines actually need the current configuration. Heck, there are only a small number of 386/486 machines still in operation and being actively updated. unfortunately this hack's side-effects are mis-used by an unknown number of drivers to mask PCI posting bugs. We want to figure out those bugs (safely and carefully) and we want to remove this hack from modern machines that dont need it. Doing anything else would be superstition. anyway, we likely wont be doing anything about this in .24. Again, 24 is "right out". 25 is a "maybe", IMO. Rene's fix could be an exception, since it is a DMI-keyed workaround for a specific machine and doesn't change behaviour in general. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Ingo Molnar wrote: * H. Peter Anvin <[EMAIL PROTECTED]> wrote: Pavel Machek wrote: this is also something for v2.6.24 merging. As much as I like this patch, I do not think it is suitable for .24. Too risky, I'd say. No kidding! We're talking about removing a hack that has been successful on thousands of pieces of hardware over 15 years because it ^[*] breaks ONE machine. [*] "- none of which needs it anymore -" there, fixed it for you ;-) So lets keep this in perspective: this is a hack that only helps on a very low number of systems. (the PIT of one PII era chipset is known to be affected) Yes, but the status quo has been *tested* on thousands of systems and is known to work. Thus, changing it puts things into unknown territory, even if only a small number of machines actually need the current configuration. Heck, there are only a small number of 386/486 machines still in operation and being actively updated. unfortunately this hack's side-effects are mis-used by an unknown number of drivers to mask PCI posting bugs. We want to figure out those bugs (safely and carefully) and we want to remove this hack from modern machines that dont need it. Doing anything else would be superstition. anyway, we likely wont be doing anything about this in .24. Again, 24 is "right out". 25 is a "maybe", IMO. Rene's fix could be an exception, since it is a DMI-keyed workaround for a specific machine and doesn't change behaviour in general. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
* H. Peter Anvin <[EMAIL PROTECTED]> wrote: > Pavel Machek wrote: >>> >>> this is also something for v2.6.24 merging. >> >> As much as I like this patch, I do not think it is suitable for >> .24. Too risky, I'd say. >> > > No kidding! We're talking about removing a hack that has been > successful on thousands of pieces of hardware over 15 years because it ^[*] > breaks ONE machine. [*] "- none of which needs it anymore -" there, fixed it for you ;-) So lets keep this in perspective: this is a hack that only helps on a very low number of systems. (the PIT of one PII era chipset is known to be affected) unfortunately this hack's side-effects are mis-used by an unknown number of drivers to mask PCI posting bugs. We want to figure out those bugs (safely and carefully) and we want to remove this hack from modern machines that dont need it. Doing anything else would be superstition. anyway, we likely wont be doing anything about this in .24. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
* H. Peter Anvin <[EMAIL PROTECTED]> wrote: > Paul Rolland wrote: >> Just an idea : from what I've read, the problem (port 80 hanging) only occurs >> on 'modern' machines... > > It happens on *one single* "modern" machine... > > Let's keep that in perspective. two or three i think (and an unknown of others where "random, unexplained freezes" were thought to be hw borkage), but yeah, it's still a very low proportion. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
Ingo Molnar wrote: * H. Peter Anvin [EMAIL PROTECTED] wrote: Pavel Machek wrote: this is also something for v2.6.24 merging. As much as I like this patch, I do not think it is suitable for .24. Too risky, I'd say. No kidding! We're talking about removing a hack that has been successful on thousands of pieces of hardware over 15 years because it ^[*] breaks ONE machine. [*] - none of which needs it anymore - there, fixed it for you ;-) So lets keep this in perspective: this is a hack that only helps on a very low number of systems. (the PIT of one PII era chipset is known to be affected) Yes, but the status quo has been *tested* on thousands of systems and is known to work. Thus, changing it puts things into unknown territory, even if only a small number of machines actually need the current configuration. Heck, there are only a small number of 386/486 machines still in operation and being actively updated. unfortunately this hack's side-effects are mis-used by an unknown number of drivers to mask PCI posting bugs. We want to figure out those bugs (safely and carefully) and we want to remove this hack from modern machines that dont need it. Doing anything else would be superstition. anyway, we likely wont be doing anything about this in .24. Again, 24 is right out. 25 is a maybe, IMO. Rene's fix could be an exception, since it is a DMI-keyed workaround for a specific machine and doesn't change behaviour in general. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
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 their downstream. May I make a small suggestion, though. If the decision is a DMI-keyed switch from out-80 to udelay(2) gets put in, perhaps there should also be a way for people to test their own configuration for the underlying problem made available as a script. Though it is a hack, all you need to freeze a problem system is to run a loop doing about 1000 cat /dev/nvram /dev/null commands. If that leads to a freeze, one might ask to have the motherboard added to the DMI-key list. H. Peter Anvin wrote: Ingo Molnar wrote: * H. Peter Anvin [EMAIL PROTECTED] wrote: Pavel Machek wrote: this is also something for v2.6.24 merging. As much as I like this patch, I do not think it is suitable for .24. Too risky, I'd say. No kidding! We're talking about removing a hack that has been successful on thousands of pieces of hardware over 15 years because it ^[*] breaks ONE machine. [*] - none of which needs it anymore - there, fixed it for you ;-) So lets keep this in perspective: this is a hack that only helps on a very low number of systems. (the PIT of one PII era chipset is known to be affected) Yes, but the status quo has been *tested* on thousands of systems and is known to work. Thus, changing it puts things into unknown territory, even if only a small number of machines actually need the current configuration. Heck, there are only a small number of 386/486 machines still in operation and being actively updated. unfortunately this hack's side-effects are mis-used by an unknown number of drivers to mask PCI posting bugs. We want to figure out those bugs (safely and carefully) and we want to remove this hack from modern machines that dont need it. Doing anything else would be superstition. anyway, we likely wont be doing anything about this in .24. Again, 24 is right out. 25 is a maybe, IMO. Rene's fix could be an exception, since it is a DMI-keyed workaround for a specific machine and doesn't change behaviour in general. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
Hi! 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 their downstream. May I make a small suggestion, though. If the decision is a DMI-keyed switch from out-80 to udelay(2) gets put in, perhaps there should also be a way for people to test their own configuration for the underlying problem made available as a script. Though it is a hack, all you need to freeze a problem system is to run a loop doing about 1000 cat /dev/nvram /dev/null commands. If that leads to a freeze, one might ask to have the motherboard added to the DMI-key list. Can you freeze it by catting /dev/rtc, too? That may be significant, because that is readable for group audio (at least on some systems)... which would smell like small security hole to me. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
Pavel Machek wrote: Hi! 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 their downstream. May I make a small suggestion, though. If the decision is a DMI-keyed switch from out-80 to udelay(2) gets put in, perhaps there should also be a way for people to test their own configuration for the underlying problem made available as a script. Though it is a hack, all you need to freeze a problem system is to run a loop doing about 1000 cat /dev/nvram /dev/null commands. If that leads to a freeze, one might ask to have the motherboard added to the DMI-key list. Can you freeze it by catting /dev/rtc, too? That may be significant, because that is readable for group audio (at least on some systems)... which would smell like small security hole to me. Pavel Heck, on my system (Fedora 7), it's mode 644... -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
David P. Reed wrote: PS: If I have time, I may try to build Rene's port 80 test for Windows and run it under WinXP on this machine (I still have a crappy little partition that boots it). If it freezes the same way, it's almost certain a design feature, and if it doesn't freeze, we might suspect that there is compensating logic in either Windows ACPI code or some way that windows sets up the machine. You'd have to replace the iopl call to an equivalent one for Windows (seems like NtSetInformationProcess(ProcessUserModeIOPL) might do what you need). -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
Ingo Molnar wrote: * H. Peter Anvin [EMAIL PROTECTED] wrote: Pavel Machek wrote: this is also something for v2.6.24 merging. As much as I like this patch, I do not think it is suitable for .24. Too risky, I'd say. No kidding! We're talking about removing a hack that has been successful on thousands of pieces of hardware over 15 years because it ^[*] breaks ONE machine. [*] - none of which needs it anymore - there, fixed it for you ;-) So lets keep this in perspective: this is a hack that only helps on a very low number of systems. (the PIT of one PII era chipset is known to be affected) unfortunately this hack's side-effects are mis-used by an unknown number of drivers to mask PCI posting bugs. We want to figure out those bugs (safely and carefully) and we want to remove this hack from modern machines that dont need it. Doing anything else would be superstition. Are there any such examples known of such drivers? It doesn't seem to make much sense.. PCI IO writes are not posted on any known system (the spec allows them to be posted in the host bus bridge, but if they were they could only be flushed by a read, not a write) and PCI MMIO writes are only guaranteed to flush by doing a read from that device, not by other random port accesses. I suppose using the _p versions of port accesses might happen to mask such problems on certain machines.. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
On 16-12-07 22:43, H. Peter Anvin wrote: Again, 24 is right out. 25 is a maybe, IMO. Rene's fix could be an exception, since it is a DMI-keyed workaround for a specific machine and doesn't change behaviour in general. I've not much opinion on the schedule as I've not the problem but yes, it's intended as the low risk option. Rene. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
* H. Peter Anvin [EMAIL PROTECTED] wrote: Paul Rolland wrote: Just an idea : from what I've read, the problem (port 80 hanging) only occurs on 'modern' machines... It happens on *one single* modern machine... Let's keep that in perspective. two or three i think (and an unknown of others where random, unexplained freezes were thought to be hw borkage), but yeah, it's still a very low proportion. Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
* H. Peter Anvin [EMAIL PROTECTED] wrote: Pavel Machek wrote: this is also something for v2.6.24 merging. As much as I like this patch, I do not think it is suitable for .24. Too risky, I'd say. No kidding! We're talking about removing a hack that has been successful on thousands of pieces of hardware over 15 years because it ^[*] breaks ONE machine. [*] - none of which needs it anymore - there, fixed it for you ;-) So lets keep this in perspective: this is a hack that only helps on a very low number of systems. (the PIT of one PII era chipset is known to be affected) unfortunately this hack's side-effects are mis-used by an unknown number of drivers to mask PCI posting bugs. We want to figure out those bugs (safely and carefully) and we want to remove this hack from modern machines that dont need it. Doing anything else would be superstition. anyway, we likely wont be doing anything about this in .24. Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Pavel Machek wrote: this is also something for v2.6.24 merging. As much as I like this patch, I do not think it is suitable for .24. Too risky, I'd say. No kidding! We're talking about removing a hack that has been successful on thousands of pieces of hardware over 15 years because it breaks ONE machine. If this should be done at all it should be done in the most careful manner possible. 2.6.25 would be an aggressive schedule. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Fri 2007-12-14 14:15:03, Ingo Molnar wrote: > > * David P. Reed <[EMAIL PROTECTED]> wrote: > > > Replace use of outb to "unused" diagnostic port 0x80 for time delay > > with udelay based time delay on x86_64 architecture machines. Fix for > > bugs 9511 and 6307 in bugzilla, plus bugs reported in > > bugzilla.redhat.com. > > > > Derived from suggestion (that didn't compile) by Pavel Machek, and > > tested, also based on measurements of typical timings of out's > > collated by Rene Herman from many in the community. > > > > This patch fixes a number of bugs known to cause problems on HP > > Pavilion dv9000z and dv6000z laptops - in the form of solid freezes > > when hwclock is used to show or set the time. Also, it potentially > > improves bus utilization on SMP machines, by using a waiting process > > that doesn't tie up the ISA/LPC bus for 1 or 2 microseconds. > > > > i386 family fixes (completely parallel) were not included, considering > > that such machines might involve more risk of problems on legacy > > machines. > > wow, cool fix! (I remember that there were other systems as well that > are affected by port 0x80 muckery - i thought we had removed port 0x80 > accesses long ago.) > > how about the simpler fix below, as a first-level approach? We can then > remove the _p in/out sequences after this. > > this is also something for v2.6.24 merging. As much as I like this patch, I do not think it is suitable for .24. Too risky, I'd say. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Fri 2007-12-14 15:23:55, Ingo Molnar wrote: > > * Rene Herman <[EMAIL PROTECTED]> wrote: > > > --- a/init/main.c > > +++ b/init/main.c > > @@ -229,10 +229,9 @@ static int __init obsolete_checksetup(char *line) > > } > > > > /* > > - * This should be approx 2 Bo*oMips to start (note initial shift), and will > > - * still work even if initially too large, it will just take slightly > > longer > > + * Initial value roughly corresponds to a 1 GHz CPU > > */ > > -unsigned long loops_per_jiffy = (1<<12); > > +unsigned long loops_per_jiffy = 10 / HZ; > > > > EXPORT_SYMBOL(loops_per_jiffy); > > this is a factor of ~2400 increase - this will take an eternity to boot > on any older CPU. I don't think we are using outb_p before loops_per_jiffy are initialized -- I believe I'd see oopsen if we did. Factor 2400 increase is bad, but if it only converts 10x 1usec delay into 10x 24msec delay, it is not _that_ bad. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Sat 2007-12-15 12:26:26, H. Peter Anvin wrote: > Paul Rolland wrote: >> Just an idea : from what I've read, the problem (port 80 hanging) only >> occurs >> on 'modern' machines... > > It happens on *one single* "modern" machine... > > Let's keep that in perspective. it hurts on other machines (like debug leds being useless), and it may be incorrect as soon as you insert leds-on-port-0x80-on-PCI card. No, it is not critical but yes, I'd like to see it fixed. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Paul Rolland wrote: Just an idea : from what I've read, the problem (port 80 hanging) only occurs on 'modern' machines... It happens on *one single* "modern" machine... Let's keep that in perspective. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Rene Herman wrote: Yes, just posted a Patch-For-Comments that switches on the availability of a TSC (tsc_init sets tsc_disable also for !cpu_has_tsc) which would mean that only really old stuff would be using the outb still. A TSC is really all we need to have a sensible udelay(). Uhm, no. You have no clue what the speed of the TSC is until you have been able to calibrate it against a fixed timesource - like the PIT. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Rene Herman wrote: It's really going to have to be a known _un_used register and (the write direction of) port 0x80 is used exactly for that reason. Port 0xed is a known "alternate diagnostic port" used by Phoenix BIOSes at least but Peter Anvin reported trouble with that one -- probably for the outb direction but assuming that means something was in fact responding, we'd have the same timing problem. Yes, for the outbound direction. I believe we have two "good" options: 1) port 0xed was tested by the current reporter and found to be safe (and provide slow enough timing). If DMI based quirk hacks are available soon enough we can switch 0x80 to 0xed based on it. Are they? DMI is just a data structure parked in memory, so it should at least be theoretically possible to get to it. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
> 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. And I did point out I'd found locking cases that may be relying upon this > I also note that curent machines like the problem machine have ACPI, and > maybe those would be the ones that vendors might start to define port 80 > to mean something. As I noted, it /seems/ to be only when ACPI is turned Port 0x80 means debug. You appear to have a laptop with some kind of buggy firmware that wants a BIOS update. Everyone use 0x80 for debug - its in the chipset hardware quite often. > My belief is that my machine has some device that is responding to port > 80 by doing something. And that something requires some other program > to "service" port 80 in some way. But it sure would be nice to know. > I can't personally sand off the top of the chipset to put probes into it > - so my normal approach of putting a logic analyzer on the bus doesn't work. Almost certainly a SMI trap. > PS: If I have time, I may try to build Rene's port 80 test for Windows > and run it under WinXP on this machine That would be very interesting. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
> My understanding is that the linux starts in real mode, and uses the > BIOS for such things as reading the very first image. Not always. We may enter from 32bit in some cases, and we may also not have a PC BIOS in the first place. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
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 standard "countdown timer" way to delay for n microseconds, which as far as I know still works. This can be used to measure the speed of a delay loop, without using ANY in/out instructions directly (the ones in the BIOS are presumably correctly delayed...). If we enter from the 32-bit entrypoint, we already don't have access to the BIOS, though. My understanding is that the linux starts in real mode, and uses the BIOS for such things as reading the very first image. arch/x86/boot/main.c seems to use BIOS calls, and one can do what I wrote in C or asm. Good place to measure the appropriate delay timing, and pass it on forward. That's what I was suggesting, which is why I copied the ASM routine from my old code listing as I did. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
This change seems rather unlikely for 2.6.24 at this point (high risk), but could be good for 2.6.25. One thing it should probably have for the early going, is a simple way to turn it on/off at boot time, so that we don't have people "stuck" unable to run the test kernels should something weird happen. Alan / David / Ingo, What do you think of the idea of a *temporary* boot flag for this, something like port80=on/off (pick a suitable name) ? Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
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 are really important. I don't want to break anybody's running systems... I'd like to see my machine run smoothly, and all the other machines that may or may not have this problem (google "hwclock freeze" to see that I'm far from alone - I just have persevered in "bisecting" this problem with kernel tweaks for months, whereas the others did not or did not know how). By the way, this laptop is really nice for Linux in lots of ways. Dual drives, so I set it up with software RAID for reliability, dual 64-bit processors, fast 3D graphics, etc. Great battery life. Just one last kernel issue. I also note that curent machines like the problem machine have ACPI, and maybe those would be the ones that vendors might start to define port 80 to mean something. As I noted, it /seems/ to be only when ACPI is turned on that this problem happens on my machine - that's when the OS starts to be involved in servicing various things, so it suggests that maybe things change about port 80's unknown function on these machines when ACPI is servicing the system management code (that's not something I have been able to verify). My belief is that my machine has some device that is responding to port 80 by doing something. And that something requires some other program to "service" port 80 in some way. But it sure would be nice to know. I can't personally sand off the top of the chipset to put probes into it - so my normal approach of putting a logic analyzer on the bus doesn't work. PS: If I have time, I may try to build Rene's port 80 test for Windows and run it under WinXP on this machine (I still have a crappy little partition that boots it). If it freezes the same way, it's almost certain a design "feature", and if it doesn't freeze, we might suspect that there is compensating logic in either Windows ACPI code or some way that windows "sets up" the machine. Alan Cox wrote: On Sat, 15 Dec 2007 14:27:25 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: * Rene Herman <[EMAIL PROTECTED]> wrote: The issue is -- how do you safely replace the outb pre-loops_per_jiffy calibration? I'm currently running with the attached hack (not submitted, only for 32-bit and discussion) the idea of which might be the best we can do? how about doing a known-NOP chipset cycle? For example: inb(PIC_SLAVE_IMR) It needs tobe a different chip to the main one (or macrocell anyway) - so PIC for PIT and vice versa. However since we know 0x80 works for everything on the planet but this one specifies of laptop which seems to need a firmware update its a very high risk approach. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Sat, 15 Dec 2007 14:27:25 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Rene Herman <[EMAIL PROTECTED]> wrote: > > > The issue is -- how do you safely replace the outb pre-loops_per_jiffy > > calibration? I'm currently running with the attached hack (not > > submitted, only for 32-bit and discussion) the idea of which might be > > the best we can do? > > how about doing a known-NOP chipset cycle? For example: > > inb(PIC_SLAVE_IMR) It needs tobe a different chip to the main one (or macrocell anyway) - so PIC for PIT and vice versa. However since we know 0x80 works for everything on the planet but this one specifies of laptop which seems to need a firmware update its a very high risk approach. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On 15-12-07 14:27, Ingo Molnar wrote: * Rene Herman <[EMAIL PROTECTED]> wrote: The issue is -- how do you safely replace the outb pre-loops_per_jiffy calibration? I'm currently running with the attached hack (not submitted, only for 32-bit and discussion) the idea of which might be the best we can do? how about doing a known-NOP chipset cycle? For example: inb(PIC_SLAVE_IMR) An inb is annoying in that it clobbers register al (well, with an inline native_io_delay it is at least) and more importantly -- the timing of this is going to vary wildly. We really want a register that is effectively guaranteed to be unused so that it dies on ISA/LPC or we might get _much_ faster PCI only decodes. Even reading port 0x80 itself varies wildly: http://lkml.org/lkml/2007/12/12/309 ? I.e. instead of trying to find an unused port, lets try to find a known-used platform register that has no side-effects if read. Use it unconditionally during early bootup and change it to an udelay after calibration. (or use it after early bootup too if a boot parameter has been specified) Or something like this. It's really going to have to be a known _un_used register and (the write direction of) port 0x80 is used exactly for that reason. Port 0xed is a known "alternate diagnostic port" used by Phoenix BIOSes at least but Peter Anvin reported trouble with that one -- probably for the outb direction but assuming that means something was in fact responding, we'd have the same timing problem. I believe we have two "good" options: 1) port 0xed was tested by the current reporter and found to be safe (and provide slow enough timing). If DMI based quirk hacks are available soon enough we can switch 0x80 to 0xed based on it. Are they? 2) the thing I posted in the message replied to where immediately after tsc_init() (which is before the PIT init) we switch to udelay() if we have a TSC which is ofcourse anything modern. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
* Rene Herman <[EMAIL PROTECTED]> wrote: > The issue is -- how do you safely replace the outb pre-loops_per_jiffy > calibration? I'm currently running with the attached hack (not > submitted, only for 32-bit and discussion) the idea of which might be > the best we can do? how about doing a known-NOP chipset cycle? For example: inb(PIC_SLAVE_IMR) ? I.e. instead of trying to find an unused port, lets try to find a known-used platform register that has no side-effects if read. Use it unconditionally during early bootup and change it to an udelay after calibration. (or use it after early bootup too if a boot parameter has been specified) Or something like this. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On 15-12-07 09:08, Paul Rolland wrote: Hello, On Fri, 14 Dec 2007 23:29:55 + Alan Cox <[EMAIL PROTECTED]> wrote: On Fri, 14 Dec 2007 14:13:46 -0800 "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: Pavel Machek wrote: On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote: How long will that take to boot on a 386? Well the dumb approach to fix that would seem to be to initialise it to cpu->family 3 -> 50MHz 4 -> 300Mhz 5-> etc... Just an idea : from what I've read, the problem (port 80 hanging) only occurs on 'modern' machines... So why not : - use port 80 for old CPUs (PII, PIII) where it has never really been a problem, - use the cpu->family to do a best match for CPU freq thus we could avoid increasing boot time too much... Yes, just posted a Patch-For-Comments that switches on the availability of a TSC (tsc_init sets tsc_disable also for !cpu_has_tsc) which would mean that only really old stuff would be using the outb still. A TSC is really all we need to have a sensible udelay(). Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Hello, On Fri, 14 Dec 2007 23:29:55 + Alan Cox <[EMAIL PROTECTED]> wrote: > On Fri, 14 Dec 2007 14:13:46 -0800 > "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: > > > Pavel Machek wrote: > > > On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote: > > > > How long will that take to boot on a 386? > > Well the dumb approach to fix that would seem to be to initialise it to > > cpu->family 3 -> 50MHz 4 -> 300Mhz 5-> etc... Just an idea : from what I've read, the problem (port 80 hanging) only occurs on 'modern' machines... So why not : - use port 80 for old CPUs (PII, PIII) where it has never really been a problem, - use the cpu->family to do a best match for CPU freq thus we could avoid increasing boot time too much... Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On 15-12-07 08:43, Ingo Molnar wrote:
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
I believe this will suffer from the issue that was raised: this will
use udelay() long before loop calibration (and no, we can't just "be
conservative" since there is no "conservative" value we can use.)
Worse, I suspect that at least the PIT, which may need to be used for
udelay calibration, is one of the devices that may be affected. I
have seen the Verilog for a contemporary chipset, and it can only
access the PIT once per microsecond -- this actually has to do with
the definition of the PIT; some of the PIT operations are ill-defined
if allowed at a higher frequency than the PIT clock.
i think the native_io_delay() in quirks.c signals the obvious solution:
a DMI (or otherwise) driven quirk that activates a port 0x80 based delay
on such boards. Combined with an iodelay=port80 boot option as well
perhaps, just in case someone hits a system that is not blacklisted yet.
This way such crazy broken hardware can be mapped correctly - like we
map such quirks in every other case. Perhaps even do this workaround on
the PIT driver level. Instead of perpetuating the superstition of port
80 forever.
The issue is -- how do you safely replace the outb pre-loops_per_jiffy
calibration? I'm currently running with the attached hack (not submitted,
only for 32-bit and discussion) the idea of which might be the best we can do?
(And the broken is the hardware that can't take writes to port 0x80, not the
other way around. It's a well-known legacy PC thing).
Rene.
diff --git a/arch/x86/boot/compressed/misc_32.c
b/arch/x86/boot/compressed/misc_32.c
index b74d60d..288e162 100644
--- a/arch/x86/boot/compressed/misc_32.c
+++ b/arch/x86/boot/compressed/misc_32.c
@@ -276,10 +276,10 @@ static void putstr(const char *s)
RM_SCREEN_INFO.orig_y = y;
pos = (x + cols * y) * 2; /* Update cursor position */
- outb_p(14, vidport);
- outb_p(0xff & (pos >> 9), vidport+1);
- outb_p(15, vidport);
- outb_p(0xff & (pos >> 1), vidport+1);
+ outb(14, vidport);
+ outb(0xff & (pos >> 9), vidport+1);
+ outb(15, vidport);
+ outb(0xff & (pos >> 1), vidport+1);
}
static void* memset(void* s, int c, unsigned n)
diff --git a/arch/x86/kernel/time_32.c b/arch/x86/kernel/time_32.c
index 8a322c9..c95d313 100644
--- a/arch/x86/kernel/time_32.c
+++ b/arch/x86/kernel/time_32.c
@@ -222,6 +222,19 @@ void __init hpet_time_init(void)
time_init_hook();
}
+static void port_io_delay(void)
+{
+ asm volatile ("outb %%al, $0x80": : : "memory");
+}
+
+static void udelay_io_delay(void)
+{
+ udelay(2);
+}
+
+void (*native_io_delay)(void) = port_io_delay;
+EXPORT_SYMBOL(native_io_delay);
+
/*
* This is called directly from init code; we must delay timer setup in the
* HPET case as we can't make the decision to turn on HPET this early in the
@@ -233,5 +246,7 @@ void __init hpet_time_init(void)
void __init time_init(void)
{
tsc_init();
+ if (!tsc_disable)
+ native_io_delay = udelay_io_delay;
late_time_init = choose_time_init();
}
diff --git a/include/asm-x86/io_32.h b/include/asm-x86/io_32.h
index fe881cd..1b73f49 100644
--- a/include/asm-x86/io_32.h
+++ b/include/asm-x86/io_32.h
@@ -250,10 +250,7 @@ static inline void flush_write_buffers(void)
#endif /* __KERNEL__ */
-static inline void native_io_delay(void)
-{
- asm volatile("outb %%al,$0x80" : : : "memory");
-}
+extern void (*native_io_delay)(void);
#if defined(CONFIG_PARAVIRT)
#include
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
On 15-12-07 08:43, Ingo Molnar wrote:
* H. Peter Anvin [EMAIL PROTECTED] wrote:
I believe this will suffer from the issue that was raised: this will
use udelay() long before loop calibration (and no, we can't just be
conservative since there is no conservative value we can use.)
Worse, I suspect that at least the PIT, which may need to be used for
udelay calibration, is one of the devices that may be affected. I
have seen the Verilog for a contemporary chipset, and it can only
access the PIT once per microsecond -- this actually has to do with
the definition of the PIT; some of the PIT operations are ill-defined
if allowed at a higher frequency than the PIT clock.
i think the native_io_delay() in quirks.c signals the obvious solution:
a DMI (or otherwise) driven quirk that activates a port 0x80 based delay
on such boards. Combined with an iodelay=port80 boot option as well
perhaps, just in case someone hits a system that is not blacklisted yet.
This way such crazy broken hardware can be mapped correctly - like we
map such quirks in every other case. Perhaps even do this workaround on
the PIT driver level. Instead of perpetuating the superstition of port
80 forever.
The issue is -- how do you safely replace the outb pre-loops_per_jiffy
calibration? I'm currently running with the attached hack (not submitted,
only for 32-bit and discussion) the idea of which might be the best we can do?
(And the broken is the hardware that can't take writes to port 0x80, not the
other way around. It's a well-known legacy PC thing).
Rene.
diff --git a/arch/x86/boot/compressed/misc_32.c
b/arch/x86/boot/compressed/misc_32.c
index b74d60d..288e162 100644
--- a/arch/x86/boot/compressed/misc_32.c
+++ b/arch/x86/boot/compressed/misc_32.c
@@ -276,10 +276,10 @@ static void putstr(const char *s)
RM_SCREEN_INFO.orig_y = y;
pos = (x + cols * y) * 2; /* Update cursor position */
- outb_p(14, vidport);
- outb_p(0xff (pos 9), vidport+1);
- outb_p(15, vidport);
- outb_p(0xff (pos 1), vidport+1);
+ outb(14, vidport);
+ outb(0xff (pos 9), vidport+1);
+ outb(15, vidport);
+ outb(0xff (pos 1), vidport+1);
}
static void* memset(void* s, int c, unsigned n)
diff --git a/arch/x86/kernel/time_32.c b/arch/x86/kernel/time_32.c
index 8a322c9..c95d313 100644
--- a/arch/x86/kernel/time_32.c
+++ b/arch/x86/kernel/time_32.c
@@ -222,6 +222,19 @@ void __init hpet_time_init(void)
time_init_hook();
}
+static void port_io_delay(void)
+{
+ asm volatile (outb %%al, $0x80: : : memory);
+}
+
+static void udelay_io_delay(void)
+{
+ udelay(2);
+}
+
+void (*native_io_delay)(void) = port_io_delay;
+EXPORT_SYMBOL(native_io_delay);
+
/*
* This is called directly from init code; we must delay timer setup in the
* HPET case as we can't make the decision to turn on HPET this early in the
@@ -233,5 +246,7 @@ void __init hpet_time_init(void)
void __init time_init(void)
{
tsc_init();
+ if (!tsc_disable)
+ native_io_delay = udelay_io_delay;
late_time_init = choose_time_init();
}
diff --git a/include/asm-x86/io_32.h b/include/asm-x86/io_32.h
index fe881cd..1b73f49 100644
--- a/include/asm-x86/io_32.h
+++ b/include/asm-x86/io_32.h
@@ -250,10 +250,7 @@ static inline void flush_write_buffers(void)
#endif /* __KERNEL__ */
-static inline void native_io_delay(void)
-{
- asm volatile(outb %%al,$0x80 : : : memory);
-}
+extern void (*native_io_delay)(void);
#if defined(CONFIG_PARAVIRT)
#include asm/paravirt.h
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
Hello, On Fri, 14 Dec 2007 23:29:55 + Alan Cox [EMAIL PROTECTED] wrote: On Fri, 14 Dec 2007 14:13:46 -0800 H. Peter Anvin [EMAIL PROTECTED] wrote: Pavel Machek wrote: On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote: How long will that take to boot on a 386? Well the dumb approach to fix that would seem to be to initialise it to cpu-family 3 - 50MHz 4 - 300Mhz 5- etc... Just an idea : from what I've read, the problem (port 80 hanging) only occurs on 'modern' machines... So why not : - use port 80 for old CPUs (PII, PIII) where it has never really been a problem, - use the cpu-family to do a best match for CPU freq thus we could avoid increasing boot time too much... Paul -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
On 15-12-07 09:08, Paul Rolland wrote: Hello, On Fri, 14 Dec 2007 23:29:55 + Alan Cox [EMAIL PROTECTED] wrote: On Fri, 14 Dec 2007 14:13:46 -0800 H. Peter Anvin [EMAIL PROTECTED] wrote: Pavel Machek wrote: On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote: How long will that take to boot on a 386? Well the dumb approach to fix that would seem to be to initialise it to cpu-family 3 - 50MHz 4 - 300Mhz 5- etc... Just an idea : from what I've read, the problem (port 80 hanging) only occurs on 'modern' machines... So why not : - use port 80 for old CPUs (PII, PIII) where it has never really been a problem, - use the cpu-family to do a best match for CPU freq thus we could avoid increasing boot time too much... Yes, just posted a Patch-For-Comments that switches on the availability of a TSC (tsc_init sets tsc_disable also for !cpu_has_tsc) which would mean that only really old stuff would be using the outb still. A TSC is really all we need to have a sensible udelay(). Rene. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
* Rene Herman [EMAIL PROTECTED] wrote: The issue is -- how do you safely replace the outb pre-loops_per_jiffy calibration? I'm currently running with the attached hack (not submitted, only for 32-bit and discussion) the idea of which might be the best we can do? how about doing a known-NOP chipset cycle? For example: inb(PIC_SLAVE_IMR) ? I.e. instead of trying to find an unused port, lets try to find a known-used platform register that has no side-effects if read. Use it unconditionally during early bootup and change it to an udelay after calibration. (or use it after early bootup too if a boot parameter has been specified) Or something like this. Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
On 15-12-07 14:27, Ingo Molnar wrote: * Rene Herman [EMAIL PROTECTED] wrote: The issue is -- how do you safely replace the outb pre-loops_per_jiffy calibration? I'm currently running with the attached hack (not submitted, only for 32-bit and discussion) the idea of which might be the best we can do? how about doing a known-NOP chipset cycle? For example: inb(PIC_SLAVE_IMR) An inb is annoying in that it clobbers register al (well, with an inline native_io_delay it is at least) and more importantly -- the timing of this is going to vary wildly. We really want a register that is effectively guaranteed to be unused so that it dies on ISA/LPC or we might get _much_ faster PCI only decodes. Even reading port 0x80 itself varies wildly: http://lkml.org/lkml/2007/12/12/309 ? I.e. instead of trying to find an unused port, lets try to find a known-used platform register that has no side-effects if read. Use it unconditionally during early bootup and change it to an udelay after calibration. (or use it after early bootup too if a boot parameter has been specified) Or something like this. It's really going to have to be a known _un_used register and (the write direction of) port 0x80 is used exactly for that reason. Port 0xed is a known alternate diagnostic port used by Phoenix BIOSes at least but Peter Anvin reported trouble with that one -- probably for the outb direction but assuming that means something was in fact responding, we'd have the same timing problem. I believe we have two good options: 1) port 0xed was tested by the current reporter and found to be safe (and provide slow enough timing). If DMI based quirk hacks are available soon enough we can switch 0x80 to 0xed based on it. Are they? 2) the thing I posted in the message replied to where immediately after tsc_init() (which is before the PIT init) we switch to udelay() if we have a TSC which is ofcourse anything modern. Rene. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
On Sat, 15 Dec 2007 14:27:25 +0100 Ingo Molnar [EMAIL PROTECTED] wrote: * Rene Herman [EMAIL PROTECTED] wrote: The issue is -- how do you safely replace the outb pre-loops_per_jiffy calibration? I'm currently running with the attached hack (not submitted, only for 32-bit and discussion) the idea of which might be the best we can do? how about doing a known-NOP chipset cycle? For example: inb(PIC_SLAVE_IMR) It needs tobe a different chip to the main one (or macrocell anyway) - so PIC for PIT and vice versa. However since we know 0x80 works for everything on the planet but this one specifies of laptop which seems to need a firmware update its a very high risk approach. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
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 are really important. I don't want to break anybody's running systems... I'd like to see my machine run smoothly, and all the other machines that may or may not have this problem (google hwclock freeze to see that I'm far from alone - I just have persevered in bisecting this problem with kernel tweaks for months, whereas the others did not or did not know how). By the way, this laptop is really nice for Linux in lots of ways. Dual drives, so I set it up with software RAID for reliability, dual 64-bit processors, fast 3D graphics, etc. Great battery life. Just one last kernel issue. I also note that curent machines like the problem machine have ACPI, and maybe those would be the ones that vendors might start to define port 80 to mean something. As I noted, it /seems/ to be only when ACPI is turned on that this problem happens on my machine - that's when the OS starts to be involved in servicing various things, so it suggests that maybe things change about port 80's unknown function on these machines when ACPI is servicing the system management code (that's not something I have been able to verify). My belief is that my machine has some device that is responding to port 80 by doing something. And that something requires some other program to service port 80 in some way. But it sure would be nice to know. I can't personally sand off the top of the chipset to put probes into it - so my normal approach of putting a logic analyzer on the bus doesn't work. PS: If I have time, I may try to build Rene's port 80 test for Windows and run it under WinXP on this machine (I still have a crappy little partition that boots it). If it freezes the same way, it's almost certain a design feature, and if it doesn't freeze, we might suspect that there is compensating logic in either Windows ACPI code or some way that windows sets up the machine. Alan Cox wrote: On Sat, 15 Dec 2007 14:27:25 +0100 Ingo Molnar [EMAIL PROTECTED] wrote: * Rene Herman [EMAIL PROTECTED] wrote: The issue is -- how do you safely replace the outb pre-loops_per_jiffy calibration? I'm currently running with the attached hack (not submitted, only for 32-bit and discussion) the idea of which might be the best we can do? how about doing a known-NOP chipset cycle? For example: inb(PIC_SLAVE_IMR) It needs tobe a different chip to the main one (or macrocell anyway) - so PIC for PIT and vice versa. However since we know 0x80 works for everything on the planet but this one specifies of laptop which seems to need a firmware update its a very high risk approach. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
This change seems rather unlikely for 2.6.24 at this point (high risk), but could be good for 2.6.25. One thing it should probably have for the early going, is a simple way to turn it on/off at boot time, so that we don't have people stuck unable to run the test kernels should something weird happen. Alan / David / Ingo, What do you think of the idea of a *temporary* boot flag for this, something like port80=on/off (pick a suitable name) ? Cheers -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
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 standard countdown timer way to delay for n microseconds, which as far as I know still works. This can be used to measure the speed of a delay loop, without using ANY in/out instructions directly (the ones in the BIOS are presumably correctly delayed...). If we enter from the 32-bit entrypoint, we already don't have access to the BIOS, though. My understanding is that the linux starts in real mode, and uses the BIOS for such things as reading the very first image. arch/x86/boot/main.c seems to use BIOS calls, and one can do what I wrote in C or asm. Good place to measure the appropriate delay timing, and pass it on forward. That's what I was suggesting, which is why I copied the ASM routine from my old code listing as I did. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
My understanding is that the linux starts in real mode, and uses the BIOS for such things as reading the very first image. Not always. We may enter from 32bit in some cases, and we may also not have a PC BIOS in the first place. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
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. And I did point out I'd found locking cases that may be relying upon this I also note that curent machines like the problem machine have ACPI, and maybe those would be the ones that vendors might start to define port 80 to mean something. As I noted, it /seems/ to be only when ACPI is turned Port 0x80 means debug. You appear to have a laptop with some kind of buggy firmware that wants a BIOS update. Everyone use 0x80 for debug - its in the chipset hardware quite often. My belief is that my machine has some device that is responding to port 80 by doing something. And that something requires some other program to service port 80 in some way. But it sure would be nice to know. I can't personally sand off the top of the chipset to put probes into it - so my normal approach of putting a logic analyzer on the bus doesn't work. Almost certainly a SMI trap. PS: If I have time, I may try to build Rene's port 80 test for Windows and run it under WinXP on this machine That would be very interesting. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
Rene Herman wrote: It's really going to have to be a known _un_used register and (the write direction of) port 0x80 is used exactly for that reason. Port 0xed is a known alternate diagnostic port used by Phoenix BIOSes at least but Peter Anvin reported trouble with that one -- probably for the outb direction but assuming that means something was in fact responding, we'd have the same timing problem. Yes, for the outbound direction. I believe we have two good options: 1) port 0xed was tested by the current reporter and found to be safe (and provide slow enough timing). If DMI based quirk hacks are available soon enough we can switch 0x80 to 0xed based on it. Are they? DMI is just a data structure parked in memory, so it should at least be theoretically possible to get to it. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
Paul Rolland wrote: Just an idea : from what I've read, the problem (port 80 hanging) only occurs on 'modern' machines... It happens on *one single* modern machine... Let's keep that in perspective. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
Rene Herman wrote: Yes, just posted a Patch-For-Comments that switches on the availability of a TSC (tsc_init sets tsc_disable also for !cpu_has_tsc) which would mean that only really old stuff would be using the outb still. A TSC is really all we need to have a sensible udelay(). Uhm, no. You have no clue what the speed of the TSC is until you have been able to calibrate it against a fixed timesource - like the PIT. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
On Sat 2007-12-15 12:26:26, H. Peter Anvin wrote: Paul Rolland wrote: Just an idea : from what I've read, the problem (port 80 hanging) only occurs on 'modern' machines... It happens on *one single* modern machine... Let's keep that in perspective. it hurts on other machines (like debug leds being useless), and it may be incorrect as soon as you insert leds-on-port-0x80-on-PCI card. No, it is not critical but yes, I'd like to see it fixed. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
On Fri 2007-12-14 15:23:55, Ingo Molnar wrote: * Rene Herman [EMAIL PROTECTED] wrote: --- a/init/main.c +++ b/init/main.c @@ -229,10 +229,9 @@ static int __init obsolete_checksetup(char *line) } /* - * This should be approx 2 Bo*oMips to start (note initial shift), and will - * still work even if initially too large, it will just take slightly longer + * Initial value roughly corresponds to a 1 GHz CPU */ -unsigned long loops_per_jiffy = (112); +unsigned long loops_per_jiffy = 10 / HZ; EXPORT_SYMBOL(loops_per_jiffy); this is a factor of ~2400 increase - this will take an eternity to boot on any older CPU. I don't think we are using outb_p before loops_per_jiffy are initialized -- I believe I'd see oopsen if we did. Factor 2400 increase is bad, but if it only converts 10x 1usec delay into 10x 24msec delay, it is not _that_ bad. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
On Fri 2007-12-14 14:15:03, Ingo Molnar wrote: * David P. Reed [EMAIL PROTECTED] wrote: Replace use of outb to unused diagnostic port 0x80 for time delay with udelay based time delay on x86_64 architecture machines. Fix for bugs 9511 and 6307 in bugzilla, plus bugs reported in bugzilla.redhat.com. Derived from suggestion (that didn't compile) by Pavel Machek, and tested, also based on measurements of typical timings of out's collated by Rene Herman from many in the community. This patch fixes a number of bugs known to cause problems on HP Pavilion dv9000z and dv6000z laptops - in the form of solid freezes when hwclock is used to show or set the time. Also, it potentially improves bus utilization on SMP machines, by using a waiting process that doesn't tie up the ISA/LPC bus for 1 or 2 microseconds. i386 family fixes (completely parallel) were not included, considering that such machines might involve more risk of problems on legacy machines. wow, cool fix! (I remember that there were other systems as well that are affected by port 0x80 muckery - i thought we had removed port 0x80 accesses long ago.) how about the simpler fix below, as a first-level approach? We can then remove the _p in/out sequences after this. this is also something for v2.6.24 merging. As much as I like this patch, I do not think it is suitable for .24. Too risky, I'd say. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
Pavel Machek wrote: this is also something for v2.6.24 merging. As much as I like this patch, I do not think it is suitable for .24. Too risky, I'd say. No kidding! We're talking about removing a hack that has been successful on thousands of pieces of hardware over 15 years because it breaks ONE machine. If this should be done at all it should be done in the most careful manner possible. 2.6.25 would be an aggressive schedule. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
* H. Peter Anvin <[EMAIL PROTECTED]> wrote: > I believe this will suffer from the issue that was raised: this will > use udelay() long before loop calibration (and no, we can't just "be > conservative" since there is no "conservative" value we can use.) > > Worse, I suspect that at least the PIT, which may need to be used for > udelay calibration, is one of the devices that may be affected. I > have seen the Verilog for a contemporary chipset, and it can only > access the PIT once per microsecond -- this actually has to do with > the definition of the PIT; some of the PIT operations are ill-defined > if allowed at a higher frequency than the PIT clock. i think the native_io_delay() in quirks.c signals the obvious solution: a DMI (or otherwise) driven quirk that activates a port 0x80 based delay on such boards. Combined with an iodelay=port80 boot option as well perhaps, just in case someone hits a system that is not blacklisted yet. This way such crazy broken hardware can be mapped correctly - like we map such quirks in every other case. Perhaps even do this workaround on the PIT driver level. Instead of perpetuating the superstition of port 80 forever. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
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 standard "countdown timer" way to delay for n microseconds, which as far as I know still works. This can be used to measure the speed of a delay loop, without using ANY in/out instructions directly (the ones in the BIOS are presumably correctly delayed...). If we enter from the 32-bit entrypoint, we already don't have access to the BIOS, though. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
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 far as I know still works. This can be used to measure the speed of a delay loop, without using ANY in/out instructions directly (the ones in the BIOS are presumably correctly delayed...). So first thing in the boot sequence, one can calibrate a timing loop using this technique, and save the value to be used for all the "early" stuff. Here's skeleton code from old ASM code I found lying around in my archives to use BIOS to measure how many unrolled short jumps can execute in 10 msec. Note that it can run without knowing anything whatsoever about port timing. haltbyte db 0 calibrate: les bx,haltbyte ; address of halt flag into es:bx mov ax,8300h sub cx,cx mov dx,1 ; 10 msec. in cx:dx int 15h jc bad sub dx,dx sub cx,cx ; decrement counter in dx:cx tloop: jmp short $+2 ; 10 short jmps jmp short $+2 jmp short $+2 jmp short $+2 jmp short $+2 jmp short $+2 jmp short $+2 jmp short $+2 jmp short $+2 test haltbyte loopz tloop jnz done dec dx jnz tloop " overflowed 32 bits ... never happens, cancel BIOS event wait. mov ax,8301h int 15h jmp error done: mov ax,cx negl " here dx:ax contains 32 bit loop count corresponding to 10 msec. ret ; return 32-bit value Doc on function 83h of int 15h should be available online. Alan Cox wrote: On Fri, 14 Dec 2007 14:13:46 -0800 "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: Pavel Machek wrote: On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote: Ingo Molnar wrote: wow, cool fix! (I remember that there were other systems as well that are affected by port 0x80 muckery - i thought we had removed port 0x80 accesses long ago.) how about the simpler fix below, as a first-level approach? We can then remove the _p in/out sequences after this. I believe this will suffer from the issue that was raised: this will use udelay() long before loop calibration (and no, we can't just "be conservative" since there is no "conservative" value we can use.) ?? Just initialize bogomips to 6GHz equivalent... and we are fine until 6GHz cpus come out. How long will that take to boot on a 386? Well the dumb approach to fix that would seem to be to initialise it to cpu->family 3 -> 50MHz 4 -> 300Mhz 5-> etc... Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
David P. Reed wrote: I believe (though no one seems to have confirming documentation from the chipset or motherboard vendor) that port 80 is actually functional for some unknown function on these machines. (They do respond to "in" instructions faster than a bus cycle abort does - more evidence). This is normal. IN from port 0x80 is used by the DMA address map chip. As far as I understand, there are other laptops with the same chipset which don't have this problem, so it's likely either a motherboard or firmware issue. My guess is that they probably let debugging code out in the field (trap port 0x80 in SMM, and then try to output it on some debugging bus.) -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
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 doing that. But if the reason is the back-to-back writes, when we can keep it, since the other writes will be trapped by kvm and emulated. Do you which is the case? As for kvm, I don't have enough info to know anything about that. Is there a test you'd like me to try? I think you are also asking if the crash on these laptops is caused only by back-to-back writes. Actually, it doesn't seem to matter if they are back to back. I can cause the crash if the writes to 80 are very much spread out in time - it seems only to matter how many of them get executed - almost as if there is a buffer overflow. (And of course if you do back to back writes to other ports that are apparently fully unused, such as 0xED on my machine, no crash occurs). I believe (though no one seems to have confirming documentation from the chipset or motherboard vendor) that port 80 is actually functional for some unknown function on these machines. (They do respond to "in" instructions faster than a bus cycle abort does - more evidence). I searched the DSDT to see if there is any evidence of an ACPI use for this port, but found nothing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Fri, 14 Dec 2007 14:13:46 -0800 "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: > Pavel Machek wrote: > > On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote: > >> Ingo Molnar wrote: > >>> wow, cool fix! (I remember that there were other systems as well that are > >>> affected by port 0x80 muckery - i thought we had removed port 0x80 > >>> accesses long ago.) > >>> how about the simpler fix below, as a first-level approach? We can then > >>> remove the _p in/out sequences after this. > >> I believe this will suffer from the issue that was raised: this will use > >> udelay() long before loop calibration (and no, we can't just "be > >> conservative" since there is no "conservative" value we can use.) > > > > ?? Just initialize bogomips to 6GHz equivalent... and we are fine > > until 6GHz cpus come out. > > How long will that take to boot on a 386? Well the dumb approach to fix that would seem to be to initialise it to cpu->family 3 -> 50MHz 4 -> 300Mhz 5-> etc... Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Pavel Machek wrote: On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote: Ingo Molnar wrote: wow, cool fix! (I remember that there were other systems as well that are affected by port 0x80 muckery - i thought we had removed port 0x80 accesses long ago.) how about the simpler fix below, as a first-level approach? We can then remove the _p in/out sequences after this. I believe this will suffer from the issue that was raised: this will use udelay() long before loop calibration (and no, we can't just "be conservative" since there is no "conservative" value we can use.) ?? Just initialize bogomips to 6GHz equivalent... and we are fine until 6GHz cpus come out. How long will that take to boot on a 386? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote: > Ingo Molnar wrote: >> wow, cool fix! (I remember that there were other systems as well that are >> affected by port 0x80 muckery - i thought we had removed port 0x80 >> accesses long ago.) >> how about the simpler fix below, as a first-level approach? We can then >> remove the _p in/out sequences after this. > > I believe this will suffer from the issue that was raised: this will use > udelay() long before loop calibration (and no, we can't just "be > conservative" since there is no "conservative" value we can use.) ?? Just initialize bogomips to 6GHz equivalent... and we are fine until 6GHz cpus come out. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Fri 2007-12-14 18:36:26, Alan Cox wrote: > > > i dont think this should matter: old systems that truly _need_ the ISA > > > delay will be slow enough to not trip up. (nor are they really affected > > > by these early delays - the delays were more for crappy ISA devices that > > > get initialized later down, when the delay loop is already calibrated) > > > > 8253 (DMAC) and 8254 (PIT) have been reported in earlier versions of the > > thread. By Alan, I believe. > > They've been seen to be problems up to PII era machines. I'm not aware of > any newer than that with this problem. We also don't need to touch the > DMAC that early anyway that I can see - just the PIT. > > In fact if we have a fast processor we have a TSC and APIC so we don't > need the PIT ? It is still good to be able to disable APIC/TSC. Neither are particulary reliable time sources. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Alan Cox wrote: i dont think this should matter: old systems that truly _need_ the ISA delay will be slow enough to not trip up. (nor are they really affected by these early delays - the delays were more for crappy ISA devices that get initialized later down, when the delay loop is already calibrated) 8253 (DMAC) and 8254 (PIT) have been reported in earlier versions of the thread. By Alan, I believe. They've been seen to be problems up to PII era machines. I'm not aware of any newer than that with this problem. We also don't need to touch the DMAC that early anyway that I can see - just the PIT. In fact if we have a fast processor we have a TSC and APIC so we don't need the PIT ? Well, the TSC may be unstable and the APIC may be disabled. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
> > i dont think this should matter: old systems that truly _need_ the ISA > > delay will be slow enough to not trip up. (nor are they really affected > > by these early delays - the delays were more for crappy ISA devices that > > get initialized later down, when the delay loop is already calibrated) > > 8253 (DMAC) and 8254 (PIT) have been reported in earlier versions of the > thread. By Alan, I believe. They've been seen to be problems up to PII era machines. I'm not aware of any newer than that with this problem. We also don't need to touch the DMAC that early anyway that I can see - just the PIT. In fact if we have a fast processor we have a TSC and APIC so we don't need the PIT ? Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On 14-12-07 19:02, H. Peter Anvin wrote: I believe this will suffer from the issue that was raised: this will use udelay() long before loop calibration (and no, we can't just "be conservative" since there is no "conservative" value we can use.) Worse, I suspect that at least the PIT, which may need to be used for udelay calibration, is one of the devices that may be affected. I have seen the Verilog for a contemporary chipset, and it can only access the PIT once per microsecond -- this actually has to do with the definition of the PIT; some of the PIT operations are ill-defined if allowed at a higher frequency than the PIT clock. Was reported before indeed: http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-09/5764.html Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Ingo Molnar wrote: wow, cool fix! (I remember that there were other systems as well that are affected by port 0x80 muckery - i thought we had removed port 0x80 accesses long ago.) how about the simpler fix below, as a first-level approach? We can then remove the _p in/out sequences after this. I believe this will suffer from the issue that was raised: this will use udelay() long before loop calibration (and no, we can't just "be conservative" since there is no "conservative" value we can use.) Worse, I suspect that at least the PIT, which may need to be used for udelay calibration, is one of the devices that may be affected. I have seen the Verilog for a contemporary chipset, and it can only access the PIT once per microsecond -- this actually has to do with the definition of the PIT; some of the PIT operations are ill-defined if allowed at a higher frequency than the PIT clock. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
David P. Reed wrote: Replace use of outb to "unused" diagnostic port 0x80 for time delay with udelay based time delay on x86_64 architecture machines. Fix for bugs 9511 and 6307 in bugzilla, plus bugs reported in bugzilla.redhat.com. Derived from suggestion (that didn't compile) by Pavel Machek, and tested, also based on measurements of typical timings of out's collated by Rene Herman from many in the community. This patch fixes a number of bugs known to cause problems on HP Pavilion dv9000z and dv6000z laptops - in the form of solid freezes when hwclock is used to show or set the time. Also, it potentially improves bus utilization on SMP machines, by using a waiting process that doesn't tie up the ISA/LPC bus for 1 or 2 microseconds. 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 doing that. But if the reason is the back-to-back writes, when we can keep it, since the other writes will be trapped by kvm and emulated. Do you which is the case? -- Any sufficiently difficult bug is indistinguishable from a feature. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On 14-12-07 15:46, Ingo Molnar wrote: * Rene Herman <[EMAIL PROTECTED]> wrote: /* - * This should be approx 2 Bo*oMips to start (note initial shift), and will - * still work even if initially too large, it will just take slightly longer + * Initial value roughly corresponds to a 1 GHz CPU */ -unsigned long loops_per_jiffy = (1<<12); +unsigned long loops_per_jiffy = 10 / HZ; EXPORT_SYMBOL(loops_per_jiffy); this is a factor of ~2400 increase - this will take an eternity to boot on any older CPU. Only any outb_p's used before loops_per_jiffy is calibrated are affected. yes - but there are a couple of early udelays, which would thus be affected. True. At the moment though they're just always not delaying anywhere close the intended amount (on anything with more than 2 bogomips). Pre-calibration all this stuff is just broken it seems. This pre-calibation thing is what's historically held this change back (it's been discussed dozens of times before). At 4096, not any machine is going to have an appreciable delay before calibration when switching from the outb to 0x80. i dont think this should matter: old systems that truly _need_ the ISA delay will be slow enough to not trip up. (nor are they really affected by these early delays - the delays were more for crappy ISA devices that get initialized later down, when the delay loop is already calibrated) 8253 (DMAC) and 8254 (PIT) have been reported in earlier versions of the thread. By Alan, I believe. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
* Rene Herman <[EMAIL PROTECTED]> wrote: >>> /* >>> - * This should be approx 2 Bo*oMips to start (note initial shift), and will >>> - * still work even if initially too large, it will just take slightly >>> longer >>> + * Initial value roughly corresponds to a 1 GHz CPU >>> */ >>> -unsigned long loops_per_jiffy = (1<<12); >>> +unsigned long loops_per_jiffy = 10 / HZ; >>> >>> EXPORT_SYMBOL(loops_per_jiffy); >> >> this is a factor of ~2400 increase - this will take an eternity to boot on >> any older CPU. > > Only any outb_p's used before loops_per_jiffy is calibrated are > affected. yes - but there are a couple of early udelays, which would thus be affected. > This pre-calibation thing is what's historically held this change back > (it's been discussed dozens of times before). At 4096, not any machine > is going to have an appreciable delay before calibration when > switching from the outb to 0x80. i dont think this should matter: old systems that truly _need_ the ISA delay will be slow enough to not trip up. (nor are they really affected by these early delays - the delays were more for crappy ISA devices that get initialized later down, when the delay loop is already calibrated) modern systems learned to depend on the PCI write posting side-effects of port 0x80 activities - those wont be helped by this initialization change either. That is a far more serious concern. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
> > updated patch attached. (from the MakeItBuild'n'Stuff dept)
>
> the one below is against current upstream. (previous ones were against
> x86.git)
the last version is the one below. Pending further discussion and
testing. And David, i nominate your fix as the coolest Linux kernel fix
of 2007 :-)
Ingo
>
Subject: x86: fix in_p/out_p crashes
From: David P. Reed <[EMAIL PROTECTED]>
Do not use port 0x80, it can cause crashes, see:
http://bugzilla.kernel.org/show_bug.cgi?id=6307
http://bugzilla.kernel.org/show_bug.cgi?id=9511
Replace use of outb to "unused" diagnostic port 0x80 for time delay
with udelay based time delay on x86_64 architecture machines. Fix for
bugs 9511 and 6307 in bugzilla, plus bugs reported in
bugzilla.redhat.com.
Derived from suggestion (that didn't compile) by Pavel Machek, and
tested, also based on measurements of typical timings of out's
collated by Rene Herman from many in the community.
This patch fixes a number of bugs known to cause problems on HP
Pavilion dv9000z and dv6000z laptops - in the form of solid freezes
when hwclock is used to show or set the time. Also, it potentially
improves bus utilization on SMP machines, by using a waiting process
that doesn't tie up the ISA/LPC bus for 1 or 2 microseconds.
[ [EMAIL PROTECTED]: minor restructuring, 32-bit support. ]
Signed-off-by: David P. Reed <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
arch/x86/boot/compressed/misc_32.c |8
arch/x86/boot/compressed/misc_64.c |8
arch/x86/kernel/quirks.c | 10 ++
include/asm-x86/io_32.h|5 +
include/asm-x86/io_64.h| 14 +-
5 files changed, 24 insertions(+), 21 deletions(-)
Index: linux-x86.q/arch/x86/boot/compressed/misc_32.c
===
--- linux-x86.q.orig/arch/x86/boot/compressed/misc_32.c
+++ linux-x86.q/arch/x86/boot/compressed/misc_32.c
@@ -276,10 +276,10 @@ static void putstr(const char *s)
RM_SCREEN_INFO.orig_y = y;
pos = (x + cols * y) * 2; /* Update cursor position */
- outb_p(14, vidport);
- outb_p(0xff & (pos >> 9), vidport+1);
- outb_p(15, vidport);
- outb_p(0xff & (pos >> 1), vidport+1);
+ outb(14, vidport);
+ outb(0xff & (pos >> 9), vidport+1);
+ outb(15, vidport);
+ outb(0xff & (pos >> 1), vidport+1);
}
static void* memset(void* s, int c, unsigned n)
Index: linux-x86.q/arch/x86/boot/compressed/misc_64.c
===
--- linux-x86.q.orig/arch/x86/boot/compressed/misc_64.c
+++ linux-x86.q/arch/x86/boot/compressed/misc_64.c
@@ -269,10 +269,10 @@ static void putstr(const char *s)
RM_SCREEN_INFO.orig_y = y;
pos = (x + cols * y) * 2; /* Update cursor position */
- outb_p(14, vidport);
- outb_p(0xff & (pos >> 9), vidport+1);
- outb_p(15, vidport);
- outb_p(0xff & (pos >> 1), vidport+1);
+ outb(14, vidport);
+ outb(0xff & (pos >> 9), vidport+1);
+ outb(15, vidport);
+ outb(0xff & (pos >> 1), vidport+1);
}
static void* memset(void* s, int c, unsigned n)
Index: linux-x86.q/arch/x86/kernel/quirks.c
===
--- linux-x86.q.orig/arch/x86/kernel/quirks.c
+++ linux-x86.q/arch/x86/kernel/quirks.c
@@ -3,9 +3,19 @@
*/
#include
#include
+#include
#include
+/*
+ * Some legacy devices need delays for IN/OUT sequences. Most are
+ * probably not needed but it's the safest to just do this short delay:
+ */
+void native_io_delay(void)
+{
+ udelay(2);
+}
+
#if defined(CONFIG_X86_IO_APIC) && defined(CONFIG_SMP) && defined(CONFIG_PCI)
static void __devinit quirk_intel_irqbalance(struct pci_dev *dev)
Index: linux-x86.q/include/asm-x86/io_32.h
===
--- linux-x86.q.orig/include/asm-x86/io_32.h
+++ linux-x86.q/include/asm-x86/io_32.h
@@ -250,10 +250,7 @@ static inline void flush_write_buffers(v
#endif /* __KERNEL__ */
-static inline void native_io_delay(void)
-{
- asm volatile("outb %%al,$0x80" : : : "memory");
-}
+extern void native_io_delay(void);
#if defined(CONFIG_PARAVIRT)
#include
Index: linux-x86.q/include/asm-x86/io_64.h
===
--- linux-x86.q.orig/include/asm-x86/io_64.h
+++ linux-x86.q/include/asm-x86/io_64.h
@@ -35,13 +35,7 @@
* - Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
*/
-#define __SLOW_DOWN_IO "\noutb %%al,$0x80"
-
-#ifdef REALLY_SLOW_IO
-#define __FULL_SLOW_DOWN_IO __SLOW_DOWN_IO __SLOW_DOWN_IO __SLOW_DOWN_IO
__SLOW_DOWN_IO
-#else
-#define __FULL_SLOW_DOWN_IO __SLOW_DOWN_IO
-#endif
+extern void native_io_delay(void);
/*
* Talk about misusing macros..
@@ -54,7 +48,8 @@ __asm__ __volatile__ ("out" #s " %" s1 "
#define
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On 14-12-07 15:23, Ingo Molnar wrote: * Rene Herman <[EMAIL PROTECTED]> wrote: --- a/init/main.c +++ b/init/main.c @@ -229,10 +229,9 @@ static int __init obsolete_checksetup(char *line) } /* - * This should be approx 2 Bo*oMips to start (note initial shift), and will - * still work even if initially too large, it will just take slightly longer + * Initial value roughly corresponds to a 1 GHz CPU */ -unsigned long loops_per_jiffy = (1<<12); +unsigned long loops_per_jiffy = 10 / HZ; EXPORT_SYMBOL(loops_per_jiffy); this is a factor of ~2400 increase - this will take an eternity to boot on any older CPU. Only any outb_p's used before loops_per_jiffy is calibrated are affected. This pre-calibation thing is what's historically held this change back (it's been discussed dozens of times before). At 4096, not any machine is going to have an appreciable delay before calibration when switching from the outb to 0x80. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
* Rene Herman <[EMAIL PROTECTED]> wrote: > --- a/init/main.c > +++ b/init/main.c > @@ -229,10 +229,9 @@ static int __init obsolete_checksetup(char *line) > } > > /* > - * This should be approx 2 Bo*oMips to start (note initial shift), and will > - * still work even if initially too large, it will just take slightly longer > + * Initial value roughly corresponds to a 1 GHz CPU > */ > -unsigned long loops_per_jiffy = (1<<12); > +unsigned long loops_per_jiffy = 10 / HZ; > > EXPORT_SYMBOL(loops_per_jiffy); this is a factor of ~2400 increase - this will take an eternity to boot on any older CPU. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
* Rene Herman <[EMAIL PROTECTED]> wrote: > And as to testing -- good luck finding a machine that cares at all ;-) actually, there's a whole lot more testing angle to a change like this than ancient boxes. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On 14-12-07 15:03, Ingo Molnar wrote: yep, i have updated the delay to 2 usecs. The latest patch is below, as queued up in x86.git. (not yet queued up for .24 - it's pending testing and more feedback, etc.) Yes, I'd like feedback on the initial value thing: http://lkml.org/lkml/2007/12/14/72 and Alan's comments here: http://lkml.org/lkml/2007/12/12/221 And as to testing -- good luck finding a machine that cares at all ;-) Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
* Rene Herman <[EMAIL PROTECTED]> wrote:
> On 14-12-07 14:15, Ingo Molnar wrote:
>
>> wow, cool fix! (I remember that there were other systems as well that are
>> affected by port 0x80 muckery - i thought we had removed port 0x80
>> accesses long ago.)
>>
>> how about the simpler fix below, as a first-level approach? We can
>> then remove the _p in/out sequences after this.
>
> Your version does the same thing that the version from Pavel/David
> does for 32-bit at least.
well, if you carefully look at the code it's not the "same" but a
similar but cleaner thing - it moves this quirk out of a common include
file. I take back the "simpler" characterisation - my patch indeed ended
up being almost the same as David's.
>> +/*
>> + * Some legacy devices need delays for IN/OUT sequences. Most are
>> + * probably not needed but it's the safest to just do this short delay:
>> + */
>> +void native_io_delay(void)
>> +{
>> +udelay(1);
>> +}
>
> Also note the thread(s) on LKML where 2 us was decided to be a nicely
> conservative value:
yep, i have updated the delay to 2 usecs. The latest patch is below, as
queued up in x86.git. (not yet queued up for .24 - it's pending testing
and more feedback, etc.)
Ingo
->
Subject: x86: fix in_p/out_p crashes
From: David P. Reed <[EMAIL PROTECTED]>
Do not use port 0x80, it can cause crashes, see:
http://bugzilla.kernel.org/show_bug.cgi?id=6307
http://bugzilla.kernel.org/show_bug.cgi?id=9511
Replace use of outb to "unused" diagnostic port 0x80 for time delay
with udelay based time delay on x86_64 architecture machines. Fix for
bugs 9511 and 6307 in bugzilla, plus bugs reported in
bugzilla.redhat.com.
Derived from suggestion (that didn't compile) by Pavel Machek, and
tested, also based on measurements of typical timings of out's
collated by Rene Herman from many in the community.
This patch fixes a number of bugs known to cause problems on HP
Pavilion dv9000z and dv6000z laptops - in the form of solid freezes
when hwclock is used to show or set the time. Also, it potentially
improves bus utilization on SMP machines, by using a waiting process
that doesn't tie up the ISA/LPC bus for 1 or 2 microseconds.
[ [EMAIL PROTECTED]: minor restructuring, 32-bit support. ]
Signed-off-by: David P. Reed <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
arch/x86/boot/compressed/misc_32.c |8
arch/x86/boot/compressed/misc_64.c |8
arch/x86/kernel/quirks.c | 10 ++
include/asm-x86/io_32.h|5 +
include/asm-x86/io_64.h| 14 +-
5 files changed, 24 insertions(+), 21 deletions(-)
Index: linux-x86.q/arch/x86/boot/compressed/misc_32.c
===
--- linux-x86.q.orig/arch/x86/boot/compressed/misc_32.c
+++ linux-x86.q/arch/x86/boot/compressed/misc_32.c
@@ -276,10 +276,10 @@ static void putstr(const char *s)
RM_SCREEN_INFO.orig_y = y;
pos = (x + cols * y) * 2; /* Update cursor position */
- outb_p(14, vidport);
- outb_p(0xff & (pos >> 9), vidport+1);
- outb_p(15, vidport);
- outb_p(0xff & (pos >> 1), vidport+1);
+ outb(14, vidport);
+ outb(0xff & (pos >> 9), vidport+1);
+ outb(15, vidport);
+ outb(0xff & (pos >> 1), vidport+1);
}
static void* memset(void* s, int c, unsigned n)
Index: linux-x86.q/arch/x86/boot/compressed/misc_64.c
===
--- linux-x86.q.orig/arch/x86/boot/compressed/misc_64.c
+++ linux-x86.q/arch/x86/boot/compressed/misc_64.c
@@ -269,10 +269,10 @@ static void putstr(const char *s)
RM_SCREEN_INFO.orig_y = y;
pos = (x + cols * y) * 2; /* Update cursor position */
- outb_p(14, vidport);
- outb_p(0xff & (pos >> 9), vidport+1);
- outb_p(15, vidport);
- outb_p(0xff & (pos >> 1), vidport+1);
+ outb(14, vidport);
+ outb(0xff & (pos >> 9), vidport+1);
+ outb(15, vidport);
+ outb(0xff & (pos >> 1), vidport+1);
}
static void* memset(void* s, int c, unsigned n)
Index: linux-x86.q/arch/x86/kernel/quirks.c
===
--- linux-x86.q.orig/arch/x86/kernel/quirks.c
+++ linux-x86.q/arch/x86/kernel/quirks.c
@@ -3,9 +3,19 @@
*/
#include
#include
+#include
#include
+/*
+ * Some legacy devices need delays for IN/OUT sequences. Most are
+ * probably not needed but it's the safest to just do this short delay:
+ */
+void native_io_delay(void)
+{
+ udelay(2);
+}
+
#if defined(CONFIG_X86_IO_APIC) && defined(CONFIG_SMP) && defined(CONFIG_PCI)
static void __devinit quirk_intel_irqbalance(struct pci_dev *dev)
Index: linux-x86.q/include/asm-x86/io_32.h
===
--- linux-x86.q.orig/include/asm-x86/io_32.h
+++ linux-x86.q/include/asm-x86/io_32.h
@@ -250,10
