Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

["David P. Reed" <dpreed@reed.com>]

Ingo -

I finished testing the rolled up patch that you provided.  It seems to 
work just fine.  Thank you for putting this all together and persevering 
in this long and complex discussion. 

Here are the results, on the offending laptop, using 2.6.24-rc5 plus 
that one patch.

First: booted with normal boot parameters (no io_delay=):

   According to dmesg, 0xed is used.

   hwclock ran fine, hundreds of times.
   my shell script loop doing "cat /dev/nvram > /dev/null" ran fine, 
several times.
   Running Rene's "port 80" speed test ran fine once, then froze the 
system hard.  (expected)

Second: booted with io_delay=0x80, several tests, rebooting after freezes:

   hwclock froze system hard.  (this is the problem that drove me to 
find this bug).
   my shell script loop froze system hard.

Third: booted with io_delay=none:

   hwclock ran fine, also hundreds of times.
   my shell script loop ran fine several times.
   Running rene's port80 test ran fine twice, froze system hard on 
third try.

Fourth: booted with io_delay=udelay:

   hwclock ran fine, also hundreds of times.
   my shell script loop ran fine several times.
   Running Rene's port80 test ran fine, froze system hard on second try.

Analysis:

   patch works fine, and default to 0xed seems super conservative.
   I will probably use the boot parameter io_delay=none, because I 
don't seem to have any I/O
   devices that require any delays - and this way I can find any that do.

Still wondering:

   what the heck is going on with port 80 on my laptop motherboard.  
Clearly it "does something".
   I will in my spare time continue investigating, though having a 
reliable system is GREAT.




  

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/