public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Knutar <jk-lkml@sci.fi>
To: lsorense@csclub.uwaterloo.ca (Lennart Sorensen)
Cc: linux-kernel@vger.kernel.org
Subject: Re: CD writer is burning with open tray
Date: Tue, 04 Oct 2005 02:16:36 +0300	[thread overview]
Message-ID: <200510040216.36796.jk-lkml@sci.fi> (raw)
In-Reply-To: <20050929162836.GA20178@csclub.uwaterloo.ca>

On Thursday 29 September 2005 19:28, you wrote:
> You should never need to use
> the emergency eject option unless you have a power failure and need a
> disc out badly, or the drive is broken and no longer installed in a
> machine and you need a disc removed from it.  It should not be used
> while the drive is powered.

Actually that is not quite true under Linux in all circumstances. There seems
to be no way to interrupt a mount attempt under Linux. I've sent a kill -9 to
the mount process, went to bed, and it was still attempting to read the disc
when I woke up 8 hours later. I'm not sure if it was due to bad firmware, or
due to Linux retrying failed read requests too many times. Somehow I would
except though, that sending kill -9 to the process in question would also try
abort the pending request rather than retrying it indefinitely.
Ejecting the disc with needle in emergency eject hole always made Linux give up
and mount fail, though, luckily saving me from reboot.

It's even worse on IDE where it can block all devices on the same channel, then
you have some pages on another device on same channel which are needed in
order to execute kill -9 or advance the cursor in your xterm :) Then you don't even
have choice of trying a kill -9 first...
Call me impatient, I usually give it a day or two after ^C and kill -9 before I resort
to emergency eject on the drive. I had a system once where even that didn't unwedge
things, I had to unplug the power from the IDE device in question before things unlocked.
Sure, it resulted in lots of nasty messages in dmesg and in the smartd log on the other
device on same IDE channel, but no data corruption luckily.

Hardware kinda sucks.

  reply	other threads:[~2005-10-03 23:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-29 14:19 CD writer is burning with open tray Karel Kulhavy
2005-09-29 14:40 ` DervishD
2005-09-29 16:28 ` Lennart Sorensen
2005-10-03 23:16   ` Jan Knutar [this message]
2005-10-04 13:52     ` Lennart Sorensen
2005-09-29 16:43 ` Pedro Venda
2005-09-29 19:19 ` Bill Davidsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200510040216.36796.jk-lkml@sci.fi \
    --to=jk-lkml@sci.fi \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lsorense@csclub.uwaterloo.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox