On 2015-08-04, Thomas Schmitt <scdbac...@gmx.net> wrote: > 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
I didn't think of that. > 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. I did think about that, but ... > ------------------------------------------------------------- > > 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. That invariable 3 minute interval seems like a (chronological) clue, but I guess it isn't. > ------------------------------------------------------------- > > 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. Makes sense. > 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 :) You too. > 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/slrnms1eh8.2bb.cu...@einstein.electron.org
