Messages in this thread | | | Date | Fri, 18 Jul 2008 17:48:39 +0200 | From | Takashi Iwai <> | Subject | Re: Endless ACPI errors on Linus tree (5b664cb235) |
| |
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
| |