Bug 24512 - Burning CD-R fails and burning CD-RW succeeds on 2.6.32. Both work on 2.6.26
Summary: Burning CD-R fails and burning CD-RW succeeds on 2.6.32. Both work on 2.6.26
Status: RESOLVED WILL_NOT_FIX
Alias: None
Product: IO/Storage
Classification: Unclassified
Component: SCSI (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: linux-scsi@vger.kernel.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-09 04:05 UTC by loupgarou
Modified: 2012-08-14 14:02 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.32
Subsystem:
Regression: No
Bisected commit-id:


Attachments
script used to gather information (2.25 KB, text/plain)
2010-12-09 04:07 UTC, loupgarou
Details
script output under 2.6.26 (55.43 KB, text/plain)
2010-12-09 04:08 UTC, loupgarou
Details
script output under 2.6.32 (55.55 KB, text/plain)
2010-12-09 04:08 UTC, loupgarou
Details
dmesg from booting 2.6.26 (56.43 KB, text/plain)
2010-12-09 04:09 UTC, loupgarou
Details
dmesg from booting 2.6.32 (57.58 KB, text/plain)
2010-12-09 04:10 UTC, loupgarou
Details
syslog during the run under 2.6.26 (89.93 KB, text/plain)
2010-12-09 04:11 UTC, loupgarou
Details
syslog during the run under 2.6.32 (90.03 KB, text/plain)
2010-12-09 04:11 UTC, loupgarou
Details

Description loupgarou 2010-12-09 04:05:00 UTC
Overview:

On a debian system, using wodim to write ISO images to CD media, then verifying the burn using md5sum. A change in behavior was seen following an upgrade from a 2.6.26 to a 2.6.32 kernel. Under 2.6.26 both CD-R and CD-RW media burn cleanly. Under 2.6.32, CD-RW media burn correctly and CD-R media fail to burn correctly.

The CD/DVD drives on the system are  
  Vendor_info    : 'PIONEER '
  Identification : 'DVD-RW  DVR-112D'
  Revision       : '1.21'
and
  Vendor_info    : 'PLEXTOR '
  Identification : 'DVDR   PX-800A  '
  Revision       : '1.00'

It doesn't matter which drive is used for the CDR and which is used 
for the CDRW.



Steps to reproduce (A script used to gather data is attached):

Create an ISO image. 
Blank the CDRW medium using: 

 # wodim dev=$CDRWDEV gracetime=2 -v blank=fast

Burn the CDRW medium using:

 # wodim -v  dev=$CDRWDEV gracetime=2 fs=4096k \
          driveropts=burnfree padsize=63s \
          -useinfo -dao -pad  -data $ISO

Burn the CDR medium using:

 # wodim -v  dev=$CDRDEV gracetime=2 fs=4096k \
          driveropts=burnfree padsize=63s \
          -useinfo -dao -pad  -data $ISO

calculate md5sum of ISO:

 # dd if=$ISO bs=$blocksize count=$blockcount conv=notrunc,noerror | md5sum

calculate md5sum of CDRW:

 # dd if=$CDRWDEV bs=$blocksize count=$blockcount conv=notrunc,noerror | md5sum

calculate the md5sum of CDR:

 # dd if=$CDRDEV bs=$blocksize count=$blockcount conv=notrunc,noerror | md5sum

compare the results running under 2.6.26 and also under 2.6.32



Actual Results: 

Under 2.6.26 the md5sums of the CDR, CDRW and ISO are the same. Under 2.6.32 the md5sums for the ISO and the CDRW match. The md5sum for the CDR does not match. 



Expected result:

md5sums of all images should match on 2.6.32 as they do on 2.6.26.
Comment 1 loupgarou 2010-12-09 04:07:13 UTC
Created attachment 39392 [details]
script used to gather information
Comment 2 loupgarou 2010-12-09 04:08:05 UTC
Created attachment 39402 [details]
script output under 2.6.26
Comment 3 loupgarou 2010-12-09 04:08:40 UTC
Created attachment 39412 [details]
script output under 2.6.32
Comment 4 loupgarou 2010-12-09 04:09:23 UTC
Created attachment 39422 [details]
dmesg from booting 2.6.26
Comment 5 loupgarou 2010-12-09 04:10:24 UTC
Created attachment 39432 [details]
dmesg from booting 2.6.32
Comment 6 loupgarou 2010-12-09 04:11:26 UTC
Created attachment 39442 [details]
syslog during the run under 2.6.26
Comment 7 loupgarou 2010-12-09 04:11:57 UTC
Created attachment 39452 [details]
syslog during the run under 2.6.32
Comment 8 loupgarou 2010-12-09 04:14:19 UTC
Under 2.6.26 the devices are /dev/hda and /dev/hdb. Under 2.6.32 the are /dev/sr0 and /dev/sr1
Comment 9 loupgarou 2010-12-09 06:11:18 UTC
2.6.36 also fails in the same way as 2.6.32.
Comment 10 Tejun Heo 2010-12-09 09:24:05 UTC
 dd if=/dev/cdrom bs=2048 count=11426 conv=notrunc,noerror | md5sum
 1+0 records in
 1+0 records out
 2048 bytes (2.0 kB) copied, 0.27374 s, 7.5 kB/s
 c99a74c555371a433d121f551d6c6398  -

Only 2kiB is copied.  Does this still fail after ejecting and then reloading the media?
Comment 11 loupgarou 2010-12-10 04:49:33 UTC
Ejecting and reloading the media DOES work to read the CDR cleanly. Still, isn't it odd that CDRW does not require eject/reload and that CDR did not require eject/reload in 2.6.26?
Comment 12 Tejun Heo 2010-12-10 15:37:53 UTC
I don't know.  It may be caused by different behavior in firmware or different command sequence used by the burning program which made sr revalidate the device afterwards.  Many optical drives can't revalidate the media after burning and require reloading anyway so it's kind of a grey area.  Maybe the old ide driver was forcing revalidation on each open or something.

It would be nice if media_changed can be set somehow so that sr is forced to revalidate after burning, but given that ejecting after burning is complete is more or less a standard practice, I don't think it's high priority.  We can probably shove it in BLKFLSBUF.

Changing ownership to SCSI.

Thanks.

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