On Fri, Dec 16, 2005 at 02:51:14PM -0500, Michael Lorenz wrote:
> Hello,
> 
> > > > > Looks like I just lucked out and my drives spun up on their
> > > > > own ( see other mail, I could reproduce the panic on macppc ).
> > > > > Anyway, sending a START in this case should be more or less
> > > > > trivial.
> > > > 
> > > > Yes, just insert the appropriate code into the error callback.
> > > 
> > > Ok, there's this in sd.c / sd_interpret_sense():
> > > 
> > > 	/*
> > > 	 * If it isn't a extended or extended/deferred error, let
> > > 	 * the generic code handle it.
> > > 	 */
> > > 	if (SSD_RCODE(sense->response_code) != SSD_RCODE_CURRENT &&
> > > 	    SSD_RCODE(sense->response_code) != SSD_RCODE_DEFERRED)
> > > 		return (retval);
> > > 
> > > 	if (SSD_SENSE_KEY(sense->flags) == SKEY_NOT_READY &&
> > > 	    sense->asc == 0x4) {
> > > 
> > > what follows is code to check if the disk needs to get started and
> > > if so starts it. My uneducated guess is that sd_interpret_sense()
> > > either bails out too early here or isn't called at all.
> > 
> > I just tested on a current kernel with esiop, this code works fine for
> > me:
> > sd0: pack is stopped, restarting...
> > 
> > So we'll have to check why it's not being triggered in Pavel's case.
> 
> Exactly. Is your disk a Seagate, IBM or something else?

It's a: <IBM, DNES-309170W, SAH0>

However it fails with a <SEAGATE, ST32272N, 0784> in the same way
reported by Pavel. Unfortunably I won't be able to debug this in
the next few days.

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