Re: Endless ACPI errors on Linus tree (5b664cb235)

[Takashi Iwai <tiwai@suse.de>]

At Fri, 18 Jul 2008 15:34:13 +0200,
I wrote:
> 
> At Fri, 18 Jul 2008 15:15:25 +0200,
> I wrote:
> > 
> > At Fri, 18 Jul 2008 13:35:48 +0200,
> > Andi Kleen wrote:
> > > 
> > > Takashi Iwai <tiwai@suse.de> writes:
> > > 
> > > > the boot with the latest Linus git tree fails on x86-64 due to the
> > > > endless kernel messages like below:
> > > >
> > > >     ACPI Error (evpge-0710): No handler or method for GPE[10],
> > > >     disabling event[20080609]
> > > >
> > > > It happens on today's tree and also on yesterday (33af79d12e).
> > > > The config is below.
> > > 
> > > That was after the ACPI merge I assume?
> > 
> > Yes.
> > 
> > >  Do you have a full boot log?
> > 
> > Sorry, no.  The kernel shows the error message (the number after GPE
> > constantly changing as 1x) endlessly, and couldn't boot up properly to
> > get a log. 
> > 
> > > Revert candidates to test would be e38e8a0743b0e996a8a3fbea8908fe75a84f02c7
> > > and c91d924e3af08d4f98eab6ebf81f2b8ce132448f (Bob, that were both
> > > changes from you for evgpe.c). Can you see if reverting
> > > those helps? If yes which?
> > 
> > Will give it a spin.
> 
> I reverting both, but it doesn't fix the problem.
> 
> Another finding is that the boot reaches to the exec of init, at
> least.  So I could get a sane state with init=/bin/sh.  The message
> appears after the init script running udevd.
> 
> Also, the machine could boot fine with the recent linux-next kernel,
> at least, 20080711-0714.  (It failed for last couple of days, but it
> can be irrelevant.)
> 
> I'll investigate a bit.  Any hints are appreciated.

OK, found out the bad commit via bisect.
Reverting below fixes the boot problem.


commit 01a5bba576b9364b33f61f0cd9fa70c2cf5535e2
Author: Jan Beulich <jbeulich@novell.com>
Date:   Wed Jul 16 23:27:08 2008 +0200

    Fix FADT parsing
    
    The (1.0 inherited) separate length fields in the FADT are byte granular.
    Further, PM1a/b may have distinct lengths and live in distinct address spaces.
     acpi_tb_convert_fadt() should account for all of these conditions.
    
    Apart from these changes I'm puzzled by the fact that, not just for
    acpi_gbl_xpm1{a,b}_enable, acpi_hw_low_level_{read,write}() get an explicit
    size passed rather than using the size found in the passed GAS.  What happens
    on a platform that defines PM1{a,b} wider than 16 bits?  Of course,
    acpi_hw_low_level_{read,write}() at present are entirely un-prepared to deal
    with sizes other than 8, 16, or 32, not to speak of a non-zero bit_offset or
    access_width...


Takashi