Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 134558

Summary: New SG_IO engine causes ripping to hang on IDE DVD-ROM
Product: [Fedora] Fedora Reporter: Derek P. Moore <derek.p.moore>
Component: cdparanoiaAssignee: Peter Jones <pjones>
Severity: high Docs Contact:
Priority: medium    
Version: rawhideCC: triage
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: alpha9.8-24 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-07 00:01:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 150221    
Description Flags
output of cdparanoia-alpha9.8-21
output of cdparanoia-alpha9.8-23
output of cdparanoia-alpha9.8-24 none

Description Derek P. Moore 2004-10-04 16:27:46 UTC
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):

How reproducible:

Comment 1 Peter Jones 2004-10-05 15:59:03 UTC
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?

Comment 2 Derek P. Moore 2004-10-06 01:14:16 UTC
With -23, I get the following smilies:

and 8-|

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
of cdparanoia.

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?

Comment 3 Derek P. Moore 2004-10-06 01:16:36 UTC
Created attachment 104816 [details]
output of cdparanoia-alpha9.8-21

Comment 4 Derek P. Moore 2004-10-06 01:17:32 UTC
Created attachment 104817 [details]
output of cdparanoia-alpha9.8-23

Comment 5 Peter Jones 2004-10-06 20:45:18 UTC
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?

Comment 6 Derek P. Moore 2004-10-08 01:34:17 UTC
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.

Comment 7 Derek P. Moore 2004-10-08 01:34:59 UTC
Created attachment 104919 [details]
output of cdparanoia-alpha9.8-24

Comment 8 Peter Jones 2004-10-08 16:01:26 UTC
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.

Comment 9 Red Hat Bugzilla 2007-02-05 19:21:09 UTC
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.

Comment 10 Bug Zapper 2008-04-03 15:40:58 UTC
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: to ensure this
doesn't happen again.

Comment 11 Bug Zapper 2008-05-07 00:01:12 UTC
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: