Bug 24512
| Summary: | Burning CD-R fails and burning CD-RW succeeds on 2.6.32. Both work on 2.6.26 | ||
|---|---|---|---|
| Product: | IO/Storage | Reporter: | loupgarou |
| Component: | SCSI | Assignee: | linux-scsi (linux-scsi) |
| Status: | RESOLVED WILL_NOT_FIX | ||
| Severity: | normal | CC: | alan, loupgarou, tj |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.32 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
script used to gather information
script output under 2.6.26 script output under 2.6.32 dmesg from booting 2.6.26 dmesg from booting 2.6.32 syslog during the run under 2.6.26 syslog during the run under 2.6.32 |
||
Created attachment 39392 [details]
script used to gather information
Created attachment 39402 [details]
script output under 2.6.26
Created attachment 39412 [details]
script output under 2.6.32
Created attachment 39422 [details]
dmesg from booting 2.6.26
Created attachment 39432 [details]
dmesg from booting 2.6.32
Created attachment 39442 [details]
syslog during the run under 2.6.26
Created attachment 39452 [details]
syslog during the run under 2.6.32
Under 2.6.26 the devices are /dev/hda and /dev/hdb. Under 2.6.32 the are /dev/sr0 and /dev/sr1 2.6.36 also fails in the same way as 2.6.32. 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? 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? 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. |
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.