Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/

[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]
  Powered by Linux