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