Hello.  I attempted to do so, but turning on probe debugging caused
the drive to be recognized, consistently.  When I turned debugging off, the
drive disappeared again.  So, I'm willing to accept that these timeout
values are  very much too long, but I'm not sure how to go about finding
the one which is the problem.  For what it's worth, the probe debug output
is below.  Any ideas?  (I'm seeing this on a number of different machines.)
-thanks
-Brian

piixide0:0: before reset, st0=0x50, st1=0x42
piixide0:0 drive 1 wd_cyl_lo(2): got 0x2 != 0x01
piixide0:1: before reset, st0=0x7f, st1=0x7f
piixide0:1 drive 0 wd_cyl_lo: got 0x7f != 0x02
piixide0:1 drive 0 wd_cyl_lo: got 0x7f != 0x01
piixide0:1 drive 0 wd_sector: got 0x7f != 0x01
piixide0:1 drive 0 wd_sector: got 0x7f != 0x02
piixide0:1 drive 0 wd_cyl_lo(2): got 0x7f != 0x01
piixide0:1 drive 1 wd_cyl_lo: got 0x7f != 0x02
piixide0:1 drive 1 wd_cyl_lo: got 0x7f != 0x01
piixide0:1 drive 1 wd_sector: got 0x7f != 0x01
piixide0:1 drive 1 wd_sector: got 0x7f != 0x02
piixide0:1 drive 1 wd_cyl_lo(2): got 0x7f != 0x01
atabusattach: ch_drive_flags 0x0 0x0
piixide1:0: before reset, st0=0x7f, st1=0x7f
piixide1:0 drive 0 wd_cyl_lo: got 0xff != 0x02
piixide1:0 drive 0 wd_cyl_lo: got 0xff != 0x01
piixide1:0 drive 0 wd_sector: got 0xff != 0x01
piixide1:0 drive 0 wd_sector: got 0xff != 0x02
piixide1:0 drive 0 wd_cyl_lo(2): got 0xff != 0x01
piixide1:0 drive 1 wd_cyl_lo: got 0xff != 0x02
piixide1:0 drive 1 wd_cyl_lo: got 0xff != 0x01
piixide1:0 drive 1 wd_sector: got 0xff != 0x01
piixide1:0 drive 1 wd_sector: got 0xff != 0x02
piixide1:0 drive 1 wd_cyl_lo(2): got 0xff != 0x01
atabusattach: ch_drive_flags 0x0 0x0
piixide1:1: before reset, st0=0x7f, st1=0x7f
piixide1:1 drive 0 wd_cyl_lo: got 0xff != 0x02
piixide1:1 drive 0 wd_cyl_lo: got 0xff != 0x01
piixide1:1 drive 0 wd_sector: got 0xff != 0x01
piixide1:1 drive 0 wd_sector: got 0xff != 0x02
piixide1:1 drive 0 wd_cyl_lo(2): got 0xff != 0x01
piixide1:1 drive 1 wd_cyl_lo: got 0xff != 0x02
piixide1:1 drive 1 wd_cyl_lo: got 0xff != 0x01
piixide1:1 drive 1 wd_sector: got 0xff != 0x01
piixide1:1 drive 1 wd_sector: got 0xff != 0x02
piixide1:1 drive 1 wd_cyl_lo(2): got 0xff != 0x01
atabusattach: ch_drive_flags 0x0 0x0
piixide0:0:0: after reset, sc=0x1 sn=0x1 cl=0x0 ch=0x0
piixide0:0:1: after reset, sc=0x0 sn=0x0 cl=0x0 ch=0x0
piixide0:0: wdcwait_reset() end, st0=0x50 st1=0x0
piixide0:0: after reset, ret_value=0x1
piixide0:0:0: after reset, sc=0x1 sn=0x1 cl=0x0 ch=0x0
piixide0:0: wait DRDY st0 0x50 st1 0x0
atabusattach: ch_drive_flags 0x1 0x0
wd0 at atabus0 drive 0: <WDC AC29100D>
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: 32-bit data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 4 (Ultra/66)
wd0(piixide0:0:0): using PIO mode 4, Ultra-DMA mode 4 (Ultra/66) (using DMA data transfers)
On Apr 22,  8:20pm, Manuel Bouyer wrote:
} Subject: Re: Kern/25659 is not isolated to pcmcia attached drives.
} On Thu, Apr 21, 2005 at 03:29:18PM -0700, Brian Buhrow wrote:
} > 	Hello.  Has anyone else noticed that the wdc.c timeouts seem to be
} > short enough that attaching drives to NetBSD-2.x systems can be somewhat
} > challenging?  Kern/25659 correctly identifies the problem as being in the
} > sys/dev/ic/wdc.c file, but it doesn't look like any changes have been made
} > to that file in the source trees which reflect the knowledge of this
} > problem.  If anything, changes over the past year or so have caused most
} > timeouts in this file to shorten considerably.  I've appended what I hope
} > is a less hackish patch to this bug in the gnats database, and hope that
} > someone with more knowledge than I could address the general problem.  The
} > patch I appended makes things work quite well, but I'd be happy to engage
} > in a discussion on this topic if it might result in a permanent fix which
} > will live on in the sources.
} 
} The patch you propose bump various values which are not dependant on the
} CPU speed, and are already much larger than what the specs says they should
} be. Also the delay(1000000) is unacceptable, because it will wedge the
} computer for one second when a drive is attached (which can be from a
} removable adapter, so on a multiuser system), and I can't see why it would
} change anything at the place where it is.
} 
} Did you look at where the exact cause of the problem is ?
} 
} -- 
} Manuel Bouyer <bouyer@antioche.eu.org>
}      NetBSD: 26 ans d'experience feront toujours la difference
} --
>-- End of excerpt from Manuel Bouyer