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]
Date:	Mon, 17 Dec 2007 02:48:26 +0100
From:	Rene Herman <rene.herman@...il.com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Paul Rolland <rol@...917.net>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Pavel Machek <pavel@....cz>, Ingo Molnar <mingo@...e.hu>,
	"David P. Reed" <dpreed@...d.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	rol@...be.net
Subject: Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

On 16-12-07 22:42, H. Peter Anvin wrote:

> It probably comes down to which version is bigger (you probably also 
> want to try uninlining.)

slow_down_io() sort of needs to stay inline due to the REALLY_SLOW_IO thing. 
That stuff could use a cleanup, but that would be a diferent patch.

>> Thanks for the heads up (also saw the SMBIOS update to this) but those 
>> don't seem to be a problem in fact. David Reed has been running with 
>> the simple udelay(2) version of this and reported no more hangs. He 
>> moreover reported no trouble after booting with "acpi=off" meaning 
>> that things seem to be fine pre-acpi which the boot code (and this 
>> io_delay_init) is. So I believe we get to ignore those.
> 
> Okay, so there is something inside ACPI which tickles this.  Which 
> brings further credibility that it's activating a debugging hack, 
> probably inside the SuperIO/system controller chip.
> 
> It would be interesting to know exactly which part of ACPI triggers 
> this.  I bet it is a reference to system controller namespace.

Do you expect a BIOS update to be able to fix it? If so, I guess any DMI 
hack should take BIOS version into account.

Rene.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ