Fwd: No supported write modes with LG GSA-H62N SATA DVD+RW
I'd mentioned that I'd forward the exchange that I accidentally took off-list yesterday for the benefit of anyone following along or coming by later and finding this in the archives. I won't bother sending them all, just two that seem to have the most relevant information.
---------- Forwarded message ----------
From: Joe MacDonald <firstname.lastname@example.org>
Date: Sep 10, 2007 8:03 PM
Subject: Re: No supported write modes with LG GSA-H62N SATA DVD+RW
To: Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de>
On 9/10/07, Joerg Schilling <
"Joe MacDonald" <email@example.com> wrote:
> Okay, so where does this leave me in terms of writing CDs/DVDs in Linux? Is
> this pretty much out of your hands since it looks very much like something
> below the cdrecord level, or is there something more I can do to narrow this
> down (hopefully to something fixable)? Or am I looking to take this up with
> the kernel folks now?
The difference between Linux & Win32 is definitely below the cdrecord code.
I have one question: Did you run this with administrator privileges?
In Windows? Yes, the account I log in as has admin privileges.
Could could try to prepend ASPI: vs. SPTI: to the dev= parameter
to verify whether this was ASPI or SPTI?
Sure thing. It seems less happy now:
$ ./cdrecord.exe -v speed=1 -audio dev=ASPI:2,0,0 tmp/*.wav
./cdrecord: No write mode specified.
./cdrecord: Asuming -sao mode.
./cdrecord: If your drive does not accept -sao, try -tao.
./cdrecord: Future versions of cdrecord may have different drive dependent defaults.
Cdrecord-ProDVD-ProBD-Clone 2.01.01a35 (i686-pc-cygwin) Copyright (C) 1995-2007 Jцrg Schilling
TOC Type: 0 = CD-DA
scsibus: 2 target: 0 lun: 0
Can not load ASPI driver! ./cdrecord: No such file or directory. Cannot open oruse SCSI driver.
./cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root.
./cdrecord: For possible transport specifiers try 'cdrecord dev=help'.
But everything is fine if I pre-pend SPTI: or leave the dev= option bare, as in my previous test. Does that tell you anything useful?
Unless the win32 drivers modify the SCSI commands as a workaround, the problem
must be inside the linux kernel.
If the related Linux drivers are developed in a professional environment, then
the developer should have a logic analyzer that allows to snoop at SATA level
and should be able to fetch the drive you have.
EMail:firstname.lastname@example.org (home) Jörg Schilling D-13353 Berlin
email@example.com (work) Blog: