In the routine wdc_atapi_real_start_2, this eventually causes a
timeout, to which the response is a call to wdc_atapi_reset. However
in wdc_atapi_reset, the soft reset will never occur, because on
loading, drvp->state is 0.
One possible solution for this is would be to change the test
if ((drvp->state === 0) && (drvp->n_resets > 0))
so that if no soft resets had ever been done to the drive, at least
one would be allowed through.
Perhaps a better solution might be to eliminate the test altogether
because, if you need to order a reset to be done, it should always
be done. A third possibility (which would eliminate the initial
problem) would be on startup to always do both a device reset followed
by a soft reset to every drive, prior to performing the IDENTIFY (INQUIRY)
At any rate, temporarily, I've picked the first solution, which makes
OpenBSD correctly recognize my drive upon bootup (after the initial
timeout of course). I'm now working on getting it to set the correct
transfer states for the drive (it supports most UDMA modes, but only
PIO mode 3 is getting set for the drive and no UDMA modes).
I would have preferred to contact the driver developer directly about this,
but could find no email address for the person currently working on this
code so I apologize if sending it to the bugs address was the wrong thing