Kernel 2.6.38 hangs unless i set acpi=off

Sannin

Hi

I just installed the newest kernel and it always hangs at a spesific point. I don't have a log for that, so i ll just right down the messages:

PCI: Using ACPI for IRQ routing
pci 000:00:00:0: no compatible bridge window for it
Switching to clocksource hpet
pnp: PnP ACPI init
ACPI: bus tupe pnp registered
system 00:01: [io (numbers, blah blah)] has been reserved
system 00:01: [io (numbers, blah blah)] has been reserved
system 00:01: [io (numbers, blah blah)] has been reserved

And it hangs at that point. I figured it must have been something wrong with ACPI, so i tried acpi=off. It booted but i had some other problems such as no network connection, so i need a permament fix. I tweaked some kernel options but nothing worked. I ll try to provide the .config file in a while.

BradN · Posted: Wed Mar 16, 2011 6:12 pm Post subject:

The best course of action would be running a bisection test to find what change in the kernel source code caused the acpi to stop working on your system. Then you can make a bug report that provides useful info to developers.

Too much to retype, see this thread: https://forums.gentoo.org/viewtopic-t-834520.html

Sannin · Posted: Wed Mar 16, 2011 7:51 pm Post subject:

Some extra information:

2.6.38 config: http://pastebin.com/5Zi6P0Jm
2.6.37-r1 2.6.38 diff: http://pastebin.com/FZrm2Af3

Sannin · Posted: Thu Mar 17, 2011 9:38 am Post subject:

BradN i tried your suggestion. I started by building a kernel almost identical to the previous one. The only changes are some deprecated options, and some new options on 2.6.38 kernel that are not set. The result is still the same. Is there anyway to log the kernel when it hangs, so i can provide more accurate information?

cach0rr0 · Posted: Thu Mar 17, 2011 9:53 am Post subject:

i guess you could try these, but not good to leave on long-term

Sannin · Posted: Thu Mar 17, 2011 10:10 am Post subject:

Here is a photo of the kernel output when it hangs: http://img12.imageshack.us/i/p1010116k.jpg/

Compare with 2.6.37 output at that point: http://pastebin.com/xEjGca6h

Maybe clocksource hpet is causing the problem. I tried setting clocksource=tsc or clocksource=acpi_pm at kernel boot options, but it switched to clocksource hpet anyway without any error message.

BradN · Posted: Tue Mar 22, 2011 4:54 am Post subject:

I think you misunderstand my suggestion - a bisection test is a feature of the git source code management system that will provide you with a midpoint (in the form of a kernel source tree) between your last known working kernel and the first known failed one, and you tell it whether that version boots or not. Then it gives you a new midpoint kernel and you tell it if that one worked... so on for log2(number of change sets committed) kernels, and at the end, you know exactly* what change broke things. Then you can make sure developers know they broke something.

*Unless the breakage is related to gentoo patches, or git gives you an unlucky tree that either doesn't compile or doesn't run far enough to hit your problem, but I think there may be ways to deal with the second case. For the first case, double check before you start that vanilla-sources also experiences the lockup.

Sannin · Posted: Tue Mar 29, 2011 1:26 pm Post subject:

An update on this thread:

The acpi problems i had and my eth0 not working were 2 separate issues. The first one was solved by flashing the newest beta bios on my motherboard. I never really understood what was the problem with that, because it was working fine with the previous kernel. My eth0 was still not working though. I tried git-sources, vanilla-sources and nothing did work so i tried BradN' s suggestion. I found some nice articles about git bisect and after some failed tries i did it. There was indeed a commit that messed up r8169. I have opened a bug about that: https://bugs.gentoo.org/show_bug.cgi?id=359671

BradN · Posted: Wed Mar 30, 2011 11:17 pm Post subject:

Cool, hopefully a gentoo dev will push this problem upstream and get it fixed. If not, now that you know the patch involved, you should be able to undo the patch and at least have a local copy that works for you until it's fixed properly.