[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-scsi
Subject:    Re: sd_mod or usb-storage fails to read a single good block (was: ehci_hcd fails to read a single go
From:       Norman Diamond <n0diamond () yahoo ! co ! jp>
Date:       2012-04-30 23:07:21
Message-ID: 909120.88778.qm () web100007 ! mail ! kks ! yahoo ! co ! jp
[Download RAW message or body]

Alan Stern wrote:
> On Mon, 30 Apr 2012, Norman Diamond wrote:
> 
> > Here you are modifying my proposal.  It is no problem to discuss your
> > idea.  At first I thought your idea was better than mine, but on
> > second thought, sorry, here's a problem.  Again it is because the
> > broken and unbroken Prolific bridges are indistinguishable.  A
> > Prolific bridge could be connected to a drive whose actual usable
> > capacity is a multiple of 63, or it could be connected to a modern
> > drive with emulated capacity that is even (in fact a multiple of 8)
> > and not usually a multiple of 63.
> > 
> > Therefore I still favour my version.  If the bridge reports an even
> > number then I want to believe it, if the bridge reports a multiple of
> > 63 then I want to believe it, and if neither then I want to fall back
> > on the existing heuristic which performs a decrement.
> 
> Hmmm.  What about when one of the broken bridges with an older drive
> reports a number which is 1 larger than a multiple of 63 but also
> happens to be even?  In that case your proposed heuristic would fail --
> but then so would the existing heuristic, so we'd be no worse off than
> we are now.

Exactly.  It's not perfect but the improvements far outweigh the downside.

> I still think your proposed heuristic should be handled separately from 
> the existing one, so that it would not be applied in situations where 
> we know the device is not a USB-(S)ATA bridge.

OK.  One quirk for bridges (accept even numbers, accept multiples of 63, and \
otherwise decrement) and one quirk for other kinds of devices (accept even numbers \
and otherwise decrement, i.e. the present heuristic).

> > > As for whether we need TEST_CAPACITY...� That is still highly
> > > debatable.� If we did have it, which quirk entries would use it?� So
> > > far the only candidate we have is your Prolific bridge, and even there
> > > it seems that the divisible-by-63 heuristic would work just as well.
> > 
> > I wish I could get a broken Prolific bridge to test together with
> > mine.  Anyway the divisible-by-63 heuristic would work better than
> > the existing heuristic but it would not work as well as
> > TEST_CAPACITY.  My proposed modified heursitic would usually work
> > better than the existing heuristic but not as well as TEST_CAPACITY.
> 
> How do you know?  You haven't read through ten years' worth of email 
> messages on this subject, have you?  You're going on the basis of your 
> experience with _one_ bridge and a couple of drives.

Because we do know there are a lot of multiples of 63 out there, and because if the \
bridge reports a capacity that is a multiple of 63 (i.e. maximum LBA one less than a \
multiple of 63) and we try reading that last block then it should be read \
successfully.  The only time we have to worry about TEST_CAPACITY is a pretty rare \
case -- and even in such rare cases, we don't know if the bridge will always hang in \
those cases. 

My bridge appeared to hang on reading multiple nonexistent blocks but not on reading \
a single nonexistent block, and at this moment it looks like it might not even be the \
bridge's fault (I have to test it on more drives).

> By the way, have you tried connecting your bridge to a CD/DVD drive?

I have read CDs through it.  I never thought of inquring the capacity.

> > By the way, a while back you asked what happens if I use sg_dd to try
> > reading multiple blocks including the last existing block and some
> > non-existing ones.  The answer seems to depend on the drive as well
> > as the method of connection (USB-to-PATA vs. eSATA plus
> > SATA-to-PATA).  With the drive that I've usually been using I think
> > the drive hangs so we can't really figure out whether to blame the
> > bridge.  With a different drive the drive reports the error but sg_dd
> > and Linux drivers do something to retry so many times that after 30
> > minutes I lost patience waiting for sg_dd to finish and report its
> > error.
> 
> Indeed -- that's exactly the sort of thing which could happen with
> TEST_CAPACITY.  It's one of the reasons I'm cautious about adding
> TEST_CAPACITY and an example of why TEST_CAPACITY might not work as 
> well as you think.

Correction:  Therefore TEST_CAPACITY should not try to read multiple blocks in one \
read.

Your other message says you have a different model of Prolific bridge which has the \
capacity bug but which is (sadly at this moment) distinguishable from mine.  Anyway, \
what happens if you try to read the last block that the bridge asserted to exist?  \
Also for curiosity what happens if you try to read multiple nonexistent blocks, but \
that curiosity is irrelevant to the single block that TEST_CAPACITY would try to \
                read.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[prev in list] [next in list] [prev in thread] [next in thread]