[I wish you guys would use ">" instead of tabs for quotes]

Eduardo wrote:
>> ---------------------------------------------------------------------------
>> ok  boot cdrom
>> ...
>> wd0 at pciide0 channel 0 drive 0: <ST39140A>
>> wd0: drive supports 16-sector pio transfers, lba addressing
>> wd0: 8693 MB, 17662 cyl, 16 head, 63 sec, 512 bytes/sect x 17803440 sectors
>> wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 2
>> wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 (using DMA data transfers)
>> pciide0: secondary channel configured to native-PCI mode
>> pciide0: disabling secondary channel (no drives)
>> pcons at mainbus0
>> No counter-timer -- using %tick at 333MHz as system clock.
>> Using tick -- intr in 3330000 cycles...done.
>> raidattach: Asked for 4 units
>> Kernelized RAIDframe activated
>> root device:
>> ---------------------------------------------------------------------------
> 
>> At this point I don't know what to do.  Typing "? yields
>> 
>> use one of : raid0[a-h] raid1[a-h] raid2[a-h] raid3[a-h] hme0 wd0[a-h] halt
>> root device:
>> 
>> Where is the "md0a" choice for the "microroot" install I would expect here?
> 
> First of all:  sparc64 does not support RAMDISKs at the moment so
> you need either a miniroot or real filesystem.

OK, in the followup with Todd you showed that the "ramdisk.fs.gz" file is
really a "miniroot.fs.gz" (right?).  So that's part of the puzzle.  That
still leaves:

>> I have no clue what to use/do at this point.  if I specify "wd0", I get 
asked
>> for "dump device" and "file system" type, after which I see (if I type in
>> "wd0b" and "ffs", respectively - even though I'm convinced these answers are
>> wrong anyway)
>> 
>> root on wd0a dumps on wd0b
>> pciide0:0:0: lost interrupt
>> 	type: ata tc_bcount: 512: tc_skip:0
>> pciide0:0:0: lost interrupt
>> 	type: ata tc_bcount: 512: tc_skip:0
>> pciide0:0:0: lost interrupt
>> 	type: ata tc_bcount: 512: tc_skip:0
>> pciide0:0:0: lost interrupt
>> 	type: ata tc_bcount: 512: tc_skip:0
>> pciide0:0:0: lost interrupt
>> 	type: ata tc_bcount: 512: tc_skip:0
>> pciide0:0:0: bus-master DMA error: missing interrupt, status=0x20
>> wd0: transfer error, downgrading to PIO mode 4
>> wd0(pciide0:0:0): using PIO mode 4
>> wd0c: DMA error reading fsbn 0 ( wd0 bn 0; cn 0 tn 0 sn 0), retring
>
>> Followed by another 4 sets of "lost interrupt" messages and then a
>> 
>> wd0c: device timeout reading fsbn 0 (wd0 bn 0; cn 0 tn 0 sn 0), retrying
>> 
>> Eventually it returns (after several more of the above cycles) with
>> 
>> wd0: disk label read error
>> cannot mount root, error = 6
>> root device (default wd0a): 
>> 
>> What now?  Why is the kernel choking on reading the internal EIDE hard disk?
>> 
>> Why are there no "md0[a-h]" and/or "cd0[a-h]" choices for "root device", as
>> one might expect?
> 
> Second: I don't see a probe of `cd0' in the above boot messages
> so the kernel may not have probed your CD-ROM drive.

[In Church Lady voice:] "Well isn't that just *special*."

I'll have to check again once I get into work, but I don't recall seeing
any "cd0:" probe messages either.

So then.  I have a bog-standard Ultra 5+ with Seagate ST39140A 9 Gb EIDE
disk, and whatever standard CD-ROM drive comes with it.  I've got a bootable
CD-ROM disc, and it boots from it fine, but I can't use it to load NetBSD
because the kernel doesn't see the drive it's been booted off of, and I
can't load it onto the internal drive anyway, because the "pciide" driver
misses interrupts and gets DMA errors and can't read the disk label.

Under these circumstances, should I not bother with this port and wait
for 1.6 (or whenever these devices work/probe OK in -current)?

	- Greg