Hi, please see the referenced bug report at [1]. From looking at the code, it seems dk-disk makes the assumption that only libata is used thus breaking systems which use ide-core/ide-cd. This results in the cd-drive being unusable as it is constantly retracted when polled. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550316
Yeah, this would be good to fix (although I wish that someone would nuke the non-libata drivers). So we should probably modify devkit-disks-poller.c so it sends "/dev/sdb,0 /dev/sr0,1" to the polling process (with the second element being whether it's a cdrom drive or not). Patch welcome. FWIW, long-term I want devkit-disks-daemon to be a multi-threaded process (for many other reasons) and then the poller can just use the DevkitDisksDevice instance structure to figure how to poll the device. But that's long-term and not going to happen soon.
(In reply to comment #1) > Yeah, this would be good to fix (although I wish that someone would nuke the > non-libata drivers). So we should probably modify devkit-disks-poller.c so it > sends "/dev/sdb,0 /dev/sr0,1" to the polling process (with the second element > being whether it's a cdrom drive or not). Patch welcome. It's not as simple as that unfortunately. currently, the poller does nothing else besides opening the device repeatedly. With libata this generates a uevent when a media has been inserted (or removed). This is not the case for ide-cd. open(ing) the device with the correct set of flags (O_RDONLY | O_NONBLOCK | O_EXCL) will *not* generate a uevent if a media is present. hal used ioctl's to poke the device afair. We could do similar in the poller process, but then we would need to communicate the results back to the main process. David suggested to fake/synthesize a uevent instead or alternatively fix the kernel/ide-cd.
(In reply to comment #2) > (In reply to comment #1) > > Yeah, this would be good to fix (although I wish that someone would nuke the > > non-libata drivers). So we should probably modify devkit-disks-poller.c so it > > sends "/dev/sdb,0 /dev/sr0,1" to the polling process (with the second element > > being whether it's a cdrom drive or not). Patch welcome. > > It's not as simple as that unfortunately. > currently, the poller does nothing else besides opening the device repeatedly. > With libata this generates a uevent when a media has been inserted (or > removed). > > This is not the case for ide-cd. open(ing) the device with the correct set of > flags (O_RDONLY | O_NONBLOCK | O_EXCL) will *not* generate a uevent if a media > is present. > hal used ioctl's to poke the device afair. We could do similar in the poller > process, but then we would need to communicate the results back to the main > process. David suggested to fake/synthesize a uevent instead or alternatively > fix the kernel/ide-cd. Kay, do you think it's feasible to fix the non-libata cdrom drivers? Apparently they don't generate any uevent on media change. I think that's a bug.
(In reply to comment #2) > process. David suggested to fake/synthesize a uevent instead or alternatively Trying to fake a "change" uevent manually after inserting the media (echo "change" > /sys/class/block/hdc/uevent) makes dk-disks detect that there is a media present (a dump of dk-disks is attached) The file system probing itself does not work yet. The (Debian) udev rules contain: # probe filesystem metadata of optical drives which have a media inserted KERNEL=="sr*", ENV{ID_CDROM_MEDIA}=="?*", \ ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}=="?*", \ IMPORT{program}="/sbin/blkid -o udev -p -u noraid -O $env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET} $tempnode" # single-session CDs do not have ID_CDROM_MEDIA_SESSION_LAST_OFFSET KERNEL=="sr*", ENV{ID_CDROM_MEDIA}=="?*", \ ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}=="", \ IMPORT{program}="/sbin/blkid -o udev -p -u noraid $tempnode" i.e. they don't act on hd* devices (in my case hdc)
Created attachment 31144 [details] dk-disks dump after a fake change uevent
(In reply to comment #3) > Kay, do you think it's feasible to fix the non-libata cdrom drivers? Apparently > they don't generate any uevent on media change. I think that's a bug. I doubt we would be able to fix them. They are officially deprecated and in "let it die" mode: http://thread.gmane.org/gmane.linux.ide/43151 Distros really should just disable the old IDE stuff.
(In reply to comment #6) > (In reply to comment #3) > > > Kay, do you think it's feasible to fix the non-libata cdrom drivers? Apparently > > they don't generate any uevent on media change. I think that's a bug. > > I doubt we would be able to fix them. They are officially deprecated and in > "let it die" mode: > http://thread.gmane.org/gmane.linux.ide/43151 > > Distros really should just disable the old IDE stuff. > OK, thanks for information, Kay. It might not be worth trying to fix things here. Maybe we just make a note in NEWS that this won't work with the old IDE drivers (and maybe we just unconditionally ignore any device matching "hd*" to be on the safe side). Michael, Debian is switching completely to libata anyway, right?
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #3) > > > > > Kay, do you think it's feasible to fix the non-libata cdrom drivers? Apparently > > > they don't generate any uevent on media change. I think that's a bug. > > > > I doubt we would be able to fix them. They are officially deprecated and in > > "let it die" mode: > > http://thread.gmane.org/gmane.linux.ide/43151 > > > > Distros really should just disable the old IDE stuff. > > > > OK, thanks for information, Kay. > > It might not be worth trying to fix things here. Maybe we just make a note in > NEWS that this won't work with the old IDE drivers (and maybe we just > unconditionally ignore any device matching "hd*" to be on the safe side). > > Michael, Debian is switching completely to libata anyway, right? > It will be, but currently it still uses ide-cd. We also have the issue of partial upgrades (Debian usually tries to support using the kernel from distro-1). Good news is, I now have a patch which uses your fake uevent idea and it seems to work reasonably well. So I'll use that for the dk-disks package in Debian for now. If you are interested, I can post it here.
(In reply to comment #8) > Good news is, I now have a patch which uses your fake uevent idea and it seems > to work reasonably well. So I'll use that for the dk-disks package in Debian > for now. If you are interested, I can post it here. Sure, no harm in posting the patch - can't guarantee it goes into master though. Thanks, David
Created attachment 31285 [details] [review] add support for ide-cd cd-roms
AFAIK the upstream kernel dropped old IDE drivers recently. Either way, we really don't want to support the old IDE drivers so I'm closing this bug.
(In reply to comment #11) > AFAIK the upstream kernel dropped old IDE drivers recently. Either way, we > really don't want to support the old IDE drivers so I'm closing this bug. That is not correct as far as it goes for 2.6.34-rc1 afaics. The old ide drivers are simply marked as deprecated, but still available. So, it is still possible, that users compile their kernel using the old IDE subsystem (iirc there are still 1 or 2 drivers which are not ported yet). That said, I'm fine with keeping this patch in Debian only.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.