>From: deetee <[EMAIL PROTECTED]> >I am running woody 2.4.18 on a toshiba portege laptop. I have an >external USB CDR: plextor's 24/10/40U. (PX-2410TU)
>I cannot reliably write complete and uncorrupted data (direct to cdr, I don't >have space to make an iso on my harddisk). >Furthermore, it appears that the system gets 'hung' after writes >(dummy or otherwise). If I do not power cycle the CDR unit, before >launching another cdrecord command, my whole system freezes and I have >to hard boot. It is also filling up syslog with not very nice looking >messages (appended below), that I don't understand. So it is obvious, that this is a kernel related bug and that you cannot get help from here..... BUT>>>>>>>> if you don't send information, anything is just guessing! http://www.fokus.fhg.de/research/cc/glone/employees/joerg.schilling/private/problems.html >I have tried cdrecord directly and xcdroast. >The commands used in cdrecord were: >for a dummy run as a script, taking directories/files to be burnt as args: > cdblocks=`mkisofs -print-size -quiet [EMAIL PROTECTED]; > nice --18 mkisofs -R -r $@ | cdrecord -v fs=4m -dummy -dao -nofix speed=5 > -driveropts=burnfree -tsize=${cdblocks}s dev=0,0,0 -; >for a real write: > cdblocks=`mkisofs -print-size -quiet [EMAIL PROTECTED]; > nice --18 mkisofs -R -r $@ | cdrecord -v fs=4m -dao speed=5 > -driveropts=burnfree -tsize=${cdblocks}s dev=0,0,0 - ; >I have lots of incompletely burnt cds, and am running out of ideas, so I >would be grateful if someone could help. Happy to provide more info if >useful, but below are some diagnostics, >tia >deetee. >---- ># cdrecord -scanbus >Cdrecord-Clone 2.01a19 (i686-pc-linux-gnu) Copyright (C) 1995-2003 J�rg Schilling >Linux sg driver version: 3.1.22 >Using libscg version 'schily-0.7' >scsibus0: > 0,0,0 0) 'PLEXTOR ' 'CD-R PX-W2410A' '1.04' Removable CD-ROM > 0,1,0 1) * > 0,2,0 2) * > 0,3,0 3) * > 0,4,0 4) * > 0,5,0 5) * > 0,6,0 6) * > 0,7,0 7) * >----- >from syslog >Feb 17 01:22:01 cygnus kernel: usb-storage: Bulk status Sig 0x53425355 T 0x632 R 0 >Stat 0x0 >Feb 17 01:22:01 cygnus kernel: usb-storage: scsi cmd done, result=0x0 >Feb 17 01:22:01 cygnus kernel: usb-storage: *** thread sleeping. >Feb 17 01:22:01 cygnus kernel: usb-storage: queuecommand() called >Feb 17 01:22:01 cygnus kernel: usb-storage: *** thread awakened. >Feb 17 01:22:01 cygnus kernel: usb-storage: Command MODE_SENSE_10 (10 bytes) >Feb 17 01:22:01 cygnus kernel: usb-storage: 5a 00 05 00 00 00 00 00 3c 00 0a c2 >Feb 17 01:22:01 cygnus kernel: usb-storage: Bulk command S 0x43425355 T 0x633 Trg 0 >LUN 0 L 60 F 128 CL 10 >Feb 17 01:22:01 cygnus kernel: usb-storage: Bulk command transfer result=0 >Feb 17 01:22:01 cygnus kernel: usb-storage: usb_stor_transfer_partial(): xfer 60 bytes >Feb 17 01:22:01 cygnus kernel: usb-storage: usb_stor_bulk_msg() returned 0 xferred >60/60 >Feb 17 01:22:01 cygnus kernel: usb-storage: usb_stor_transfer_partial(): transfer >complete Here is no problem at your site! Here is where many cheap drives hang Linux and even Solaris for ~ 30 seconds. This is a result from the fact that many drives cause DMA overflows caused by a broken SCSI implementation in firmwarem or by incorrect implementaions in the kernel. If a DMA overrun happens with USB, the system takes some time to recover. >------- >using xcdroast: >cdrecord.mmap: Operation not permitted. WARNING: Cannot set RR-scheduler >cdrecord.mmap: Permission denied. WARNING: Cannot set priority using setpriority(). >cdrecord.mmap: WARNING: This causes a high risk for buffer underruns. >--------- Incorrect usage---> see man page! 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.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
