Subject: Re: IDE probing problems
To: None <current-users@netbsd.org>
From: Manuel Bouyer <bouyer@antioche.eu.org>
List: current-users
Date: 06/09/2004 20:15:09
On Tue, Jun 08, 2004 at 04:34:47PM +0100, Ian Fry wrote:
> I'm having problems with recent -current kernels not probing IDE devices
> properly. A normal boot finds the following IDE/SCSI devices:
> 
> NetBSD 2.0E (TERRY) #312: Mon May 10 11:22:52 BST 2004
> [...]
> fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
> IPsec: Initialized Security Association Processing.
> scsibus0: waiting 2 seconds for devices to settle...
> atapibus0 at atabus0: 2 targets
> cd0 at atapibus0 drive 1: <MATSHITA CR-585, , ZS15> cdrom removable
> cd0: 32-bit data port
> cd0: drive supports PIO mode 3, DMA mode 1
> wd0 at atabus0 drive 0: <Maxtor 83201A6>
> wd0: drive supports 16-sector PIO transfers, LBA addressing
> wd0: 3060 MB, 6218 cyl, 16 head, 63 sec, 512 bytes/sect x 6267744 sectors
> wd0: 32-bit data port
> wd0: drive supports PIO mode 4, DMA mode 2
> wd0(siside0:0:0): using PIO mode 4, DMA mode 2 (using DMA data transfers)
> cd0(siside0:0:1): using PIO mode 3, DMA mode 1 (using DMA data transfers)
> sd0 at scsibus0 target 0 lun 0: <QUANTUM, FIREBALL ST3.2S, 0F0C> disk fixed
> sd0: 3090 MB, 7068 cyl, 4 head, 223 sec, 512 bytes/sect x 6328861 sectors
> sd0: sync (50.00ns offset 15), 8-bit (20.000MB/s) transfers, tagged queueing
> wd1 at atabus1 drive 0: <ST38410A>
> wd1: drive supports 32-sector PIO transfers, LBA addressing
> wd1: 8223 MB, 16708 cyl, 16 head, 63 sec, 512 bytes/sect x 16841664 sectors
> wd1: 32-bit data port
> wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 4 (Ultra/66)
> wd1(siside0:1:0): using PIO mode 4, Ultra-DMA mode 2 (Ultra/33) (using DMA data transfers)
> boot device: wd0
> root on wd0a dumps on wd0b
> root file system type: ffs
> 
> However, with all the 2.0F kernels I've tried, wd0 isn't detected at all,
> and I get a 'lost interrupt' message from the IDE controller. Probing also
> takes much longer than normal - an extra 5-10 seconds, I think, and the
> CDROM seems to spin-up twice, rather than once.

Can you set wdcdebug_mask to 0x10, and send me the result ?
It's easier to do it with a serial console of course, as I assume your
boot disk isn't functionnal.
Another way to avoid writting the debug messages by hand is to use a boot
floppy, or a NFS root.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--