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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
