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:
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
also the O_EXCL patch contains open loops without O_EXCL !?!
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...
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.
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.
Colin, can you try the rpms at http://people.redhat.com/pjones/cdparanoia/ ?
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".
My external usb dvd burner's at home, I can try it when I get back there. Thanks!
Yep, cdparanoia-{devel-,libs-,}alpha9.8-21sgio1.i386.rpm works for me.
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?
Any word on this?
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.
Cool, thanks!