Re: NATA update

[YONETANI Tomokazu <qhwt+dfly@xxxxxxxxxx>]

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.