From owner-freebsd-acpi@FreeBSD.ORG Thu Jan 7 07:04:35 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D65C6106568B; Thu, 7 Jan 2010 07:04:35 +0000 (UTC) (envelope-from j@uriah.heep.sax.de) Received: from uriah.heep.sax.de (uriah.heep.sax.de [213.240.137.9]) by mx1.freebsd.org (Postfix) with ESMTP id 28C338FC16; Thu, 7 Jan 2010 07:04:34 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id B229D45; Thu, 7 Jan 2010 08:04:33 +0100 (MET) Date: Thu, 7 Jan 2010 08:04:33 +0100 From: Joerg Wunsch To: John Baldwin Message-ID: <20100107070433.GH1616@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100106220905.GG1616@uriah.heep.sax.de> X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-acpi@freebsd.org Subject: Re: FreeBSD 8.0 hangs on boot with ACPI enabled X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joerg Wunsch List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 07:04:36 -0000 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. ;-)