Re: sd_mod or usb-storage fails to read a single good block (was: ehci_hcd fails to read a single good block)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 28 Apr 2012, Norman Diamond wrote:

> That is not a fix for what really is my immediate problem, which is
> that my users can have any kind of bridge and any kind of disk, and
> in an emergency I can tell them to add a kernel boot parameter, or
> see if they can use a different bridge, etc., but it's really better
> if we can avoid such emergencies.

I have told you several times during this conversation: What you're 
asking for is not completely feasible.  But maybe we can do better than 
we are doing now.

> A preference for taking the device's word (in cases where we don't
> have a more reliable heuristic) is different from always taking the
> device's word (in all cases even when we have a more reliable
> heuristic).  CAPACITY_HEURISTICS will remain meaningful and will
> become more meaningful.

How could you tell whether the heuristic is more reliable than the
device?  The idea behind CAPACITY_HEURSTICS is that someone has already
considered the problem, and decided that the heuristic is more
reliable.  Otherwise the quirk entry would simply have no
capacity-related flag at all.

> > For example, consider all those cameras sold by Nikon, Pentax, and so
> > on.� They probably all used Symbian's firmware, which some years ago� 
> > had the capacity bug.� Maybe the firmware has been fixed since then; I
> > don't know.� But under the reasonable assumption that the
> > SD/CF/whatever memories used in these cameras will always have an even 
> > number of blocks, the existing CAPACITY_HEURISTICS solution is 
> > appropriate.
> 
> If you think that a revised CAPACITY_HEURISTICS incorporating my
> suggestion will become less appropriate than the existing
> CAPACITY_HEURISTICS then we need two separate heuristics, one for
> Symbian and similar, one for Prolific and similar.  And we even more
> surely do need TEST_CAPACITY.

The impression I get is that you want two different heuristics: one
that aims for an even number of blocks, and one that aims for a number
divisible by 63.  All devices known to be USB-(S)ATA bridges could use 
the second heuristic.  Maybe that's what you meant.

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.

> > You know that for decades, ATA disks have reported capacities that were
> > multiples of 63.� So if a drive reports a capacity that is 5 larger
> > than a multiple of 63, why would you want to decrement the value?
> 
> Where a report is 5 larger than a multiple of 63, I left the existing
> heuristic intact.  I suggested only modifying the heuristic to avoid
> decrementing from exact multiples of 63.

Okay, now I understand.  This still has the problem that it is likely
to be wrong for flash drives, again suggesting that a separate
heuristic is appropriate.

> > Also, the amount of effort required to write the TEST_CAPACITY code and 
> > get it accepted into the kernel would be non-trivial.� I prefer not to 
> > do it unless it turns out to be clearly necessary.
> 
> I think it is clearly necessary.  In the meantime a revised heuristic
> will help a lot.
> 
> By the way, I will not be the primary beneficiary of these revisions.  
> The primary beneficiaries will be owners of bridges and devices that
> you and I have learned to dislike, but we have to live with them.

I have no objection to that, provided it doesn't cause increased
problems for other people.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux