>From [EMAIL PROTECTED] Mon Mar 26 01:48:14 2001
>[EMAIL PROTECTED] writes ("Re: cdrecord 1.10a17 and Iomega USB ZIP=
>CD"):
>> Well I like to be as standard compliant as possible.
>Quite.
>> It id definitely a cdrecord topic. From my tests it seems to be
Sorry, this is caused by sticky fingers on my notebook at the CeBIT..
It shoukd read: it is definitely _not_ a cdrecord topic.
>> mainly a Linux USB problem. Last year, I made some tests with the
>> IOMEGA USB drive with a plain PC of a collegue .... It dis not work
>> very well so far because there have been problems after the DMA
>> overrun detection.
>That seems consistent with my experiences.
>From you recent transscript, it is a problem with the USB driver.
>> Some weks ago, I made tests with my Sony VAIO Transmeta motebook
>> and it turns out, that it does not work at all if you boot with
>> the drive connected or if you enable enhanced debugging.
>>=20
>> However, if you carefully wait until everything is quiet, then plug i=
>n
>> the drive and start to use it via cdrecord there is absolutely
>> no problem! No hangs - only a one to two second delay when
>> detecting the DMA overrun at the beginning.
>I have just tried that, and it behaves no differently. Transcript
>below.
Id this really a Sony VAIO with crusoe chip (PCG-C1VE) ?
YOur problems happend to me last year on a machine with differernt
hardware. It does _not_ happen on my VAIO.
>> Sory, but many things changeed during the last versions and I have ab=
>soutely
>> no time to check reports that are not based on the latest cdrtools
>> release.
>My bug report *was* based on the latest cdrtools, 1.10a17 !
SO eithe you stripped of the version number or I missed it.
>> In addition, you may want to run the scgckeck program to see whether=20=
>> other than the known Linux SCSI problems are present on
>> your machine.
>Transcript attached.
Besides the usual Linux SCSI kernel bugs, there is nothing special in it.
>Executing 'mode sense g1' command on Bus 0 Target 0, Lun 0 timeout 40s
>CDB: 5A 00 2A 00 00 00 00 00 02 00
>cmd finished after 6.003s timeout 40s
>Mode Sense Data 00 1C
>Mode Sense Data (converted) 19
>Executing 'mode sense g1' command on Bus 0 Target 0, Lun 0 timeout 40s
>CDB: 5A 00 2A 00 00 00 00 00 1E 00
>/usr/bin/cdrecord: Input/output error. mode sense g1: scsi sendcmd: no =
>error
>CDB: 5A 00 2A 00 00 00 00 00 1E 00
>status: 0x2 (CHECK CONDITION)
>Sense Bytes: 70 00 06 6A 7F FA AF 13 00 00 00 00 29 00 00 00
>Sense Key: 0x6 Unit Attention, Segment 0
>Sense Code: 0x29 Qual 0x00 (power on, reset, or bus device reset occurr=
>ed) Fru 0x0
>Sense flags: Blk 1786772143 (not valid)=20
>cmd finished after 0.015s timeout 40s
For some strange reason, there was no failure of the first
mode sense command so I cannot detect the DMA overrun...
It looks to me like a problem of the USB kernel drivers as the
DMA overrun most likely happened...
Please check out this patch:
------- modes.c -------
*** - Mon Mar 26 10:09:47 2001
--- modes.c Mon Mar 26 10:07:45 2001
***************
*** 90,95 ****
--- 90,100 ----
}
len = ((struct scsi_mode_header *)mode)->sense_data_len + 1;
}
+ /*
+ * IOMEGA USB drives may receive a SCSI bus device recet in between
+ * these two mode sense commands.
+ */
+ (void)unit_ready(scgp);
if (mode_sense(scgp, mode, len, page, 0) < 0) { /* Page n current */
scgp->silent--;
return (FALSE);
J�rg
EMail:[EMAIL PROTECTED] (home) J�rg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni) If you don't have iso-8859-1
[EMAIL PROTECTED] (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
