Re: What pulls in the tray of my /dev/sr1 ?
Hi, > This is fair, back in the old days I recall setting a machine to burn a > disc then wandering off. My incremental backup updates shortened from 3.5 minutes to about 1.5 minutes on the new machine. Nevertheless i have reason to go for a cup of tea because it is advisable to keep the hands off the keyboard during this time. Else i risk to get copies of files truncated or padded up with zeros, because their size changed between writing of directory record and writing of content. Not to speak of files which are being written while being copied to ISO. There i'd have race conditions on the content consistency. > buffer underrun. Let's hold a moment of silence for all the misburned CDs which fell victim to insufficient feeding speed. (This time ended for me in 2003 when my Yamaha burner died and i got a Lite-on with burn-proof feature.) > >> it discourages the tray's misuse by the illiterate (e.g. as a > >> carry handle or cup holder). > > So if not i can control a burner - who else would ? > we both know there *are* users that have been guilty of the *exact* crimes > that I've described. :-) Well, the cup holder was subject to an old joke out of the series "Duemmster Anzunehmender User" (= "Dumbest Credible User"). Together with application of Wite-Out to the screen and the mouse being clicked against the window after removing the flower pots from its sill. But i think all classic professional DAUs retired meanwhile. The new DAU uses iPhone and Facebook to shoot the own foot. > Is there a command that says 'retract tray after N seconds'? Not to my knowledge. I believe to know quite well the SCSI specs for optical drives (mainly MMC, but also SBC and SPC). > Clearly the firmware has decided that it should retract the drive > without there being a command being issued at that moment This is not proven yet. btrace(8) shows no SCSI command passing through the kernel. This is not the same as no SCSI command going through the SATA controller to the drive. The boot firmware could theoretically do it on its own. > > Even more strange, i had two incidents of unexpected eject > Not sure if it's worth switching the machine across to > sysvinit to rule out any systemd shenanigans? Any system service would have to use the kernel for sending SCSI commands (or causing SCSI commands to be sent). Yesterday, when i tested my growisofs proposal for Eike Lantzsch, the usual tray dance at the end was not out-in, but out-in-out. Another drive showed only the traditional out-in move. (growisofs re-loads the tray after burning in order to make buffered i/o aware of the new disc content. Else the next session could fail because mkisofs cannot read the newly written previous session. libburn does not re-load because it does not read via buffered i/o after writing via SG_IO, because i deem the tray dance physically dangerous, and because it won't work on laptop drives anyway. The user shall re-load before using the medium for mounting or other buffered i/o.) 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/6201560348878944...@scdbackup.webframe.org
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. -- 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/55c280cc.5010...@longlandclan.yi.org
Re: What pulls in the tray of my /dev/sr1 ?
On 2015-08-04, Thomas Schmitt 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 > > -- -- 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/slrnms1eh8.2bb.cu...@einstein.electron.org
Re: What pulls in the tray of my /dev/sr1 ?
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 -- 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/4513560313179462...@scdbackup.webframe.org
Re: What pulls in the tray of my /dev/sr1 ?
On 2015-08-04, Thomas Schmitt wrote: > > 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. > What about sysctl -w dev.cdrom.autoclose=0 Or is that completely off the mark? -- 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/slrnms12d6.2bb.cu...@einstein.electron.org
Re: What pulls in the tray of my /dev/sr1 ?
On Tue, 04 Aug 2015 09:06:15 +0200 "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. Hi, I apologize for mailing you off-list, especially as I can not answer your question, but as you say in your mail yourself, there aren't many people in the Linux world who knows about these things. I have a BD-R drive and a few disks that I would like to use for backups, and was wondering what your thoughts are on the safety of this - is it a bad choice of media? What about R vs RW disks, and what file system should I choose? Again, I'm sorry about the off-list mail, but hope you would give me some quick insights as one who knows these things. :) Petter -- "I'm ionized" "Are you sure?" "I'm positive." pgpCtNgjyGqoO.pgp Description: OpenPGP digital signature
Re: What pulls in the tray of my /dev/sr1 ?
Hi, Stuart Longland wrote: > > Finally it discourages the tray's misuse by the illiterate (e.g. as a > > carry handle or cup holder). Chris Bannister wrote: > That sounds like Windoze thinking. I, personaly, would hate the idea > that the disc tray may automatically retract without notice. > Doesn't fit in with the Linux/Unix philosophy at all. Well, the often lamented benevolent desktop helpers and automats are far from being Unix-like, anyway. On my previous machine i killed hald-addonstorage for each of the attached drives. But now that systemd drilled itself to the roots of the system, i rather try to live with it and to work around any oddities. This does not mean i make myself depending on its features. My silent hope is that some day there will be a Linux for old people with no surprises and no fancy novelties. For now Jessie with fvwm2 is as near as i can get to it. (Main pain is that its kernel shows most miserable performance with multiple concurrent burn runs. LG drives can stand the decade old IDE master-slave workaround of keeping the drive buffer hungry, but my Optiarc cannot.) 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/15370560284380809...@scdbackup.webframe.org
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 -- 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/15600560287579445...@scdbackup.webframe.org
Re: What pulls in the tray of my /dev/sr1 ?
On Tue, Aug 04, 2015 at 09:06:49AM +1000, Stuart Longland wrote: > > To me, a tray automatically retracting itself after being open for more > than a minute sounds a perfectly reasonable damage-prevention measure. > > It prevents dust from settling on the tray, thus getting drawn into the > workings of the drive causing problems. It prevents the tray itself > being damaged from being bumped whilst being left out. > > Finally it discourages the tray's misuse by the illiterate (e.g. as a > carry handle or cup holder). That sounds like Windoze thinking. I, personaly, would hate the idea that the disc tray may automatically retract without notice. Doesn't fit in with the Linux/Unix philosophy at all. -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X -- 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/20150804052904.GA13670@tal
Re: What pulls in the tray of my /dev/sr1 ?
Hi Lisi, On 04/08/15 08:43, Lisi Reisz wrote: > On Monday 03 August 2015 23:39:48 Stuart Longland wrote: >> On 28/07/15 22:58, Thomas Schmitt wrote: The delay seems a bit long for such an action though. >>> >>> My measurements were all between 197 and 200 seconds. >>> With some inaccuracy because waiting 3 minutes harms my >>> reaction time. >> >> Silly question, but why does re-loading a disc take more than 197 seconds? > See the beginning of the thread: > https://lists.debian.org/1371955517162095...@scdbackup.webframe.org Yes, I saw the initial post: > one of my optical drives automatically pulls in its tray if it stands > out for a few minutes. The four others do not try to byte[sic] my fingers. > > The waiting time between manual tray eject and automatic tray load > is quite reliably 195 to 200 seconds. To me, a tray automatically retracting itself after being open for more than a minute sounds a perfectly reasonable damage-prevention measure. It prevents dust from settling on the tray, thus getting drawn into the workings of the drive causing problems. It prevents the tray itself being damaged from being bumped whilst being left out. Finally it discourages the tray's misuse by the illiterate (e.g. as a carry handle or cup holder). 195-200 seconds seems a more than generous amount of time to allow for the loading or removal of a disc from the tray, including the time needed to retrieve the disc or return the disc to its storage cover and perhaps put that cover back on a shelf. I can think of two possibilities: 1. This is a built-in feature of the drive for the above reasons, and would happen regardless of what software stack is running. (Maybe try boot up GRUB, break into the command prompt, then try the eject timing experiment.) 2. Some software on the host periodically 'polls' the drive for disc insertion status, and this triggers that particular drive to retract its tray to see if a disc has been loaded (while the others just report 'no disc'). -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- 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/55bff409.8020...@longlandclan.yi.org
Re: What pulls in the tray of my /dev/sr1 ?
On Monday 03 August 2015 23:39:48 Stuart Longland wrote: > On 28/07/15 22:58, Thomas Schmitt wrote: > >> The delay seems a bit long for such an action though. > > > > My measurements were all between 197 and 200 seconds. > > With some inaccuracy because waiting 3 minutes harms my > > reaction time. > > Silly question, but why does re-loading a disc take more than 197 seconds? > > When the tray ejects for me, it usually takes me no more than about 20 > seconds to reach down, take out whatever disc is sitting in the tray, > and/or place another disc in the tray. > > Even on laptop CD-ROM drives where you have to press the disc down onto > the spindle, it doesn't take me 3 minutes. See the beginning of the thread: https://lists.debian.org/1371955517162095...@scdbackup.webframe.org Lisi -- 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/201508032343.19082.lisi.re...@gmail.com
Re: What pulls in the tray of my /dev/sr1 ?
On 28/07/15 22:58, Thomas Schmitt wrote: >> The delay seems a bit long for such an action though. > My measurements were all between 197 and 200 seconds. > With some inaccuracy because waiting 3 minutes harms my > reaction time. Silly question, but why does re-loading a disc take more than 197 seconds? When the tray ejects for me, it usually takes me no more than about 20 seconds to reach down, take out whatever disc is sitting in the tray, and/or place another disc in the tray. Even on laptop CD-ROM drives where you have to press the disc down onto the spindle, it doesn't take me 3 minutes. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- 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/55bfedb4.7040...@longlandclan.yi.org
Re: What pulls in the tray of my /dev/sr1 ?
Hi, Frédéric Marchal wrote: > Could it be closing because the open sensor is defective or not > properly aligned or the drawer reaches the mechanical hard stop? The drive mechanics appear to be ok. It goes out when i want it and it is unused. It goes in when i want ... and after 200 seconds regardless whether i want or not. The mechanical sound is a bit shaky but most drives nowadays rattle when moving the tray. (Normally burners die from blindness and not from broken mechanics.) > The delay seems a bit long for such an action though. My measurements were all between 197 and 200 seconds. With some inaccuracy because waiting 3 minutes harms my reaction time. 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/2366655485022566...@scdbackup.webframe.org
Re: What pulls in the tray of my /dev/sr1 ?
2015-07-28 10:20 GMT+02:00 Thomas Schmitt : > Hi, > > Mike Castle wrote: >> Has the drive displayed this behavior since you turned on the machine, >> or just you just start to notice it after a while? > > I noticed it on the day when i got the machine. > > >> Ok, really maybe it only starts to happen after some specific event, >> which could be any thing you'd done while working on libburn, or some >> internal timer kicked off, or something like that. > > Some delayed action came to my mind too. > But my own experience with the MMC specs and the statement of the > manufacturer make this improbable. > > If there was a command sequence which causes such a delayed > action, then it must be in effect for more than one pull-in. > Normally i would expect that such a delayed action is not > repeated without new commands. > But my drive pulls in without any commands shown by btrace > between two experiments. Could it be closing because the open sensor is defective or not properly aligned or the drawer reaches the mechanical hard stop? Then, maybe the motor detects it as a over-current and closes the drawer the way it does when you push it manually. The delay seems a bit long for such an action though. I would expect the drive to give up much sooner if the drawer doesn't open wide enough to its liking... Frederic -- 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/caj7r-8rzxgoa2u1bvyhnamkdr9+rdcaqotbn_ukbng1twzu...@mail.gmail.com
Re: What pulls in the tray of my /dev/sr1 ?
Hi, Mike Castle wrote: > Has the drive displayed this behavior since you turned on the machine, > or just you just start to notice it after a while? I noticed it on the day when i got the machine. > Maybe it only starts to happen after it's been on for a while, and > Window machines don't stay booted long enough. Under other circumstances i would happily support this theory. > Ok, really maybe it only starts to happen after some specific event, > which could be any thing you'd done while working on libburn, or some > internal timer kicked off, or something like that. Some delayed action came to my mind too. But my own experience with the MMC specs and the statement of the manufacturer make this improbable. If there was a command sequence which causes such a delayed action, then it must be in effect for more than one pull-in. Normally i would expect that such a delayed action is not repeated without new commands. But my drive pulls in without any commands shown by btrace between two experiments. > It wasn't clear if your stability testing revolved around libburn or > not. All dangerous tests are made with burners in USB boxes. (Linux still has the best behavior when it comes to get rid of a stuck USB drive.) The burner in question is attached via SATA directly. It gets no SCSI commands from libburn, which the other four burners did not get. 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/16833554831973457...@scdbackup.webframe.org
Re: What pulls in the tray of my /dev/sr1 ?
On Sat, Jul 25, 2015 at 4:44 AM, Thomas Schmitt wrote: > > LG Germany answered quickly and stated that the drive is > not known to show this behavior under MS-Windows. > (Linux is not on their compatibility list, they say.) Has the drive displayed this behavior since you turned on the machine, or just you just start to notice it after a while? Maybe it only starts to happen after it's been on for a while, and Window machines don't stay booted long enough. Ok, really maybe it only starts to happen after some specific event, which could be any thing you'd done while working on libburn, or some internal timer kicked off, or something like that. It wasn't clear if your stability testing revolved around libburn or not. If it is, then maybe something tweaked it that wouldn't have happened just a user box (vs a developer who might be more likely to do something unusual). mrc -- 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/ca+t9imxkw0_ue_4zrd-ybdyrbsvvoul3utl-tcz2mpunmp9...@mail.gmail.com
Re: What pulls in the tray of my /dev/sr1 ?
On Monday 27 July 2015 15:17:50 Thomas Schmitt wrote: > Hi, > > i wrote: > > > btrace(8) (resp. blktrace(8)) seems to be the better > > Chris Bannister wrote: > > Excuse my ignorance, but I was wondering what 'resp.' means here. > > btrace lets blktrace do the work and blkparse tell the user. > > man 8 btrace: > "The btrace script provides a quick and easy way to do live tracing of > block devices. It calls blktrace on the specified devices and pipes > the output through blkparse for formatting. See blktrace (8) for more > in-depth information about how blktrace works." > > > Have a nice day :) Thanks, Thomas. But what does "resp." mean? Lisi -- 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/201507271546.08378.lisi.re...@gmail.com
Re: What pulls in the tray of my /dev/sr1 ?
Hi, i wrote: > > btrace(8) (resp. blktrace(8)) seems to be the better Chris Bannister wrote: > Excuse my ignorance, but I was wondering what 'resp.' means here. btrace lets blktrace do the work and blkparse tell the user. man 8 btrace: "The btrace script provides a quick and easy way to do live tracing of block devices. It calls blktrace on the specified devices and pipes the output through blkparse for formatting. See blktrace (8) for more in-depth information about how blktrace works." 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/26594554899122450...@scdbackup.webframe.org
Re: What pulls in the tray of my /dev/sr1 ?
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,122 2.235197000 16278 G N [probing-thread] 11,123 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,124 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,125 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,122 1266874889.706979665 9753 G N [cdrom_id] 11,123 1266874889.706979928 9753 I N 0 (1e 00 00 00 01 00 ..) [cdrom_id] 11,124 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
Re: What pulls in the tray of my /dev/sr1 ?
On 2015-07-24, Thomas Schmitt wrote: > Hi, > > one of my optical drives automatically pulls in its tray if it stands > out for a few minutes. The four others do not try to byte my fingers. > > The waiting time between manual tray eject and automatic tray load > is quite reliably 195 to 200 seconds. > > Optical driving is one of my sports. So i am sure that it doesn't do > this on its own. It rather must get a SCSI command START/STOP UNIT > with Start bit and Load/Eject bit. > > Now i riddle from where this command might come and why only /dev/sr1 > is affected but not /dev/sr0, sr2, sr3, sr4. > > I killed all processes of udisks2 and gvfs, but am not brave enough > to kill systemd-udevd. > > udevadm monitor -k -u -p > does not show any event at the time when the tray moves in. > I also unpacked the initrd and inspected > /lib/udev/rules.d/60-persistent-storage.rules. > The ones which call blkid would be suspects. But they seem to rely > on the presence of CDROM content info, which cannot be known while > the tray is out. > > crontab says that neither desktop user nor superuser have cron jobs. > atq says there is no at-job while the tray is out. > > > Any idea what automat gropes my cheap DVD drive and ignores > all my expensive Blurays ? > > > Have a nice day :) > > Thomas 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. -- 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/slrnmra4p4.4r5.alanjg@archduke.router
Re: What pulls in the tray of my /dev/sr1 ?
Hi,
Nicolas George:
> I have read that some windows install images are available gratis.
Before i do that i dismantle my new computer.
But there are enough old Linux ISOs in my regression test vault.
> Trying
> one (without actually installing) would be a good way of proving that the LG
> support is spreading nonsense.
Currently i believe the statement that it is not an intentional
feature of the whole series.
The answer (in german language) was qualified and detailed.
It matches my own opinion at the time i started this thread.
I.e. something like an obtrusive automounter would be to blame.
This does not outrule that the individual drive is mad.
I had funny incidents with libburn users and with own drives.
E.g. i can make my Optiarc BD-5300S deformat BD-RE media just
by showing it a CD-RW. It stays in this mood until i give its
USB box a power-off.
> > mount: unknown filesystem type 'efivarfs'
> Assuming the system actually has a UEFI firmware, that means your system is
> booted in BIOS compatibility ("lecacy") mode rather than with a UEFI
> bootloader.
Ahum.
I did not do the fundamental netinstall myself but rather
got it debianized from my hardware provider.
Mainboard https://www.asus.com/Motherboards/P9D_WS/
features "New UEFI BIOS".
The system disk has an MBR partition table. No partition of
type 0xef to see. /boot is sda2 of type 0x83 "Linux".
/boot/EFI is sda1, 0x06 "FAT16", 953 MB, totally empty.
So yes, my system does not boot via UEFI.
Might be that the "New UEFI BIOS" is bored by running in
legacy mode.
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/32097555126350758...@scdbackup.webframe.org
Re: What pulls in the tray of my /dev/sr1 ?
Le septidi 7 thermidor, an CCXXIII, Thomas Schmitt a écrit :
> I will also try a non-Debian rescue system for BIOS.
I have read that some windows install images are available gratis. Trying
one (without actually installing) would be a good way of proving that the LG
support is spreading nonsense.
> At Linux runtime there seems to be few opportunity to
> access EFI. According to
> https://firmware.intel.com/blog/accessing-uefi-variables-linux
> and my kernel version 3.16.0-4-amd64, i should have the modern
> efivarfs. lsmod reports
> efivarfs 12902 0
> but there is no directory /sys/firmware/efi.
> If i do
>
> mkdir /mnt/efivars
> mount -t efivarfs none /mnt/efivars
>
> i get
>
> mount: unknown filesystem type 'efivarfs'
Assuming the system actually has a UEFI firmware, that means your system is
booted in BIOS compatibility ("lecacy") mode rather than with a UEFI
bootloader.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
Re: What pulls in the tray of my /dev/sr1 ?
Hi, i wrote: > > LG Germany answered quickly and stated that the drive is > > not known to show this behavior under MS-Windows. Lisi Reisz wrote: > Well, it was a nice idea while it lasted. And worth testing. Your theory is not totally ruled out yet. It is just hard to test because to surely distinguish it from the EFI theory i would have to put the drive into a BIOS computer and check whether the behavior changes. Currently i am not ready to shut down the machine. But when i do, i will make some experiments and maybe even break out the screw driver. (Being entirely softwerker this is not my usual habit.) Nicolas George wrote: > You could test if the observed behaviour happens when the computer is on the > UEFI boot menu or the GRUB menu. That will be the first stage of testing, yes. If it is an EFI runtime feature it might be not present before GRUB2 starts. I will also try a non-Debian rescue system for BIOS. Any constellation were the drive tray stays out will free LG drive firmware from suspicion. At Linux runtime there seems to be few opportunity to access EFI. According to https://firmware.intel.com/blog/accessing-uefi-variables-linux and my kernel version 3.16.0-4-amd64, i should have the modern efivarfs. lsmod reports efivarfs 12902 0 but there is no directory /sys/firmware/efi. If i do mkdir /mnt/efivars mount -t efivarfs none /mnt/efivars i get mount: unknown filesystem type 'efivarfs' 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/3198131709290...@scdbackup.webframe.org
Re: What pulls in the tray of my /dev/sr1 ?
Le septidi 7 thermidor, an CCXXIII, Thomas Schmitt a écrit : > LG Germany answered quickly and stated that the drive is > not known to show this behavior under MS-Windows. > (Linux is not on their compatibility list, they say.) You could test if the observed behaviour happens when the computer is on the UEFI boot menu or the GRUB menu. Regards, -- Nicolas George signature.asc Description: Digital signature
Re: What pulls in the tray of my /dev/sr1 ?
On Saturday 25 July 2015 12:44:47 Thomas Schmitt wrote: > Hi, > > LG Germany answered quickly and stated that the drive is > not known to show this behavior under MS-Windows. > (Linux is not on their compatibility list, they say.) :-( Well, it was a nice idea while it lasted. And worth testing. I'd swear that sometimes gremlins get into our computers. Lisi -- 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/201507251256.56780.lisi.re...@gmail.com
Re: What pulls in the tray of my /dev/sr1 ?
Hi, LG Germany answered quickly and stated that the drive is not known to show this behavior under MS-Windows. (Linux is not on their compatibility list, they say.) 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/19720555113875147...@scdbackup.webframe.org
Re: What pulls in the tray of my /dev/sr1 ?
Hi, Lisi Reisz wrote: > Yes, I rather wondered whether it was the drive itself. Currently your theory has good chances to be true. Only the theory about EFI looks like a valid competitor. 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/19932555114012280...@scdbackup.webframe.org
Re: What pulls in the tray of my /dev/sr1 ?
Hi, The Wanderer wrote: > * The BIOS, or (more likely in a modern system) UEFI. Good point. I forgot that my new machine possibly runs two OSes simultaneously: EFI and Linux. But my experience with UEFI is restricted to creating the entry points in bootable ISOs. (The circumstances of my migration to the new machine prevented any playing with its boot OS. The old one died one week before the new one arrived.) > * The firmware on the optical drive itself. I now contacted the manufacturer LG. > Neither is likely to be nearly as accessible, Any proposals how to inspect remaining activities of EFI after the Linux kernel is up ? 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/19948555112634583...@scdbackup.webframe.org
Re: What pulls in the tray of my /dev/sr1 ?
On Saturday 25 July 2015 12:07:29 The Wanderer wrote: > * The firmware on the optical drive itself. Yes, I rather wondered whether it was the drive itself. https://lists.debian.org/201507241208.16237.lisi.re...@gmail.com Lisi -- 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/201507251222.34749.lisi.re...@gmail.com
Re: What pulls in the tray of my /dev/sr1 ?
On 07/25/2015 at 07:06 AM, Thomas Schmitt wrote: > Hi, > > i stumbled over btrace(8) which lists the SCSI commands by > blktrace, blkparse, and /sys/kernel/debug. > > The only traffic is every 2 seconds a 0x4A GET EVENT STATUS > NOTIFICATION command in "Polled" operational mode, and > notification class request "Media". I did not find out yet > how to get to view the drive's replies. > In summary there seems to be really no initiator in > the operating system for the tray movements. > Very astonishing. As far as I can see, this leaves two possible places to look: * The BIOS, or (more likely in a modern system) UEFI. * The firmware on the optical drive itself. Neither is likely to be nearly as accessible, on this level, as the OS or its userspace, but I can't see where else you could look at this point. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: What pulls in the tray of my /dev/sr1 ?
Hi, i stumbled over btrace(8) which lists the SCSI commands by blktrace, blkparse, and /sys/kernel/debug. The only traffic is every 2 seconds a 0x4A GET EVENT STATUS NOTIFICATION command in "Polled" operational mode, and notification class request "Media". I did not find out yet how to get to view the drive's replies. 11,102 2.047952134 0 C R (4a 01 00 00 10 00 00 00 08 00 ..) [0] 11,114 2.047580736 19046 G N [kworker/1:3] 11,115 2.047582462 19046 I R 8 (4a 01 00 00 10 00 00 00 08 00 ..) [kworker/1:3] 11,116 2.047582648 19046 D R 8 (4a 01 00 00 10 00 00 00 08 00 ..) [kworker/1:3] (I wonder why C with the older timestamp is listed before G, I, and D.) The other drives get the same treatment. I tested that e.g. xorriso's SCSI commands are reported. So either the drive really pulls in the tray on its own, or it is annoyed by a hundred 0x4A commands and finally wants to give the caller an answer. https://lwn.net/Articles/423619/ and Michael Biebl's previous proposal brought me to # cat /sys/block/sr1/events_poll_msecs 2000 # echo 0 >/sys/block/sr1/events_poll_msecs # cat /sys/block/sr1/events_poll_msecs 0 This silences the 0x4A commands. But the drive tray still gets pulled in. Shortly after, btrace reports 11,110 0.0 0 m N cfq20698S / put_queue A second experiment pulled in the tray without any btrace message. In summary there seems to be really no initiator in the operating system for the tray movements. Very astonishing. 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/95010799137...@scdbackup.webframe.org
Re: What pulls in the tray of my /dev/sr1 ?
Hi, Michael Biebl wrote: > >> /lib/udev/rules.d/60-block.rules I wrote: > > There is no such file in my still quite vanilla 8.1. Michael Biebl wrote: > Ok, it wasn't clear which Debian version you were using. I was referring > to unstable/testing. Sorry, i mentioned it in my other thread about alpine. (I come from older SuSE but already ran Debian 6 on another machine. So i know about apt-get install.) > Reloading the udev rules won't unset that sysfs parameter. The easiest > is to reboot. Uptime 38 days. I am testing long term stability. Looks fine so far. > You should be able to reset that parameter though via > echo 0 > /sys/module/block/parameters/events_dfl_poll_msecs As superuser: # cat /sys/module/block/parameters/events_dfl_poll_msecs 2000 # echo 0 >/sys/module/block/parameters/events_dfl_poll_msecs # cat /sys/module/block/parameters/events_dfl_poll_msecs 0 So far so good $ eject /dev/sr1 ; date Fri Jul 24 19:33:42 CEST 2015 and waiting until about 19:37 ... Darn. It pulled in after 197 seconds. 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/21593555176068898...@scdbackup.webframe.org
Re: What pulls in the tray of my /dev/sr1 ?
Am 24.07.2015 um 16:37 schrieb Thomas Schmitt:
> Hi,
>
> Michael Biebl wrote:
>> Not sure if the in-kernel polling enabled in
>> /lib/udev/rules.d/60-block.rules
>> triggers this specific behaviour for this particular drive.
>>
>> Can you comment out the following two lines:
>> ACTION=="add", SUBSYSTEM=="module", KERNEL=="block",
>> ATTR{parameters/events_dfl_poll_msecs}=="0", \
>> ATTR{parameters/events_dfl_poll_msecs}="2000"
>
> There is no such file in my still quite vanilla 8.1.
Ok, it wasn't clear which Debian version you were using. I was referring
to unstable/testing.
> I find events_dfl_poll_msecs in
> /lib/udev/rules.d/60-persistent-storage.rules
>
> # enable in-kernel media-presence polling
> ACTION=="add", SUBSYSTEM=="module", KERNEL=="block",
> ATTR{parameters/events_dfl_poll_msecs}=="0",
> ATTR{parameters/events_dfl_poll_msecs}="2000"
> ACTION=="add", ATTR{removable}=="1", ATTR{events_poll_msecs}=="-1",
> ATTR{events_poll_msecs}="2000"
>
> Ok, i commented out the last two of above three lines
> and stored the file. No change in behavior.
>
> Do i have anything to do in order to activate the rule ?
> udevadm control --reload ? udevadm trigger ?
> (Reboot will be very inconvenient.)
Reloading the udev rules won't unset that sysfs parameter. The easiest
is to reboot.
You should be able to reset that parameter though via
echo 0 > /sys/module/block/parameters/events_dfl_poll_msecs
signature.asc
Description: OpenPGP digital signature
Re: What pulls in the tray of my /dev/sr1 ?
Hi,
Michael Biebl wrote:
> Not sure if the in-kernel polling enabled in
> /lib/udev/rules.d/60-block.rules
> triggers this specific behaviour for this particular drive.
>
> Can you comment out the following two lines:
> ACTION=="add", SUBSYSTEM=="module", KERNEL=="block",
> ATTR{parameters/events_dfl_poll_msecs}=="0", \
> ATTR{parameters/events_dfl_poll_msecs}="2000"
There is no such file in my still quite vanilla 8.1.
I find events_dfl_poll_msecs in
/lib/udev/rules.d/60-persistent-storage.rules
# enable in-kernel media-presence polling
ACTION=="add", SUBSYSTEM=="module", KERNEL=="block",
ATTR{parameters/events_dfl_poll_msecs}=="0",
ATTR{parameters/events_dfl_poll_msecs}="2000"
ACTION=="add", ATTR{removable}=="1", ATTR{events_poll_msecs}=="-1",
ATTR{events_poll_msecs}="2000"
Ok, i commented out the last two of above three lines
and stored the file. No change in behavior.
Do i have anything to do in order to activate the rule ?
udevadm control --reload ? udevadm trigger ?
(Reboot will be very inconvenient.)
The interval of of 2000 ms is only 1/100 of the interval
which i perceive. (It's not a periodic interval but always
starts when i eject the tray.)
I ran
udevadm info -n /dev/sr1
which yields with the self-retracting drive:
---
P: /devices/pci:00/:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sr1
N: sr1
S: disk/by-id/ata-HL-DT-ST_DVDRAM_GH24NSC0_K8AF33A3528
S: disk/by-id/wwn-0x50014800
E: DEVLINKS=/dev/disk/by-id/ata-HL-DT-ST_DVDRAM_GH24NSC0_K8AF33A3528
/dev/disk/by-id/wwn-0x50014800
E: DEVNAME=/dev/sr1
E:
DEVPATH=/devices/pci:00/:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sr1
E: DEVTYPE=disk
E: ID_ATA=1
E: ID_ATA_SATA=1
E: ID_ATA_SATA_SIGNAL_RATE_GEN1=1
E: ID_BUS=ata
E: ID_CDROM=1
E: ID_MODEL=HL-DT-ST_DVDRAM_GH24NSC0
E:
ID_MODEL_ENC=HL-DT-ST\x20DVDRAM\x20GH24NSC0\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
E: ID_REVISION=LK00
E: ID_SERIAL=HL-DT-ST_DVDRAM_GH24NSC0_K8AF33A3528
E: ID_SERIAL_SHORT=K8AF33A3528
E: ID_TYPE=cd
E: ID_WWN=0x50014800
E: ID_WWN_WITH_EXTENSION=0x50014800
E: MAJOR=11
E: MINOR=1
E: SUBSYSTEM=block
E: TAGS=:seat:systemd:uaccess:
E: UDISKS_PRESENTATION_NOPOLICY=0
E: USEC_INITIALIZED=90966
---
In comparison to the non-self-retracting sr0:
---
P: /devices/pci:00/:00:1f.2/ata3/host2/target2:0:0/2:0:0:0/block/sr0
N: sr0
L: -100
S: cdrom
S: cdrw
S: disk/by-id/ata-HL-DT-ST_BDDVDRW_GGC-H20L_K5C88LJ1616
S: dvd
S: dvdrw
E: DEVLINKS=/dev/cdrom /dev/cdrw
/dev/disk/by-id/ata-HL-DT-ST_BDDVDRW_GGC-H20L_K5C88LJ1616 /dev/dvd /dev/dvdrw
E: DEVNAME=/dev/sr0
E:
DEVPATH=/devices/pci:00/:00:1f.2/ata3/host2/target2:0:0/2:0:0:0/block/sr0
E: DEVTYPE=disk
E: ID_ATA=1
E: ID_ATA_FEATURE_SET_PM=1
E: ID_ATA_FEATURE_SET_PM_ENABLED=1
E: ID_ATA_SATA=1
E: ID_ATA_SATA_SIGNAL_RATE_GEN1=1
E: ID_BUS=ata
E: ID_CDROM=1
E: ID_CDROM_BD=1
E: ID_CDROM_CD=1
E: ID_CDROM_CD_R=1
E: ID_CDROM_CD_RW=1
E: ID_CDROM_DVD=1
E: ID_CDROM_DVD_PLUS_R=1
E: ID_CDROM_DVD_PLUS_RW=1
E: ID_CDROM_DVD_PLUS_R_DL=1
E: ID_CDROM_DVD_R=1
E: ID_CDROM_DVD_RAM=1
E: ID_CDROM_DVD_RW=1
E: ID_CDROM_HDDVD=1
E: ID_MODEL=HL-DT-ST_BDDVDRW_GGC-H20L
E:
ID_MODEL_ENC=HL-DT-ST\x20BDDVDRW\x20GGC-H20L\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
E: ID_REVISION=1.03
E: ID_SERIAL=HL-DT-ST_BDDVDRW_GGC-H20L_K5C88LJ1616
E: ID_SERIAL_SHORT=K5C88LJ1616
E: ID_TYPE=cd
E: MAJOR=11
E: MINOR=0
E: SUBSYSTEM=block
E: TAGS=:seat:systemd:uaccess:
E: UDISKS_PRESENTATION_NOPOLICY=0
E: USEC_INITIALIZED=79780
---
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/30869555181819417...@scdbackup.webframe.org
Re: What pulls in the tray of my /dev/sr1 ?
Am 24.07.2015 um 13:48 schrieb Thomas Schmitt:
> But here i suspect to be victim of some fancy new feature
> of udev or kernel. My list of usual suspects is empty now.
> So i ask for new ones.
Not sure if the in-kernel polling enabled in /lib/udev/rules.d/60-block.rules
triggers this specific behaviour for this particular drive.
Can you comment out the following two lines:
ACTION=="add", SUBSYSTEM=="module", KERNEL=="block",
ATTR{parameters/events_dfl_poll_msecs}=="0", \
ATTR{parameters/events_dfl_poll_msecs}="2000"
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Re: What pulls in the tray of my /dev/sr1 ?
Hi, Lisi Reisz wrote: > I would expect it to be the DVD drive itself, That would be the first one to do this since i began to operate them on SCSI level in 2006. (I'm developer of libburn.) The drive is new. An LG GH24NSC0. Regrettably it is built-in to the computer. So i cannot easily make experiments with brainless power. > turn the computer on, it will shut almost straight away. That's a very different situation. Most drives pull in when power is switched on. Then the boot firmware and the kernel might be curious enough to issue START/STOP UNIT. But here i suspect to be victim of some fancy new feature of udev or kernel. My list of usual suspects is empty now. So i ask for new ones. 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/13931555159240180...@scdbackup.webframe.org
Re: What pulls in the tray of my /dev/sr1 ?
On Friday 24 July 2015 11:31:52 Thomas Schmitt wrote: > Any idea what automat gropes my cheap DVD drive and ignores > all my expensive Blurays ? I would expect it to be the DVD drive itself, designed to prevent people forgetting to shut it. Don't forget that it needs power to do anything, so if you open it with the computer powered off it won't shut. But I'll bet if you do that, then turn the computer on, it will shut almost straight away. Lisi -- 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/201507241208.16237.lisi.re...@gmail.com
