subject:"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 ?

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 ?

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 ?

2015-08-04 Thread Petter Adsen

On Tue, 04 Aug 2015 09:06:15 +0200
Thomas Schmitt scdbac...@gmx.net 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: Backup on BD-R. Was: What pulls in the tray of my /dev/sr1 ?

2015-08-04 Thread Joel Roth

Thomas Schmitt wrote:
 I use BD-R and BD-RE for multi-volume backups with scdbackup,
 and for multi-session backups with xorriso directly.
 
 scdbackup
   http://scdbackup.sourceforge.net/main_eng.html
 splits large backup areas into file collections which
 fit on single media:
(...)
   http://scdbackup.sourceforge.net/README

Very thoroughly documented. Without actually running
the software, it looks like great work!


-- 
Joel Roth
  


-- 
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/20150804093839.GA8019@sprite

Backup on BD-R. Was: What pulls in the tray of my /dev/sr1 ?

Hi,

 I apologize for mailing you off-list

Well, i got it with these headers
  To: debian-user@lists.debian.org
  Resent-From: debian-user@lists.debian.org

The mail address  scdbac...@gmx.net  is public for support of
optical drives, ISO 9660, and backup in general. If your topic
is of public interest in this field, you may also write to
bug-xorr...@gnu.org .

But i'd say that backup on BD is on topic for debian-user, too.


 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

Single session on BD-R is at least as reliable as on
DVD-R or DVD+R. Multi-session has its limitations. Depending
on the drive one may only write about 120 sessions.
My youngest BD drive (LG BH16NS40, 20 months old) meanwhile
reliably spoils the fourth or fifth session of a BD-R. In the
past it did up to 130 sessions.

You have to be aware that old BD burners might be unable
to write to new BD-R media. Whatever, if the burn run succeeds
without error and checkreading confirms this success, then
the burner should work fine with other media of the same
product generation.

When buying media, better stay away from BD-R labeled as LTH
(Low-To-High reflectivity change on burning). They are likely
to be not readable by many drives.


 What about R vs RW disks,

It's BD-RE, not BD-RW. Their reliability is good.
Speed is a bit low, especially if the hardware Defect Management
stays enabled. This feature checkreads immediately after writing
a buffer-full of data. If the read quality is poor, then it
retries writing. If still bad, then it writes to the Spare Area
and the affected block addresses get redirected there.

BD-R can be formatted to perform Defect Management, too.
I prefer to use them without and to rather apply my own
checkreading after the burn run is finished.


 and what file system should I choose?

I use ISO 9660 with extensions RockRidge (for POSIX
attributes) and AAIP (for ACL and xattr).

With BD-R it must be a sequential write-once filesystem like
ISO 9660, sequential UDF, or a sequential archiver format
like tar or cpio.
You may also bring up a read-write filesystem in an image
file on hard disk and burn it to BD when its content is
complete.

With BD-RE you may use read-write filesystems like FAT or
ext{2,3,4}. Performance is sluggish because of Defect Management
and because of poor random-access addressing performance.
Expect not more than 2 or 3 MB/s of write throughput on
a 2x BD-RE (2xBD = 9 MB/s nominally).

I use BD-R and BD-RE for multi-volume backups with scdbackup,
and for multi-session backups with xorriso directly.

scdbackup
  http://scdbackup.sourceforge.net/main_eng.html
splits large backup areas into file collections which
fit on single media:
  sdvdbackup -bd /my/fat/tree
It can use xorriso or genisoimage for production of ISO 9660,
and growisofs, cdrskin, or xorriso for burning.
Checkreading by
  time sdvdbackup_verify /dev/sr0 -auto_end
This software needs some initial configuration
  http://scdbackup.sourceforge.net/examples.html#configure_dvd
(BD counts as DVD in this context. You will get disabled
 Defect Management for all blocks after the first 100 MB.)

xorriso can read the ISO 9660 directory tree on BD, determine
the differences to file trees on hard disk, and burn an
add-on session which brings those differences into the
ISO 9660 filesystem.
See man xorriso, example Incremental backup of a few
directory trees. (One should maintain such a command in
a shell script for easy repetition and for adding detail
improvements.)

Defect Management can be disabled after the first 100 MB
by command
  -stream_recording 100m
(Or by -stream_recording off for total disabling.)
I leave Defect Management on for the first 100 MB because
the superblock and the directory tree usually fit into
this range. Bad file content is easier to handle than
bad metadata.
(The overall benefit of Defect Management is quite limited.
 If the medium is really bad, then it will fail earlier than
 without Defect Management. After much clonking and blinking.)



scdbackup is not available as Debian package, because
of its peculiar configuration.
  http://scdbackup.sourceforge.net/scdbackup-0.9.2.tar.gz
See
  http://scdbackup.sourceforge.net/README
(or the README file in the tarball), chapters Planning
and Installation.

xorriso is available in an old but sufficient version on Debian:
  apt-get install xorriso
or in its newest version as source tarball from
  http://www.gnu.org/software/xorriso/#download
which depends only on vanilla equipment for software development
and system runtime. I.e. gcc, ld, libc, libpthread.
(Current tarball is
  http://www.gnu.org/software/xorriso/xorriso-1.4.0.tar.gz
)



 hope you would give me
 some quick insights as one who knows these things. :)

I think i failed to comply to the wish about quick.

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

2015-08-04 Thread Curt

On 2015-08-04, Thomas Schmitt scdbac...@gmx.net 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 ?

2015-08-04 Thread Curt

On 2015-08-04, Thomas Schmitt scdbac...@gmx.net 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 ?

2015-08-03 Thread Stuart Longland

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 ?

2015-08-03 Thread Stuart Longland

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 ?

2015-08-03 Thread Lisi Reisz

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 ?

2015-08-03 Thread Chris Bannister

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: Pitfalls of german-english dictionaries. Was: What pulls in the tray of my /dev/sr1 ?

2015-07-28 Thread Joel Rees

On Tue, Jul 28, 2015 at 3:32 PM, Thomas Schmitt scdbac...@gmx.net wrote:
Hi,

[...]
Here is a nice spectrum of beziehungsweise and its english
counterparts.
http://www.linguee.com/german-english/translation/beziehungsweise.html
Some respectively are among them. Some are quite near to
my (mislead) use of it.

They seem nearer to you than to me, I think.

I instinctively look for a pair of lists of things to map when I see
respectively in these contexts. Hovering the cursor over the
ellipses (sp?) brings up the context, and the two lists were present
in every case I checked.

In respect of ___ or respecting may come close to the meaning in
some cases. Or not.

... or rather ... seems to work in the present case, but I notice a
number of places in that list of examples that it would not. (or
rather just does not map to and.)

I think beziehungsweise bears some similarity to the logical
implication operator.

This may be one time that Google translate was useful.

It helps from time to time. (But how trustworthy is it,
given the miserable state of german-english online
dictionaries ?)

Clues, yes, translations, no.

Linguee looks really useful for studying the deeper semantics of
German. I'll have to check the Japanese and Spanish texts, too. Thanks
for pointing it out.

--
Joel Rees

Be careful when you look at conspiracy.
Arm yourself with knowledge of yourself, as well:
http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html

--
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/caar43ipqxnthkfyhbbgmshmg25390huxrvbn6rnad+igfis...@mail.gmail.com

Re: Pitfalls of german-english dictionaries. Was: What pulls in the tray of my /dev/sr1 ?

On Tuesday 28 July 2015 05:23:48 Joel Rees wrote:
 Hi, Lisi,

Hi, Joel,

 If I'm still in your blacklists, it won't help for me to comment, but ...

No, you're not.  I'm surprised that it mattered enough for you to remember!

 2015/07/28 6:46 Lisi Reisz lisi.re...@gmail.com:
  On Monday 27 July 2015 16:53:14 Thomas Schmitt wrote:
   The problem with defending the purity of the English language is that
English is about as pure as a cribhouse whore. We don't just borrow

 words;

   on occasion, English has pursued other languages down alleyways to beat
   them unconscious and rifle their pockets for new vocabulary.  -- James

 D.

   Nicoll
  
   So:
   bzw. is a really useful word. Get it and use it whenever
   you want to point to a fork in your thoughts.
 
  I'm not defending the purity of anything.  The English language is a
  right mish-mash of Latin, French, German, Norse, Hindi etc..  But

 none-the-less, it

  improves comprehensibility if one sticks roughly to the language in which

 one

  is speaking/writing.
 
  If you do use foreign words, you need to be willing to explain them when
  asked, as you were by Chris.
 
  I'm still not clear on the meaning of bzw,

 I'm guessing it was in the part you cut out, the beziehungsweise that he
 was translating as respectively, abbrevitated to resp.

I couldn't follow.  Yes, I knew that bzw was beziehungsweise, and that he 
translated it to respectively, which he chose to abbreviate to resp, thus 
from my point of view muddying the waters still further.

  nor in what way its meaning differs
  from or.  So I shall continue to use or. ;-)
 
  Lisi

 With a little help from google translate, or rather.

 I'd go with the idea suggested on the stackexchange post he referenced,
 that, in other contexts, the English grammar puts the beziehungswiese
 after two lists which are being associated:

 ... translating breakfast, lunch, and dinner
 as asa-gohan, o-hiru, and yuu-han, _respectively_.

 (with apologies for potentally muddying the waters further by using
 Japanese in my example).

 And, in this case, namely doesn't work other.

 This may be one time that Google translate was useful.

Thanks, Joel.  What you have said is clear, and respectively makes sense 
there.  But it still doesn't make sense to me of what Thomas originally 
said.  resp remains a _foreign_ word of English origin.

Since we are referring now to Japanese, when my granddaughter was a toddler 
she often asked for dako as a noun, or issued dako! as a command.  We 
accepted the Japanese simply because it was untranslatable.  We used the 
Japanese word even when speaking English, and she bemused my Israeli cousins 
by announcing loudly that Grandma needs dako when I had pneumonia and was 
feeling very ill.

Nonetheless, no matter how useful the word, I have never used it in English to 
a non-Japanese speaking child. 

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/201507280936.11395.lisi.re...@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
 snarkWindow machines don't stay booted long enough/snark.

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: Pitfalls of german-english dictionaries. Was: What pulls in the tray of my /dev/sr1 ?

On Tuesday 28 July 2015 07:32:54 Thomas Schmitt wrote:
 I was not aware that resp. is wrong
 in that context.

The main problem is that it isn't an English word, so one can't look it up in 
a dictionary.  And Chris's question was quite clear!!

I obviously have a mental block for bzw.  I'll make another attempt later when 
I've had a cup of tea. ;-)

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/201507280940.03134.lisi.re...@gmail.com

Re: Pitfalls of german-english dictionaries. Was: What pulls in the tray of my /dev/sr1 ?

Hi,

Joel Rees wrote:
 I instinctively look for a pair of lists of things to map when I see
 respectively in these contexts.

Now that i know the correct meaning i do understand why
the german-ish use appears so odd to native speakers.

That's why i deem the main translation flatly false:
respectively is nearly never beziehungsweise.

But even my old paper dictionary Langenscheidts
Handwoerterbuch Englisch has them as first proposal and the
correct meanings only as second ones:
or rather for beziehungsweise.
in dieser Reihenfolge (= in this sequence) for respectively.

The lure for error is even more appealing because both words
have an abbreviation: resp. and bzw..


 I think beziehungsweise bears some similarity to the logical
 implication operator.

This impression would be wrong. Among logical operators it
is indeed nearest to or. Not so much to exor.
Somehow it resembles a diffuse if-then:
If you like to view it differently then it can also be
 seen as this given alternative.

As said: English language should adopt it. It is as versatile
as put and get.


 Thanks for pointing it [www.linguee.com] out.

Google's merit.
But i must say this page really summarizes the problem.
Including the standard first proposal and the empirical
evidence that it is wrong.

as the case may be appears very near to the german
meaning of beziehungsweise.
Directly translated from its two word parts it would be
relation-wise.


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/836755485772990...@scdbackup.webframe.org

Re: Pitfalls of german-english dictionaries. Was: What pulls in the tray of my /dev/sr1 ?

On Tuesday 28 July 2015 11:49:33 Thomas Schmitt wrote:
 The lure for error is even more appealing because both words
 have an abbreviation: resp. and bzw..

We are back to the nub of the problem.  Not in English, it doesn't;  resp. is 
meaningless, unfortunately.  My spell-checker has just (correctly) objected 
to it!  Resp. is a German word, derived from an English word.

Every language has useful words that other languages don't have.  And I still 
haven't really understood what bzw. means, so I don't think that I'll be 
adopting it any time soon.

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/201507281230.08984.lisi.re...@gmail.com

Re: Pitfalls of german-english dictionaries. Was: What pulls in the tray of my /dev/sr1 ?

Hi,

Lisi Reisz wrote:
 Not in English, it doesn't;  resp.  is meaningless, unfortunately.

Blame the dictionaries. I'm just their victim.

  https://en.wiktionary.org/wiki/resp.#Abbreviation
  http://www.oxforddictionaries.com/definition/english/resp.

Yes, various forum users do object loudly.
But you can find any opinion there.


 Resp. is a German word, derived from an English word.

No it isn't. We already have our bzw..

It is an illegal alien in english language who is
already registered by the local trade control authorities
and pays taxes.
(Just like the genitive apostrophe is in german. We will
 never get rid of it again.)


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/8483554845622524...@scdbackup.webframe.org

Re: Pitfalls of german-english dictionaries. Was: What pulls in the tray of my /dev/sr1 ?

On Tuesday 28 July 2015 12:48:25 Alexis wrote:
 Lisi Reisz lisi.re...@gmail.com writes:
  On Tuesday 28 July 2015 11:49:33 Thomas Schmitt wrote:
  The lure for error is even more appealing because both words
  have an abbreviation: resp. and bzw..
 
  We are back to the nub of the problem.  Not in English, it
  doesn't;  resp. is  meaningless, unfortunately.

 i've seen 'resp.' used elsewhere; iirc, i've seen it used in
 English-language mathematics papers.

Possibly.  But maths is a language all of its own.

 And Wiktionary not only lists 
 'resp.' as an alternative form of 'respectively', 

Yes, I missed that.  I couldn't find it.  I stand corrected.  But it is 
certainly not in normal use.

 but also gives 
 an example of its full form as an adverb:

 https://en.wiktionary.org/wiki/respectively

Oh, yes.  of course the word respectively exists.

Lisi


 Alexis.


-- 
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/201507281528.14171.lisi.re...@gmail.com

Re: Pitfalls of german-english dictionaries. Was: What pulls in the tray of my /dev/sr1 ?

On Tuesday 28 July 2015 12:59:06 Thomas Schmitt wrote:
 Hi,

 Lisi Reisz wrote:
  Not in English, it doesn't;  resp.  is meaningless, unfortunately.

 Blame the dictionaries. I'm just their victim.

   https://en.wiktionary.org/wiki/resp.#Abbreviation
   http://www.oxforddictionaries.com/definition/english/resp.

 Yes, various forum users do object loudly.
 But you can find any opinion there.

  Resp. is a German word, derived from an English word.

 No it isn't. We already have our bzw..

 It is an illegal alien in english language who is
 already registered by the local trade control authorities
 and pays taxes.

:-)

 (Just like the genitive apostrophe is in german. We will
  never get rid of it again.)

How on earth does it get used in German?  I'd like to know - but you had 
better reply off list!

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/201507281530.21145.lisi.re...@gmail.com

Re: Pitfalls of german-english dictionaries. Was: What pulls in the tray of my /dev/sr1 ?

2015-07-28 Thread Ron

On Tue, 28 Jul 2015 15:30:21 +0100
Lisi Reisz lisi.re...@gmail.com wrote:

 How on earth does it get used in German?  I'd like to know - but you had 
 better reply off list!

Please, no, we also want to know !
 
Cheers,
 
Ron.
-- 
 There is no branch of mathematics, however abstract,
  which may not some day be applied to phenomena of the real world.
-- Nikolai Lobatchevski

   -- http://www.olgiati-in-paraguay.org --
 


-- 
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/20150728112613.38718...@ron.cerrocora.org

Re: Pitfalls of german-english dictionaries. Was: What pulls in the tray of my /dev/sr1 ?

On Tuesday 28 July 2015 16:31:42 Curt wrote:
  Yes, I missed that.  I couldn't find it.  I stand corrected.  But it is
  certainly not in normal use.

 You said it was meaningless in English.

Yes, as I said above, and you have quoted, I stand corrected.

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/201507281712.57182.lisi.re...@gmail.com

Re: Pitfalls of german-english dictionaries. Was: What pulls in the tray of my /dev/sr1 ?

2015-07-28 Thread Curt

On 2015-07-28, Lisi Reisz lisi.re...@gmail.com wrote:
 On Tuesday 28 July 2015 12:48:25 Alexis wrote:
 Lisi Reisz lisi.re...@gmail.com writes:
  On Tuesday 28 July 2015 11:49:33 Thomas Schmitt wrote:
  The lure for error is even more appealing because both words
  have an abbreviation: resp. and bzw..
 
  We are back to the nub of the problem.  Not in English, it
  doesn't;  resp. is  meaningless, unfortunately.
 
 i've seen 'resp.' used elsewhere; iirc, i've seen it used in
 English-language mathematics papers.

 Possibly.  But maths is a language all of its own.

 And Wiktionary not only lists 
 'resp.' as an alternative form of 'respectively', 

 Yes, I missed that.  I couldn't find it.  I stand corrected.  But it is 
 certainly not in normal use.

You said it was meaningless in English.

 but also gives 
 an example of its full form as an adverb:

 https://en.wiktionary.org/wiki/respectively

 Oh, yes.  of course the word respectively exists.

 Lisi


 Alexis.




-- 



-- 
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/slrnmrf82u.2or.cu...@einstein.electron.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: Pitfalls of german-english dictionaries. Was: What pulls in the tray of my /dev/sr1 ?

2015-07-28 Thread Alexis



Lisi Reisz lisi.re...@gmail.com writes:


On Tuesday 28 July 2015 11:49:33 Thomas Schmitt wrote:
The lure for error is even more appealing because both words 
have an abbreviation: resp. and bzw..


We are back to the nub of the problem.  Not in English, it 
doesn't;  resp. is  meaningless, unfortunately.


i've seen 'resp.' used elsewhere; iirc, i've seen it used in 
English-language mathematics papers. And Wiktionary not only lists 
'resp.' as an alternative form of 'respectively', but also gives 
an example of its full form as an adverb:


   https://en.wiktionary.org/wiki/respectively


Alexis.


--
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/87k2tkpkom@gmail.com

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

2015-07-28 Thread Frédéric Marchal

2015-07-28 10:20 GMT+02:00 Thomas Schmitt scdbac...@gmx.net:
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: Pitfalls of german-english dictionaries. Was: What pulls in the tray of my /dev/sr1 ?

2015-07-28 Thread Ron

On Tue, 28 Jul 2015 19:19:05 +0200
Thomas Schmitt scdbac...@gmx.net wrote:

 Ok. By popular demand a link to a comprehensive explanation
 of the Deppenapostroph and how to avoid it:

Vielen Dank.

Grüssen,
  
Ron.
-- 
   Do not meddle in the affairs of wizards,
   for they are subtle and quick to anger.
-- Gildor Inglorion

   -- http://www.olgiati-in-paraguay.org --
 


--
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/20150728133008.0fc24...@ron.cerrocora.org

Re: Pitfalls of german-english dictionaries. Was: What pulls in the tray of my /dev/sr1 ?

Hi,

i wrote:
   (Just like the genitive apostrophe is in german. We will
never get rid of it again.)

Lisi Reisz wrote:
  How on earth does it get used in German?  I'd like to know - but you had 
  better reply off list!

Renaud (Ron) OLGIATI wrote:
 Please, no, we also want to know !

Ok. By popular demand a link to a comprehensive explanation
of the Deppenapostroph and how to avoid it:

  https://www.thegermanz.com/german-apostrophes-deppenapostroph-denglisch/

(I would translate Deppenapostroph by Dumbnut's apostrophe
 not by Jerk's apostrophe as they do.)

--

I agree with Lisi that we should close the case of german-english
translation mishaps for now.
Just to summarize how this sub thread should have looked like:

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. 

i should then have written:

Oops. I meant btrace(8) (or rather its backend blktrace(8)) 


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/14398554865333487...@scdbackup.webframe.org

Re: Pitfalls of german-english dictionaries. Was: What pulls in the tray of my /dev/sr1 ?

Hi,

Lisi Resiz wrote:
  If you do use foreign words, you need to be willing to explain them when
  asked, as you were by Chris.

But i did not understand that it was about english language
and not about computing. I was not aware that resp. is wrong
in that context.


  I'm still not clear on the meaning of bzw,

It is quite wide.
As said, it expresses alternative views on the topics of
the sentence.

The nearest structural similarity to respectively is like
this:
german way:   A bzw. B bzw. C related to 1 bzw. 2 bzw. 3
english way:  A, B, C related to 1, 2, 3 respectively

But normally bzw. needs no second tuple to which it has to
create a 1:1 relation:
german:   A bzw. B bzw. C

There is some similarity between both words but this does
not justify to make them a pair in the vocabulary book.


Joel Rees wrote:
 With a little help from google translate, or rather.

Yes. Something like that. or alone is too general,
because it does not emphasize the need for changing the
viewpoint before the alternative becomes valid.


 And, in this case, namely doesn't work other.

namely has few chances to match a german bzw..


Here is a nice spectrum of beziehungsweise and its english
counterparts.
  http://www.linguee.com/german-english/translation/beziehungsweise.html
Some respectively are among them. Some are quite near to
my (mislead) use of it.


 This may be one time that Google translate was useful.

It helps from time to time. (But how trustworthy is it,
given the miserable state of german-english online
dictionaries ?)


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/28122554830122466...@scdbackup.webframe.org

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

2015-07-27 Thread Lisi Reisz

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

Pitfalls of german-english dictionaries. Was: What pulls in the tray of my /dev/sr1 ?

2015-07-27 Thread Thomas Schmitt

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. 

  [i missed the point]

Lisi Reisz wrote:
 But what does resp. mean?

I guess there is something wrong with my use of respectively.
Google ... ahum ...

Obviously an inappropriate use inspired by german language where
the translation beziehungsweise is used to express alternatives
depending on different perspectives.
The english dictionaries rather define it for emphasizing 1:1
relations between tuples. (This we do in math, not in prose.)

Actually there seem to be no single-word translations for
respectively and beziehungsweise. So they met in the
spare parts box and married.
This way our german-english dictionaries offer translations as
reliable as Monty Python's hungarian phrasebook.

It is becoming an international infection (mainly led by us
germans but also with french people involved):
http://ell.stackexchange.com/questions/6491/what-does-resp-mean-in-these-sentences

But hey ! To quote a mail footer from debian-cd list:
Steve McIntyre, Cambridge, UK.
The problem with defending the purity of the English language is that
 English is about as pure as a cribhouse whore. We don't just borrow words; on
 occasion, English has pursued other languages down alleyways to beat them
 unconscious and rifle their pockets for new vocabulary.  -- James D. Nicoll

So:
bzw. is a really useful word. Get it and use it whenever
you want to point to a fork in your thoughts.


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/18856554924246133...@scdbackup.webframe.org

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

2015-07-27 Thread Thomas Schmitt

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: Pitfalls of german-english dictionaries. Was: What pulls in the tray of my /dev/sr1 ?

2015-07-27 Thread Lisi Reisz

On Monday 27 July 2015 16:53:14 Thomas Schmitt wrote:
 The problem with defending the purity of the English language is that
  English is about as pure as a cribhouse whore. We don't just borrow words;
 on occasion, English has pursued other languages down alleyways to beat
 them unconscious and rifle their pockets for new vocabulary.  -- James D.
 Nicoll

 So:
 bzw. is a really useful word. Get it and use it whenever
 you want to point to a fork in your thoughts.

I'm not defending the purity of anything.  The English language is a right 
mish-mash of Latin, French, German, Norse, Hindi etc..  But none-the-less, it 
improves comprehensibility if one sticks roughly to the language in which one 
is speaking/writing.

If you do use foreign words, you need to be willing to explain them when 
asked, as you were by Chris.

I'm still not clear on the meaning of bzw, nor in what way its meaning differs 
from or.  So I shall continue to use or. ;-)

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/201507272246.22658.lisi.re...@gmail.com

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

2015-07-27 Thread Mike Castle

On Sat, Jul 25, 2015 at 4:44 AM, Thomas Schmitt scdbac...@gmx.net 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
snarkWindow machines don't stay booted long enough/snark.

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: Pitfalls of german-english dictionaries. Was: What pulls in the tray of my /dev/sr1 ?

2015-07-27 Thread Chris Bannister

On Tue, Jul 28, 2015 at 01:23:48PM +0900, Joel Rees wrote:
 I'd go with the idea suggested on the stackexchange post he referenced,
 that, in other contexts, the English grammar puts the beziehungswiese
 after two lists which are being associated:
 
 ... translating breakfast, lunch, and dinner
 as asa-gohan, o-hiru, and yuu-han, _respectively_.

Yes, in this instance it makes sense, but is a digression.
I think for the original issue, it could be read as 'actually'?

-- 
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/20150728052430.GA26535@tal

Re: Pitfalls of german-english dictionaries. Was: What pulls in the tray of my /dev/sr1 ?

2015-07-27 Thread Joel Rees

Hi, Lisi,

If I'm still in your blacklists, it won't help for me to comment, but ...

2015/07/28 6:46 Lisi Reisz lisi.re...@gmail.com:

 On Monday 27 July 2015 16:53:14 Thomas Schmitt wrote:
  The problem with defending the purity of the English language is that
   English is about as pure as a cribhouse whore. We don't just borrow
words;
  on occasion, English has pursued other languages down alleyways to beat
  them unconscious and rifle their pockets for new vocabulary.  -- James
D.
  Nicoll
 
  So:
  bzw. is a really useful word. Get it and use it whenever
  you want to point to a fork in your thoughts.

 I'm not defending the purity of anything.  The English language is a right
 mish-mash of Latin, French, German, Norse, Hindi etc..  But
none-the-less, it
 improves comprehensibility if one sticks roughly to the language in which
one
 is speaking/writing.

 If you do use foreign words, you need to be willing to explain them when
 asked, as you were by Chris.

 I'm still not clear on the meaning of bzw,

I'm guessing it was in the part you cut out, the beziehungsweise that he
was translating as respectively, abbrevitated to resp.

 nor in what way its meaning differs
 from or.  So I shall continue to use or. ;-)

 Lisi


With a little help from google translate, or rather.

I'd go with the idea suggested on the stackexchange post he referenced,
that, in other contexts, the English grammar puts the beziehungswiese
after two lists which are being associated:

... translating breakfast, lunch, and dinner
as asa-gohan, o-hiru, and yuu-han, _respectively_.

(with apologies for potentally muddying the waters further by using
Japanese in my example).

And, in this case, namely doesn't work other.

This may be one time that Google translate was useful.

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

2015-07-27 Thread Thomas Schmitt

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 ?

2015-07-26 Thread Alan Greenberger

On 2015-07-24, Thomas Schmitt scdbac...@gmx.net 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 ?

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,

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 ?

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,

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 ?

2015-07-25 Thread The Wanderer

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 ?

2015-07-25 Thread Lisi Reisz

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 ?

2015-07-25 Thread Lisi Reisz

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 ?

2015-07-25 Thread Nicolas George

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 ?

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 ?

2015-07-25 Thread Nicolas George

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

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

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


-- 
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/1371955517162095...@scdbackup.webframe.org

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

2015-07-24 Thread Lisi Reisz

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

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

2015-07-24 Thread Michael Biebl

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 ?

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 ?

2015-07-24 Thread Michael Biebl

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 ?