Re: Differences between cdw/k3b on Jessie and Stretch (testing)?
Hi,
Eike Lantzsch wrote:
> Now we know that the problem is indeed with DAO.
> ...
> Hardware and medium [Maxell] seem to be healthy as it works OK with Jessie
> in Virtualbox on the same machine.
I see two riddles here which might also be hints:
1: How can DAO from the VM succeed on the real drive which is
actually supposed to be operated by the kernel of the real
machine ?
2: How can the (real or virtual) system distinguish between
a DAO and an Incremental run and only spoil DAO ?
It is totally a burner thing. An aspect which Linux
traditionally ignores.
About number 1:
Can you verify by btrace(8) on the real machine that it
passes SCSI commands to the drive when the virtual machine
performs e.g. dvd+rw-mediainfo on the virtual drive ?
Superuser on real machine:
btrace /dev/sr0 > /tmp/btrace_log_sr0
Maybe only then start the VM that uses this drive and
let it perform some SCSI commands:
dvd+rw-mediainfo /dev/sr0
Afterwards end btrace and have a look into /tmp/btrace_log_sr0
If there is traffic, then i'd be interested to see it.
(If large, then by private mail or public web exposure.)
> Libgcc1 changed from 4.9.2-10 to 5.1.1-14
> Libstdc++6 changed from 4.9.2-10 to 5.1.1-14
It is very very unlikely that these have any share in the
difference between DAO and Incremental.
>From the view of compiler or libc they make no difference.
Just some other byte strings get composed and sent via
ioctl(SG_IO) at some other stages of the burn run.
(For an overview of how to control both write types see my
cheat sheet:
http://libburnia-project.org/browser/libburn/trunk/doc/cookbook.txt#L1026
http://libburnia-project.org/browser/libburn/trunk/doc/cookbook.txt#L1103
)
Hard to envision how the compiler should spoil the results
of two independent pieces of source code which just happen
to implement the same communications protocol.
growisofs wrote:
> :-[ FLUSH CACHE failed with SK=0h/ASC=00h/ACQ=03h]: Input/output error
Not an official SCSI error code.
"FLUSH CACHE" actually means command 0x35 SYNCHRONIZE CACHE.
Possibly fabricated by the kernel or mistaken by growisofs.
There are two formats of error reply. The one that is issued
by optical drives is hardcoded in dvd+rw-tools-7.1/transport.hxx.
The other sometimes comes from controller hardware or kernels.
If it was the other format, then we know only the four
lowest bits of ASC to be 0. (That's what the expected format
has as SK.)
My grand unified error list has these candidates:
0 00 00 NO ADDITIONAL SENSE INFORMATION
2 30 01 CANNOT READ MEDIUM UNKNOWN FORMAT
2 30 02 CANNOT READ MEDIUM INCOMPATIBLE FORMAT
2 30 03 CLEANING CARTRIDGE INSTALLED
2 30 04 CANNOT WRITE MEDIUM UNKNOWN FORMAT
2 30 05 CANNOT WRITE MEDIUM INCOMPATIBLE FORMAT
2 30 06 CANNOT FORMAT MEDIUM INCOMPATIBLE MEDIUM
2 30 07 CLEANING FAILURE
2 30 11 CANNOT WRITE MEDIUM UNSUPPORTED MEDIUM VERSION
4 00 17 CLEANING REQUESTED
4 40 NN DIAGNOSTIC FAILURE ON COMPONENT NN (80H-FFH)
5 00 16 OPERATION IN PROGRESS
5 20 00 INVALID COMMAND OPERATION CODE
5 30 01 CANNOT READ MEDIUM UNKNOWN FORMAT
5 30 02 CANNOT READ MEDIUM INCOMPATIBLE FORMAT
5 30 03 CLEANING CARTRIDGE INSTALLED
5 30 04 CANNOT WRITE MEDIUM UNKNOWN FORMAT
5 30 05 CANNOT WRITE MEDIUM INCOMPATIBLE FORMAT
5 30 06 CANNOT FORMAT MEDIUM INCOMPATIBLE MEDIUM
5 30 07 CLEANING FAILURE
5 30 08 CANNOT WRITE APPLICATION CODE MISMATCH
5 30 09 CURRENT SESSION NOT FIXATED FOR APPEND
5 30 10 MEDIUM NOT FORMATTED
5 30 11 CANNOT WRITE MEDIUM UNSUPPORTED MEDIUM VERSION
B 00 06 I/O PROCESS TERMINATED
The error key SK=B is known to be issued by kernel and/or bus
hardware.
Do you see some error messages in the kernel logs about "sr"
which have matching timestamps ?
xorriso wrote:
> Writing to '/dev/sr0' completed successfully.
> ...
> Media summary: 1 session, 641871 data blocks, 1254m data, 0 free
The drive believes to have done it right. It reports a
readable logical track when inquired by SCSI commands.
I guess this belief ends when the medium is ejected and
reloaded.
Try after reload by
xorriso -outdev /dev/sr0 -toc
xorriso did not receive an error code when flushing the
drive buffer.
If each burn run failed at SYNCHRONIZE CACHE, then
i would say the kernel or bus is impatient with the
possibly long running command.
But in this case libburn would have experienced a silent
failure up to a matching illusion of the drive.
I would prefer if all DAO did fail and simply point to
a drive that reached the end of its work life, or an
impatient kernel on the real OS.
Have a nice day :)
Thomas
Reply to: