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: | cdparanoia | Assignee: | Peter Jones <pjones> | ||||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | |||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | medium | ||||||||||
| Version: | rawhide | CC: | 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: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 150221 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Derek P. Moore
2004-10-04 16:27:46 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? 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? 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: 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. 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 |