Bug 134558 - New SG_IO engine causes ripping to hang on IDE DVD-ROM
New SG_IO engine causes ripping to hang on IDE DVD-ROM
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: cdparanoia (Show other bugs)
rawhide
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Peter Jones
bzcl34nup
: Reopened
Depends On:
Blocks: FC5Target
  Show dependency treegraph
 
Reported: 2004-10-04 12:27 EDT by Derek P. Moore
Modified: 2008-05-06 20:01 EDT (History)
1 user (show)

See Also:
Fixed In Version: alpha9.8-24
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 20:01:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output of cdparanoia-alpha9.8-21 (859 bytes, text/plain)
2004-10-05 21:16 EDT, Derek P. Moore
no flags Details
output of cdparanoia-alpha9.8-23 (1.72 KB, text/plain)
2004-10-05 21:17 EDT, Derek P. Moore
no flags Details
output of cdparanoia-alpha9.8-24 (1.84 KB, text/plain)
2004-10-07 21:34 EDT, Derek P. Moore
no flags Details

  None (edit)
Description Derek P. Moore 2004-10-04 12:27:46 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041002
Firefox/0.10.1

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%
completion.

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
4.61).

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):
cdparanoia-alpha9.8-23

How reproducible:
Always
Comment 1 Peter Jones 2004-10-05 11:59:03 EDT
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-05 21:14:16 EDT
With -23, I get the following smilies:

:-P
:-/
;-(
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-05 21:16:36 EDT
Created attachment 104816 [details]
output of cdparanoia-alpha9.8-21
Comment 4 Derek P. Moore 2004-10-05 21:17:32 EDT
Created attachment 104817 [details]
output of cdparanoia-alpha9.8-23
Comment 5 Peter Jones 2004-10-06 16:45:18 EDT
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-07 21:34:17 EDT
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-07 21:34:59 EDT
Created attachment 104919 [details]
output of cdparanoia-alpha9.8-24
Comment 8 Peter Jones 2004-10-08 12:01:26 EDT
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 14:21:09 EST
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Comment 10 Bug Zapper 2008-04-03 11:40:58 EDT
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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 11 Bug Zapper 2008-05-06 20:01:12 EDT
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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

Note You need to log in before you can comment on or make changes to this bug.