Re: NATA update

["Thomas E. Spanjaard" <tgen@xxxxxxxxxxxxx>]

YONETANI Tomokazu wrote:
> 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 :).

I fear this panic is unrelated, as Victor Balada Diaz is having the same 
on his 1.6 system. His /sbin/init is stuck in nanosleep, and apparently 
never jumped to.

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

It's not that it breaks stuff, but the probes just will never work :).

I just experienced something odd, perhaps similar to your experience 
earlier. I (probably) experience a null deref when trying to open acd0c, 
as you can see on http://deviate.fi/~tgen/mountroot_1.png . It appears 
si_drv1 is NULL on line 218 in sys/dev/disk/nata/atapi-cd.c. Which is 
strange, because in acd_attach() I really do set si_drv1 on acd0. And, 
on the SCSI test system, I can open, read, write, etc /dev/acd0c without 
problems. And the code was able to find acd_open(), so the dev_ops have 
been registered, so it's not like it's passing the wrong device. 
Therefore I suspect something somewhere is scribbling over si_drv1, but 
I don't know where.

Cheers,
--
        Thomas E. Spanjaard
        tgen@netphreax.net

Attachment: signature.asc
Description: OpenPGP digital signature