Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Rene Herman <[EMAIL PROTECTED]> writes: > > If there are no sensible fixes, an 0x80/0xed choice could I assume be > hung of DMI or something (if that _is_ parsed soon enough). Another possibility would be to key this off DMI year (or existence of DMI year since old systems don't have it). I guess it would be reasonable to not do any delays on anything modern. On x86-64 it could be presumably always disabled too, although I was always too chicken to do that. -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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
"David P. Reed" <[EMAIL PROTECTED]> writes: > > ANy help/suggestions? Use a variable for the port and and do a early quirk to change the port to something safe on your chipset? Ok there might be code using outb_p() before the early quirks, but should be possible to find using instrumentation. Also the port assignment might not be chipset specific, but BIOS specific, then you would need to match the DMI identifier. The disadvantage of that is that there are usually other BIOS with other identifiers but the same problem around. > Changing the delay instruction sequence from the outb to short jumps > might be the safe thing. But Linus, et al. may have experience with > that on other architectures like older Pentiums etc. I don't think that makes sense to do on anything modern. The trouble is that the jumps will effectively execute near "infinitely fast" on any modern CPU compared to the bus. But the delay really needs to be something that is about IO port speed. Ok in theory you could try to measure a outb using RDTSC and then use udelay, but first you would need a safe port for that already and then RDTSC is not necessarily constant. -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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 07-12-07 08:17, Rene Herman wrote: On 07-12-07 06:54, David P. Reed wrote: Pardon my ignorance, but is port 0xed really safe to push an out cycle at across the entire x86_64 family? Please do not top-post. Who knows, probably not. You just experienced that 0x80 is apparently not safe for you and that one's the conventional choice so it's likely that someone somewhere will have problems with 0xed as well. That's why I adviced you'd test and see what blows up and suggested that in the absence of better fixes a 0x80/0xed port choice might be able to hang off machine types as retrievable from DMI or something. The better fix would probably be to simply udelay(1) but you need calibrated timers before you can do that and some googling leads me to believe that's why it's not today. There's also a possible issue in that an I/O access might serve as a method of flushing forwarding buffers on a PCI bridge but I have no idea if that's a real issue (and if it is, an inb() should suffice as well). How long must real _p pauses be in reality? 8 ISA bus cycles is the intended delay it seems which at a typical ISA bus speed of 8 MHz amounts to 1 us. (and who cares about what the code calls "really slow i/o"). Paranoid programmers and those that need to delay for 4 us. Why are we waiting at all? I read the comments in io_64.h, and am a bit mystified. Does Windoze or DOS do this magical mystery wait? The CMOS example at hand is the standard example. It's accessed through an index/data register pair. You need to be sure that the RTC has switched the correct internal register to the data register before you poke at it or you may read/write the wrong one. Now, as said, I can't say I've ever in fact caught _any_ piece of hardware with its pants down like that and needing this for actual RTC/CMOS could as far as I'm aware be more of a left-over from The Olden Days with a bus more or less directly tied to the 8086 than sensible for anything on which Linux could run. Hard to test though and certainly for generic outb_p use. Yes, DOS or at least many programs that ran under it did very similar things but DOS ofcourse originated on those first PCs. Anyway, the virtualization hooks in 32-bit x86 almost make it possible to isolate this simply - maybe - after the merge of 32/64 being contemplated. And anyone who knows what the chipset might be doing with the 80 port rather than POST codes, perhaps could contribute. Any nvidia folks who know what's happening under NDA? Any Phoenix BIOS types? It's fairly surprising that 0x80 is given you trouble. It's a very well known legacy port. Even though it may not be all that sensible a thing today I'd say that if your machine put anything other than an actual integrated POST monitor on port 0x80 it in fact fucked up. This is a good thread to read: http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-09/5700.html maybe you have some LPC device that gets confused by aborts on the bus as well. 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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 07-12-07 06:54, David P. Reed wrote: Pardon my ignorance, but is port 0xed really safe to push an out cycle at across the entire x86_64 family? Please do not top-post. Who knows, probably not. You just experienced that 0x80 is apparently not safe for you and that one's the conventional choice so it's likely that someone somewhere will have problems with 0xed as well. That's why I adviced you'd test and see what blows up and suggested that in the absence of better fixes a 0x80/0xed port choice might be able to hang off machine types as retrievable from DMI or something. The better fix would probably be to simply udelay(1) but you need calibrated timers before you can do that and some googling leads me to believe that's why it's not today. There's also a possible issue in that an I/O access might serve as a method of flushing forwarding buffers on a PCI bridge but I have no idea if that's a real issue (and if it is, an inb() should suffice as well). How long must real _p pauses be in reality? 8 ISA bus cycles is the intended delay it seems which at a typical ISA bus speed of 8 MHz amounts to 1 us. (and who cares about what the code calls "really slow i/o"). Paranoid programmers and those that need to delay for 4 us. Why are we waiting at all? I read the comments in io_64.h, and am a bit mystified. Does Windoze or DOS do this magical mystery wait? The CMOS example at hand is the standard example. It's accessed through an index/data register pair. You need to be sure that the RTC has switched the correct internal register to the data register before you poke at it or you may read/write the wrong one. Now, as said, I can't say I've ever in fact caught _any_ piece of hardware with its pants down like that and needing this for actual RTC/CMOS could as far as I'm aware be more of a left-over from The Olden Days with a bus more or less directly tied to the 8086 than sensible for anything on which Linux could run. Hard to test though and certainly for generic outb_p use. Yes, DOS or at least many programs that ran under it did very similar things but DOS ofcourse originated on those first PCs. Anyway, the virtualization hooks in 32-bit x86 almost make it possible to isolate this simply - maybe - after the merge of 32/64 being contemplated. And anyone who knows what the chipset might be doing with the 80 port rather than POST codes, perhaps could contribute. Any nvidia folks who know what's happening under NDA? Any Phoenix BIOS types? It's fairly surprising that 0x80 is given you trouble. It's a very well known legacy port. Even though it may not be all that sensible a thing today I'd say that if your machine put anything other than an actual integrated POST monitor on port 0x80 it in fact fucked up. I think the worst of the problems would be fixed by changing just the CMOS_READ/CMOS_WRITE macros. But the danger lingers in the *_p code. 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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Pardon my ignorance, but is port 0xed really safe to push an out cycle at across the entire x86_64 family? How long must real _p pauses be in reality? (and who cares about what the code calls "really slow i/o"). Why are we waiting at all? I read the comments in io_64.h, and am a bit mystified. Does Windoze or DOS do this magical mystery wait? Anyway, the virtualization hooks in 32-bit x86 almost make it possible to isolate this simply - maybe - after the merge of 32/64 being contemplated. And anyone who knows what the chipset might be doing with the 80 port rather than POST codes, perhaps could contribute. Any nvidia folks who know what's happening under NDA? Any Phoenix BIOS types? I think the worst of the problems would be fixed by changing just the CMOS_READ/CMOS_WRITE macros. But the danger lingers in the *_p code. Rene Herman wrote: On 07-12-07 01:23, Robert Hancock wrote: David P. Reed wrote: After much, much testing (months, off and on, pursuing hypotheses), I've discovered that the use of "outb al,0x80" instructions to "delay" after inb and outb instructions causes solid freezes on my HP dv9000z laptop, when ACPI is enabled. It takes a fair number of out's to 0x80, but the hard freeze is reliably reproducible by writing a driver that solely does a loop of 50 outb's to 0x80 and calling it in a loop 1000 times from user space. !!! The serious impact is that the /dev/rtc and /dev/nvram devices are very unreliable - thus "hwclock" freezes very reliably while looping waiting for a new second value and calling "cat /dev/nvram" in a loop freezes the machine if done a few times in a row. This is reproducible, but requires a fair number of outb's to the 0x80 diagnostic port, and seems to require ACPI to be on. io_64.h is the source of these particular instructions, via the CMOS_READ and CMOS_WRITE macros, which are defined in mc146818_64.h. (I wonder if the same problem occurs in 32-bit mode). I'm happy to complete and test a patch, but I'm curious what the right approach ought to be. I have to say I have no clue as to what ACPI is doing on this chipset (nvidia MCP51) that would make port 80 do this. A raw random guess is that something is logging POST codes, but if so, not clear what is problematic in ACPI mode. ANy help/suggestions? Changing the delay instruction sequence from the outb to short jumps might be the safe thing. But Linus, et al. may have experience with that on other architectures like older Pentiums etc. The fact that these "pausing" calls are needed in the first place seems rather cheesy. If there's hardware that's unable to respond to IO port writes as fast as possible, then surely there's a better solution than trying to stall the IOs by an arbitrary and hardware-dependent amount of time, like udelay calls, etc. Does any remotely recent hardware even need this? The idea is that the delay is not in fact hardware dependent. With in the the absense of a POST board port 0x80 being sort of guaranteeed to not be decoded on PCI but forwarded to and left to die on ISA/LPC one should get the effect that the _next_ write will have survived an ISA/LPC bus address cycle acknowledgement timeout. I believe. And no, I don't believe any remotely recent hardware needs it and have in fact wondered about it since actual 386 days, having since that time never found a device that wouldn't in fact take back to back I/O even. Even back then (ie, legacy only systems, no forwarding from PCI or anything) BIOSes provided ISA bus wait-state settings which should be involved in getting insanely stupid and old hardware to behave... Port 0xed has been suggested as an alternate port. Probably not a great "fix" but if replacing the out with a simple udelay() isn't that simple (during early boot I gather) then it might at least be something for you to try. I'd hope that the 0x80 in include/asm/io.h:native_io_delay() would be the only one you are running into, so you could change that to 0xed and see what catches fire. If there are no sensible fixes, an 0x80/0xed choice could I assume be hung of DMI or something (if that _is_ parsed soon enough). 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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 07-12-07 01:23, Robert Hancock wrote: David P. Reed wrote: After much, much testing (months, off and on, pursuing hypotheses), I've discovered that the use of "outb al,0x80" instructions to "delay" after inb and outb instructions causes solid freezes on my HP dv9000z laptop, when ACPI is enabled. It takes a fair number of out's to 0x80, but the hard freeze is reliably reproducible by writing a driver that solely does a loop of 50 outb's to 0x80 and calling it in a loop 1000 times from user space. !!! The serious impact is that the /dev/rtc and /dev/nvram devices are very unreliable - thus "hwclock" freezes very reliably while looping waiting for a new second value and calling "cat /dev/nvram" in a loop freezes the machine if done a few times in a row. This is reproducible, but requires a fair number of outb's to the 0x80 diagnostic port, and seems to require ACPI to be on. io_64.h is the source of these particular instructions, via the CMOS_READ and CMOS_WRITE macros, which are defined in mc146818_64.h. (I wonder if the same problem occurs in 32-bit mode). I'm happy to complete and test a patch, but I'm curious what the right approach ought to be. I have to say I have no clue as to what ACPI is doing on this chipset (nvidia MCP51) that would make port 80 do this. A raw random guess is that something is logging POST codes, but if so, not clear what is problematic in ACPI mode. ANy help/suggestions? Changing the delay instruction sequence from the outb to short jumps might be the safe thing. But Linus, et al. may have experience with that on other architectures like older Pentiums etc. The fact that these "pausing" calls are needed in the first place seems rather cheesy. If there's hardware that's unable to respond to IO port writes as fast as possible, then surely there's a better solution than trying to stall the IOs by an arbitrary and hardware-dependent amount of time, like udelay calls, etc. Does any remotely recent hardware even need this? The idea is that the delay is not in fact hardware dependent. With in the the absense of a POST board port 0x80 being sort of guaranteeed to not be decoded on PCI but forwarded to and left to die on ISA/LPC one should get the effect that the _next_ write will have survived an ISA/LPC bus address cycle acknowledgement timeout. I believe. And no, I don't believe any remotely recent hardware needs it and have in fact wondered about it since actual 386 days, having since that time never found a device that wouldn't in fact take back to back I/O even. Even back then (ie, legacy only systems, no forwarding from PCI or anything) BIOSes provided ISA bus wait-state settings which should be involved in getting insanely stupid and old hardware to behave... Port 0xed has been suggested as an alternate port. Probably not a great "fix" but if replacing the out with a simple udelay() isn't that simple (during early boot I gather) then it might at least be something for you to try. I'd hope that the 0x80 in include/asm/io.h:native_io_delay() would be the only one you are running into, so you could change that to 0xed and see what catches fire. If there are no sensible fixes, an 0x80/0xed choice could I assume be hung of DMI or something (if that _is_ parsed soon enough). 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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
David P. Reed wrote: After much, much testing (months, off and on, pursuing hypotheses), I've discovered that the use of "outb al,0x80" instructions to "delay" after inb and outb instructions causes solid freezes on my HP dv9000z laptop, when ACPI is enabled. It takes a fair number of out's to 0x80, but the hard freeze is reliably reproducible by writing a driver that solely does a loop of 50 outb's to 0x80 and calling it in a loop 1000 times from user space. !!! The serious impact is that the /dev/rtc and /dev/nvram devices are very unreliable - thus "hwclock" freezes very reliably while looping waiting for a new second value and calling "cat /dev/nvram" in a loop freezes the machine if done a few times in a row. This is reproducible, but requires a fair number of outb's to the 0x80 diagnostic port, and seems to require ACPI to be on. io_64.h is the source of these particular instructions, via the CMOS_READ and CMOS_WRITE macros, which are defined in mc146818_64.h. (I wonder if the same problem occurs in 32-bit mode). I'm happy to complete and test a patch, but I'm curious what the right approach ought to be. I have to say I have no clue as to what ACPI is doing on this chipset (nvidia MCP51) that would make port 80 do this. A raw random guess is that something is logging POST codes, but if so, not clear what is problematic in ACPI mode. ANy help/suggestions? Changing the delay instruction sequence from the outb to short jumps might be the safe thing. But Linus, et al. may have experience with that on other architectures like older Pentiums etc. The fact that these "pausing" calls are needed in the first place seems rather cheesy. If there's hardware that's unable to respond to IO port writes as fast as possible, then surely there's a better solution than trying to stall the IOs by an arbitrary and hardware-dependent amount of time, like udelay calls, etc. Does any remotely recent hardware even need this? -- 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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
> Changing the delay instruction sequence from the outb to short jumps > might be the safe thing. But Linus, et al. may have experience with > that on other architectures like older Pentiums etc. Post boot we can use udelay() for this. Earlier I guess we could use udelay and make sure it starts "safe" before we know the timing. 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/
RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
After much, much testing (months, off and on, pursuing hypotheses), I've discovered that the use of "outb al,0x80" instructions to "delay" after inb and outb instructions causes solid freezes on my HP dv9000z laptop, when ACPI is enabled. It takes a fair number of out's to 0x80, but the hard freeze is reliably reproducible by writing a driver that solely does a loop of 50 outb's to 0x80 and calling it in a loop 1000 times from user space. !!! The serious impact is that the /dev/rtc and /dev/nvram devices are very unreliable - thus "hwclock" freezes very reliably while looping waiting for a new second value and calling "cat /dev/nvram" in a loop freezes the machine if done a few times in a row. This is reproducible, but requires a fair number of outb's to the 0x80 diagnostic port, and seems to require ACPI to be on. io_64.h is the source of these particular instructions, via the CMOS_READ and CMOS_WRITE macros, which are defined in mc146818_64.h. (I wonder if the same problem occurs in 32-bit mode). I'm happy to complete and test a patch, but I'm curious what the right approach ought to be. I have to say I have no clue as to what ACPI is doing on this chipset (nvidia MCP51) that would make port 80 do this. A raw random guess is that something is logging POST codes, but if so, not clear what is problematic in ACPI mode. ANy help/suggestions? Changing the delay instruction sequence from the outb to short jumps might be the safe thing. But Linus, et al. may have experience with that on other architectures like older Pentiums etc. -- 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/
