On 2004-05-23 itohy@NetBSD.org wrote:
> martin@duskware.de writes:
> > On Sun, May 23, 2004 at 08:10:00AM +0900, ITOH Yasufumi wrote:
> >
> > > I think the problem is that the pcmcia/cardbus driver turns
> > > on and off the device too frequently during probe/attach (kern/8731).
> >
> > It's been a while, but last I looked there was one power up-probe-power-down
> > phase, optionally followed by another power-up-on-mount. I don't see how you
> > could optimize that.
>
> I have 1.6ZL (May 27, 2004) kernel, and I see at least two power on/off
> cycles while probe and attach.
>
> 	power ON
> 	read CIS
> 	power OFF
> 	power ON
> 	attach wdc
> 	power OFF

  At least at one point there was an additional power cycle for ffs
partitions between reading the disklabel and mounting the drive (but not
for msdos partitions, causing a PCMCIA hard drive I had to work only if a
dos partition on the drive was mounted first).

  Speaking of which, I have been meaning to check: does NetBSD issue one
of the following commands before removing power: soft reset, standby,
standby immediate, sleep?  PCMCIA hard drives will perform a head unload
for each of these commands.  If unload is not performed when power is cut,
then the drive will survive many fewer unloads than it otherwise would
(for a Toshiba PCMCIA drive, they say 20,000 vs. 300,000 normally.  Mine
died much sooner than that, possibly not related).  I wonder if issuing
standby or sleep (if this isn't done already) would induce the drive to
wait until its cache is flushed before completing the command.

> > > I think we can fix both problems by delaying power down for a while
> > > (say 5s) after power-down requests.
> >
> > There is a final flush command to the drive before power is turned off,
> > so this should not be needed - IIUC.
>
> The power-off delay is one method to avoid excessive power on-off cycles,
> which might help for data integrity but is not required of course.

  The problem is that this would delay all final unmounts by the delay
time (if it doesn't you could accedently pull a drive with power on, which
would likely be much worse than the power cycles).  A 1s delay might not
be too bad.  The system should be able to tell in cases that matter if it
is going to do something else with it soon and be able to arrange to keep
the power on as long as will be needed in the near future.  I think that
would be better than a power-off delay.

Matthew Orgass
darkstar@city-net.com