[PATCH] Quirk to fix suspend/resume on another Lenovo ThinkPad Edge, model 030246G.

[Stefan Bader]

On 02/14/2011 02:41 PM, Stefan Bader wrote:
> On 02/13/2011 03:17 PM, Thomas Schwinge wrote:
>> BugLink: http://launchpad.net/bugs/702434
>> Signed-off-by: Thomas Schwinge <thomas at schwinge.name>
>> ---
>>
>> Hallo!
>>
>> I had to apply this additional patch on top of ubuntu-maverick's
>> Ubuntu-2.6.35-26.46 (my patch is building on top of Manoj's
>> b95ee31d81f578162310e346a0b3277a65ac4a4d) in order to get suspend/resume
>> working on my girlfriend's ThinkPad Edge.  Previously, the machine would
>> sort-of resume, but the screen stayed dark; remote SSH login was possible
>> though.
>>
>>
>> Grüße,
>>  Thomas
>>
> Hi Thomas,
> 
> first thanks for the test and patch. And sorry when I start this nag here. But
> as you mention this patch adds to the other quirks that Manoj got added to
> Maverick (and I thought he had been saying this was submitted upstream). Just
> that I don't see anything there. Which makes me uneasy thinking that all of this
> might be coming back with Natty.
> 
> So I would like to take this opportunity to as: what happened to those?
> 
> -Stefan
> 
>>

So I did a bit of research and it seems that the root cause for the problem was
that there is a BIOS bug that causes IRQ0 to use the wrong polarity (at least on
systems with AMD SB800) and skipping the mapping just avoided the problem
because the other IRQs where not wrong.

The upstream discussion "Quirk to fix suspend/resume on Lenovo Edge 11,13,14,15"
ended with a test patch and the outlook to get a proper fix asap.
Andreas, I know there is always lots of stuff to do, do you have any outlook there?
Thomas, is your girlfriend's Edge an AMD based system, too?

-Stefan

Below the relevant mail with some explanation and debugging hints for convenience.

---

Seems that we've identified the root cause.

I wondered why systems with the problem have configured IOAPIC pin
with polarity=1 (low active).  That was different to what the working
systems used.

Switching the configuration to the usual polarity=0 (high active)
fixed the issue.

The explanation is that when hpet interrupt is triggerd, signal goes
from low to high. (AFAIK HPET spec even mentions that HPET interrupts
are all active high.)

Now if IO-APIC pin is configured as low active it just ignores this
signal change. It just triggers later when for next interrupt signal
will go from high to low and high again. (That happens the first time
after resume when the HPET counter wrapped around.)

Setting the correct polarity fixes the detection of the first hpet
interrupt after resume.

To confirm that your systems behave similar you should boot with
"apic=debug" kernel parameter. The output for IO APIC should show
polarity=1 for IO APIC pin 2, e.g.

 [    0.158179] IO APIC #2......
  ...
 [    0.158205]  NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:
 [    0.158210]  00 000 1    0    0   0   0    0    0    00
 [    0.158217]  01 003 0    0    0   0   0    1    1    31
 [    0.158224]  02 003 0    0    0   1   0    1    1    30

Furthermore you can check with attached test patch whether changing
the polarity fixes the problem on your system. IO APIC debug output
with this patch should change to

 [    0.156170] IO APIC #2......
  ...
 [    0.156197]  NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:
 [    0.156202]  00 000 1    0    0   0   0    0    0    00
 [    0.156209]  01 003 0    0    0   0   0    1    1    31
 [    0.156216]  02 003 0    0    0   0   0    1    1    30


I'll come up with an SB800 quirk asap. (Of course we'll also try to
fix the respective BIOSes but too often BIOS updates are only
available for a limited time period.)