From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen)
To: Jan Knutar <jk-lkml@sci.fi>
Cc: linux-kernel@vger.kernel.org
Subject: Re: CD writer is burning with open tray
Date: Tue, 4 Oct 2005 09:52:45 -0400 [thread overview]
Message-ID: <20051004135245.GS7949@csclub.uwaterloo.ca> (raw)
In-Reply-To: <200510040216.36796.jk-lkml@sci.fi>
On Tue, Oct 04, 2005 at 02:16:36AM +0300, Jan Knutar wrote:
> 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.
If your drive needs a forced eject to interrupt it's firmware from
trying to read a disc, it has problems.
> 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.
I find that mounting a cdrom will either suceed or fail within a few
minutes on any hardware I have ever bought. My hardware seems to tell
the OS that it can't read the disc. I have seen cheap drives that
seemed to just keep trying forever and were essentially unable to be
interrupted. I don't buy that kind of hardware.
Check if your drive firmware is actually up to date. If not, update it.
Maybe the company making the drive has fixed their mistakes.
Len Sorensen
next prev parent reply other threads:[~2005-10-04 13:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-29 14:19 Karel Kulhavy
2005-09-29 14:40 ` DervishD
2005-09-29 16:28 ` Lennart Sorensen
2005-10-03 23:16 ` Jan Knutar
2005-10-04 13:52 ` Lennart Sorensen [this message]
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=20051004135245.GS7949@csclub.uwaterloo.ca \
--to=lsorense@csclub.uwaterloo.ca \
--cc=jk-lkml@sci.fi \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®