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