YUP wrote: > Hi Sergei, Albert and Bartek, > > Thanks for the patch. If you dealt with it, could you please apply this > patch to 2.6.20.3 kernel and send me diff? I'm just afraid that I > couldn't do it right. > > Albert and Bartek, > > please find latest dmsg output with Albert's patch. I quoted here only > output after the first "qc timeout" as Albert requested (see below). > Hope it will help you. > Thanks for the help. Your trace is valuable. It seems we have identified the cause. The AOpen drive returned 0x51 (check condition) on INQUIRY of 254 bytes, and it seems to mess up when REQUEST SENSE was issued: [ 105.480046] CDB (4:0,1,0) 12 01 00 00 fe 00 00 00 00 [ 105.480101] ata4: protocol 5 task_state 4 (dev_stat 0x58) <== INQUIRY [ 105.480551] ata4: protocol 5 task_state 1 [ 105.480555] ata4: host_stat 0x4 [ 105.480561] ata4: protocol 5 task_state 1 (dev_stat 0x51) [ 105.480564] ata4: protocol 5 task_state 2 (dev_stat 0x51) [ 105.480567] ata4: protocol 5 task_state 3 (dev_stat 0x51) <= check condition [ 105.480644] ata4: protocol 5 task_state 4 (dev_stat 0x58) <== REQUEST SENSE [ 113.509692] ata4: protocol 5 task_state 1 <== interrupt. device BSY. [ 113.509703] ata4: host_stat 0x0 <== device messed up [ 113.510276] ata4: protocol 5 task_state 1 [ 113.510280] ata4: host_stat 0x0 [ 113.510890] ata4: protocol 5 task_state 1 [ 113.510894] ata4: host_stat 0x0 [ 113.512120] ata4: protocol 5 task_state 1 <== .. loop until time out This INQUIRY problem can be reliable reproduced: [ 171.258863] CDB (4:0,1,0) 12 01 00 00 fe 00 00 00 00 [ 171.258918] ata4: protocol 5 task_state 4 (dev_stat 0x58) <== INQUIRY [ 171.259359] ata4: protocol 5 task_state 1 [ 171.259363] ata4: host_stat 0x4 [ 171.259368] ata4: protocol 5 task_state 1 (dev_stat 0x51) [ 171.259371] ata4: protocol 5 task_state 2 (dev_stat 0x51) [ 171.259374] ata4: protocol 5 task_state 3 (dev_stat 0x51)<= check condition [ 171.259451] ata4: protocol 5 task_state 4 (dev_stat 0x58) <== REQUEST SENSE [ 172.538040] ata4: protocol 5 task_state 1 <== interrupt. device BSY. [ 172.538051] ata4: host_stat 0x0 <== device messed up [ 172.538145] ata4: protocol 5 task_state 1 [ 172.538150] ata4: host_stat 0x0 [ 173.424869] ata4: protocol 5 task_state 1 <== .. loop until time out Except INQUIRY, other commands/REQUEST SENSE are ok. (ex. TEST UNIT READY) [ 105.456944] CDB (4:0,1,0) 00 00 00 00 00 00 00 00 00 [ 105.457003] ata4: protocol 6 task_state 4 (dev_stat 0x58) <= TEST UNIT READY [ 105.457551] ata4: protocol 6 task_state 2 [ 105.457555] ata4: host_stat 0x4 [ 105.457561] ata4: protocol 6 task_state 2 (dev_stat 0x51) [ 105.457563] ata4: protocol 6 task_state 3 (dev_stat 0x51)<= check condition [ 105.457647] ata4: protocol 5 task_state 4 (dev_stat 0x58) <== REQUEST SENSE [ 105.458233] ata4: protocol 5 task_state 1 <== interrupt. device ok. [ 105.458237] ata4: host_stat 0x4 [ 105.458242] ata4: protocol 5 task_state 1 (dev_stat 0x58) [ 105.458350] ata4: protocol 5 task_state 1 [ 105.458353] ata4: host_stat 0x4 <== device returns sense data ok. [ 105.458358] ata4: protocol 5 task_state 1 (dev_stat 0x50) [ 105.458361] ata4: protocol 5 task_state 2 (dev_stat 0x50) Hi Yarema, Could you help to send me the dmesg before the first qc timeout (i.e. before [ 69.646046] ata4.01: qc timeout (cmd 0xa0)). We can see how the AOpen drive deal with the first INQUIRY (e.g. 36 bytes). Thanks. -- albert - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
