Red Hat Bugzilla – Bug 134558
New SG_IO engine causes ripping to hang on IDE DVD-ROM
Last modified: 2008-05-06 20:01:14 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041002
Description of problem:
The new cdparanoia with the SG_IO engine causes ripping to be very
slow (0.2x, as reported by Sound Juicer) and hang after about 7 to 10%
I'm experiencing these problems on a Toshiba Tecra 8200 laptop with a
DVD-ROM drive (TOSHIBA DVD-ROM SD-C2302 using driver ide-cdrom version
I have yet to give "export CDDA_TRANSPORT=cooked" a try. I simply
downgraded to cdparanoia-alpha9.8-21, and the ripping speed and system
responsiveness during ripping have returned to normal.
Version-Release number of selected component (if applicable):
If you run "cdparanoia 1 /dev/null" instead of sound juicer, what
happens? Are there any error or debugging messages shown?
Also, does -21 work if you use ide-scsi and sg, instead of /dev/hdc?
Did you use this drive to rip with any kernels before 2.6?
With -23, I get the following smilies:
And the progress bar fills with V and +.
cdparanoia-alpha9.8-23 does report more information during start-up,
but they don't seem to be errors. It just has those errors it reports
via its normal interface.
I'm attaching two text files, each one is the output for that version
I've only tested these packages on my laptop, which hasn't run 2.4 in
a long time (if ever). I haven't tried to use ide-scsi or sg with
-21. Should I try for some reason? And how?
Created attachment 104816 [details]
output of cdparanoia-alpha9.8-21
Created attachment 104817 [details]
output of cdparanoia-alpha9.8-23
Yep, I can duplicate this now. I think it's a kernel problem, but
I'll see about building a -24 today which has a workaround until I can
point the blame solidly at us or them ;)
Can you test it when it shows up in rawhide?
The new build (cdparanoia-alpha9.8-24) is working.
It seems to be working a little bit slower than I'm used to.
Historically, Sound Juicer reports between 2.0x and 2.2x, but the CD
I'm testing with right now seems to top out between 1.5x and 1.8x.
Maybe it's the current media, maybe it's the new engine; I'll be able
to make a more thorough determination as I rip more (newer) CDs over
the next few days.
I'm attaching the current output of the new working cdparanoia build,
just for completeness. I'll also set this particular bug to resolved.
If I determine that cdparanoia is performing more slowly, I'll open a
new "cdparanoia performs slower with new engine" bug.
Created attachment 104919 [details]
output of cdparanoia-alpha9.8-24
I suspect that it is running more slowly -- the workaround for this
issue was to change from reading 32 sectors at a time to doing 24
sectors at a time. So for a 74-minute disk that reads perfectly,
that's roughly 12000 reads instead of 9000. This seems consistent
with your 2.1x -> 1.65x averages.
We really should be able to do more than 32 sectors at a time -- on my
laptop with a slightly older kernel 55 sectors worked just fine -- but
there are some kernel subsystems (usb cd drives especially) that seem
to handle this extraordinarily poorly. 32 seemed to always work before.
If you set an environmental variable CDDA_IGNORE_BUFSIZE_LIMIT=1 and
run cdparanoia, it'll try to do transfers at whatever size the scsi
subsystem claims it can do (most likely 55 sectors or so), but my
experience with current kernels is that >24 sectors means your reads
are garbage. So right now, I think this is a kernel bug, and I want
to keep this open to track the status of cdparanoia in this regard.
I'd really like to take that workaround _out_, but for now we're stuck
reading somewhat suboptimally.
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.
If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.
The process we're following is outlined here: