Re: What pulls in the tray of my /dev/sr1 ?
On 04/08/15 17:06, Thomas Schmitt wrote:
> 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.
This is fair, back in the old days I recall setting a machine to burn a
disc then wandering off.
Back in the days of double and quad-speed burners which took a good 15
minutes or more, and required much of the machine's I/O throughput to
achieve the burn without a buffer underrun.
I can see though why the sudden retraction is a problem though if you
come across it randomly, then even a two hour delay would be no good.
>> 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 ?
Yeah, the implication was not yourself or anyone on this list, but we
both know there *are* users that have been guilty of the *exact* crimes
that I've described. :-)
> 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.
Indeed.
>> 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.
Is there a command that says 'retract tray after N seconds'?
Clearly the firmware has decided that it should retract the drive
without there being a command being issued at that moment, which
suggests (if it isn't an inbuilt feature) that it was told to after a
timeout by some command during start-up.
> 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.
Very strange. Not sure if it's worth switching the machine across to
sysvinit to rule out any systemd shenanigans? Not that this is
necessarily to blame, but it tends to lay itself very close to the kernel.
Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
Reply to: