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:	Thu, 13 Jan 2011 14:33:45 -0600
From:	Manoj Iyer <manoj.iyer@...onical.com>
To:	Thomas Gleixner <tglx@...utronix.de>
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>,
	"Herrmann3, Andreas" <Andreas.Herrmann3@....com>
Subject: Re: [PATCH] Quirk to fix suspend/resume on Lenovo Edge 11,13,14,15

I have attached 4 dmesg outputs from AMD based thinkpad Edge 11.

1. dmesg output with kernel parameter acpi_skip_timer_override after
suspend/resume
2. dmesg output with kernel parameter acpi_skip_timer_override after system boot
3. dmesg output with nohpet kernel parameter after system boot
4. dmesg output of stock kernel with no kernel parameters.

I also noticed certain inaccuracies in my patch, but once we decide
what the right approach to the problem is I will be happy to send out
a new patch.

Many thanks
Manoj Iyer

On Thu, Jan 13, 2011 at 1:41 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> On Thu, 13 Jan 2011, Borislav Petkov wrote:
>
>> On Thu, Jan 13, 2011 at 08:13:42PM +0100, Thomas Gleixner wrote:
>> > > Well, Andreas did boot with 'hpet=verbose' on an affected machine here
>> > > and did a suspend/resume and the hpet config registers looked ok before
>> > > suspend and after resume. It might be that the HPET is temporarily
>> > > "insane" while resume lasts but we don't have any hard facts confirming
>> >
>> > And you have no explanation at all why applying the irq pin routing
>> > quirk makes HPETs temporal insanity go away magically :)
>>
>> But after the HPET counter wraps around, the machine is alive again.
>> Which means that the IRQ0 pin2 override is only temporarily needed after
>> resume... Strange.
>
> Thinking more about it:
>
> Case 1: IRQ0 pin2 override applied
>
>     Resume hangs until HPET wraps around and issues another interrupt
>
> Case 2: IRQ0 pin2 override ignored via quirk
>
>     Resume just works
>
> So the question is what is restored _AFTER_ the HPET is reprogrammed
> in the resume path ?
>
> The HPET reprogramming happens via timekeeping_resume() which is in
> the sysdev part of resume. ioapic, apic, iommus etc. are also resumed
> via the sysdev_class. So what makes sure that the ordering of these is
> correct?
>
> AFAICT nothing :)
>
> We need information about the resume order of sysdev_class and the
> difference of the pin routings in the quirk non/quirk case.
>
> Thanks,
>
>        tglx
>



-- 
--manjo

Download attachment "dmesg.acpi_skip_timer_override-after-sr" of type "application/octet-stream" (91909 bytes)

Download attachment "dmesg.acpi_skip_timer_override-boot" of type "application/octet-stream" (80193 bytes)

Download attachment "dmesg.nohpet-kernel" of type "application/octet-stream" (79728 bytes)

Download attachment "dmesg.stock-kernel" of type "application/octet-stream" (79895 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ