On Tue, Dec 12, 2006 at 03:13:45PM +0000, Thomas E. Spanjaard wrote: > YONETANI Tomokazu wrote: > >If I boot a UP kernel, it proceeds to "start_init: trying /sbin/init", > >but then stuck there(the backtrace in DDB is from console handler). > > Could you put the dmesg and backtrace of the UP kernel online? The panic > backtrace from last week was from my faulty locking use in the device > timeout handling...
The backtrace looks something like this: Debugger(c02a1a77) scgetc(c030e8a0,2,c017ba0b,0,c0306b40) sckbdevent(c0306b40,0,c030e8a0) atkbd_intr(c0306b40,0,cd682d84,c015d699,c0306b40) atkbd_isa_intr(c0306b40,0) ithread_handler(1,0,0,0,0) lwkt_exit() so I have no idea which kernel thread to show you. I'll try to get the dmesg and the kernel dump tomorrow as I don't have access to the machine in question right now(and I need to get some sleep :). > >One thing caught my attention in dmesg from SMP kernel: > > nata0 [tentative] failed to probe at port 0x1f0 irq 14 on isa0 > > nata1 [tentative] failed to probe at port 0x170 irq 15 on isa0 > >vs > > ata2 [tentative] failed to probe at port 0x1f0 irq 14 on isa0 > > ata3 [tentative] failed to probe at port 0x170 irq 15 on isa0 > > You can't specify nata0 at isa and nata1 at isa, they have to be ata0 > and ata1. The device option name is nata, but the devicename is actually > ata, to remain compatible with the old ATA code (it shares majors device > numbers). In theory you can have device nata and ata0 at isa and ata1 at > isa, but I really doubt anyone is running DragonFlyBSD on a machine with > a non-PnP ISA ATA controller ;). So you can just remove those two lines > from the kernel and not have these messages (btw, they're harmless). OK, I'll try that later (but the similar configuration worked on another machine whose root fs is on a SCSI disk). > >FWIW, I put the kernel configs here: > > http://les.ath.cx/DragonFly/FIREBOLT.SMP.nata > > http://les.ath.cx/DragonFly/FIREBOLT.nata > > Other than the isa stuff, they're fine. I don't think I'm using > ATA_STATIC_ID much anymore, maybe in atapicd and atapist... atadisk uses > device_get_unit() now unconditionally. Thanks.
