[this error happens only when using the SG interface; modern kernels
offer a newer SG_IO interface which is preferred by cdparanoia]
This error means exactly what it says; the generic SCSI devices are
missing, unusable or have permissions set to deny access by users.
First, a bit of explanation...
When using the old 'sg' (scsi generic) interface, cdparanoia doesn't
actually use the 'normal' SCSI cdrom device, typically /dev/scd* or
/dev/sr*; it uses (and requires) a generic SCSI device (typically
/dev/sg*) to access a drive's audio extraction features. Cdparanoia
does accept the CDROM device name because users are used to this
device specifying a cdrom drive, but only uses the CDROM device name
to map to a matching generic SCSI device.
If cdparanoia can't get to a working set of generic devices, it can't
use a SCSI drive with the sg interface. Before sending mail, check that:
- The kernel has generic SCSI support compiled in (or the generic
module available). Generic SCSI support does *not* mean only SCSI or
SCSI CDROM.
- Those using ATAPI CDROM drives with IDE-SCSI emulation must *not*
have ATAPI CDROM support included. ATAPI IDE-SCSI emulation users
must have all the appropriate SCSI support selected.
- The generic SCSI devices (/dev/sg*) must exist and be accessible.
Check that permissions on the device entries allow user or group read *and*
write access (it's safest to grant user or group access only to the device
matching the cdrom).
Extraction is very slow; the CDROM is accessed continuously, but cdparanoia makes no apparent (or very slow) progress
I recently discovered the existence of drives with a bimodal jitter
pattern (just before the release of alpha 9.4). Essentially, these
drives jitter in two different patterns; one is a constant amount of
slight jitter followed by periods of very large jitter. The current
automatically adjusting overlap code in cdparanoia will choose too
small an overlap value for these drives to function.
For these drives, I've temporarily provided a switch (-o) to force the
overlap setting to a specific value. If your drive exhibits this
behavior, try forcing the overlap to a specific value. You'll likely
have to experiment to find the best choice; try ten or so to begin.
As before, the next release will update the algorithm to address this
newly discovered problem.
Drives are not required to be able to seek exactly to any position;
they simply must be able to hit within one second. Add to this the
fact that the disc itself is premitted to be off by a bit as well, and
you can well land well too early or too late.
The good news is that such discs and CDROM drives are rare. I've not
been able to reproduce reports of drive models with this problem
myself, and all the untested reports are currently by Toshiba drive
owners. More news on this subject as I get it; new TOC code to appear
at some point in alpha 10 might provide a good workaround for this
problem.
(Linux) When ripping the last track on a disc, the rip stops and I
get "packet command error" messages.
Most likely, the session ended just before the TOC said it would, or
the drive's positioning isn't exactly correct and it's managing to
read a bit too far.
The problem would not be serious except that the Linux cooked-ioctl
kernel interface (used by older kernels and older versions of
cdparanoia) automatically tells the drive to retry.... and gets the
same error which triggers a retry, etc. In this case, the solution,
as above, is to use the drive with IDE-SCSI hostadapter emulation.
The errors will become harmless.
Also, discs with sectors in the gaps between tracks marked as non-audio
are becoming more common. Some cdrom drives complain about it. Is
this another really lame attempt at copy protection? Gotta wonder....
(Linux) I get an error about not having SG_BIG_BUFF defined in my kernel
[This note does not apply to modern (2.6) kernels]
This was a common problem in Linux distributions until about 1999.
Without the big buffer for generic SCSI reads, cdparanoia can only
read a single sector from a SCSI cdrom at a time. This is too small
for cdparanoia to function.
To add the big buffer, add the line:
#define SG_BIG_BUFF 65536
To the end of linux/src/include/scsi/sg.h just before the last #endif,
then rebuild and install the new kernel.
My ATAPI CDROM drive reports 'unable to read any data'!
The information below applies to older Linux kernels (2.4 and earlier)
without the SG_IO interface, or older versions of cdparanoia (earlier
than cdparanaoia 10) that could not use SG_IO.
Chances are that the drive is not capable of reading audio discs. To
be certain, try using the drive under Linux IDE-SCSI emulation rather
than with the cooked ioctl ATAPI driver. The emulation is more flexible,
and cdparanoia will be able to try more possible read techniques.
Note that a few Matsushita drives (and Panasonics which are made by
Matsushita) that certainly *are* CDDA capable are currently not
working with cdparanoia. I'm trying to get technical information from
Matsushita to correct the problem.
(Linux) How do I use my ATAPI drive through IDE-SCSI hostadapter
emulation?
First off, if you're using a recent (2.6) kernel, there's no reason to
do so; the 2.6 kernel offers SG_IO, which can do everything the old
IDE-SCSI emulation could.
If you're stuck with Linux older than 2.6 or a version of cdparanoia
before cdparanoia 10, then IDE-SCSI hostadapter emulation is
recommended for ATAPI drives. To use the SCSI emulation with an
ATAPI cdrom, the kernel must be configured with SCSI
support, generic SCSI device support and IDE-SCSI emulation, and
without ATAPI (IDE) CDROM drive support. If the kernel
includes cooked ioctl ATAPI (IDE CDROM drive) support, then the kernel
will always use it over the emulation interface.
cdparanoia will not work with the sbpcd.o module that comes with the
2.0.x kernels. It hangs when checking the endianness of the data. The
problem is that the sbpcd module that comes with the kernel can not read
more than 1 sector correctly, at least not with my type of drive. I
looked into this problem some time ago and managed to get good results
with your paranoia patch to cdda2wav and some small modifications of the
sbpcd.c module, fixing some timing and syncronization problems. Using
the same modified sbpcd module, cdparanoia III seemes to work fine,
although slow. I think the reason is that only 8 sectors are read at a
time. With cdda2wav(paranoiaII) I use 75 sectors as default, and it is a
factor 2-3 faster. There are still some remaining problems with the
sbpcd.c module though, but since this interface is getting obsolete, I
guess noone bothers to fix them:
1) I must load the module manually (not automatically with kerneld)
otherwise all data (at least in the first invocation of cdparanoia)
seems to be set to 0.
2) It does not handle a CD change properly (does not affect cdparanoia).
I include my sbpcd.c patch below, which at least is working reasonably
well on my system (100 MHz Cyrix 586 cpu & Panasonic CR563 drive).
