linux-kernel - Re: [PATCH] Quirk to fix suspend/resume on Lenovo Edge 11,13,14,15

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 28 Jan 2011 18:59:10 +0100
From:	Andreas Herrmann <andreas.herrmann3@....com>
To:	Manoj Iyer <manoj.iyer@...onical.com>,
	"James C. Georgas" <james.georgas@...oo.ca>
CC:	Borislav Petkov <bp@...64.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] Quirk to fix suspend/resume on Lenovo Edge 11,13,14,15

On Fri, Jan 14, 2011 at 02:55:30PM -0500, Manoj Iyer wrote:
> Borislav,
> 
> Any more thoughts on this one ?

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.)

Regards,

Andreas

-- 
Operating | Advanced Micro Devices GmbH
  System  | Einsteinring 24, 85609 Dornach b. München, Germany
 Research | Geschäftsführer: Alberto Bozzo, Andrew Bowd
  Center  | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
  (OSRC)  | Registergericht München, HRB Nr. 43632

View attachment "polarity-fix.diff" of type "text/plain" (550 bytes)