Bug 31872

Created attachment 51982 [details]
/proc/cpuinfo

Created attachment 51992 [details]
picture of boot message

Created attachment 52002 [details]
picture of boot message

Created attachment 52012 [details]
full boot sequence

I could capture boot messages until the crash with a camera using the boot_delay option. Relevant messages could be those on the two pictures in attachment (I am not sure). I also linked to a tarball with pictures of the whole boot sequence (just wget http://dl.free.fr/nbej8o6bE should do it). I stopped capture boot messages until they seem to repeat endelessly, but if needed I can provide more.

Please ask me if you need more information.

Regards

Pascal Dormeau

Please confirm that this fails with unmodified kernel.org 2.6.38,
and that it does not fail with the kernel.org 2.6.37.stable (now 2.6.37.6)

Can you bisect which change between 2.6.37 and 2.6.38-rc6 causes
the failure, or at least try the rc's, such as -rc1?

please attach the .config for the failing kernel,
in the hopes that it can be reproduced on an additional machine.

Created attachment 52512 [details]
config of failing kernel

Thanks,

I will do both (confirm which unmodified kernel.org version fails, and bisect) and report back when done.

In the meantime, please find in attachment the config of the failing kernel (sorry to forget about this one).

Regards

FWIW, I seriously doubt this is an ACPICA problem.  It rather looks like this
is related to interrupts (I/O ACPI or LAPIC issue perhaps).

Created attachment 53002 [details]
2.6.38 dmesg with bf325f9538d8c89312be305b9779edbcb436af00 reverted

Hello,

I tested kernels from kernel.org:

v2.6.37.6   -> OK
v2.6.38.1   -> failed
v2.6.38-rc1 -> failed

With git bisect I could isolate the commit that results into the crash:

commit bf325f9538d8c89312be305b9779edbcb436af00
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Thu Nov 25 00:10:44 2010 +0100

    ACPI / PM: Register power resource devices as soon as they are needed
    
    Depending on the organization of the ACPI namespace, power resource
    device objects may generally be scanned after the "regular" device
    objects that they are referred from through _PRn.  This, in turn, may
    cause acpi_bus_get_power_flags() to attempt to access them through
    acpi_bus_init_power() before they are registered (and initialized by
    acpi_power_driver).  [This is not a theoretical issue, it actually
    happens for one PnP device on my testbed HP nx6325.]
    
    To fix this problem, make acpi_bus_get_power_flags() attempt to
    register power resource devices as soon as they have been found in
    the _PRn output for any other devices.
    
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Len Brown <len.brown@intel.com>

I could build and run a 2.6.38 kernel with the above commit reverted. It boots with no problem (with acpi support)
The corresponding dmesg is in attachement

Best regards

Pascal Dormeau

Please attach the output of acpidump from your machine.

Created attachment 54612 [details]
ouput of acpidump

Please,

Find in attachement the output of the acpidump command.

Best regards,

Pascal Dormeau

Created attachment 55262 [details]
Debug early registration of power resources

Please apply think patch and see if the crash happens.  If it doesn't, please
attach the dmesg output.

Sorry, the "think" above should be "this".

Created attachment 55272 [details]
ACPI: Avoid infinite recurrence in registering power resources

Well, I think I know what the problem is.

In your DSDT the _PR0 object of power resource PUT2 points back to this
power resource.  In consequence, while registering PUT2
acpi_bus_get_power_flags() sees that it depends on PUT2 and tries to
register it again, which leads to an infinitely deep recurrence.

The attached patch should work around this issue.  If it does, please
disregard the two previous comments.

Hello,

Problem fixed when patch applied. Thanks a lot.

Should I understand that the DSDT table is too much buggy here 
(I really have no understanding of the ACPI spec.) ?
In such case, should I remove PUT2 inside the
Name (_PR0, Package (0x01)
                            {
                                PUT2
                            }
stanza ?

Best regards

Pascal Dormeau

Created attachment 55342 [details]
ACPI: Avoid infinite recurrence in registering power resources (v2)

Well, it shouldn't be there, but I bet your BIOS is not the only one with
a problem of this kind, so we should add a safeguard against that.

Please check if the attached patch helps too.

Hello,

The acpi-power-resources-fix.patch v2 also helps. Thanks.

Note that I tested v2 alone (not v1+v2).

Best regards,

Pascal Dormeau

(In reply to comment #18)
> Hello,
> 
> The acpi-power-resources-fix.patch v2 also helps. Thanks.
> 
> Note that I tested v2 alone (not v1+v2).

That was as intended. :-)

Thanks for testing, I'll submit the patch for merging shortly.

Fixed by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7bed50c5edf5cba8dd515a31191cbfb6065ddc85 .