Bug 496020

The same problem happened when I tried to eject an audio CD using 'grip'.  I had successfully read two CD's.  The first one I ejected manually and had no problem.  For the second one I pressed the eject button in the 'grip' application.  The disc began spinning and I was (still am, until I reboot) unable to eject the disc manually, even after exiting grip.

I had verbose output turned on.  This is what came up on the console:

...
Drive status is 4
Drive status is 4
Drive status is 4
Have disc -- ejecting
Checking for a new disc
Drive status is 4
Drive status is 4
CDStat found a disc, checking tracks
We have a valid disc!
Drive status is 4
Drive status is 4
Drive status is 4
...

and here is the kernel message log, which looks very similar to the DVD burning case:

May 24 16:21:07 hydra kernel: end_request: I/O error, dev sr1, sector 0
May 24 16:21:07 hydra kernel: __ratelimit: 11 callbacks suppressed
May 24 16:21:07 hydra kernel: Buffer I/O error on device sr1, logical block 0
May 24 16:21:07 hydra kernel: Buffer I/O error on device sr1, logical block 1
May 24 16:21:07 hydra kernel: Buffer I/O error on device sr1, logical block 2
May 24 16:21:07 hydra kernel: Buffer I/O error on device sr1, logical block 3
May 24 16:21:07 hydra kernel: Buffer I/O error on device sr1, logical block 4
May 24 16:21:07 hydra kernel: Buffer I/O error on device sr1, logical block 5
May 24 16:21:07 hydra kernel: Buffer I/O error on device sr1, logical block 6
May 24 16:21:07 hydra kernel: Buffer I/O error on device sr1, logical block 7
May 24 16:21:07 hydra kernel: end_request: I/O error, dev sr1, sector 0
May 24 16:21:07 hydra kernel: Buffer I/O error on device sr1, logical block 0
May 24 16:21:07 hydra kernel: Buffer I/O error on device sr1, logical block 1
May 24 16:21:07 hydra kernel: end_request: I/O error, dev sr1, sector 32

I can confirm this problem. I have a PX-712A drive too. Any insights how to debug this issue would be of great help...

I confirm the same problem on Fedora 12 beta / rawhide.  (Please can someone update the "Version" field of this bug.)

As far as I understand it this is not a hardware problem or even a driver problem but is due to a bug in wodim: https://bugs.launchpad.net/ubuntu/+source/cdrkit/+bug/149076

I tried a lot of the suggestions in the above Ubuntu bug report, including adding my user account to the cdrom group (not sure if Fedora and Ubuntu even set this up the same way), doing "chmod u+s /usr/bin/wodim", manually changing ownership/perms of my drive device, etc.  The only thing that actually worked was to reduce the burning speed in k3b to 4x.  A higher speed may have worked too, but the default of "maximum speed" (which averaged out about 14.2x) produced coasters every time.

The symptoms for me were basically the same: the burning (in Brasero) would get to "Finalizing" and then sit there forever with the disk spinning.  I could not eject the disk even with "eject -f", I had to reboot.  When rebooting, the laptop would hang while trying to power-cycle.

Ironically, after producing a coaster, the disk surface did not appear written to at all upon manual inspection, so only the very first part of the disk seems to have been burned at all.

(Cue Jörg Schilling to add the obligatory explanation below about how replacing the "illegal" cdrkit with official software cdrtools will fix all your problems.  Regardless, Fedora is not currently distributing cdrtools, so I hope we can fix this in cdrkit because this makes burning non-functional on Fedora 12.)

Here is my output of wodim -v -V -inq dev=/dev/sr0 >/tmp/wodim 2>&1

--

scsidev: '/dev/sr0'
devname: '/dev/sr0'
scsibus: -2 target: -2 lun: -2
Linux sg driver version: 3.5.27
Wodim version: 1.1.9
SCSI buffer size: 64512

Executing 'test unit ready' command on Bus 1 Target 0, Lun 0 timeout 40s
CDB:  00 00 00 00 00 00
cmd finished after 0.000s timeout 40s

Executing 'test unit ready' command on Bus 1 Target 0, Lun 0 timeout 40s
CDB:  00 00 00 00 00 00
cmd finished after 0.000s timeout 40s

Executing 'inquiry' command on Bus 1 Target 0, Lun 0 timeout 40s
CDB:  12 00 00 00 24 00
cmd finished after 0.000s timeout 40s
Inquiry Data   : 05 80 05 32 5B 00 00 00 54 45 41 43 20 20 20 20 44 56 2D 57 32 38 53 2D 52 54 20 20 20 20 20 20 37 2E 30 44

Executing 'inquiry' command on Bus 1 Target 0, Lun 0 timeout 40s
CDB:  12 00 00 00 60 00
cmd finished after 0.000s timeout 40s
Inquiry Data   : 05 80 05 32 5B 00 00 00 54 45 41 43 20 20 20 20 44 56 2D 57 32 38 53 2D 52 54 20 20 20 20 20 20 37 2E 30 44 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Executing 'test unit ready' command on Bus 1 Target 0, Lun 0 timeout 40s
CDB:  00 00 00 00 00 00
cmd finished after 0.000s timeout 40s

Executing 'mode sense g1' command on Bus 1 Target 0, Lun 0 timeout 40s
CDB:  5A 00 3F 00 00 00 00 00 08 00
cmd finished after 0.000s timeout 40s
Mode Sense Data 00 D0 12 00 00 00 00 00

Executing 'test unit ready' command on Bus 1 Target 0, Lun 0 timeout 40s
CDB:  00 00 00 00 00 00
cmd finished after 0.000s timeout 40s

Executing 'mode sense g1' command on Bus 1 Target 0, Lun 0 timeout 40s
CDB:  5A 00 2A 00 00 00 00 00 02 00
cmd finished after 0.000s timeout 40s
Mode Sense Data 00 42
Mode Sense Data (converted) 3F

Executing 'test unit ready' command on Bus 1 Target 0, Lun 0 timeout 40s
CDB:  00 00 00 00 00 00
cmd finished after 0.000s timeout 40s

Executing 'mode sense g1' command on Bus 1 Target 0, Lun 0 timeout 40s
CDB:  5A 00 2A 00 00 00 00 00 44 00
cmd finished after 0.000s timeout 40s
Mode Sense Data 00 42 12 00 00 00 00 00 2A 3A 3F 37 F1 73 29 23 10 89 01 00 07 D0 10 89 00 00 10 89 10 89 00 01 00 00 00 00 10 89 00 05 00 00 10 89 00 00 0D C8 00 00 0B 06 00 00 06 E4 00 00 02 C1 00 00 00 00 00 00 00 00
Mode Sense Data (converted) 3F 12 00 00 2A 3A 3F 37 F1 73 29 23 10 89 01 00 07 D0 10 89 00 00 10 89 10 89 00 01 00 00 00 00 10 89 00 05 00 00 10 89 00 00 0D C8 00 00 0B 06 00 00 06 E4 00 00 02 C1 00 00 00 00 00 00 00 00
Mode Sense Data 3F 12 00 00 2A 3A 3F 37 F1 73 29 23 10 89 01 00 07 D0 10 89 00 00 10 89 10 89 00 01 00 00 00 00 10 89 00 05 00 00 10 89 00 00 0D C8 00 00 0B 06 00 00 06 E4 00 00 02 C1 00 00 00 00 00 00 00 00
Mode Page  Data 2A 3A 3F 37 F1 73 29 23 10 89 01 00 07 D0 10 89 00 00 10 89 10 89 00 01 00 00 00 00 10 89 00 05 00 00 10 89 00 00 0D C8 00 00 0B 06 00 00 06 E4 00 00 02 C1 00 00 00 00 00 00 00 00

Executing 'test unit ready' command on Bus 1 Target 0, Lun 0 timeout 40s
CDB:  00 00 00 00 00 00
cmd finished after 0.000s timeout 40s

Executing 'mode sense g1' command on Bus 1 Target 0, Lun 0 timeout 40s
CDB:  5A 00 2A 00 00 00 00 00 44 00
cmd finished after 0.000s timeout 40s
Mode Sense Data 00 42 12 00 00 00 00 00 2A 3A 3F 37 F1 73 29 23 10 89 01 00 07 D0 10 89 00 00 10 89 10 89 00 01 00 00 00 00 10 89 00 05 00 00 10 89 00 00 0D C8 00 00 0B 06 00 00 06 E4 00 00 02 C1 00 00 00 00 00 00 00 00
Mode Sense Data (converted) 3F 12 00 00 2A 3A 3F 37 F1 73 29 23 10 89 01 00 07 D0 10 89 00 00 10 89 10 89 00 01 00 00 00 00 10 89 00 05 00 00 10 89 00 00 0D C8 00 00 0B 06 00 00 06 E4 00 00 02 C1 00 00 00 00 00 00 00 00
Mode Sense Data 3F 12 00 00 2A 3A 3F 37 F1 73 29 23 10 89 01 00 07 D0 10 89 00 00 10 89 10 89 00 01 00 00 00 00 10 89 00 05 00 00 10 89 00 00 0D C8 00 00 0B 06 00 00 06 E4 00 00 02 C1 00 00 00 00 00 00 00 00

Executing 'test unit ready' command on Bus 1 Target 0, Lun 0 timeout 40s
CDB:  00 00 00 00 00 00
cmd finished after 0.000s timeout 40s
TOC Type: 1 = CD-ROM
Inquiry Data   : ...2[...TEAC    DV-W28S-RT      7.0D                    ........................................
Device type    : Removable CD-ROM
Version        : 5
Response Format: 2
Capabilities   : 
Vendor_info    : 'TEAC    '
Identification : 'DV-W28S-RT      '
Revision       : '7.0D'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.

PS I get the same sort of errors in the dmesg log: 

[drm:drm_mode_rmfb] *ERROR* tried to remove a fb that we didn't own
type=1305 audit(1256248474.860:22692): audit_enabled=0 old=1 auid=4294967295 ses=4294967295 subj=kernel res=1
fuse init (API version 7.12)
cdrom: This disc doesn't have any tracks I recognize!
sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sr 1:0:0:0: [sr0] Sense Key : Illegal Request [current] 
sr 1:0:0:0: [sr0] Add. Sense: Logical block address out of range
end_request: I/O error, dev sr0, sector 0
Buffer I/O error on device sr0, logical block 0
sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sr 1:0:0:0: [sr0] Sense Key : Illegal Request [current] 
sr 1:0:0:0: [sr0] Add. Sense: Logical block address out of range
end_request: I/O error, dev sr0, sector 0
Buffer I/O error on device sr0, logical block 0
bkl-orbiter[1722]: segfault at 0 ip 00000034a045b1f0 sp 00007fff18239db8 error 4 in libglib-2.0.so.0.2200.2[34a0400000+e4000]

It is possible that this is because hald tries to read the disk before it is finalized, as mentioned in the Ubuntu bug report referenced above.

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Bug still present in F11 and F12 (all updates applied).

sr 2:0:0:0: [sr0] Unhandled sense code
sr 2:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sr 2:0:0:0: [sr0] Sense Key : Blank Check [current] 
sr 2:0:0:0: [sr0] Add. Sense: No additional sense information
end_request: I/O error, dev sr0, sector 0
Buffer I/O error on device sr0, logical block 0

Symptoms exactly as described in Comment #3 but with different hardware:

 sdb:
scsi 2:0:0:0: CD-ROM            PIONEER  DVD-RW  DVR-212D 1.21 PQ: 0 ANSI: 5
 sdb1
sd 1:0:0:0: [sdb] Attached SCSI disk
sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray

Additional info: To answer Luke's claim that the problem is due to a bug in "wodim", I just now attempted burning another DVD-R after replacing "wodim" with "cdrecord" 2.01.01a66 from cdrecord.berlios.de.  It still hung for a while after burning a few Megs, and I still see in the message log "kernel: cdrom: This disc doesn't have any tracks I recognize!"; but this version of cdrecord gracefully timed out after 5 minutes and stopped spinning the drive so I could eject the disk.

This gives weight to the theory that the burn failure is the kernel's fault, but the drive spinning indefinitely was wodim's fault.

I also attempted reducing the write speed from 8 to 4 per the comments on Ubuntu bug #149076.  The result was exactly the same -- another kernel interruption after writing a few MB.

I should start charging for wasted discs...

same behavior here, i.e. same kernel messages.
After the installation of FC11 some months ago I could burn CDs/DVDs what I could only do with a workaround in FC9. 

Since some time I and after the installation of many packagages (GNOME and KDE) - mostly with yum - CD/DVD-burning freezed the DVD-driver as described above or blocked even the machine when attempted from vmware / windows.
 
I remembered the workaround I used with FC9 and I'm happy that it works still with FC11 - although something in the roundabouts of HAL probably has changed since then.

I don't remember how I figured out the workaround exactly, for sure I did not fully understand what I was doing. It had to do that under FC9 during the attempt to burn a CD / DVD with k3b somebody (GNOME desktop ?) popped up a window asking what I want to do with that CD/DVD. That gave me the idea that several parties - i.e. GNOME-and KDE-mechanisms where struggling for the newly inserted CD/DVD. Hence the attempt to switch off detection of a newly inserted CD/DVD.

In FC9 the there was a file /etc/hal/fdi/policy/10-cd-dvd-burner.fdi or I copied it to that location from somewehre else.

The Workarounds consists in toggling the contents of that file for CD/DVD-Burning and for normal behavior.

You would have to adapt the file with the name of your CD/DVD burner.

/etc/hal/fdi/policy/10-cd-dvd-burner.fdi:

<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
  <device>
    <match key="storage.model" string="DVDR   PX-716A">
       <merge key="storage.cdrom.cdr" type="bool">true</merge>
       <merge key="storage.cdrom.cdrw" type="bool">true</merge>
       <merge key="storage.cdrom.dvdr" type="bool">true</merge>
       <merge key="storage.cdrom.dvdram" type="bool">true</merge>
       <merge key="storage.no_partitions_hint" type="bool">true</merge>

<!-- disable automount for CDROM Plextor PX-761A -->
       <merge key="storage.automount_enabled_hint" type="bool">true</merge>
       <merge key="storage.media_check_enabled" type="bool">false</merge>
<!-- end disalbe automount for CDROM .....-->

    </match>
  </device>
</deviceinfo>


I have two versions of that file in /etc/hal/fdi/policy: one with automount switched on and one with switched it off. 

Shell scripts copy the one or the other file to 10-cd-dvd-burner.fdi and do a 
# service haldeamon restart

I hope this is of help for you.

Still present in Fedora 13.  If I set burn speed to 4x then I can burn reliably, anything faster produces coasters.  Interestingly if I set it to 4x it burns at 8.3x or something anyway.

Supposedly here are the sources of the problems: http://cdrecord.berlios.de/private/linux-dist.html#problems

Can someone please update the Version field to 13?  I don't have access.

I can confirm the bug on FC13.

The bug is very unpredictable though. I just tried to burn a DVD through Brasero and it failed midway, and asked me to eject the DVD. I could manually eject the disc (physically pressing the button on the DVD recorder), but I got an error saying "there were errors while burning the disc". The files on the disc were in fact corrupted.

I then burnt another DVD with the same files and this time it all worked until the end, when I got the "cannot eject disc" error. Again, I could manually eject it but this time the files were OK.

I don't have any error in the terminal, at least when the burning suceeds, I only get the following when closing the software (probably completely unrelated to this problem)


(brasero:15788): GConf-CRITICAL **: gconf_client_set_string: assertion `val != NULL' failed

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.