Hi, Mauro Sacchetto wrote: > samiel@darkstar:~$ sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 > --outfile=tdb_data.bin > SCSI Status: Check Condition > > Sense Information: > Fixed format, current; Sense key: Illegal Request > Additional sense: Unaligned write command
Now we know from where that error came, which is inappropriate for optical drives. (Maybe that the kernel created it, and not the drive.) > Is it my test right and enough? The main question is: Is the drive unusable afterwards ? (I.e. do i have identified the culprit for your drive problem ?) > In fact I am a little surprised (although I don't know how these things are > handled by the Debin team) > that so far there has been no intervention by the packagers of Brasero I understand that there is no upstream developer any more and no community which would continue the GUI part and build it with patch proposals. It looks like i was involved in the second youngest thread on the mailing list, back in 2019: https://mail.gnome.org/archives/brasero-list/2019-January/thread.html The youngest thread is a request for help with building Brasero. It got no answer. Possibly i will post a report about the problem there. Just in case some new developer shows up. Said that, and contrary to my statement in the previous mail, i have not yet used up my ideas for experiments: - Will the Pioneer drive go bad if i send the READ CD 0xffffffff command ? It looks like Brasero doesn't do this. - Will READ CD MSF 00:01:74 work better ? Maybe with all three drives without incident and dmesg complaint ? (I have to study the specs, because i never used that command before.) If the Pioneer drive goes bad too, then it might even be a kernel problem with that obviously disliked sector address, and not a problem only with the ASUS drive. This could become obvious if the Additional sense: Unaligned write command from your above experiment changes to my result >>> transport error: Host_status=0x03 [DID_TIME_OUT] if you use kernel 5.10. Have a nice day :) Thomas
