Re: PX-2410TU freezes system, doesn't write well
>From: deetee <deetee@diversity-radio.net>
>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 $@`;
> 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 $@`;
> 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: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: