[Bug 219652] READ CAPACITY(16) not used on large USB-attached drive in recent kernels

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=219652

--- Comment #8 from Kris Karas (bugs-a21@moonlit-rail.com) ---
For Martin in comment #5:

    # : Working kernel sg_readcap
     00     ff ff ff ff 00 00 02 00
    # : Ditto --16
     00     00 00 00 01 5d 50 a3 ae  00 00 02 00 00 00 00 00
     10     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
    # : Failing kernel sg_readcap
     00     ff ff ff fe 00 00 02 00
    # : Ditto --16
     00     00 00 00 01 5d 50 a3 ae  00 00 02 00 00 00 00 00
     10     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

As Michael surmised, the only difference I can see from the above is in the
regular READ_CAPACITY, returning ffffffff normally and fffffffe under the
failing patch.

For Alan in comment #4 and Michael in comment #6:

I spent a couple hours staring at the code (all of it new to me), and the only
thing I could see pre/post patch is that the retry loop was moved one level
down.  Commands passed, buffers, etc., look the same.  Timing/Race?

Command buffer is a bit bigger (16 vs 10).  sshdr.ascq is checked (== 0x00)
pre-patch but not post-patch.  Retry count 13 vs 10.

Can you guys write me a couple sd_printk()'s you would like to see in there?  I
am not familiar with the structure extractors enough to craft a printk with
useful info in it.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.