On Sun, 6 Oct 2002, Seth Hieronymus wrote:
> Thanks for the pointers. Here's the trace 1: > mi_switch(c0bb9988,14,c01bbe60,c0bb98f0,1) at mi_switch+0x290 > msleep(c03778a0,0,68,c03153d7,14) at msleep+0x477 > g_waitidle(1,c0314e10,c18f2885,c031bd64,c0b8dc20) at g_waitidle+0x8b > g_dev_clone(0,c18f2885,6,c879cc08,c0bb6d80) at g_dev_clone+0x37 > getdiskbyname(c18f2880,c879cc80,c0202f87,c18f2880,c18f2880) at > getdiskbyname+0xa2 > setrootbyname(c18f2880,c18f2880,c879cc48,c18f2880,20302020) at > setrootbyname+0x11 > vfs_mountroot_try(c1867220,c01912e0,c0bb8dc0,c879cd0c,c019134b) at > vfs_mountroot_try+0x127 > vfs_mountroot(c034b1c0,1,c0316bc7,216,203a2065) at vfs_mountroot+0x70 > start_init(0,c879cd48,c031790b,34d,726f772d) at start_init+0x6b > fork_exit(c01912e0,0,c879cd48) at fork_exit+0xa5 > fork_trampoline() at fork_trampoline+0x1a This sounds identical (modulo geom details) to the la-la land my boxes were going off into. As I said, I never really followed up, but it looked like one of the i/o/device transactions during the root mount was getting "lost", and as a result the init thread was never waking up. I'll probably have to let someone with more i/o clue take it from here. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
