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 15:12: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

Also, attaching dmesg with my patch applied. Please note the warning
message is printed from dmi_ignore_irq0_timer_override() in
acpi/boot.c, printed before setting acpi_skip_timer_override = 1;

Cheers
Manoj

On Thu, Jan 13, 2011 at 2:33 PM, Manoj Iyer <manoj.iyer@...onical.com> wrote:
> 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
>



-- 
--manjo

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ