Hmmm... given Paladin's statement of correct operation under Windows 7, either there is a workaround by that OS, or Colin's initial diagnosis is not quite right.
My shiny new x201s has aversions to waking up (I can totally relate!), and using Win7... ;) Anything I can do to help here ? On Thu, Apr 1, 2010 at 10:16 AM, Colin King <[email protected]> wrote: > Unfortunately, it looks like a BIOS issue to me at this point. > > Looking at Tom's logs I get: > > [1266874884.830945] ACPI Error: Hardware did not change modes > (20090903/hwacpi-144) > [1266874884.830954] ACPI Error: Could not transition to ACPI mode > (20090903/evxfevnt-93) > > On my T410 I get the same. This error occurs when the kernel ACPI driver > attempts to transition to ACPI mode > by writing ACPI_ENABLE to the SMI_CMD port but fails. This is dependant on > the FADT containing the correct > ACPI_ENABLE and/or ACPI_DISABLE values - I've disassembled the FADT and > they are 0xf0 and 0xf1 respectively > which means they are defined according to ACPI 2.0. > > One possibility of the transition to ACPI mode failing is that hardware is > taking more than the 3 seconds allowed or that > the FADT contains the wrong values, the latter is very unlikely. > > It is noteworthy that the BIOS should have disabled all GP events by the > time the transition occurs - if it hasn't transitioned > correctly, perhaps these are still enabled causing a huge number of IRQ's > on line 9 which causes the later error message: > > irq 9: nobody cared (try booting with the "irqpoll" option) > > this seems to happen when the IRQ handler detects more than 99900 > unhandled IRQs. > > I will debug the mode transition code to see if I can tease a little > more out of this bug, but it looks like a firmware problem at this > stage. > > -- > Lenovo Thinkpads with Core i5 and i7 suspend/resume (with kernel oops) once > then fail horribly on next suspend > https://bugs.launchpad.net/bugs/532374 > You received this bug notification because you are a direct subscriber > of the bug. > > Status in The Linux Kernel: Unknown > Status in OEM Priority Project: New > Status in “linux” package in Ubuntu: Confirmed > Status in “linux” source package in Lucid: Confirmed > > Bug description: > This happens identically with both Thinkpad T410 and T510 models (intel > integrated graphics, nvidia discrete graphics). The first suspend/resume > completes successfully. The second suspend appears to work, but when > waking, a few LEDs flicker, but the laptop stays suspended (moon LED on the > lid stays lit, LED around power button continues to pulse). Pressing the > power button again causes a reboot (no other buttons seem to do anything in > this state). > > Per https://wiki.ubuntu.com/DebuggingKernelSuspend: > > $ grep -A4 Magic .tmp/dmesg.txt > [ 1.148585] Magic number: 0:523:347 > [ 1.148587] hash matches > /build/buildd/linux-2.6.32/drivers/base/power/main.c:471 > [ 1.148615] pci0000:00: hash matches > > That's the DRAM Controller. > > Same results from the "xterm" session, and also without X, so no > gnome-power-manager interactions. > > > > To unsubscribe from this bug, go to: > https://bugs.launchpad.net/linux/+bug/532374/+subscribe > -- Lenovo Thinkpads with Core i5 and i7 suspend/resume (with kernel oops) once then fail horribly on next suspend https://bugs.launchpad.net/bugs/532374 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
