Re: More info on port 80 symptoms on MCP51 machine.

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

Port 0xED, just FYI:

cycles: out 1430, in 1370
cycles: out 1429, in 1370

(800 Mhz)


Rene Herman wrote:
> On 12-12-07 21:07, David P. Reed wrote:
>
> > 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).
>
> Don't know if someone else mentioned those but I only said 0xed. 
> That's the value Phoenix BIOSes use (yes, and which H. Peter Anvin) 
> reported as being generally problematic as well).
>
> It's in fact not all that unexpected it seems that port 0x80 responds 
> to in given that it's used by the DMA controller. It's a write that 
> falls on deaf ears. The read is going to be faster if it doesn't 
> timeout on an unused port.
>
> Although it's not faster for everyone, such as for me indicating that 
> for us port 0x80 is really-really unused, it is for many. See results 
> here:
>
> http://lkml.org/lkml/2007/12/12/309
>
> > 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.
>
> Yes, so it seems. In this case we could in fact also "fix" your 
> situation by just going to 0xed depending on for example DMI. Alan Cox 
> just posted a few further problems with a simple udelay() replacement...
>
> > 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
>
> At 800 MHz, that's 1.79 / 0.99 microseconds. The precision of the "in" 
> is somewhat interesting. Did someone at nVidia think it's an "in" from 
> 0x80 which should get the 1 microsec delay?
>
> > port ef:    cycles: out 1431, in 1378
> > port ec:   cycles: out 1432, in 1372
>
> Unused ports, bus timeouts.
>
> > ----------------------------
> >
> > 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
>
> Rene.
--
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/