lkml.org 
[lkml]   [2007]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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.
>


\
 
 \ /
  Last update: 2007-12-12 21:39    [W:0.139 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site