https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #26 from Thomas Schmitt <scdbac...@gmx.net> --- Hi, > The error ImgBurn gives me is something like "invalid address for write". > Other users receiving that error were told it's because of the medium > quality, It's probably a miscoordination between burn program and drive. There is SCSI error code 5 21 02 INVALID ADDRESS FOR WRITE Each SCSI WRITE command contains the block address where the write operation shall start and the number of blocks which shall be written with the payload bytes of the SCSI command. If the drive replies "invalid address", then either one of the affected blocks was out of the range of writable blocks on a BD-RE or a BD-R which was formatted to "Pseudo Overwrite" (POW), or the start block address was not the Next Writable address of a BD-R which was not formatted to POW. > 50GB Panasonics So probably double-layer BD-R. Unlike with DVD+R DL, we burn programmers have no influence on the hopping between the layers. That's rather good, as with DVD+R DL we had some problem reports with any of the possible modes of operation. My best guess would be that the passing-through of SCSI commands to the burner is prone to disturbances or hick-ups. > http://paste.debian.net/1008790/ No protests from the drive to see. It took nearly 50 GiB. The only suspicious message is > cdrfifo 0: on read: errno=22 , "Invalid argument" This was when reading the input file into the ring buffer. And it happened before writing began. But it did not prevent writing ... which i cannot reproduce yet. All my tries with simulated errors abort early. My apologies for the medium waste, anyway. errno 22 is not a usual read error. man 2 read mentions O_DIRECT. Maybe the distro configured libburn with non-default --enable-track-src-odirect and your disk has physical blocks larger than 2048. But Debian and therefore probably Mint has in the buildd log of libburn: disabled use of O_DIRECT with track input If it's O_DIRECT, then a run with growisofs might encounter the same problem. If i understand its source right, then it uses O_DIRECT by default if Linux is younger than 2.5. -------------------------------------------------------------------------- What was the exact cdrskin command you used and what do you get from ls -ld $path with $path leading to the image file ? -------------------------------------------------------------------------- What happens if you do (without risking a BD-R medium) cdrskin --allow_emulated_drives -sao -v dev=stdio:/dev/null fs=32m -eject $path Does it report again cdrfifo 0: on read: errno=22 , "Invalid argument" If so, then we need to build cdrskin from source with surely O_DIRECT disabled. -------------------------------------------------------------------------- What does a hex editor say about your burned BD-R ? Does it show any non-zero bytes after maybe some first MBs of zeros ? -------------------------------------------------------------------------- Have a nice day :) Thomas -- You are receiving this mail because: You are watching all bug changes.
