Comment 48 for bug 532374
Revision history for this message
| Daron Chabot (daron-chabot) wrote Re: [Bug 532374] Re: Lenovo Thinkpads with Core i5 and i7 suspend/resume (with kernel oops) once then fail horribly on next suspend | #48 |
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/
> [1266874884.830954] ACPI Error: Could not transition to ACPI mode
> (20090903/
>
> 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:/
> 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:/
>
> $ grep -A4 Magic .tmp/dmesg.txt
> [ 1.148585] Magic number: 0:523:347
> [ 1.148587] hash matches
> /build/
> [ 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:/
>