DragonFly kernel List (threaded) for 2006-12
Re: NATA update
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:
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
> > 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.