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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

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 <[email protected]>

 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux