In message <20040517211036.8B1277B44@berkshire.research.att.com>, "Steven M. Be
llovin" writes:
>In message <20040517210116.GA6013@antioche.eu.org>, Manuel Bouyer writes:
>>On Mon, May 17, 2004 at 11:24:55AM -0400, Steve Bellovin wrote:
>>> [...]
>>> I can remove and reinsert the card:
>>> 
>>> atabus2 detached
>>> wdc2 detached
>>> wdc2 at pcmcia0 function 0
>>> atabus2 at wdc2 channel 0
>>
>>Can you try a recent current kernel ?
>>I debugged a similar problem with a PCMCIA cdrom last week-end ...
>>
>>If this doesn't help, you can try breaking into ddb before inserting
>>the adapter and typing
>>write wdcdebug_mask 0x10
>>c
>>
>>Then the kernel should print message, which hopefully will help finding
>>why the kernel thinks there's no drive here.
>>
>
>Per my followup posting, the kernel is saying
>
>wdc2:0: before reset, st0=0x80, st1=0x80
>atabusattach: ch_drive_flags 0x0 0x0
>
>This is with a kernel from yesterday's 2.0-branch source.  If it will 
>help, I can build a -current kernel for that machine, but that will 
>take until tomorrow, given how slow my -current machine is.
>

I built two different test kernels.  The first is from yesterday's 
-current source:

atabus2 at wdc2 channel 0
wdc2:0: before reset, st0=0x80, st1=0x80
wdc2:0 drive 0 wd_cyl_lo: got 0x80 != 0x02
wdc2:0 drive 0 wd_cyl_lo: got 0x80 != 0x01
wdc2:0 drive 0 wd_sector: got 0x80 != 0x01
wdc2:0 drive 0 wd_sector: got 0x80 != 0x02
wdc2:0 drive 0 wd_cyl_lo(2): got 0x80 != 0x01
wdc2:0 drive 1 wd_cyl_lo: got 0x80 != 0x02
wdc2:0 drive 1 wd_cyl_lo: got 0x80 != 0x01
wdc2:0 drive 1 wd_sector: got 0x80 != 0x01
wdc2:0 drive 1 wd_sector: got 0x80 != 0x02
wdc2:0 drive 1 wd_cyl_lo(2): got 0x80 != 0x01
atabusattach: ch_drive_flags 0x0 0x0

If I interpret this correctly, it's saying that the BSY bit is staying 
on, which is what Charles Hannum suggested was the problem.  I built
a test 2.0 kernel with a delay/retry loop in the initialization; that
got a bit further than the stock kernel, but still no joy:

wdc2 at pcmcia1 function 0
atabus2 at wdc2 channel 0
wdc2:0: before reset, st0=0x80 (10), st1=0x0 (0)
wdc2:0:0: after reset, sc=0x1 sn=0x1 cl=0x0 ch=0x0
wdc2:0:1: after reset, sc=0x1 sn=0x1 cl=0x0 ch=0x0
wdc2:0: wdcwait_reset() end, st0=0x50 st1=0x0
wdc2:0: after reset, ret_value=0x2
wdc2:0:1: after reset, sc=0x1 sn=0x1 cl=0x0 ch=0x0
wdc2:0: wait DRDY st0 0x50 st1 0x0
atabusattach: ch_drive_flags 0x0 0x0

The parenthesized number in the "before reset" message is the counter
value when exiting the retry loop.  I speculate that the delays from
retrying the first channel ten times (with a delay(100000) call in
the loop) were enough to let things stabilize for the second channel.