On 10/3/10 6:14 AM, David Wolfskill wrote: > On Sun, Oct 03, 2010 at 02:52:19PM +0300, Andriy Gapon wrote: >> on 03/10/2010 14:28 David Wolfskill said the following: >> [snipped] >> >> Can't you just drop to DDB prompt and examine where the threads are? > Eh -- thanks for the reality check; I needed that. :-} > > OK; I enabled the KDB& DDB options& rebuilt the kernel; 2nd reboot > after "make installkernel" huhng as before. > > Now, unfortunately, the new laptop doesn't have a serial console, so > below is hand-transcribed: > > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > 524288K of memory above 4GB ignored > Copyright (c) 1992-2010 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-CURRENT #4 r213380: Sun Oct 3 04:35:15 PDT 2010 > ... > ugen7.1:<Intel> at usbus7 > uhub7:<Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus7 > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub4: 2 ports with 2 removable, self powered > uhub5: 2 ports with 2 removable, self powered > uhub6: 2 ports with 2 removable, self powered > uhub3: 6 ports with 6 removable, self powered > cd0 at ata3 bus 0 scbus2 target 0 lun 0 > cd0:<TSSTcorp DVD+-RW TS-U633A D200> Removable CD-ROM SCSI-0 device > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed > ada0 at ata2 bus 0 scbus1 target 0 lun 0 > ada0:<Seagate ST9250421ASG DE16> ATA-8 SATA 2.x device > ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, device > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) > SMP: AP CPU #1 Launched! > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > uhub7: 6 ports with 6 removable, self powered > ugen2.2:<Broadcom Corp> at usbus2 > > <previously-descibed hang; I used Ctl+Alt+Esc to enter DDB. > > KDB: enter: manual escape to debugger > [ thread pid 12 tid 100017 ] > Stopped at 0xc08d992a = kdb_enter+0x3a: movl $0,0xc0e33574 = kdb_why > db> bt > Tracing pid 12 tid 100017 td 0xc94575a0 > kdb_enter(c0c737ab,c0caf6cb,1,0,1,...) at 0xc06d992a = kdb_enter+0x3a > scgetc(c0e21950,0,c0caf5f1,2a1,c9457644,...) at 0xc07930a8 = scgetc+0x568 > sckbdevent)c92f7500,0,c0fb3ea0,c92f9400,c6da9c4c,...) at 0xc0793424 = sckbdevent+0x1e4 > kbdmux_intr(c92f7500,0,c92f9608,c6da9c78,c08e63e3,...) at 0xc069c86b = kbdmux_intr+0x2b > kbdmux_kbd_intr(c92f7500,1,c0ccd301,53,c9194a94,...) at 0xc069ce45 = kbdmux_kbd_intr+0x25 > taskqueue_run(c9194a98,0,c0ccd301,4a,c6da9cb8,...) at 0xc08e63e3 = taskqueue_run+0xc3 > taskqueue_swi_giant_run(0,0,c0cc37a5,4c3,c945a0b8,...) at 0xc08e6be6 = taskqueue_swi_giant_run+0x66 > intr_event_execute_handlers(c91d37f8,c945a080,c0cc37a5,533,c945a0f0,...) at 0xc087e655 = intr_event_execute_handlers+0x125 > ithread_loop(c943f980,c6da9d28,c0cc3520,349,c91d37f8,...) at 0xc087f42f = ithread_loop+-x9f > fork_exit(c087f390,c943f980,c6da9d28) at 0xc087c3a8 = fork_exit+0xb8 > fork_trampoline() at 0xc0bd5824 = fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc6da9d60, ebp = 0 --- > db> > > I used the "ps" command at that point to see that PID 12 is "[intr]", > with the following assignments: > > PID state wmesg cmd > 100072 I [irq15: ata1] > 100071 I [irq14: ata0] > 100070 I [irq12: psm0] > 100069 I [irq1: atkbd0] > 100067 I [irq19: cbb0 atapci+] > 100064 I [irq17: fwohci0] > 100045 I [irq1258: iwn0] > 100044 I [irq1257: hdac0] > 100035 I [irq122: uhci2 ehci0+] > 100030 I [irq121: uhci1 ehci4] > 100025 I [irq120: hpet0 ehci0*] > 100023 I [irq19: acpi0] > 100018 I [swi6: task queue] > 100017 Run CPU 1 [swi6: Giant taskq] > 100015 I [swi5: +] > 100014 I [swi2: cambio] > 100008 I [swi4: clock] > 100007 I [swi4: clock] > 100006 I [swi1: netisr 0] > 100005 I [swi3: vm] > > I then tried "panic", but that does not appear to have been successful. > > Peace, > david well you got the stacktrace of the keyboard handler since you got into ddb via the keyboard.. you need to see what ELSE is running.. especially the initial threads. and look at THOSE stacks I think "bt [thread-ID]" works or maybe "thread [ID]" (it's bee a year).Received on Sun Oct 03 2010 - 20:43:10 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:08 UTC