libcdio-devel
[Top][All Lists]
Advanced

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

Re: [Libcdio-devel] OpenBSD vs libcdio vs Audacious


From: Edd Barrett
Subject: Re: [Libcdio-devel] OpenBSD vs libcdio vs Audacious
Date: Sat, 26 Jan 2019 19:24:16 +0000
User-agent: Mutt/1.11.2 (2019-01-07)

On Sat, Jan 26, 2019 at 06:43:58PM +0100, Thomas Schmitt wrote:
> Hi,
>
> > ERROR cdaudio-ng.cc:502 [scan_cd]: Cannot set drive speed.

Yeah we've talked about this one before.

> I would give set_speed_mmc() a try.
> Alternatively one could try to find a set-CD-speed ioctly of NetBSD.

OK, will give that a shot, probably tomorrow now.

> read_audio_sectors_netbsd: SCIOCCOMMAND1 cmd 0xbe sts 0 lsn 0 nblocks 37
> ...
> lib/driver/netbsd.c emits the message only if
>
>         if (req.retsts != SCCMD_OK) {
>
> and then prints req.retsts as "sts %d".
>
> So why does the message get printed at all if req.retsts == 0 ?
> (Edd: Are the "lsn" and "nblocks" fields additions in your branch ?
>  I cannot find such messages in my local clone.)

Yeah, I made modifications to the error strings. This function looks
like this on my local edits:

---8<---
  static int
  read_audio_sectors_netbsd(void *user_data, void *data, lsn_t lsn,
                            unsigned int nblocks)
  {
                  ...

          if (ioctl(_obj->gen.fd, SCIOCCOMMAND, &req) < 0) {
                  fprintf(stderr, "%s: SCIOCCOMMAND1 cmd 0xbe sts %d lsn %lu 
nblocks %u\n", __func__, req.retsts, lsn, nblocks);
                  return 1;
          }
          if (req.retsts != SCCMD_OK) {
                  fprintf(stderr, "%s: SCIOCCOMMAND2 cmd 0xbe sts %d lsn %lu 
nblocks %u\n", __func__, req.retsts, lsn, nblocks);
                  return 1;
          }

          return 0;
  }
--->8---

So to answer your question, it's the ioctl itself failing.

Notice SCIOCCOMMAND1 vs SCIOCCOMMAND2 -- I made that quick change so I could
see which bit fails.

sts is probably 0 since it hasn't been updated.

> > Fetching the first sector of a track always makes an SCSI error.
>
> If this is a real error (despite "sts 0") then it would be interesting
> to learn the Sense bytes and especially KEY, ASC, ASQ of the error.

I guess this is irrelevant now that we know that it's the ioctl failing.

FWIW, that first error was a perror(). I was wrong to change it. Reverting it,
it prints:

        SCIOCCOMMAND: Invalid argument

So there's something wrong with the request, I suppose.

I'm out of time today, but tomorrow I can investigate the inputs. If there's
anything you'd specifically like to see the value of, let me know.

--
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk



reply via email to

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