Hello
I ran cdrecord -tao dev=ATAPI:0,0,0 speed=8 /home/clock/cdrom.iso on
2.6.12-gentoo-r10 and it burned a good CD.
Then I repeated the same command (press up and enter) and it
1) Burned two bad CD's with a strip near the central area
2) Third CD burned bad
3) When rerun cdrecord says
cdrecord: Drive does not support TAO recording.
cdrecord: Illegal write mode for this drive.
I should note here that I didn't hotplug the hardware - I can't
understand how supported modes can change on the fly...
Anyway the activity LED is now flashing (later shining) even when
cdrecord is not running and I open the tray using emergency open
(it cannot be opened by normal open). /dev/hdc (the CDROM) is not mounted.
The mechanics inside is quite heated up.
The activity LED is flashing or shining even when the mechanics is open
and I can look into the laser lens! However I didn't see any dim red
light - looks like the laser switches off when the tray is open.
Is it possible to get eye damage due to faulty kernel driver?
Is it possible to destroy the mechanics by overheating or mechanical
damage due to faulty kernel driver?
Is this intended behaviour of Linux kernel?
CL<
Hi Karel :)
* Karel Kulhavy <[email protected]> dixit:
> Then I repeated the same command (press up and enter) and it
> 1) Burned two bad CD's with a strip near the central area
> 2) Third CD burned bad
> 3) When rerun cdrecord says
> cdrecord: Drive does not support TAO recording.
> cdrecord: Illegal write mode for this drive.
Your writer doesn't seem to work good with cdrecord...
> Is it possible to get eye damage due to faulty kernel driver?
First, CD recording doesn't have to do directly with the kernel.
AFAIK, the kernel driver just passes commands to the device, is the
userspace app which generates the commands.
Second, your writer looks faulty, although the problem may be a
simple incompatibility between the device and cdrecord.
Third, not, you cannot get eye damage due to a faulty kernel
driver, but is possible to get eye damage if you look directly to a
laser. No matter if you use Linux or not.
> Is it possible to destroy the mechanics by overheating or mechanical
> damage due to faulty kernel driver?
I don't think so. Better: I *hope* that my CD writer mechanics
can stand high temperatures without destroying, otherwise it won't
last long...
> Is this intended behaviour of Linux kernel?
Do you think that the kernel designers want to create a good
source of coasters? My writer (Plextor) has burned almost 500 CD's
more or less, and I only have two coasters. Certainly both cdrecord
and the kernel seems to work quite good here. But my old CD writer, a
Philips 3610 (or something like that) did more or less what you tell
when it got broken.
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...
On Thursday 29 September 2005 14:19, Karel Kulhavy wrote:
> Hello
>
> The activity LED is flashing or shining even when the mechanics is open
> and I can look into the laser lens! However I didn't see any dim red
> light - looks like the laser switches off when the tray is open.
>
> Is it possible to get eye damage due to faulty kernel driver?
as DervishD already explained, the kernel driver doesn't, but lasers can
easily cause severe irreversible eye damage. doesn't matter if you actually
*see* the laser beam. NEVER use a non-closed cd drive (either standard simple
stereo units or dvd burners, they all present similar dangers). most drives
have hardware safety features that disable all lasers when tray is open, but
some other may not...
[]
--
Pedro Jo?o Lopes Venda
email: pjvenda < at > rnl.ist.utl.pt
http://arrakis.dhis.org
On Thu, Sep 29, 2005 at 04:19:24PM +0200, Karel Kulhavy wrote:
> I ran cdrecord -tao dev=ATAPI:0,0,0 speed=8 /home/clock/cdrom.iso on
> 2.6.12-gentoo-r10 and it burned a good CD.
>
> Then I repeated the same command (press up and enter) and it
> 1) Burned two bad CD's with a strip near the central area
> 2) Third CD burned bad
> 3) When rerun cdrecord says
> cdrecord: Drive does not support TAO recording.
> cdrecord: Illegal write mode for this drive.
Which model cd writer?
It was very common years ago that drives with phillips internals would
crash if you didn't include the --eject option to cdrecord to force it
to eject the disc when done so the drive would reinitialize when
inserting the disc again. If you didn't you had to reboot the system
before you could burn another cd. This was quite annoying, so I got
used to include --eject on old hp 2x writers since they used phillips
mechanisms inside.
> I should note here that I didn't hotplug the hardware - I can't
> understand how supported modes can change on the fly...
Firmware tells cdrecord what drive can do. Garbage firmware produces
garbage output.
> Anyway the activity LED is now flashing (later shining) even when
> cdrecord is not running and I open the tray using emergency open
> (it cannot be opened by normal open). /dev/hdc (the CDROM) is not mounted.
> The mechanics inside is quite heated up.
>
> The activity LED is flashing or shining even when the mechanics is open
> and I can look into the laser lens! However I didn't see any dim red
> light - looks like the laser switches off when the tray is open.
>
> Is it possible to get eye damage due to faulty kernel driver?
If you hit the emergency eject hole, you actually disengage the tray
from the tray motor. The reason it won't open is that cd drives LOCK
the tray (by disableing the eject button) when they are busy, such as
when they are burning a cd, or the cd is mounted. If you had managed to
get the cdwriter to finish burning (or it hadn't crashes itself) it
would have allowed you to open it. Rebooting the machine would also
reset the drive and allow you to open it. 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.
> Is it possible to destroy the mechanics by overheating or mechanical
> damage due to faulty kernel driver?
Badly designed hardware may allow itself to be damaged by faulty
firmware and its interaction with applications.
> Is this intended behaviour of Linux kernel?
I didn't see anything that indicates the linux kernel did anything
wrong. It passed data between cdrecord and your drive. If they don't
like each other and the drive crashes, then the drive has crap for
firmware. Go buy a better drive or get updated firmware. I use
plextors and am very happy with them.
Your whole problem sounds like you have a drive with major firmware
bugs.
Len Sorensen
Karel Kulhavy wrote:
> Hello
>
> I ran cdrecord -tao dev=ATAPI:0,0,0 speed=8 /home/clock/cdrom.iso on
> 2.6.12-gentoo-r10 and it burned a good CD.
>
> Then I repeated the same command (press up and enter) and it
> 1) Burned two bad CD's with a strip near the central area
> 2) Third CD burned bad
> 3) When rerun cdrecord says
> cdrecord: Drive does not support TAO recording.
> cdrecord: Illegal write mode for this drive.
>
> I should note here that I didn't hotplug the hardware - I can't
> understand how supported modes can change on the fly...
My guess is that your writer is bad, or at minimum needs a firmware
upgrade. However, is this the real cdwrite program from Joerg Schilling,
or is it one of the hacked versions which come with some distributions
with mods to burn DVDs?
I would also specify the real device name, like dev=/dev/hdX, and drop
the speed= option and let it choose one it likes. You may also want to
use the -atip option to see what cdrecord thinks about your drive.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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.
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