[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] CD_MSF_FORMAT vs LBA on NetBSD

From: Thomas Schmitt
Subject: Re: [Libcdio-devel] CD_MSF_FORMAT vs LBA on NetBSD
Date: Mon, 29 Oct 2018 15:59:09 +0100


Edd Barrett wrote:
> My branch is:

> To be clear, I've only changed libcdio, and not cdio-paranoia.

Ah yes. This explains much of my confusion.

But most of the messages reported by Greg do not stem from libcdio.
So back to your quote of Greg Troxels error messages:

> > > Log follows, from your branch and libcdio-paranoia master:

I clone

> > 010: Unable to access sector 169348352: skipping...


read_blocks (cdrom_drive_t *d, void *p, lsn_t begin, long i_sectors)
  do {
    err  = cdio_read_audio_sectors( d->p_cdio, buffer, begin, i_sectors);
    if ( DRIVER_OP_SUCCESS != err ) {
      if (i_sectors==1) {
        if (retry_count>MAX_RETRIES-1) {
          char b[256];
          snprintf(b, sizeof(b),
                   "010: Unable to access sector %ld: skipping...\n",
                   (long int) begin);

So this message comes if cdio_read_audio_sectors() does not succeed, if only
one sector is wanted, and the number of retries is exceeded.
Then it reports the desired sector number "begin", which is totally insane
for a CD (700 MiB data capacity means 350,000 sectors).

It might well be that most or all of the messages
> >    SCIOCCOMMAND cmd 0xbe sts 3
stem from the call to cdio_read_audio_sectors(), which calls 
p_cdio->op.read_audio_sectors(), for which libcdio/lib/driver/netbsd.c
exposes read_audio_sectors_netbsd, where the message is emitted).

libcdio-paranoia/lib/cdda_interface/low_interface.h has
  #define MAX_RETRIES 8
So maybe one of the SCIOCCOMMAND messages stems from a different caller.

Now where did the call to libcdio-paranoia's read_blocks() come from ?

Anybody willing and able to get a stack trace when read_blocks()
emits above message "Unable to access sector" ?


I am still looking for a gesture which reads the CD table-of-content and
misinterprets the result, confusing MSF and LBA addressing.

Greg Troxel's report begins by such experiments provoking SCSIOCOMMAND
error messages

Such confusion would explain a sector number of 169 million: has
  union msf_lba {
        struct {
                u_char unused;
                u_char minute;
                u_char second;
                u_char frame;
        } msf;
        uint32_t lba;
        u_char  addr[4];

169348352 = 0x0A180D00 so MINUTE could be 0x0D = 13, SECOND = 24, FRAME= 10.

But you seem to have manipulated only the address format aspects of OpenBSD,
not of NetBSD. This fact does not yet fit into my theory.

Have a nice day :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]