Hi,
i'm not subscribed, please Cc: me with replies.
John Paul Adrian Glaubitz wrote:
Also, let's pull Thomas Schmitt from libburnia upstream who might know more.
I don't think that it is a problem with the structure of the ISO image.
The error happens early, when the superblock shall be loaded. Its position
and size is the same for xorriso and genisoimage.
More probable is a non-standard block size of the CDROM device. The
messages look like 1024 bytes per block.
But i fail to spot how this size triggers the "unaligned transfer" error.
All modern CD drives show block size 2048 for data CDs (with other sector formats it may be up to 2352).
Are there hardware switches at the CDROM devices to set block size ?
@Ulrich Teichert:
Can the drives be tested with a running Linux system by
lsblk -o LOG-SEC,PHY-SEC /dev/sr0
If so: What sizes get reported ?
What kind of drives ? (Parallel external SCSI ? With screws at the plugs ?)
Do you see more info about the drive after
Oct 11 20:11:49 kernel: [ 28.706039] sr 0:0:4:0: Attached scsi CD-ROM sr0
@John Paul Adrian Glaubitz:
Where can i see the code with the xorriso run which produced the ISO ?
-------------------------------------------------------------------------- Insight so far:
Oct 11 20:15:32 kernel: [ 260.904163] sr 0:0:4:0: [sr0] tag#33 unaligned transfer
Assumed that it comes from sr.c, i find the complaint "unaligned transfer"
only once, in
https://github.com/torvalds/linux/blob/master/drivers/scsi/sr.c
line 462 ff:
/*
* request doesn't start on hw block boundary, add scatter pads
*/
if (((unsigned int)blk_rq_pos(rq) % (s_size >> 9)) ||
(scsi_bufflen(SCpnt) % s_size)) {
scmd_printk(KERN_NOTICE, SCpnt, "unaligned transfer\n");
goto out;
}
The disappointed customer of the read operation tells:
Oct 11 20:15:32 kernel: [ 260.905139] isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=32
"iso_blknum=16" matches the normal attempt to read the Primary Volume Descriptor. But "block=32" looks suspicious. (I'd expect 64.)
https://github.com/torvalds/linux/blob/master/fs/isofs/inode.c
line 1002 ff.:
out_no_read:
printk(KERN_WARNING "%s: bread failed, dev=%s, iso_blknum=%d, block=%d\n",
__func__, s->s_id, iso_blknum, block);
The only bread() in that function is in line 673:
block = iso_blknum << (ISOFS_BLOCK_BITS - s->s_blocksize_bits);
if (!(bh = sb_bread(s, block)))
goto out_no_read;
ISOFS_BLOCK_BITS is 11. So to get to block=32 from iso_blknum=16 the
value of s->s_blocksize_bits has to be 10. I.e. 1024 bytes per block.
I understand that this is the device block size as recorded in the
super_block structure.
Why this triggers the error in line 465 ff. riddles me.
The code in sr.c is prepared for 1024 bytes per block.
https://github.com/torvalds/linux/blob/master/drivers/scsi/sr.c
line 425:
s_size = cd->device->sector_size;
if (s_size != 512 && s_size != 1024 && s_size != 2048) {
scmd_printk(KERN_ERR, SCpnt, "bad sector size %d\n", s_size);
goto out;
}
If i assume s_size=1024 then the test in line 465 becomes
if (((unsigned int)blk_rq_pos(rq) % 2)) ||
(scsi_bufflen(SCpnt) % 1024)) {
which with blk_rq_pos(rq)=32 and a normally sized transaction buffer
should be false.
Nevertheless we see the message indicationg that the outcome is true.
One would have to print the values of
blk_rq_pos(rq)
s_size
scsi_bufflen(SCpnt)
to find out which of my assumptions is wrong.
(Best guess is that scsi_bufflen(SCpnt) became 512 for some reason.)
Have a nice day :)
Thomas
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)