Re: What pulls in the tray of my /dev/sr1 ?
Hi,
Stuart Longland wrote:
> Silly question, but why does re-loading a disc take more than 197 seconds?
It comes out (intentionally) after a backup run is complete
and went well. (See man xorriso example "Incremental backup
of a few directory trees".)
Then i'd expect it to stay out until i remove the medium.
It may well be that i am not at the machine when the backup
finishes.
> To me, a tray automatically retracting itself after being open for more
> than a minute sounds a perfectly reasonable damage-prevention measure.
One may discuss whether this is a helpful feature.
(My machine is located where a protruded tray is not in
danger to be hit by humans.)
But for me it is a fundamental goal to be in control of my
optical drives. That's why i have a Linux desktop and not
an iPhone.
Debian's kernel says it does not send commands, LG Germany
says the drive does not pull in on its own.
> To me, a tray automatically retracting itself after being open for more
> than a minute sounds a perfectly reasonable damage-prevention measure.
To be a user-grade feature it would have to work in
an equal way for all attached drives. But at my machine
it happens only with one out of five.
> it discourages the tray's misuse by the illiterate (e.g. as a
> carry handle or cup holder).
I consider myself the last remaining programmer for optical
drives in the GNU/Linux world. Andy Polyakov does not work
on dvd+rw-tools any more and Joerg Schilling of cdrtools
fell into disgrace nearly 10 years ago. cdrkit (fork-founded
by Debian) even lost its website meanwhile.
So if not i can control a burner - who else would ?
My initial reason to post the question here was the theory that
one of the new desktop's automats was to blame. They changed
with each computer i got in the last 15 years. So i hoped for
a quick solution by editing some udev rule file or a similar
remedy.
Now the riddle goes much deeper.
> I can think of two possibilities:
> 1. This is a built-in feature of the drive for the above reasons
LG support denies. My own experience agrees to this denial.
> 2. Some software on the host periodically 'polls' the drive for disc
> insertion status
Yes, the kernel usually does issue command 0x4A GET EVENT STATUS
every 2 seconds. But it is a harmless command which cannot move
the drive. Further, about a hundred of these commands are executed
before the tray gets pulled in.
Nevertheless i disabled this kernel feature by
echo 0 >/sys/block/sr1/events_poll_msecs
and now btrace(8) does not show any SCSI traffic when the tray
goes in.
Even more strange, i had two incidents of unexpected eject
meanwhile. Both happened when the drive device file got operated
by programs. Once by btrace(8), once by a run of
xorriso -devices
At least in the latter case i am sure that no 0x1B START/STOP
UNIT command was issued by libburn with Load/Eject bit set.
My best theory currently is that the drive had an eject request
from another originator while 0x1E PREVENT/ALLOW MEDIA REMOVAL
was active with Prevent bit set. When libburn closes the connection
to the drive, it issues a 0x1E with Prevent bit cleared.
This would allow the drive to perform the pending eject.
> Maybe try boot up GRUB, break into the command prompt,
Still my uptime is more important than the solution of
this riddle.
But when maintainance time comes, i will try with other OSes,
and also with pure EFI waiting for user interaction.
As last resort i will have to put the drive into a different
computer or into a USB box.
Have a nice day :)
Thomas
Reply to: