On Fri, Dec 16, 2005 at 08:58:54PM +0100, Pavel Cahyna wrote:
> 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 ,

You can try to set one on sd_interpret_sense, and see at which point
here it returns.

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