NATA update

YONETANI Tomokazu qhwt+dfly at
Wed Dec 13 08:47:49 PST 2006

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
> >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:
> >
> >
> 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.


More information about the Kernel mailing list