https://bugzilla.kernel.org/show_bug.cgi?id=219652 --- Comment #8 from Kris Karas (bugs-a21@xxxxxxxxxxxxxxxx) --- 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.
