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

From: Takashi Iwai
Date: Fri Jul 18 2008 - 11:48:49 EST


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@xxxxxxx> 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@xxxxxxxxxx>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/