Re: [PATCH] x86: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

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

Here we go.

# dmidecode -s baseboard-manufacturer
Quanta
# dmidecode -s baseboard-product-name
30B9

There do seem to be other systems, besides mine, that have the same 
problem.  I think it's pretty likely that other machines that have this 
problem are Quanta machines, since Quanta is one of the primary ODM's 
that does HP laptops.   Don't know about the product-name being common 
with the HP dv6000z family, which is another one reported to have this 
problem.  We could try to ask all the reporters of hwclock freezes to 
report their results from dmidecode.


Rene Herman wrote:
> On 15-12-07 21:27, H. Peter Anvin wrote:
>
> > Rene Herman wrote:
> > > Yes, just posted a Patch-For-Comments that switches on the 
> > > availability of a TSC (tsc_init sets tsc_disable also for 
> > > !cpu_has_tsc) which would mean that only really old stuff would be 
> > > using the outb still. A TSC is really all we need to have a sensible 
> > > udelay().
> >
> > Uhm, no.  You have no clue what the speed of the TSC is until you 
> > have been able to calibrate it against a fixed timesource - like the 
> > PIT.
>
> Yes. Hnng. Okay, this is going nowhere in a hurry, so back to the very 
> first suggestion in this thread. How about this? This allows to switch 
> from port 0x80 to port 0xed based on DMI.
>
> David: I plugged in my own DMI values for testing, but obviously yours 
> are needed. The values that are needed are retrieved by the 
> "dmidecode" program which you will probably have installed (it might 
> be in an sbin directory) or will be able to install through whatever 
> package manager you use.
>
> dmidecode -s baseboard-manufacturer
> dmidecode -s baseboard-product-name
>
> are the values you should plug into the .matches field in the 
> dmi_system_id struct in this. It would be great if you could do that, 
> test, and post back with those values. .ident should be a nice human 
> name.
>
> It's been tested on x86-32 and seems to work fine. It's not been 
> tested on x86-64 but seems to stand a fair chance of working similarly.
>
> It ofcourse remains possible to switch to a udelay() based method 
> later on anyways but with all the pre-calibratin trouble, this might 
> be the lowest risk method in the short run.
>
> This is partly based on previous patches by Pavel Machek and David P. 
> Reed.
>
> I hope this is considered half-way correct/sane (note by the way that 
> it's not a good idea to switch a "native_io_delay_port" value since 
> plugging in a variable port would clobber register dx for every 
> outb_p, which would then have to be reloaded for the next outb again). 
> Comments appreciated.
>
> Signed-off-by: Rene Herman <rene.herman@gmail.com>
>
>  arch/x86/boot/compressed/misc_32.c |    8 ++---
>  arch/x86/boot/compressed/misc_64.c |    8 ++---
>  arch/x86/kernel/Makefile_32        |    2 -
>  arch/x86/kernel/Makefile_64        |    2 -
>  arch/x86/kernel/io_delay.c         |   53 
> +++++++++++++++++++++++++++++++++++++
>  arch/x86/kernel/setup_32.c         |    2 +
>  arch/x86/kernel/setup_64.c         |    2 +
>  include/asm-x86/io_32.h            |   17 ++---------
>  include/asm-x86/io_64.h            |   23 ++++++----------
--
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/