Re: What pulls in the tray of my /dev/sr1 ?

["Thomas Schmitt" <scdbackup@gmx.net>]

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