Messages in this thread | | | Date | Wed, 12 Dec 2007 15:37:07 -0500 | From | "David P. Reed" <> | Subject | Re: More info on port 80 symptoms on MCP51 machine. |
| |
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. >
| |