Message-ID: <4763FE7A.4000105@reed.com>
Date:	Sat, 15 Dec 2007 11:19:06 -0500
From:	"David P. Reed" <dpreed@...d.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Ingo Molnar <mingo@...e.hu>, Rene Herman <rene.herman@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Rene Herman <rene.herman@...access.nl>,
	Pavel Machek <pavel@....cz>
Subject: Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80
 on some AMD64x2 laptops, etc.

I understand the risks of such a fundamental change, and it may be only 
a minor concern, but I did also point out that using an unused port 
causes the bus to be tied up for a microsecond or two, which matters on 
a fast SMP machine.

Of course all the other concerns you guys are worrying about are really 
important.  I don't want to break anybody's running systems...  I'd like 
to see my machine run smoothly, and all the other machines that may or 
may not have this problem (google "hwclock freeze" to see that I'm far 
from alone - I just have persevered in "bisecting" this problem with 
kernel tweaks for months, whereas the others did not or did not know how).

By the way, this laptop is really nice for Linux in lots of ways.  Dual 
drives, so I set it up with software RAID for reliability, dual 64-bit 
processors, fast 3D graphics, etc.  Great battery life.  Just one last 
kernel issue.

I also note that curent machines like the problem machine have ACPI, and 
maybe those would be the ones that vendors might start to define port 80 
to mean something. As I noted, it /seems/ to be only when ACPI is turned 
on that this problem happens on my machine - that's when the OS starts 
to be involved in servicing various things, so it suggests that maybe 
things change about port 80's unknown function on these machines when 
ACPI is servicing the system management code (that's not something I 
have been able to verify).

My belief is that my machine has some device that is responding to port 
80 by doing something.  And that something requires some other program 
to "service" port 80 in some way.  But it sure would be nice to know.   
I can't personally sand off the top of the chipset to put probes into it 
- so my normal approach of putting a logic analyzer on the bus doesn't work.

PS: If I have time, I may try to build Rene's port 80 test for Windows 
and run it under WinXP on this machine (I still have a crappy little 
partition that boots it).   If it freezes the same way, it's almost 
certain a design "feature", and if it doesn't freeze, we might suspect 
that there is compensating logic in either Windows ACPI code or some way 
that windows "sets up" the machine.

Alan Cox wrote:
> On Sat, 15 Dec 2007 14:27:25 +0100
> Ingo Molnar <mingo@...e.hu> wrote:
>
>   
>> * Rene Herman <rene.herman@...il.com> wrote:
>>
>>     
>>> The issue is -- how do you safely replace the outb pre-loops_per_jiffy 
>>> calibration? I'm currently running with the attached hack (not 
>>> submitted, only for 32-bit and discussion) the idea of which might be 
>>> the best we can do?
>>>       
>> how about doing a known-NOP chipset cycle? For example:
>>
>>   inb(PIC_SLAVE_IMR)
>>     
>
> It needs tobe a different chip to the main one (or macrocell anyway) - so
> PIC for PIT and vice versa. However since we know 0x80 works for
> everything on the planet but this one specifies of laptop which seems to
> need a firmware update its a very high risk approach.
>
> Alan
>
>   
--
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