On Mon, Jan 17, 2011 at 06:12:09PM +0100, Tejun Heo wrote:
> Hello,
>
> On Mon, Jan 17, 2011 at 08:43:40AM -0800, Marc MERLIN wrote:
> > > It could be that the drives need to spin up to answer the smart
> > > command and the timeout on the smart commands is a bit too short for
> > > that to happen. Forcing a disk access before issuing the smart
> > > command could work around the problem.
> >
> > Right, although the idea is of course to keep the drives spun down :)
> > I haven't been able to find which SMART call is causing those errors yet.
> > Does cmd b0/d8:00:00:4f:c2/00:00:00:00:00/00 translate to anything useful?
>
> That's SMART ENABLE OPERATIONS. It turns on SMART.
Haha, ok, not as useful as I thought :)
> > > > That said, is it normal/expected for the PMP code to do a full bus reset
> > > > because of a SMART command that couldn't go through?
> > >
> > > Yeah, after a timeout, the driver doesn't know what state the
> > > controller / PMP / devices are in, so it's kind of forced to do full
> > > reset.
> >
> > Fair enough. I guess it's one of the downsides of PMP.
>
> The device would still be reset even if it's attached directly. The
> only different is that everything under PMP is reset together instead
> of individual ones.
That's absolutely correct. I was kind of trying to avoid unnecessary full
PMP resets: they always make me nervous with software raid on top, but so
far no real disasters have happened :)
Thanks for your answers,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
