# 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

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

Some extra information: 

2.6.38 config: http://pastebin.com/5Zi6P0Jm

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

----------

## Sannin

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

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

```

Symbol: ACPI_DEBUG [=n]

  │ Type  : boolean

  │ Prompt: Debug Statements

  │   Defined at drivers/acpi/Kconfig:285

  │   Depends on: ACPI [=y]

  │   Location:

  │     -> Power management and ACPI options

  │       -> ACPI (Advanced Configuration and Power Interface) Support (ACPI [=y])

 Symbol: ACPI_DEBUG_FUNC_TRACE [=n]

  │ Type  : boolean

  │ Prompt: Additionally enable ACPI function tracing

  │   Defined at drivers/acpi/Kconfig:297

  │   Depends on: ACPI [=y] && ACPI_DEBUG [=n]

  │   Location:

  │     -> Power management and ACPI options

  │       -> ACPI (Advanced Configuration and Power Interface) Support (ACPI [=y])

  │         -> Debug Statements (ACPI_DEBUG [=n])

```

If this does not yield anything useful, unfortunately i think you will be stuck either getting your hands dirty and trying to bisect with git to keep reverting to commit after commit after commit until you can find which one causes the problem, or just trust that it will be resolved, and hope that it is fixed upstream - neither is very fun.

----------

## Sannin

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

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

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

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.

----------

