[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: plextor px-708uf: cannot get disk type



>From magliery@csb.yale.edu  Wed Jan 28 00:55:56 2004

>> The drive works fine for me on Linux 2.4.10-4GB
>Are you using the 708A?  Because I'm actually using the 708UF.  It's the
>same drive, but with a USB2.0/firewire interface.  Could the problem be with
>USB2.0?  Sadly, I don't have a firewire port on this PC, but I can drop in
>an Audigy soundcard with one from anther rig, if you think this might be
>helpful.

OK, I forgot about this....

>> if it does not work for you
>> there are only a few possible reasons left over:
>> 
>> -	A Linux kernel bug
>Do you think the "kernel: cdrom" message that was repeated from the KDE
>automounter might suggest that the cdrom module is having a problem?

I don't believe so.


>> -	a broken drive.
>Again, since growisofs works, I doubt this, but perhaps cdrecord avails
>itself of some facility that growisofs ignores.  Is this the case?  In other
>words, WHY would growisofs either not have or not be stopped by this error,
>while cdrecord is?  Recall that cdrecord is fine with blank CD-Rs using the
>same drive.

A possible reason may be a bug in growisofs....

If a program does not check for all error codes, it may not be aware of the
problem. The low level code in libscg checks for _all_ possible problems.

>I will also try using the drive with Nero on a WinXP machine.  I'll also buy
>a DVD-R and test it.  But I'm currently betting it's a cdrom or scsi module
>(i.e., kernel) problem that doesn't bother growisofs for some reason, or a
>USB2.0 problem that doesn't bother growisofs, or a problem with cdrecord and
>one of these things.  I have no idea how to troubleshoot this, though--it's
>not like I'm going to reprogram the cdrom module.  Suggestions?

>Getting back to the original emails on this, I get the following:
>===========================
>cdrecord.prodvd: Input/output error. read disk info: scsi sendcmd: no error
>CDB: 51 00 00 00 00 00 00 00 24 00
>status: 0x2 (CHECK CONDITION)
>Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00
>Sense Key: 0x0 No Additional Sense, Segment 0
>Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0
>Sense flags: Blk 0 (not valid)
>cmd finished after 0.002s timeout 240s
>cdrecord.prodvd: Cannot get disk type.
>============================

>While you get:
>============================
>Executing 'read disk info' command on Bus 0 Target 0, Lun 0 timeout 240s
>CDB:  51 00 00 00 00 00 00 00 24 00
>cmd finished after 0.000s timeout 240s
>Got 36 (0x24), expecting 36 (0x24) bytes of data.
>Received Data:  00 22 00 01 01 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00
>00 23 05 40 00 00 00 00 00 00 00 00 00 00 00 00
>============================

>Can you tell me what this means?

A possible reason is a bug in the USB part of the kernel that creates a false
status: 0x2 (CHECK CONDITION) - this is an assumption as the drive later 
replies that there was no problem (if this is not false sense bytes).

The Linux SCSI kernel code is a pure disaster :-(

In special the bit 0x02 is handled as 0x01 in parts of the kernel.
As I mentioned several times, the Linux kernel people didn't fix a lot of known
bugs during the past 5 years. 

As parts of the kernel insist in a shifted by one SCSI status byte and others
expect the correct and unmodified SCSI staus byte, strange things may happen
in special when an instance uses the bit 0x01 for internal purposes....

My proposal now is to unmount the drive from the case and connect it via
an IDE cable. I am pretty sure it will work.

If this works, you need to send a bug report to the Linux kernel folks....

Sorry, but libscg and cdrecord depend on correct error information.
I had the same discussion with Sun (*) people when they started to always return a 
DMA residual cound eaqual to the expected DMA count so cdrecord did believe that
no DMA at all did happen. Furtunately, it is possible to convince the relevant
people at Sun :-)

*) Suns 'cdrw' did work because it is buggy and ignores some error conditions.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily



Reply to: