More info on port 80 symptoms on MCP51 machine.

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

Sadly, I've been busy with other crises in my day job for the last few 
days.   I did modify Rene's test program and ran it on my "problem" 
machine, with the results below.

The interesting part of this is that port 80 seems to respond to "in" 
instructions faster than the presumably "unused" ports 0xEC  and 0XEF  
(those were mentioned by someone as alternatives to port 80).

That, and the fact that the port 80 test reliably freezes the machine 
solid the second time it is run, and the "hwclock" utility reliably 
hangs the machine if the port 80's are used in the CMOS_READ/CMOS_WRITE 
loop, seems to strongly indicate that this chipset or motherboard 
actually uses port 80, rather than there being a bus problem.

Someone might have an in to nVidia to clarify this, since I don't.  In 
any case, the udelay(2) approach seems to be a safe fix for this machine.

Hope input from an "outsider" is helpful in going forward.   I put a lot 
of time and effort into tracking down this problem on this particular 
machine model, largely because I like the machine.

Running the (slightly modified to test ports 80, ec, ef instead of just 
port 80) test when the 2 GHz max speed CPU is running at 800 MHz, here's 
what I get for port 80 and port ec and port ef.

port 80:   cycles: out 1430, in 792
port ef:    cycles: out 1431, in 1378
port ec:   cycles: out 1432, in 1372
----------------------------

System info:  HP Pavilion dv9000z laptop (AMD64x2)

PCI bus controller is nVidia MCP51.
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 72
model name      : AMD Turion(tm) 64 X2 Mobile Technology TL-60
stepping        : 2
cpu MHz         : 800.000
cache size      : 512 KB