Hi, Curt wrote: > What about > sysctl -w dev.cdrom.autoclose=0
Now that's an interesting name. # sysctl dev.cdrom.autoclose dev.cdrom.autoclose = 1 Nitpickingly, i'd say that /dev/cdrom is not the mad drive sr1, but rather its iwell behaved neighbor sr0 lrwxrwxrwx 1 root root 3 Aug 3 11:28 /dev/cdrom -> sr0 Further it would not explain why btrace(8) does not report any SCSI command when the tray moves in. ------------------------------------------------------------- While digging for docs on this variable i set it to 0 and eject the tray ... Really bitten was this Gentoo user (who probably had an obtrusive periodic reader sucking on the drive): http://www.eugenemdavis.com/dvd-drive-autoclose-edev-bug Outdated and sparse http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO/sr.html Well, the drive just moved in. 3 minutes can be quite short when googling for info. ------------------------------------------------------------- By experiment i now believe that "dev.cdrom.autoclose" controls the feature that a read attempt to a CD drive causes its tray to go in. This feature stops to work with dev.cdrom.autoclose=0 and resumes to try working with dev.cdrom.autoclose=1. Well, it actually does not work because it throws at dd an error "No medium found" before the drive LED stops blinking. I.e before drive and/or udev are done with inspection. I saw this regression on about half of my Linuxes. Not on 2.6.34. It really was a good kernel for optical drives. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/4513560313179462...@scdbackup.webframe.org