linux-kernel - Re: [Bug 15289] Regression 2.6.32 -> 2.6.33, Kernel needs a helping key to boot :)

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:	Mon, 1 Mar 2010 22:21:39 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	bugzilla-daemon@...zilla.kernel.org,
	LKML <linux-kernel@...r.kernel.org>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	Andreas Herrmann <andreas.herrmann3@....com>,
	Asbjørn Sannes <kernelbugzilla@...nes.org>,
	Venkatesch Pallipadi <venkatesh.pallipadi@...el.com>
Subject: Re: [Bug 15289] Regression 2.6.32 -> 2.6.33, Kernel needs a helping
 key to boot :)

On Mon, 1 Mar 2010, Rafael J. Wysocki wrote:
> [Swithing to e-mail, please keep bugzilla-daemon in the CC list.]
> 
> On Monday 01 March 2010, bugzilla-daemon@...zilla.kernel.org wrote:
> > http://bugzilla.kernel.org/show_bug.cgi?id=15289
> > 
> > --- Comment #30 from Asbjørn Sannes <kernelbugzilla@...nes.org>  2010-03-01 06:17:06 ---
> > hm, so from what I have gathered the previously bisected commit only exposes
> > another bug (hidden by enabling hpet). So I started bisecting again, this time
> > with hpet=disabled all the way and found:
> > 
> > commit aa276e1cafb3ce9d01d1e837bcd67e92616013ac
> > Author: Thomas Gleixner <tglx@...utronix.de>
> > Date:   Mon Jun 9 19:15:00 2008 +0200
> > 
> > x86, clockevents: add C1E aware idle function
> > 
> > Reverting this from a non-working 2.6.27 makes it work also. Things have
> > changed considerably since then so I was not able to revert it from the newest
> > kernel.
> > 
> > Maybe that disabling of SBX00 hpet msi, only should be done when you do
> > actually have floppy support? Makes more people boot atleast :P
> 
> Thomas, it looks like something's missing in our C1E handling.  Can you have
> a look at this bug report, please?

Groan. We have been through that exercise of blaming the above commit
and the C1E handling for a couple of times now. It never turned out to
be the real culprit.

Looking at the various steps Asbjorn took to analyse that problem it
simply boils down to the oldest problem with timers on ATI chipsets:

       the irq0 timer interrupt routing is hosed

I have no clue yet, why this is not detected by the test logic we have
in place for that, but it might be something which gets borked later
in the boot process.

Enabling MSI for HPET just papers over the problem as it uses a
different interrupt vector and mechanism.

Disabling HPET does not help simply because PIT is using IRQ0 as well
as the MSI disabled HPET.

I need some sleep to come up with a reasonable method to debug that,
but maybe someone else has an brilliant idea before I have to twist my
brain around it.

Thanks,

	tglx