Date:	Wed, 12 Dec 2007 15:37:07 -0500
From:	"David P. Reed" <dpreed@...d.com>
To:	Rene Herman <rene.herman@...il.com>
CC:	Pavel Machek <pavel@....cz>, Andi Kleen <andi@...stfloor.org>,
	"linux-os (Dick Johnson)" <linux-os@...logic.com>,
	David Newall <david@...idnewall.com>,
	Paul Rolland <rol@...917.net>,
	"H. Peter Anvin" <hpa@...or.com>, Krzysztof Halasa <khc@...waw.pl>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, rol@...be.net
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.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists