FreeBSD 8.0 hangs on boot with ACPI enabled

[Joerg Wunsch]

As Joerg Wunsch wrote:

> I might try jumping from breakpoint to breakpoint, but I first have
> to sketch a kind of schedule about where to set DDB breakpoints.
> Alas, time to go to bed now here, so I have to do that by tomorrow.

OK, I think we're getting closer on the "hangs on boot" issue (letting
the issue aside that ahc0 doesn't get the correct IO address space
assigned, I'm using the Tekram DC-895 sym0 controller by now).

I managed it to set breakpoints to xpt_alloc(), and then to _sleep().

That's where they are reached:

Waiting 5 seconds for SCSI devices to settle
[thread pid 0 tid 100000 ]
Breakpoint at   _sleep: pushl   %ebp
db> c
[thread pid 2 tid 100007 ]
Breakpoint at   _sleep: pushl   %ebp
db> c
[thread pid 3 tid 100008 ]
Breakpoint at   _sleep: pushl   %ebp
db> c
[thread pid 4 tid 100009 ]
Breakpoint at   _sleep: pushl   %ebp
db> c
[thread pid 13 tid 100011 ]
Breakpoint at   _sleep: pushl   %ebp
db> c
[thread pid 5 tid 100020 ]
Breakpoint at   _sleep: pushl   %ebp
db> c
[thread pid 14 tid 100025 ]
Breakpoint at   _sleep: pushl   %ebp
db> trace
Tracing pid 14 tid 100025 td 0xc2c61b40
_sleep(0,c2b69d38,0,0,0,...) at _sleep
fork_exit(c04bf050,0,c2b69d38) at fork_exit+0x90
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xc2b69d70, ebp = 0 ---

If I continue there, it just sits there, and hangs.  No DDB break, no
nothing.  I tried setting a breakpoint to fork_exit+0x90 (which would
be the next instruction after the _sleep), which is never reached.

The DDB ps command shows:

  pid  ppid  pgrp   uid   state   wmesg     wchan    cmd
    6     0     0     0  RL                          [fdc0]
   15     0     0     0  RL                          [acpi_cooling0]
   14     0     0     0  RL      CPU 0               [acpi_thermal]
    5     0     0     0  SL      ccb_scan 0xc08dd5d4 [xpt_thrd]
   13     0     0     0  SL      -        0xc08f4ce4 [yarrow]
    4     0     0     0  SL      -        0xc08f2ac4 [g_down]
    3     0     0     0  SL      -        0xc08f2ac0 [g_up]
    2     0     0     0  SL      fdwait   0xc2d82d00 [g_event]
   12     0     0     0  WL      (threaded)          intr
100030                   I                           [irq7: ppc0]
100029                   I                           [swi0: uart uart]
100027                   I                           [irq1: atkbd0]
100024                   I                           [irq10: sym0]
100023                   I                           [irq12: xl0]
100022                   I                           [irq9: acpi0]
100021                   I                           [swi2: cambio]
100018                   I                           [swi6: task queue]
100017                   I                           [swi6: Giant taskq]
100015                   I                           [swi5: +]
100006                   I                           [swi3: vm]
100005                   I                           [swi1: netisr 0]
100004                   I                           [swi4: clock]
   11     0     0     0  RL                          [idle]
    1     0     0     0  ?L                          [kernel]
   10     0     0     0  SL      audit_wo 0xc0906640 [audit]
    0     0     0     0  RLs     (threaded)          kernel
100019                   RunQ                        [kqueue taskq]
100016                   RunQ                        [thread taskq]
100014                   RunQ                        [acpi_task_2]
100013                   RunQ                        [acpi_task_1]
100012                   RunQ                        [acpi_task_0]
100010                   RunQ                        [firmware taskq]
100000                   D       conifhk  0xc08b640c [swapper]

If I'm getting that right, this means the _sleep that never returns
belongs to the process acpi_thermal.  This would also explain why the
hang only occurs if ACPI is enabled.

I hope that helps a little in tracking this down.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)