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.
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.
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.
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.
* 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 __OU
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 +
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > updated patch attached. (from the MakeItBuild'n'Stuff dept) the one below is against current upstream. (previous ones were against x86.git) Ingo ---> Subject: x86: fix in/out_p delays From: Ingo Molnar <[EMAIL PROTECTED]> Debugged by 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 instead of just removing _p postfixes en masse, lets just first remove the 0x80 port usage, then remove any unnecessary _p io ops gradually. It's more debuggable this way. 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(1); +} + #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 __OUT(s,s1,x) \ __OUT1(s,x) __OUT2(s,s1,"w") : : "a" (value), "Nd" (port)); } \ -__OUT1(s##_p,x) __OUT2(s,s1,"w") __FULL_SLOW_DOWN_IO : : "a" (value), "Nd" (port));} \ +__OUT1(s##_p,x) __OUT2(s,s1,"w") : : "a" (value), "Nd" (port)); \ +native_io_delay(); } \ #define __IN1(s) \ static inline RETURN_TYPE in##s(unsigned short port) { RETURN_TYPE _v; @@ -64,7 +59,8 @@ __asm__ __volatile__ ("in" #s " %" s2 "1 #define __IN(s,s1,i...) \ __IN1(s) __IN2(s,s1,"w") : "=a" (_v) : "Nd" (port) ,##i ); return _v; } \ -__IN1(s##_p) __IN2(s,s1,"w") __FULL_SLOW_DOWN_IO : "=a" (_v) : "Nd" (port) ,##i ); return _v; } \ +__IN1(s##_p) __IN2(s,s1,"w") : "=a" (_v) : "Nd" (port) ,##i ); return _v; \ +native_io_delay(); } \ #define __INS(s) \ static inline void
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
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. +/* + * 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: http://lkml.org/lkml/2007/12/12/309 Also see: http://lkml.org/lkml/2007/12/14/72 And also: http://lkml.org/lkml/2007/12/12/221 As such, please wait a bit for a fuller resolution. We're still discussing this. 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 <[EMAIL PROTECTED]> 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. > > this is also something for v2.6.24 merging. updated patch attached. (from the MakeItBuild'n'Stuff dept) Ingo --> Subject: x86: fix in/out_p delays From: Ingo Molnar <[EMAIL PROTECTED]> Debugged by 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 instead of just removing _p postfixes en masse, lets just first remove the 0x80 port usage, then remove any unnecessary _p io ops gradually. It's more debuggable this way. 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|5 + 5 files changed, 20 insertions(+), 16 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 @@ -275,10 +275,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(1); +} + #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,10 +35,7 @@ * - Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> */ -static inline void native_io_delay(void) -{ - asm volatile("outb %%al,$0x80" : : : "memory"); -} +extern void native_io_delay(void); #if defined(CONFIG_PARAVIRT) #include -- 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 <[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. Ingo -> Subject: x86: fix in/out_p delays From: Ingo Molnar <[EMAIL PROTECTED]> Debugged by 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 instead of just removing _p postfixes en masse, lets just first remove the 0x80 port usage, then remove any unnecessary _p io ops gradually. It's more debuggable this way. 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 |9 + include/asm-x86/io_32.h|5 + include/asm-x86/io_64.h|5 + 5 files changed, 19 insertions(+), 16 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 @@ -275,10 +275,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 @@ -6,6 +6,15 @@ #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(1); +} + #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,10 +35,7 @@ * - Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> */ -static inline void native_io_delay(void) -{ - asm volat
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Andi Kleen wrote: " With the additional call this should be completely out of line now to save code size. Similar for the in variant. Sure. Want me to make a new patch with the _p croutines out-of-line? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the 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" <[EMAIL PROTECTED]> writes: > > i386 family fixes (completely parallel) were not included, considering > that such machines might involve more risk of problems on legacy machines. They're needed because lots of people fomr some reason still boot 32bit kernels on 64bit machines. > +#define __OUT(s, s1, x) \ > +__OUT1(s, x) __OUT2(s, s1, "w") } \ > + __OUT1(s##_p, x) __OUT2(s, s1, "w") udelay(_IOPORT_PAUSE_DELAY); } \ With the additional call this should be completely out of line now to save code size. Similar for the in variant. -Andi -- 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 03:59, 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. i386 family fixes (completely parallel) were not included, considering that such machines might involve more risk of problems on legacy machines. Here's the corresponding 32-bit patch. Applies fine to (and works on) v2.6.23.x as well after un-uniting the paths... I do believe it would be better to do both; x86-64 machines can run 32-bit kernels fine and might certainly in the form of generic (installer) kernels and the like so if it's a fix lets fix it across the board -- the 2 us delay is going to be enough for everything out there, certainly given that _0_ is normally enough. With the arches just merged, minimising diferences should be a goal in itself I guess. One thing though -- I believe we want to adjust the loops_per_jiffy default to make sure this works, or would work, pre-calibration as well? Not really sure how needed it is, but bogomips is defined as bogomips = loops_per_jiffy / (50 / HZ) <=> loops_per_jiffy = bogomips * (50 / HZ) which with assuming any machine above 1G isn't affected by any of this and bogomips coming out to 2 * MHz on anything I myself have run linux on might suggest that loops_per_jiffy = 2 * 1000 * (50 / HZ) = 10 / HZ could possibly be a sane if very large default? Alan? diff --git a/init/main.c b/init/main.c index 9def935..6d41771 100644 --- 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); From: Pavel Machek <[EMAIL PROTECTED]> 32-bit part of the port 0x80 delay replacement. 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/include/asm-x86/io_32.h b/include/asm-x86/io_32.h index fe881cd..9abc215 100644 --- a/include/asm-x86/io_32.h +++ b/include/asm-x86/io_32.h @@ -3,6 +3,7 @@ #include #include +#include /* * This file contains the definitions for the x86 IO instructions @@ -17,17 +18,6 @@ * mistake somewhere. */ -/* - * Thanks to James van Artsdalen for a better timing-fix than - * the two short jumps: using outb's to a nonexistent port seems - * to guarantee better timings even on fast machines. - * - * On the other hand, I'd like to be sure of a non-existent port: - * I feel a bit unsafe about using 0x80 (should be safe, though) - * - * Linus - */ - /* * Bit simplified and optimized by Jan Hubicka * Support of BIGMEM added by Gerhard Wichert, Siemens AG, July 1999. @@ -252,7 +242,7 @@ static inline void flush_write_buffers(void) static inline void native_io_delay(void) { - asm volatile("outb %%al,$0x80" : : : "memory"); + udelay(2); } #if defined(CONFIG_PARAVIRT)
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Dec 13, 2007 6:59 PM, 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. > > Signed-off-by: David P. Reed <[EMAIL PROTECTED]> > > Index: linux-2.6/arch/x86/boot/compressed/misc_64.c > === > --- linux-2.6.orig/arch/x86/boot/compressed/misc_64.c > +++ linux-2.6/arch/x86/boot/compressed/misc_64.c > @@ -269,10 +269,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-2.6/include/asm/io_64.h > === > --- linux-2.6.orig/include/asm/io_64.h > +++ linux-2.6/include/asm/io_64.h include/asm-x64/io_64.h ? YH -- 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/
[PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
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. Signed-off-by: David P. Reed <[EMAIL PROTECTED]> Index: linux-2.6/arch/x86/boot/compressed/misc_64.c === --- linux-2.6.orig/arch/x86/boot/compressed/misc_64.c +++ linux-2.6/arch/x86/boot/compressed/misc_64.c @@ -269,10 +269,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-2.6/include/asm/io_64.h === --- linux-2.6.orig/include/asm/io_64.h +++ linux-2.6/include/asm/io_64.h @@ -1,6 +1,7 @@ #ifndef _ASM_IO_H #define _ASM_IO_H +#include /* * This file contains the definitions for the x86 IO instructions @@ -15,19 +16,7 @@ * mistake somewhere. */ -/* - * Thanks to James van Artsdalen for a better timing-fix than - * the two short jumps: using outb's to a nonexistent port seems - * to guarantee better timings even on fast machines. - * - * On the other hand, I'd like to be sure of a non-existent port: - * I feel a bit unsafe about using 0x80 (should be safe, though) - * - * Linus - */ - - /* - * Bit simplified and optimized by Jan Hubicka +/* Bit simplified and optimized by Jan Hubicka * Support of BIGMEM added by Gerhard Wichert, Siemens AG, July 1999. * * isa_memset_io, isa_memcpy_fromio, isa_memcpy_toio added, @@ -35,36 +24,36 @@ * - Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> */ -#define __SLOW_DOWN_IO "\noutb %%al,$0x80" - +/* the following delays are really conservative, at least for modern machines */ #ifdef REALLY_SLOW_IO -#define __FULL_SLOW_DOWN_IO __SLOW_DOWN_IO __SLOW_DOWN_IO __SLOW_DOWN_IO __SLOW_DOWN_IO +#define _IOPORT_PAUSE_DELAY 10 #else -#define __FULL_SLOW_DOWN_IO __SLOW_DOWN_IO +#define _IOPORT_PAUSE_DELAY 2 #endif /* * Talk about misusing macros.. */ -#define __OUT1(s,x) \ +#define __OUT1(s, x) \ static inline void out##s(unsigned x value, unsigned short port) { -#define __OUT2(s,s1,s2) \ -__asm__ __volatile__ ("out" #s " %" s1 "0,%" s2 "1" - -#define __OUT(s,s1,x) \ -__OUT1(s,x) __OUT2(s,s1,"w") : : "a" (value), "Nd" (port)); } \ -__OUT1(s##_p,x) __OUT2(s,s1,"w") __FULL_SLOW_DOWN_IO : : "a" (value), "Nd" (port));} \ +#define __OUT2(s, s1, s2) \ + __asm__ __volatile__ ("out" #s " %" s1 "0,%" s2 "1" : : "a" (value), "Nd" \ +(port)); + +#define __OUT(s, s1, x) \ +__OUT1(s, x) __OUT2(s, s1, "w") } \ + __OUT1(s##_p, x) __OUT2(s, s1, "w") udelay(_IOPORT_PAUSE_DELAY); } \ #define __IN1(s) \ static inline RETURN_TYPE in##s(unsigned short port) { RETURN_TYPE _v; -#define __IN2(s,s1,s2) \ -__asm__ __volatile__ ("in" #s " %" s2 "1,%" s1 "0" +#define __IN2(s, s1, s2) \ +__asm__ __volatile__ ("in" #s " %" s2 "1,%" s1 "0" : "=a" (_v) : "Nd" (port)); -#define __IN(s,s1,i...) \ -__IN1(s) __IN2(s,s1,"w") : "=a" (_v) : "Nd" (port) ,##i ); return _v; } \ -__IN1(s##_p) __IN2(s,s1,"w") __FULL_SLOW_DOWN_IO : "=a" (_v) : "Nd" (port) ,##i ); return _v; } \ +#define __IN(s, s1) \ +__IN1(s) __IN2(s, s1, "w") return _v; } \ + __IN1(s##_p) __IN2(s, s1, "w") udelay(_IOPORT_PAUSE_DELAY); return _v; } \ #define __INS(s) \ static inline void ins##s(unsigned short port, void * addr, unsigned long count) \ -- 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/