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 Fri, 27 Apr 2012, Norman Diamond wrote:

> > Let's just not worry about it.� It seems pretty clear that the patches 
> > will fix your immediate problem.
> 
> Only partly, because an odd multiple of 63 is possible.

Look, I didn't say the changes would help with every possible disk.  
Just that they would fix your immediate problem, i.e., the problem with
your current disk.

> > What about a device that has 6362 sectors but reports 6363?� Then your 
> > test would fail to decrement the value when we do want to.
> 
> But we can't distinguish two versions of the device, one where 6363
> is correct and one where 6363 is wrong.  I prefer to take the
> device's word for it unless we know for sure that it is wrong.  
> TEST_CAPACITY would still be a good idea.  FIX_CAPACITY (where we
> know for sure that the device is wrong) will not suffer from this
> ambiguity and will always get a decrement.

That's the whole point of CAPACITY_HEURISTICS -- we have two versions 
of the device, of which one is buggy and the other isn't, and we can't 
tell them apart.  If we preferred to take the device's word for it 
whenever we didn't know for sure, there would be no need for 
CAPACITY_HEURISTICS 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.

> > Anyway, why do you want to test for n % 63 != 0?� You have no
> > justification for decrementing the block count if the result would
> > not be divisible by 63.
> 
> I sure do.  You know as well as I do that for decades a lot of ATA
> disks reported capacities that were multiples of 63 and they had a
> reason for it.

?  That makes no sense.  Go back and reread what I wrote.  In 
particular, I was asking why you changed the test from (n % 63 == 1) to 
(n % 63 != 0).

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?  The
result still would not be a multiple of 63.  Didn't you say that you 
preferred to take the device's word for it?

> > Bear in mind that if anybody reports a problem caused by the new
> > "divisible by 63" criterion, we will have to revert the changed test
> > (the updated message could remain, since it doesn't affect
> > functionality).
> 
> Mostly I agree.  But if reversion causes a different known problem to
> be reinstated, then TEST_CAPACITY is really needed.

The same caveat applies to TEST_CAPACITY.

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.

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