Hi, Jeroen Diederen wrote: > kernel: [timestamp] sr 1:0:0:0: [sr0] tag#0 Sense Key : Illegal Request > kernel: [timestamp] sr 1:0:0:0: [sr0] tag#0 Add. Sense: Illegal mode for > this track > ... > kernel: [timestamp] attempt to access beyond end device > kernel: [timestamp] sr0: rw=0, want 640412, limit 640408
This could be the TAO CD readahead bug with a drive which cooperates badly with an obscure remedy in the kernel. Preconditions for the bug are: - CD-R or CD-RW medium, not DVD, not BD. - Write type was Track-At-Once (which is default with cdrecord and wodim). The remedy, which only works beginning with the next read attempt, can be seen in https://github.com/torvalds/linux/blob/master/drivers/scsi/sr.c under the false statement * The SCSI specification allows for the value * returned by READ CAPACITY to be up to 75 2K * sectors past the last readable block. If it works well, then it reduces the registered size of the medium (ioctl(BLKGETSIZE), lsblk -o SIZE) by 4 KiB. It is know to work better if the number of 2K blocks of the readable range is divisible by 2. In our case we have 160103 2K blocks and it looks like overcorrection: debian-10.0.0-powerpc-NETINST-1.iso of yesterday (2020110715225600) has 327890944 bytes i.e. 640412 blocks of 512 bytes. So above "want" is already beyond the end of the ISO but "limit" is inside. "want" would match the initial perception mistake of the kernel, which would be with the TAO bug 640416 or 640420 blocks, and an overshooting correction to 640408 blocks. The read access to the very end usually happens when software lookings for a GPT backup block or for an UDF anchor block. There are various rumors around this bug, but mine is provable and backed by more optical drives than the others' together. >:] Normally it gets circumvented by a adding 300 KiB of padding at the end of the CD track. If my theory is right, then no padding was added to this CD. How exactly did you burn the it ? If the burn software offers write type Session-At-Once (SAO) then burn again using this option. E.g. xorriso with explicit SAO (it uses it by default if possible) and padding: xorriso -as cdrecord \ -v dev=/dev/sr0 blank=as_needed -eject padsize=300k \ -sao debian-10.0.0-powerpc-NETINST-1.iso The padding might lead to success even if my theory is wrong, because if the drive would systematically underestimate SAO CDs, then the padding would sacrifice itself to the mistake like a zinc anode does to salt water. So in case of success, it would be interesting to see whether a CD burnt without option padsize=300k is mountable too, and whether a CD burnt by TAO without padding fails: xorriso -as cdrecord \ -v dev=/dev/sr0 blank=as_needed -eject \ -tao debian-10.0.0-powerpc-NETINST-1.iso ------------------------------------------------------------------------- If this all turns out to be really the old readahed bug, does anybody here have enough reputation in linux-scsi to get a fix committed, which i have ready as set of [PATCH 0/3] Fix the old CD read-ahead bug for media with a single TAO track [PATCH 1/3] cdrom: export cdrom_mmc3_profile() [PATCH 2/3] sr: provide a test for readability of sectors as data blocks [PATCH 3/3] sr: detect CD TAO Run-out blocks and correct device capacity if needed Currently based on 5.9-rc2. Works fine with various drives. Lengthy cover letter and commit messages. Like this mail. Sorry for that. Have a nice day :) Thomas
