On Fri, Dec 16, 2005 at 08:44:55PM +0100, Manuel Bouyer wrote:
> On Fri, Dec 16, 2005 at 02:29:58PM -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.

Should I put a breakpoint somewhere? I have a netbsd.gdb ,

Pavel