Description of problem: Even though cdrecord recognizes one of my RW media to have a max write speed of 2x and despite the "speed=2" option on the command line, it tries to write (or blank) it with 10x speed. Version-Release number of selected component (if applicable): cdrecord-2.01-0.a27.1 How reproducible: Easy. Steps to Reproduce: 1. e.g. "cdrecord -v speed=2 -dummy blank=fast dev=..." Actual results: Burns/Blanks with 10x speed Expected results: Burns/blanks with 2x speed Additional info: Apparently setting the speed to the drive and getting it back fails, in cdrecord/drv_mmc.c, around lines 1934 (mmc_set_speed()) and 1938 (scsi_get_speed ()). The drive is a "SAMSUNG CDRW/DVD SN-324F". Seeting severity to high because the bug may produce coasters.
Logged dummy blank session, it's the same without -dummy: ---- 8< ---- nils@gibraltar:~> rpm -q cdrecord cdrecord-2.01-0.a27.1 nils@gibraltar:~> cdrecord -v -dummy speed=2 blank=session dev=/dev/hdc Cdrecord-Clone 2.01a27-dvd (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg Schilling Note: This version is an unofficial (modified) version with DVD support Note: and therefore may have bugs that are not present in the original. Note: Please send bug reports or support requests to <warly>. Note: The author of cdrecord should not be bothered with problems in this version. TOC Type: 1 = CD-ROM cdrecord: Operation not permitted. WARNING: Cannot do mlockall(2). cdrecord: WARNING: This causes a high risk for buffer underruns. cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler cdrecord: Permission denied. WARNING: Cannot set priority using setpriority(). cdrecord: WARNING: This causes a high risk for buffer underruns. scsidev: '/dev/hdc' devname: '/dev/hdc' scsibus: -2 target: -2 lun: -2 Warning: Open by 'devname' is unintentional and not supported. Linux sg driver version: 3.5.27 Using libscg version 'schily-0.8'. cdrecord: Warning: using inofficial libscg transport code version (schily - Red Hat-scsi-linux-sg.c-1.80-RH '@(#)scsi-linux-sg.c 1.80 04/03/08 Copyright 1997 J. Schilling'). SCSI buffer size: 64512 atapi: 1 Device type : Removable CD-ROM Version : 0 Response Format: 1 Vendor_info : 'SAMSUNG ' Identifikation : 'CDRW/DVD SN-324F' Revision : 'U203' Device seems to be: Generic mmc2 DVD-ROM. Current: 0x000A Profile: 0x000A (current) Profile: 0x0009 Profile: 0x0008 Profile: 0x0010 Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R Drive buf size : 1959936 = 1914 KB Current Secsize: 2048 ATIP info from disk: Indicated writing power: 5 Reference speed: 2 Is not unrestricted Is erasable ATIP start of lead in: -11635 (97:26/65) ATIP start of lead out: 337350 (75:00/00) 1T speed low: 2 1T speed high: 2 power mult factor: 5 6 recommended erase/write power: 3 A1 values: 11 5C B0 Disk type: Phase change Manuf. index: 3 Manufacturer: CMC Magnetics Corporation Starting to write CD/DVD at speed 10.0 in dummy BLANK mode for single session. Last chance to quit, starting dummy write 0 seconds. Operation starts. Blanking last session Blanking time: 303.322s nils@gibraltar:~> ---- 8< ----
*** Bug 120790 has been marked as a duplicate of this bug. ***
The dvd patch seems to screw up the commandline argument handling. I can't burn a bin/cue with the current RPM. (cdrecord-2.01-0.a27.2) # cdrecord -v dev=/dev/hdc -dao cuefile=foo.cue cdrecord-2.01-0.a27.2 cdrecord: No tracks specified. Need at least one. Usage: cdrecord [options] track1...trackn ... Recompiling it without the dvd patch makes it work.
djh, I think your problem is different from what we have here, please open an own Bugzilla entry. I ran cdrecord from a debugger and found that it tries to set the speed as specified on the command line in speed_select_mmc() -- so no wrong command line parsing here: --- 8< --- cdrecord/drv_mmc.c --- [...] LOCAL int curspeed = 1; [...] LOCAL int speed_select_mmc(scgp, dp, speedp) SCSI *scgp; cdr_t *dp; int *speedp; { [...] if (speedp) curspeed = *speedp; [...] /* * 44100 * 2 * 2 = 176400 bytes/s * * The right formula would be: * tmp = (((long)curspeed) * 1764) / 10; * * But the standard is rounding the wrong way. * Furtunately rounding down is guaranteed. */ val = curspeed*177; if (val > 0xFFFF) val = 0xFFFF; if (mmc_isyamaha(scgp) && forcespeed) { if (force_speed_yamaha(scgp, -1, val) < 0) return (-1); } else if (mmc_set_speed(scgp, -1, val, ROTCTL_CLV) < 0) { return (-1); } if (scsi_get_speed(scgp, 0, &val) >= 0) { if (val > 0) { curspeed = val / 176; *speedp = curspeed; } } return (0); } [...] --- >8 ------------------------- I saw that curspeed == 2 until it is set in "curspeed=val/176" above, i.e. the speed gets set with mmc_set_speed(), but the drive seems to ignore the setting (or one of mmc_{set,get}_speed() is buggy in that regard) and returns a different value in mmv_get_speed() which sets curspeed=10.
I have noticed a mistake in cdrtools-2.01a27-dvd.patch, there is a missing comma between arguments. "formattype&pktsize#" should be "formattype&,pktsize#" The bug results in many options not getting parsed (like cuefile or dao/sao). I have also notified warly
cool! Thank you very much!
Warly has fixed the missing comma in his dvd patch; the patch filename did not change. http://peoples.mandrakesoft.com/~warly/files/cdrtools/archives/cdrtools-2.01a27-dvd.patch.bz2 The speed, cuefile, dao/sao and other options seem to behave now. Enjoy,
already submitted a fixed package in the buildsystem, will soon appear on rawhide..
*** Bug 122318 has been marked as a duplicate of this bug. ***
fixed in 2.01-0.a27.3
*** Bug 122053 has been marked as a duplicate of this bug. ***