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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20902560364454515...@scdbackup.webframe.org