Bug 146611

Summary:	cdparanoia tries to use /dev/scd0 and fails
Product:	[Fedora] Fedora	Reporter:	Todd Allen <redhatbugzillaold>
Component:	cdparanoia	Assignee:	Peter Jones <pjones>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:
Severity:	low	Docs Contact:
Priority:	medium
Version:	3	CC:	mattdm
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-02-05 06:14:25 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:

Description Todd Allen 2005-01-30 17:11:08 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041020 Galeon/1.3.19

Description of problem:
It appears that cdparanoia is trying to use the /dev/scd0 device. 
From reading bugs 121218, 128891, and 133312, it appears that this is
the intent of the maintainers.  However, it fails to do so
successfully.  Here's an example output from "cdparanoia -vsQ":

cdparanoia III release 9.8 (March 23, 2001)
(C) 2001 Monty <monty> and Xiphophorus

Report bugs to paranoia
http://www.xiph.org/paranoia/

Checking /dev/cdrom for cdrom...
        DMA scatter/gather table entries: 1
        table entry size: 65536 bytes
        maximum theoretical transfer: 27 sectors
        Setting default read size to 24 sectors (56448 bytes).


CDROM model sensed sensed: PLEXTOR CD-ROM PX-40TS 1.00 

Checking for SCSI emulation...
        Drive is ATAPI (using SCSI host adaptor emulation)

Checking for MMC style command set...

Error reading command:  
        5a 00 2a 00 00 00 00 00  16 00 
        Drive does not have MMC CDDA support
Verifying CDDA command set...

Error reading command:  
        be 00 00 00 2e 6a 00 00  01 f8 00 00 

Error reading command:  
        be 00 00 00 83 4d 00 00  01 f8 00 00 

Error reading command:  
        be 00 00 00 d5 0a 00 00  01 f8 00 00 

Error reading command:  
        be 00 00 01 28 a8 00 00  01 f8 00 00 

Error reading command:  
        be 00 00 01 54 4f 00 00  01 f8 00 00 

Error reading command:  
        be 00 00 01 7f 98 00 00  01 f8 00 00 

Error reading command:  
        be 00 00 01 c6 3e 00 00  01 f8 00 00 

Error reading command:  
        be 00 00 02 06 48 00 00  01 f8 00 00 

Error reading command:  
        be 00 00 02 49 50 00 00  01 f8 00 00 

Error reading command:  
        be 00 00 02 7a 7a 00 00  01 f8 00 00 

Error reading command:  
        be 00 00 02 a7 1b 00 00  01 f8 00 00 

Error reading command:  
        be 00 00 02 ed c3 00 00  01 f8 00 00 

Error reading command:  
        be 00 00 03 3d 13 00 00  01 f8 00 00 

Error reading command:  
        be 00 00 03 8d 50 00 00  01 f8 00 00 

Error reading command:  
        be 00 00 03 c4 95 00 00  01 f8 00 00 
        Expected command set FAILED!
        Performing full probe for CDDA command set...
        test -> density: [none    ]  command: [28 0x,00]

Error reading command:  
        28 00 00 00 2e 6a 00 00  01 00 
                Drive rejected read command packet(s)
        test -> density: [yes/0x00]  command: [28 0x,00]

Error reading command:  
        55 10 00 00 00 00 00 00  0c 00 
                Drive rejected density set
        test -> density: [yes/0x04]  command: [28 0x,00]

Error reading command:  
        55 10 00 00 00 00 00 00  0c 00 
                Drive rejected density set
        test -> density: [yes/0x81]  command: [28 0x,00]

Error reading command:  
        55 10 00 00 00 00 00 00  0c 00 
                Drive rejected density set
        test -> density: [none    ]  command: [a8 0x,00]
                Command set FOUND!
This command set may use a Force Unit Access bit.
Checking drive for FUA bit support...
        Drive accepted FUA bit.

Attempting to determine drive endianness from data..................
        Data appears to be coming back little endian.
        certainty: 56%

Table of contents (audio tracks only):
track        length               begin        copy pre ch
===========================================================
  1.    23765 [05:16.65]        0 [00:00.00]    no   no  2
  2.    19697 [04:22.47]    23765 [05:16.65]    no   no  2
  3.    22153 [04:55.28]    43462 [09:39.37]    no   no  2
  4.    20660 [04:35.35]    65615 [14:34.65]    no   no  2
  5.     1690 [00:22.40]    86275 [19:10.25]    no   no  2
  6.    20472 [04:32.72]    87965 [19:32.65]    no   no  2
  7.    15700 [03:29.25]   108437 [24:05.62]    no   no  2
  8.    17088 [03:47.63]   124137 [27:35.12]    no   no  2
  9.    17232 [03:49.57]   141225 [31:23.00]    no   no  2
 10.     7940 [01:45.65]   158457 [35:12.57]    no   no  2
 11.    14910 [03:18.60]   166397 [36:58.47]    no   no  2
 12.    21265 [04:43.40]   181307 [40:17.32]    no   no  2
 13.    19343 [04:17.68]   202572 [45:00.72]    no   no  2
 14.    21740 [04:49.65]   221915 [49:18.65]    no   no  2
 15.     6557 [01:27.32]   243655 [54:08.55]    no   no  2
TOTAL  250212 [55:36.12]    (audio only)

An attempt to actually rip a track with "cdparanoia -vs -e -B 01"
emits the same errors as above, then seems to try to rip, but produces
track01.cdda.wav output extremely slowly (98k in the first minute,
753k after 8 minutes), and the output contains only silence or very
light static.

If, instead, I arrange to load the sg module either with just a manual
"modprobe sg", or by placing this material in /etc/modprobe.conf:

   # -- SCSI generic device for CD drive
   install sr_mod /sbin/modprobe --ignore-install sr_mod;
/sbin/modprobe sg

And then add the "-d /dev/sg0" option to any of the above cdparanoia
commands, it works just fine.

The aforementioned bugs say that the sg modules and devices are
deprecated, and that cdparanoia has been updated to work with
/dev/scd0.  The bugs were fixed in Rawhide, but I would have expected
there was enough time for them to propagate into Fedora Core 3.  If
that's not so, please let me know.  If the fixes are in Fedora Core 3,
then perhaps this is just a new problem.

If more information would be helpful, please let me know what exactly
what information.  For instance, an strace?

I'm marking this as Low severity, since there's a workaround.  But in
whatever release the /dev/sg0 interfaces disappear, if this isn't
fixed, the severity would be much higher.


Version-Release number of selected component (if applicable):
cdparanoia-alpha9.8-24

How reproducible:
Always

Steps to Reproduce:
1. Use system with SCSI CDROM (e.g. PLEXTOR CD-ROM PX-40TS)
2. Note that /dev/cdrom -> scd0
3. cdparanoia -vsQ
    

Actual Results:  Errors as mentioned above.

Expected Results:  Either cdparanoia should use /dev/sg0 (which I
suppose would be only an interim solution, if that interface is
deprecated), or should actually rip proper tracks with /dev/scd0.


Additional info:

Comment 1 Matthew Miller 2006-07-10 20:28:55 UTC

Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

Comment 2 petrosyan 2008-02-05 06:14:25 UTC

Fedora Core 3 is not maintained anymore.

Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release please reopen this bug and assign it to the corresponding
Fedora version.