Bug 481346

what about udev-136-2 from rawhide?

and does it work if you:

Put in the empty DVD, wait until udev/hal/gnome recognized the media and then run growisofs?

Same here, Fedora 11 64 bit.  growisofs, wodim, etc, all hang as soon as udev appears to launch vol_id while burning and boom, burn freezes, disk is coastered.

udev-141-4.fc11.x86_64

During a hang, I did lsof and dicovered vol_id was accessing /dev/sr0..

cdrecord  3519     wally    3u      BLK               11,0        0t0        763 /dev/sr0
cdrecord  3521     wally    3u      BLK               11,0        0t0        763 /dev/sr0
vol_id    3555    nobody    3r      BLK               11,0        0t0        763 /dev/sr0

So then I figured out that killing udevd stopped my problem, so I turned on debug mode..

fork /sys/devices/pci0000:00/0000:00:0e.0/host0/target0:0:0/0:0:0:0 (1361)
exit /sys/devices/pci0000:00/0000:00:0e.0/host0/target0:0:0/0:0:0:0 (1361)
fork /sys/devices/pci0000:00/0000:00:0e.0/host0/target0:0:0/0:0:0:0/block/sr0 (1362)
exit /sys/devices/pci0000:00/0000:00:0e.0/host0/target0:0:0/0:0:0:0/block/sr0 (1362)
# Before it actually started burning, I hit enter to get some space..  after it failed, I see this..

fork /sys/devices/pci0000:00/0000:00:0e.0/host0/target0:0:0/0:0:0:0 (1363)
exit /sys/devices/pci0000:00/0000:00:0e.0/host0/target0:0:0/0:0:0:0 (1363)
fork /sys/devices/pci0000:00/0000:00:0e.0/host0/target0:0:0/0:0:0:0/block/sr0 (1364)

And here's ps auxwf output..

root      3506  0.0  0.0  10724  1468 pts/0    S<+  19:37   0:00              |       \_ u
devd --debug-trace
root      3547  0.0  0.0  10724   884 pts/0    S<+  19:37   0:00              |           
\_ udevd --debug-trace
nobody    3555  0.0  0.0   8096   648 pts/0    D<+  19:37   0:00              |           
    \_ /lib/udev/vol_id --export --skip-raid --offset= /dev/block/11:0

Ok, it seems to open the device writable and closes it in between somehow.
The close() causes the udev change event, which triggers the vol_id to be run.

One way to fix this would be to remove the close() from these tools.
The other one would be to add O_EXCL to the vol_id open().

I've found it happens in wodim, growisofs, brasero, etc..  All fail about the same in this regard, it writes perhaps 5-15M of data (I assume some buffer) and then it stalls.  I don't know why it doesn't happen on every system, however, as I have a similar system at work and I don't have any problems burning except for occationally the device is locked and in use, but at least in that case I'm not making coasters.

hi,

Just a query; Would this bug cause this? 

output from dmesg:

"usb 1-1: new high speed USB device using ehci_hcd and address 8
usb 1-1: New USB device found, idVendor=05e3, idProduct=0701
usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 1-1: Product: USB TO IDE
usb 1-1: configuration #1 chosen from 1 choice
scsi10 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 8
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete
scsi 10:0:0:0: CD-ROM            SONY     DVD+-RW DW-D56A  PDS7 PQ: 0 ANSI: 0
sr1: scsi3-mmc drive: 62x/24x writer cd/rw xa/form2 cdda tray
sr 10:0:0:0: Attached scsi CD-ROM sr1
sr 10:0:0:0: Attached scsi generic sg3 type 5
sr 10:0:0:0: [sr1] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sr 10:0:0:0: [sr1] Sense Key : Illegal Request [current] 
sr 10:0:0:0: [sr1] Add. Sense: Logical block address out of range
end_request: I/O error, dev sr1, sector 0
Buffer I/O error on device sr1, logical block 0
sr 10:0:0:0: [sr1] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sr 10:0:0:0: [sr1] Sense Key : Illegal Request [current] 
sr 10:0:0:0: [sr1] Add. Sense: Logical block address out of range
end_request: I/O error, dev sr1, sector 0
Buffer I/O error on device sr1, logical block 0
sr 10:0:0:0: Device offlined - not ready after error recovery
sr 10:0:0:0: rejecting I/O to offline device
sr 10:0:0:0: rejecting I/O to offline device
sr 10:0:0:0: rejecting I/O to offline device"

I'm having trouble burning media too. However, my problem persists for a USB dvd drive. I'm still burning coasters. 20 of them compared to 12 dvds :(
Tried wodim, brasero, k3b.

regards,
Ankur

well.. try it.. 

# killall udevd

and try to burn..

(In reply to comment #8)
> well.. try it.. 
> 
> # killall udevd
> 
> and try to burn..  

hi,

I did the test. It's still offlining my USB drive, so udev isnt causing it. 

regards,

Ankur

Ankur,

I'm afraid you probably need to log a separate bug, your issue seems different than this one and we wouldn't want bug creep.

As for the originally logged problem, yes, it does go away when udevd is killed on the system.  I just did several dummy burns in wodim then a real burn using growisofs and all worked fine, where otherwise (even wodim -dummy) would fail at the first 5-10M of data.

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

This is clearly a Fedora 11 issue as well, please update the version appropriately.  I can't say yet if this is an F12 issue as well, as I have not yet upgraded my system affected and do not plan to in the immediate future.

(In reply to comment #8)
> well.. try it.. 
> 
> # killall udevd
> 
> and try to burn..  

BTW, this does workaround it..

can someone not kill udevd and run instead in a terminal

# udevadm monitor

(In reply to comment #14)
> can someone not kill udevd and run instead in a terminal
> 
> # udevadm monitor  

and burn a coaster..

and paste the output here in this bug :)

Sorry I didn't notice this bug needed more info, here it is..  I have inserted a DVD, and start up cdrecord..

cdrecord dev=/dev/cdrw speed=24 driveropts=burnproof -v -dummy CD-FullImages.iso

# udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

# here it's sitting at 0 for about 10s, always does this regardless..

KERNEL[1261618355.217927] change   /devices/pci0000:00/0000:00:0e.0/host0/target0:0:0/0:0:0:0 (scsi)
KERNEL[1261618355.221408] change   /devices/pci0000:00/0000:00:0e.0/host0/target0:0:0/0:0:0:0/block/sr0 (block)
UDEV  [1261618355.223366] change   /devices/pci0000:00/0000:00:0e.0/host0/target0:0:0/0:0:0:0 (scsi)
UDEV  [1261618355.266674] change   /devices/pci0000:00/0000:00:0e.0/host0/target0:0:0/0:0:0:0/block/sr0 (block)

# burning has started, is burning..

KERNEL[1261618378.028739] change   /devices/pci0000:00/0000:00:0e.0/host0/target0:0:0/0:0:0:0 (scsi)
KERNEL[1261618378.029386] change   /devices/pci0000:00/0000:00:0e.0/host0/target0:0:0/0:0:0:0/block/sr0 (block)
UDEV  [1261618378.029575] change   /devices/pci0000:00/0000:00:0e.0/host0/target0:0:0/0:0:0:0 (scsi)

# now it has stalled at 6% and is dead..

# rpm -qa | grep udev 
udev-145-15.fc12.i686
libgudev1-145-15.fc12.i686
libudev-145-15.fc12.i686

Still makes coasters, thankfuly with kill-dash-nine works afterwards.

blkid still has to be patched to use open(2) with O_EXCL

udev-145-20.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/udev-145-20.fc12

update udev-145-20 finally works

thank you

.. can be closed ..

udev-145-20.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update udev'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/udev-145-20.fc12

udev-145-20.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.