Date: Thu, 7 Jan 2010 08:04:33 +0100 From: Joerg Wunsch <j@uriah.heep.sax.de> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-acpi@freebsd.org Subject: Re: FreeBSD 8.0 hangs on boot with ACPI enabled Message-ID: <20100107070433.GH1616@uriah.heep.sax.de> In-Reply-To: <20100106220905.GG1616@uriah.heep.sax.de> References: <20091230082556.GD1637@uriah.heep.sax.de> <201001061343.16098.jhb@freebsd.org> <20100106193915.GE1616@uriah.heep.sax.de> <201001061554.33326.jhb@freebsd.org> <20100106220905.GG1616@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100107070433.GH1616>