Re: No supported write modes with LG GSA-H62N SATA DVD+RW
Hi,
me:
> > The user exchanged the SATA controller
Joe MacDonald:
> I'm not completely opposed to that, but I've been considering that a
> non-solution so far since it appears that the controller isn't completely
> defective, just not completely functional in Linux.
I will hardly tell you to throw away the
problematic controller before we found out
what's going on. Call it selfish curiosity. :))
A test swap would be of great interest though.
After all, there is only _one_ known success
with exchanging controllers. It can have had
many causes.
> - Can you find out the type of that SATA controller ?
> Let me know if the information above isn't what you were looking for and
Since i got no clue about SATA either
it shall suffice for now.
> 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID
... grepping ...
Andreas Klauer, Wed, 4 Apr 2007:
http://lists.debian.org/cdwrite/2007/04/msg00033.html
> I'm trying to get my Samsung SH-S183A SATA drive to work.
> ...
> The board is an ASUS A7V880, with a VIA VT6420 SATA RAID Controller
> (integrated into VT8237 southbridge)
Andreas Klauer, Mon, 2 Jul 2007:
http://lists.debian.org/cdwrite/2007/07/msg00001.html
> No, I gave up on it. I just bought a VIA SATA PCI controller (VT6421),
> which works for the device also in Linux.
I think the suspect got a name for now.
> At this stage I'll entertain any suggestions if it helps me figure out
> what the root cause is. I'd rather find a solution that uses cdrecord,
> but as far as I'm concerned I'm still in the analysis phase of the
> problem, not the part where I try to actually fix anything. :-)
(Preliminarily outdated, see below:
Ok. I'll prepare a test program and tell your where
to download the tarball.
)
If we find a remedy then it will be published of course,
so Joerg can decide what to do or not to do in cdrecord.
Maybe the remedy has to be found in the kernel.
I could back you with MMC knowlege if you post your
problem to LKML. With the kernel itself i have not
much of competence. My delivery point is ioctl(SGIO)
by which i send SPC/SBC/MMC commands and receive
eventual replies.
>From then on it's the job of kernel, bus, controller,
and drive.
Either my command is bad or that chain is bad.
Much points to the chain, meanwhile.
After all, commands of cdrecord, growisofs and
cdrskin did not succeed. All three are independend
in that aspect. Only common properties of all three
are the specs of MMC mode page 05h, the SPC command
MODE SELECT and the Linux ioctl SGIO.
(I anticipate growisofs on DVD-R[W] will not work.
For Andreas it didn't.)
New mail with SCSI trace of cdrecord.
There's a MODE SENSE of mode page 05h i.e. that's
already the experiment which i wanted to do next:
> Executing 'mode sense g1' command on Bus 0 Target 0, Lun 0 timeout 40s
> CDB: 5A 00 05 00 00 00 00 00 3C 00
> cmd finished after 0.001s timeout 40s
> Mode Sense Data 00 3A 41 00 00 00 00 00 05 32 61 04 08 10 00 00 00 00 00
> 00 00 00 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
The thing reports a page length of 32h.
That's exactly the page length which fails with
wodim and with cdrskin.
With Andreas i tested to send pages of lenght 32h
as well as of length 36h. Both failed with a
SCSI error about bad length.
That means it can last a bit longer until i have
an idea about the next experiment.
Currently i feel clueless.
Above mode sense data mean according to MMC-5 Table 664:
Write Type is 1 = TAO, Burnfree available, no Test Write,
Track mode 4, Data Block type 8 (= Mode 1),
Audio Pause length 96h (=2 seconds)
This all looks totally normal.
Have a nice day :)
Thomas
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Reply to: