Re: [Bug #12263] Sata soft reset filling log

[Sergei Shtylyov]

Hello, I wrote:

> > > > > > > This message has been generated automatically as a part of a report
> > > > > > > of regressions introduced between 2.6.27 and 2.6.28.

> > > > > > > The following bug entry is on the current list of known regressions
> > > > > > > introduced between 2.6.27 and 2.6.28.  Please verify if it still 
> > > > > > > should
> > > > > > > be listed and let me know (either way).

> > > > > > > Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=12263
> > > > > > > Subject        : Sata soft reset filling log
> > > > > > > Submitter    : Justin Madru <bevicm@xxxxxxxxxxxxxx>
> > > > > > > Date        : 2008-12-13 2:07 (64 days old)
> > > > > > > References    : 
> > > > > > > http://marc.info/?l=linux-kernel&m=122913412608533&w=4

> > > > > > I'm still seeing this on .29-rc5, and I think that my bug #12263 
> > > > > > is a duplicate of bug #12609,
> > > > > > or more correctly it's a duplicate of mine because I reported first.

> > > > > > It seems like the bug has been fixed in tip/master for some time now.
> > > > > > Below is the diff of origin and tip from when I tested.

> > > > > Ingo, do you know whinch patch in -tip fixes this regression?

> > > > This one, done on Jan 10, more than a month ago:

> > > >  f1d26da: Revert "libata: Add 32bit PIO support"

> > > > When a commit causes trouble in -tip qa i immediately revert it in 
> > > > 95% of the cases, no questions asked. Especially if it's related to 
> > > > persistent storage.

> > > OK, thanks.

> > > We seem to have a working fix patch for this issue in bug #12609.

> >    Wait, if this is indeed post-2.6.27 regression, it couldn't 
> > possibly have been caused by that patch which got merged during 
> > 2.6.29-rc1 timeframe. Something's up with this bug...

>    Also, it's been reported for a hard disk while regression in bug 
> 12609 only hits the ATAPI devices.  I think that bug 12263 needs to be reopened.

   After referring to the SCSI command codes "cdb 0x1e" means ALLOW MEDIUM 
REMOVAL command -- which could hardly be addressed to an usual hard disk. So, 
it looks like we had a case of the confused bug report which has a lot of info 
on the hard disk while errors were most probably happening with a CD/DVD 
drive. :-)

MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/