NATA update

[Thomas E. Spanjaard]

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 at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00026.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20061214/e7f64211/attachment-0020.obj>