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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <476250D5.8000409@gmail.com>
Date:	Fri, 14 Dec 2007 10:45:57 +0100
From:	Rene Herman <rene.herman@...il.com>
To:	"David P. Reed" <dpreed@...d.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Pavel Machek <pavel@....cz>
Subject: Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80
 on some AMD64x2 laptops, etc.

On 14-12-07 03:59, David P. Reed wrote:

> Replace use of outb to "unused" diagnostic port 0x80 for time delay
> with udelay based time delay on x86_64 architecture machines.  Fix for
> bugs 9511 and 6307 in bugzilla, plus bugs reported in
> bugzilla.redhat.com.
> 
> Derived from suggestion (that didn't compile) by Pavel Machek, and
> tested, also based on measurements of typical timings of out's
> collated by Rene Herman from many in the community.
> 
> This patch fixes a number of bugs known to cause problems on HP
> Pavilion dv9000z and dv6000z laptops - in the form of solid freezes
> when hwclock is used to show or set the time.  Also, it potentially
> improves bus utilization on SMP machines, by using a waiting process
> that doesn't tie up the ISA/LPC bus for 1 or 2 microseconds.
> 
> i386 family fixes (completely parallel) were not included, considering
> that such machines might involve more risk of problems on legacy machines.

Here's the corresponding 32-bit patch. Applies fine to (and works on) 
v2.6.23.x as well after un-uniting the paths...

I do believe it would be better to do both; x86-64 machines can run 32-bit 
kernels fine and might certainly in the form of generic (installer) kernels 
and the like so if it's a fix lets fix it across the board -- the 2 us delay 
is going to be enough for everything out there, certainly given that _0_ is 
normally enough. With the arches just merged, minimising diferences should 
be a goal in itself I guess.

One thing though -- I believe we want to adjust the loops_per_jiffy default 
to make sure this works, or would work, pre-calibration as well? Not really 
sure how needed it is, but bogomips is defined as

	bogomips = loops_per_jiffy / (500000 / HZ)
			<=>
	loops_per_jiffy = bogomips * (500000 / HZ)

which with assuming any machine above 1G isn't affected by any of this and 
bogomips coming out to 2 * MHz on anything I myself have run linux on might 
suggest that

	loops_per_jiffy = 2 * 1000 * (500000 / HZ) = 1000000000 / HZ

could possibly be a sane if very large default? Alan?

diff --git a/init/main.c b/init/main.c
index 9def935..6d41771 100644
--- a/init/main.c
+++ b/init/main.c
@@ -229,10 +229,9 @@ static int __init obsolete_checksetup(char *line)
  }

  /*
- * This should be approx 2 Bo*oMips to start (note initial shift), and will
- * still work even if initially too large, it will just take slightly longer
+ * Initial value roughly corresponds to a 1 GHz CPU
   */
-unsigned long loops_per_jiffy = (1<<12);
+unsigned long loops_per_jiffy = 1000000000 / HZ;

  EXPORT_SYMBOL(loops_per_jiffy);

View attachment "v24-port80.diff" of type "text/plain" (1784 bytes)