On 11/05/2011 03:37 PM, Thomas Schmitt wrote:
MMC-3 5.2 and MMC-5 6.2.3 state about processing of command BLANK with
Immed bit set to one:
"In response to the REQUEST SENSE command, unless an error has occurred,
the Drive shall return a SK/ASC/ASCQ values set to
NOT READY/LOGICAL UNIT NOT READY/OPERATION IN PROGRESS,
with the sense key specific bytes set for progress indication."
But libburn gets on qemu
TEST UNIT READY
00 00 00 00 00 00
+++ sense data = 71 00 02 00 00 00 00 0A 00 00 00 00 04 08 00 80 24 8B
+++ key=2 asc=04h ascq=08h ( 0 ms)
REQUEST SENSE
03 00 00 00 12 00
From drive: 18b
f0 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 00
0 ms
It is ok that TEST UNIT READY reports the sense data with
2 04 08 LOGICAL UNIT NOT READY, LONG WRITE IN PROGRESS
But it is not ok that REQUEST SENSE does not do the same.
On qemu it reports:
0 00 00 NO ADDITIONAL SENSE INFORMATION
This is because QEMU always emulates REQUEST SENSE and always returns
the sense data from the last request. Is this git master or 0.15? For
git master, I would have expected REQUEST SENSE to return the correct
sense data, but without updating it.
In general, it seems safer (and simpler?) if libburn uses TEST UNIT
READY and its autosense data to report progress. REQUEST SENSE would be
used if SG_IO reports CHECK CONDITION without SG_ERR_DRIVER_SENSE (but
modern OSes will always emulate autosense even if the HBA does not
support it) and possibly if TEST UNIT READY returns GOOD which is
allowed by deprecated in MMC.
Paolo