Hi, Alan Greenberger wrote: > You might try > lsof -r 1 /dev/sr0 > If you are lucky it will catch something. If I type eject a few times, > it will catch one.
btrace(8) (resp. blktrace(8)) seems to be the better inspector in this case. It shows i/o traffic down to SCSI commands and there is no race condition involved. If it does not lie at me then no SCSI command is sent to the drive from userland or kernel. (After stopping harmless media event polling by the kernel.) I riddle, though, about this command 11,1 2 2 2.235197000 16278 G N [probing-thread] 11,1 2 3 2.235198766 16278 I R 512 (85 08 2e 00 00 00 01 00 00 00 00 00 00 00 a1 00 ..) [probing-thread] 11,1 2 4 2.235198941 16278 D R 512 (85 08 2e 00 00 00 01 00 00 00 00 00 00 00 a1 00 ..) [probing-thread] 11,1 2 5 2.236231372 0 C R (85 08 2e 00 00 00 01 00 00 00 00 00 00 00 a1 00 ..) [2] I cannot find command 0x85 among SPC, SBC, or MMC commands. Wikipedia has it as ATA PASS-THROUGH(16). Obviously the contrary of the ATA command which transports SCSI commands. It seems very inappropriate to try executing ATA commands on an optical drive. Well, my other drives get it too. Quite suspicious is that btrace has hard-to-reproduce side effects on the drive tray. I had one eject on start of btrace /dev/sr1 (could not see the 0x1B command which is supposed to do that). About every second run of btrace keeps the loaded tray from being manually ejected. Obviously by command 0x1E PREVENT ALLOW MEDIA REMOVAL like this: 11,1 2 2 1266874889.706979665 9753 G N [cdrom_id] 11,1 2 3 1266874889.706979928 9753 I N 0 (1e 00 00 00 01 00 ..) [cdrom_id] 11,1 2 4 1266874889.706980210 9753 D N 0 (1e 00 00 00 01 00 ..) [cdrom_id] No process 9753 to see. "cdrom_id" sounds like an udev action. The timestamp 1266874889 is far higher than my uptime. Manual tray ejection is then delayed until btrace ends. This blocking of manual ejection does not happen without btrace running. Possibly the method by which blktrace attaches to the device file causes a little avalanche of kernel and/or udev activities. --------------------------------------------------------- Whatever, under the assumption that blktrace does not lie about non-traffic at the time of the unwanted pull-in: Since the system was booted via BIOS emulation, i do not see much responsibility of Debian's boot equipment to disable any EFI runtime services which might send SCSI commands without the knowledge of the Linux kernel. So for now, it seems to be a hardware peculiarity. Either of the motherboard ASUS P9D WS or of the drive LG GH24NSC0. I will learn more when there is an occasion to split both apart. (I silently apologize for any secret hostile thoughts towards udev, systemd, usdisks2, gvfs, and alike.) Have a nice day :) 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/21154554747662516...@scdbackup.webframe.org
