Daniel Drake wrote: > Tejun Heo wrote: >>> <4>ata2.00: HSM violation: eh_analyze_tf: BUSY|DRQ >>> <3>ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen >>> <3>ata2.00: cmd a0/00:00:00:0a:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data >>> 10 in >>> <4> res 58/00:02:00:0a:00/00:00:00:00:00/a0 Emask 0x2 (HSM >>> violation) >>> <3>ata2.00: status: { DRDY DRQ } >>> <6>ata2: soft resetting link >>> <6>ata2.00: configured for UDMA/33 >>> <6>ata2: EH complete >> >> Does this patch fix the problem? > > That fixes it, thanks! There is no more ugly error in dmesg, the test > prog doesn't print any sense data, and brasero works OK too. However, > these messages appear in the kernel log every time I run the test app > (or when brasero does its thing): > > <4>ata2.00: 10 bytes trailing data > <4>ata2.00: 10 bytes trailing data > <4>ata2.00: 10 bytes trailing data > <4>ata2.00: 10 bytes trailing data > <4>ata2.00: 10 bytes trailing data > <4>ata2.00: 10 bytes trailing data > <4>ata2.00: 6 bytes trailing data Yeah, that's expected. What's going on here is that your drive sends full mode sense data (76bytes) regardless of allocation size in CDB but it does honor transfer chunk set in the PACKET TF, which is set to the same value as allocation size by Alan's patch. So, now the drive sends the 76 bytes in 8 chunks. The first chunk is transferred into the sg buffer and the following chunks are thrown away. Previously, transfer chunk was set to 8k, so the drive claims to transfer 76 bytes from the buegging, libata transfers leading 10 bytes got transferred into the user buffer and throws away what's remaining. The change caused problem because libata HSM always switches to HSM_ST_LAST (command sequence completion) after filling the command buffer completely. So, throwing away is activated iff the extra data to throw away is transfered together with the last chunk of useful data. With the chunk size reduced to allocation size, the initial chunk fills the data buffer completely and all the extra bytes are transfered in separate chunks. However, libata HSM expects command sequence to complete after the initial chunk but the drive asserts DRQ for the next chunk on the following interrupt, so HSM violation is triggered. The patch modifies HSM such that it keeps throwing away extra data as long as the drive asserts DRQ which is how IDE driver does it. However, there's still remaining issues. What does happen if you raise allocation length and buffersize of the test program to 16? ie. Change 0x0a in cmd[] to 0x10 and increase buffer[10] to buffer[16]. Thanks. -- tejun - 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