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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 23 Dec 2007 16:56:51 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Carlos Corbacho <carlos@...angeworlds.co.uk>
cc:	"H. Peter Anvin" <hpa@...nel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, linux-kernel@...r.kernel.org,
	Greg KH <gregkh@...e.de>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Len Brown <lenb@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4
 suspend-to-RAM



On Mon, 24 Dec 2007, Carlos Corbacho wrote:
> 
> Please disregard the patch anyway - my test system was still using the custom 
> DSDT - it doesn't fix anything.

Ok, so it's not a simple IO port conflict.

And the range 0x1400-0x147f (which is apparently the ACPI block) is 
properly marked as reserved.

So the IO write to 1428 is a red herring. It's just part of the normal 
sequence to suspend-to-ram, and while it failing probably has something to 
do with the failure to s2ram, it's simply a result of ACPI doing something 
insane, and probably making some assumptions that we've broken by mistake 
when we do the higher-level device_suspend() before we do the low-level 
one.

IOW, it looks like the normal kind of ACPI mess. Color me not in the least 
surprised, and it needs somebody who understands AML and what the heck is 
supposed to happen to figure out.

The kernel doesn't do anything at all to port 1428 (since it is reserved), 
so if any write to it "fails" (how?) it's probably because the writer made 
some assumptions about system state.

			Linus


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