[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101224110327.GB8781@htj.dyndns.org>
Date: Fri, 24 Dec 2010 12:03:27 +0100
From: Tejun Heo <htejun@...il.com>
To: James Bottomley <James.Bottomley@...e.de>
Cc: Jens Axboe <axboe@...nel.dk>,
linux-scsi <linux-scsi@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Boot failure with block/for-next
Hello, James.
On Thu, Dec 23, 2010 at 12:25:17PM -0600, James Bottomley wrote:
> On Thu, 2010-12-23 at 17:13 +0100, Tejun Heo wrote:
> > On Thu, Dec 23, 2010 at 10:10:14AM -0600, James Bottomley wrote:
> > > > Can you please apply the debug patch I posted in the other message and
> > > > post the boot log? Let's see how the partition read is failing.
> > >
> > > That's actually a red herring ... the disk isn't spinning up, so the
> > > partition read is getting a not ready.
> >
> > Oh, yay, but at any rate I think the don't-clear-media-presence patch
> > is probably a good idea just in case UA gets reported somehow.
>
> Well, it wasn't this either. It turns out that this disk alone reports
> UNIT_ATTENTION RESET_OCCURRED on the first TEST UNIT READY of spin up.
> Ordinarily this is harmless, but the new medium change code wrongly
> interprets any UNIT_ATTENTION as medium changed (and then refuses to
> talk to the disk). This is actually a change from the previous code, so
> the fix is to put it back the way it was.
I see. I wonder why the previous patch didn't work. It should have
had about the same effect. I think the UA change went in there while
trying to bring sr and sd behaviors closer to each other, but yes it
seems the original code didn't have that. That said, now there are
paths where UA would be consumed without setting ->changed and thus sd
may miss media change events. This has been like this for quite some
time and there aren't many removable sd devices these days, so maybe
this doesn't matter too much.
Anyways, for now, the change looks good to me too. Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists