Re: What pulls in the tray of my /dev/sr1 ?
On 2015-08-04, Thomas Schmitt <scdbackup@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
>
>
--
Reply to: