Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 133312 - cdparanoia doesn't understand /dev/scd0 (external usb cdrom)
Summary: cdparanoia doesn't understand /dev/scd0 (external usb cdrom)
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: cdparanoia
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Peter Jones
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 132888
TreeView+ depends on / blocked
 
Reported: 2004-09-23 02:32 UTC by Colin Walters
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-09-30 15:50:43 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

Description Colin Walters 2004-09-23 02:32:45 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040809 Epiphany/1.3.8

Description of problem:
I'm trying to use sound-juicer to extract from my external USB cdrom
drive, which with the latest udev shows up as /dev/scd0.  

It looks like cdparanoia tries an ioctl or two, but then just gives up
on it and starts polling the nonexistent /dev/sg0:

lstat64("/dev", {st_mode=S_IFDIR|0755, st_size=4400, ...}) = 0
lstat64("/dev/scd0", {st_mode=S_IFBLK|0600, st_rdev=makedev(11, 0),
...}) = 0
open("/dev/scd0", O_RDONLY|O_NONBLOCK|O_EXCL) = 17
ioctl(17, CDROMAUDIOBUFSIZ, 0xfefe6a58) = 0
ioctl(17, 0x5386, 0xfefe6a54)           = 0
open("/dev/sg0", O_RDONLY|O_NONBLOCK)   = -1 ENOENT (No such file or
directory)
write(2, "Error trying to open /dev/sg0 ex"..., 93Error trying to open
/dev/sg0 exclusively (No such file or directory). retrying in 1 second.
) = 93


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Plug in external usb cdrom
2. Put audio CD in it
3. cdparanoia -d /dev/scd0 1
    

Additional info:
Comment 1 Harald Hoyer 2004-09-23 08:10:31 UTC 
the O_EXCL patch has to be fixed and has to cope with errno == ENOENT .

Also in this case the sg module was not loaded, thus no /dev/sg0.
Maybe cdparanoia can use /dev/scd0 directly, without sg0
Comment 2 Harald Hoyer 2004-09-23 08:11:44 UTC 
also the O_EXCL patch contains open loops without O_EXCL !?!
Comment 3 Colin Walters 2004-09-23 13:10:55 UTC 
Why is it looping anyways?  This causes GUI applications that invoke
cdparanoia to simply lock up for 10 seconds, the user has no idea
what's going on.  But that's another bug...
Comment 4 Peter Jones 2004-09-23 15:16:50 UTC 
Harald: the place with the loop lacking the O_EXCL is on a devfs only
path, so it wasn't worth going back and fixing.  You're right about it
needing to handle -ENOENT, though.  In general, though, this problem
is that this version doesn't support SG_IO, which is needed with newer
kernels.  I'm hoping to have a version in the tree in the next couple
of days with rudamentary support for it.

Colin: all of our other apps that use CD drives do it, so I copied
that ;).  Not the best answer, sorry.  In general, yes, this is
horrible for GUIs.  In fact, the whole API is awful for interactive
use as a library.  I'm hoping to start adding reasonably APIs in the
upstream version soon, time permitting.  Although, in this case, it's
not so bad -- if a GUI app invokes cdparanoia in such a way that
you're going to get stuck on the O_EXCL open loop path, it probably
means there's a serious bug anyway.  That is, it's almost certainly
not going to work at all.  I know that's not a great answer either.
Comment 5 Colin Walters 2004-09-23 16:07:03 UTC 
I don't think the core problem from this bug relates to ENOENT or
/dev/sg0.  My application explicitly gives /dev/scd0 as the device to
use, which should work.  That's the device that udev creates for my
USB cdrom.

Note that cdparanoia does stat it and try an ioctl, but decides for
some reason or another that it won't work, and falls back to /dev/sg0.
 In my strace above, the second ioctl looks a bit suspicious to me
since apparently strace doesn't know about it.
Comment 6 Peter Jones 2004-09-23 16:15:09 UTC 
Colin, can you try the rpms at
http://people.redhat.com/pjones/cdparanoia/ ?
Comment 7 Peter Jones 2004-09-23 16:27:56 UTC 
Colin: fwiw, you're both right and wrong.  It's not that it's "failing
back" to /dev/sg0.  The version of cdparanoia currently in the tree
prefers the /dev/sg0 interface, because it doesn't yet have SG_IO
support.  The version I just pointed you at (which the code that goes
into fedora soon will probably be heavily derived from) has support
for SG_IO, but it's a bit kludgy.

So it does some ioctl's, yes, but they're to find things like the
buffer sizes, how many packets it can send to a drive at once, etc.,
not actual CD-reading ioctls.  It should try to fall back to the
"cooked ioctl" interface if sg fails, but that's strongly preferred
against, because it works very poorly.

So the best answer is really "make the SG_IO version work well enough
to at least put out for more broad testing".
Comment 8 Colin Walters 2004-09-23 18:43:29 UTC 
My external usb dvd burner's at home, I can try it when I get back
there.  Thanks!
Comment 9 Colin Walters 2004-09-24 03:06:48 UTC 
Yep, cdparanoia-{devel-,libs-,}alpha9.8-21sgio1.i386.rpm works for me.
Comment 10 Colin Walters 2004-09-24 18:24:41 UTC 
If we want testing for the SG_IO version, let's put it in rawhide and
FC3t3, and if things really break it can be backed out.  Does that
sound reasonable to you?
Comment 11 Colin Walters 2004-09-29 21:38:33 UTC 
Any word on this?
Comment 12 Peter Jones 2004-09-30 15:50:43 UTC 
Sorry for not updating after the last comment.  We can push the sgio
packages on my people site to FC3, but first I want to add a way to
get the old behavior if it doesn't work.

... done now.  If SG_IO for some reason completely fails, and fallback
doesn't work, setting "CDDA_TRANSPORT=cooked" will get cooked ioctl mode.
Comment 13 Colin Walters 2004-09-30 15:54:47 UTC 
Cool, thanks!
Note You need to log in before you can comment on or make changes to this bug.