k_smp-2.4.20-102 deemed harmful to cdrecord
I can't believe this nonsense. I have been abusing myself for something like 5 years with "Linux on the desktop," always thinking that the next release would be "it." Today, I'm trying to burn a CD. JUST BURN A CD! And on two separate -- though very similar -- computers, I'm getting the exact same nonsense. (Which is to say that it's not my hardware, both of which have worked just fine the last time I tried on each.) I'm long past trying to burn as a normal user. Oh no. That would be too hard. I can't even burn as root any more. It's really simple. I have a completely-SCSI setup. ``cdrecord --scanbus'' as root sees all my hardware. 0,0,0 0) 'IBM ' 'DDYS-T18350N ' 'S96H' Disk 0,1,0 1) 'SEAGATE ' 'ST318437LW ' '0105' Disk 0,2,0 2) 'PLEXTOR ' 'CD-ROM PX-40TS ' '1.11' Removable CD-ROM 0,3,0 3) 'PLEXTOR ' 'CD-R PX-W124TS' '1.05' Removable CD-ROM 0,4,0 4) 'IOMEGA ' 'ZIP 100 ' 'J.03' Removable Disk 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * But today, all of a sudden, I get crap like this (in this example, I'm just trying to burn the image for the SuSE 8.2 boot CD, so I know it's good): enterprise:/home/david/tmp # cdrecord -v dev=0,3,0 speed=12 root Cdrecord 2.0 (i686-suse-linux) Copyright (C) 1995-2002 J?rg Schilling TOC Type: 1 = CD-ROM scsidev: '0,3,0' scsibus: 0 target: 3 lun: 0 Linux sg driver version: 3.1.24 Using libscg version 'schily-0.7' cdrecord: Warning: using inofficial libscg transport code version (okir@suse.de-scsi-linux-sg.c-1.75-resmgr-patch '@(#)scsi-linux-sg.c 1.75 02/10/21 Copyright 1997 J. Schilling'). atapi: 0 Device type : Removable CD-ROM Version : 2 Response Format: 2 Capabilities : SYNC LINKED Vendor_info : 'PLEXTOR ' Identifikation : 'CD-R PX-W124TS' Revision : '1.05' Device seems to be: Generic mmc CD-RW. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : MMC SWABAUDIO Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R Drive buf size : 2373168 = 2317 KB FIFO size : 4194304 = 4096 KB Track 01: data 44 MB Total size: 51 MB (05:05.38) = 22904 sectors Lout start: 51 MB (05:07/29) = 22904 sectors cdrecord: Input/output error. start/stop unit: scsi sendcmd: no error CDB: 1B 00 00 00 01 00 status: 0x2 (CHECK CONDITION) Sense Bytes: F0 00 0B 00 00 00 00 00 Sense Key: 0xB Aborted Command, Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (valid) cmd finished after 0.000s timeout 40s Current Secsize: 2048 ATIP info from disk: Indicated writing power: 5 Is not unrestricted Is not erasable Disk sub type: Medium Type A, high Beta category (A+) (3) ATIP start of lead in: -11634 (97:26/66) ATIP start of lead out: 359848 (79:59/73) Disk type: Short strategy type (Phthalocyanine or similar) Manuf. index: 3 Manufacturer: CMC Magnetics Corporation Blocks total: 359848 Blocks current: 359848 Blocks remaining: 336944 Starting to write CD/DVD at speed 12 in real TAO mode for single session. Last chance to quit, starting real write 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. Performing OPC... Starting new track at sector: 0 Track 01: 1 of 44 MB written (fifo 100%) [buf 67%] 23.9x.cdrecord: Input/output error. write_g1: scsi sendcmd: no error CDB: 2A 00 00 00 03 A2 00 00 1F 00 status: 0x2 (CHECK CONDITION) Sense Bytes: F0 00 0B 00 00 00 00 00 Sense Key: 0xB Aborted Command, Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (valid) cmd finished after 0.000s timeout 40s write track data: error after 1904640 bytes Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 Writing time: 26.126s Average write speed 28.3x. Fixating... Fixating time: 24.048s cdrecord: fifo had 94 puts and 31 gets. cdrecord: fifo was 0 times empty and 13 times full, min fill was 95%. I know what errors like this are about. I know how involved, and how machine-specific they can be. I know there's no chance that someone can tell me what the problem would be. I keep up with all the patches, so the best I can hope for is for someone to tell me that the latest kernel or bugfix patch screwed something up. Otherwise, I think I'll just go insane. There's no excuse for this. Linux just CAN'T be this hard, or it will NEVER succeed on the desktop. Whatever is going on, I'll take the blame. Since it's not hardware, it's got to be software, and how I manage my machines. But, MAN!, I'm not a noob. I've working with Linux for almost 10 years now, and I'm a Unix admin in my day job. It's not like I don't know what I'm doing! Problematic CD burning was the final straw with Red Hat 8.0 for me. I actually filed a bug that got to be well known on their list, but the bug remained through 9, and it's probably still in Fedora, though I'm well past caring. I guess I'm just writing this to vent my frustration. If by some miracle, someone can actually tell me how to fix this, I'll just consider myself lucky. And, yes, I Googled myself silly with these messages. I even downloaded the entire backlog of the cdrecord-support listserv. Lots of people have the problems *like* this, and apparently NO ONE has any answers, even the guy who wrote cdrecord. Post mortem: I stared at my navel for a few minutes and downgraded to the k_smp-2.4.20-100 kernel. That was it. It's apparently been that long since I tried to burn a disc. I still say that there's no excuse for this. Why did a security fix break burning CD's? Who knows. Again, this sort of thing is pretty hardware-specific, I know. Aaaargh! Sigh, dk P.S. Just in case you're still reading, here's the nonsense from the messages file, in case anyone might be able to do something with it. If someone involved with the kernel development wants to contact me, I'd work myself silly getting whatever logs or scans or whatever is needed to fix this. Jan 30 21:20:17 enterprise kernel: scsi0:0:3:0: Attempting to queue an ABORT message Jan 30 21:20:17 enterprise kernel: CDB: 0x0 0x0 0x0 0x0 0x0 0x0 Jan 30 21:20:17 enterprise kernel: >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< Jan 30 21:20:17 enterprise kernel: scsi0: Dumping Card State in Command phase, at SEQADDR 0x178 Jan 30 21:20:17 enterprise kernel: Card was paused Jan 30 21:20:17 enterprise kernel: ACCUM = 0x80, SINDEX = 0xa0, DINDEX = 0xe4, ARG_2 = 0x3 Jan 30 21:20:17 enterprise kernel: HCNT = 0x0 SCBPTR = 0x1d Jan 30 21:20:17 enterprise kernel: SCSISIGI[0x84]:(BSYI|CDI) ERROR[0x0] SCSIBUSL[0xc0] Jan 30 21:20:17 enterprise kernel: LASTPHASE[0x80]:(CDI) SCSISEQ[0x12]:(ENAUTOATNP|ENRSELI) Jan 30 21:20:17 enterprise kernel: SBLKCTL[0xa]:(SELWIDE|SELBUSB) SCSIRATE[0x15]:(SINGLE_EDGE) Jan 30 21:20:17 enterprise kernel: SEQCTL[0x10]:(FASTMODE) SEQ_FLAGS[0x0] SSTAT0[0x5]:(DMADONE|SDONE) Jan 30 21:20:17 enterprise kernel: SSTAT1[0x2]:(PHASECHG) SSTAT2[0x10]:(EXP_ACTIVE) SSTAT3[0x0] Jan 30 21:20:17 enterprise kernel: SIMODE0[0x8]:(ENSWRAP) SIMODE1[0xac]:(ENSCSIPERR|ENBUSFREE|ENSCSIRST|ENSELTIMO) Jan 30 21:20:17 enterprise kernel: SXFRCTL0[0x88]:(SPIOEN|DFON) DFCNTRL[0x4]:(DIRECTION) Jan 30 21:20:17 enterprise kernel: DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) Jan 30 21:20:17 enterprise kernel: STACK: 0x35 0xee 0x170 0x186 Jan 30 21:20:17 enterprise kernel: SCB count = 36 Jan 30 21:20:17 enterprise kernel: Kernel NEXTQSCB = 19 Jan 30 21:20:17 enterprise kernel: Card NEXTQSCB = 19 Jan 30 21:20:17 enterprise kernel: QINFIFO entries: Jan 30 21:20:17 enterprise kernel: Waiting Queue entries: Jan 30 21:20:17 enterprise kernel: Disconnected Queue entries: Jan 30 21:20:17 enterprise kernel: QOUTFIFO entries: Jan 30 21:20:17 enterprise kernel: Sequencer Free SCB List: 13 25 21 9 12 0 30 27 1 10 3 20 2 4 23 11 14 8 19 6 18 17 24 7 22 16 26 15 31 5 28 Jan 30 21:20:17 enterprise kernel: Sequencer SCB Info: Jan 30 21:20:17 enterprise kernel: 0 SCB_CONTROL[0xc0]:(DISCENB|TARGET_SCB) SCB_SCSIID[0x37] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 1 SCB_CONTROL[0xc0]:(DISCENB|TARGET_SCB) SCB_SCSIID[0x37] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 2 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 3 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 4 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 5 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 6 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 7 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 8 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 9 SCB_CONTROL[0xc0]:(DISCENB|TARGET_SCB) SCB_SCSIID[0x37] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 10 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 11 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 12 SCB_CONTROL[0xc0]:(DISCENB|TARGET_SCB) SCB_SCSIID[0x37] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 13 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 14 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 15 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 16 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 17 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 18 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 19 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 20 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 21 SCB_CONTROL[0xc0]:(DISCENB|TARGET_SCB) SCB_SCSIID[0x37] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 22 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 23 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 24 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 25 SCB_CONTROL[0xc0]:(DISCENB|TARGET_SCB) SCB_SCSIID[0x37] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 26 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 27 SCB_CONTROL[0x80]:(TARGET_SCB) SCB_SCSIID[0x37] SCB_LUN[0x0] Jan 30 21:20:17 enterprise kernel: SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 28 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 29 SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0x37] SCB_LUN[0x0] Jan 30 21:20:17 enterprise kernel: SCB_TAG[0xe] Jan 30 21:20:17 enterprise kernel: 30 SCB_CONTROL[0xc0]:(DISCENB|TARGET_SCB) SCB_SCSIID[0x37] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: 31 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x17] Jan 30 21:20:17 enterprise kernel: SCB_LUN[0x0] SCB_TAG[0xff] Jan 30 21:20:17 enterprise kernel: Pending list: Jan 30 21:20:17 enterprise kernel: 14 SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0x37] SCB_LUN[0x0] Jan 30 21:20:17 enterprise kernel: Kernel Free SCB list: 18 28 0 30 29 20 15 26 12 2 35 13 1 4 31 22 10 25 11 27 8 7 9 16 23 34 21 17 3 24 5 6 33 32 Jan 30 21:20:17 enterprise kernel: Untagged Q(3): 14 Jan 30 21:20:17 enterprise kernel: DevQ(0:0:0): 0 waiting Jan 30 21:20:17 enterprise kernel: DevQ(0:1:0): 0 waiting Jan 30 21:20:17 enterprise kernel: DevQ(0:2:0): 0 waiting Jan 30 21:20:17 enterprise kernel: DevQ(0:3:0): 0 waiting Jan 30 21:20:17 enterprise kernel: DevQ(0:4:0): 0 waiting Jan 30 21:20:17 enterprise kernel: Jan 30 21:20:17 enterprise kernel: <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> Jan 30 21:20:17 enterprise kernel: scsi0:0:3:0: Device is active, asserting ATN Jan 30 21:20:17 enterprise kernel: Recovery code sleeping Jan 30 21:20:17 enterprise kernel: (scsi0:A:3:0): Abort Message Sent Jan 30 21:20:17 enterprise kernel: (scsi0:A:3:0): SCB 14 - Abort Completed. Jan 30 21:20:17 enterprise kernel: Recovery SCB completes Jan 30 21:20:17 enterprise kernel: Recovery code awake Jan 30 21:20:17 enterprise kernel: aic7xxx_abort returns 0x2002
On Friday 30 January 2004 09:32 pm, David Krider wrote:
If by some miracle, someone can actually tell me how to fix this, I'll just consider myself lucky.
I have been reading a lot about all the problems people are having burning cd's and dvd's yet mine seems to work with nary a hitch, The one big difference is I DO NOT use the scsi emulation. Havent use it since about kernel 2.19 back in early SuSE 8.1. I got all my K3B stuff, and all the dependencies from packman via apt and ripping/burning cd's and dvd's are no-brainers. Of course I was using Yamaha cd burners and now use LG dvd burner with no problem. Guess it must be just plain dumb luck on my part! You might try removing all your current k3b and cdrecord stuff and then using apt point toward the packman site and install what they have there. So far I have found the ulb and packman sites have generally trouble free rpms. Hope this may give you some ideas. Richard
The Saturday 2004-01-31 at 00:59 -0600, Richard Atcheson wrote:
cd's and dvd's yet mine seems to work with nary a hitch, The one big difference is I DO NOT use the scsi emulation.
Read carefully: he has real scsi, he is not using scsi simulation: DK>> I have a DK>> completely-SCSI setup. ``cdrecord --scanbus'' as root sees all my DK>> hardware. -- Cheers, Carlos Robinson
On Wednesday 04 February 2004 10:41 pm, Carlos E. R. wrote:
Read carefully: he has real scsi, he is not using scsi simulation:
DK>> I have a DK>> completely-SCSI setup. ``cdrecord --scanbus'' as root sees all my DK>> hardware. Hi Carlos: That still doesnt change my answer which is I'm using ATAPI and it works. Could it be something amiss with SCSI? I don't know but it certainly is worth looking at, dont you think? Regards, Richard
On Friday 30 January 2004 18:32, David Krider wrote:
Post mortem: I stared at my navel for a few minutes and downgraded to the k_smp-2.4.20-100 kernel. That was it. It's apparently been that long since I tried to burn a disc. I still say that there's no excuse for this. Why did a security fix break burning CD's? Who knows. Again, this sort of thing is pretty hardware-specific, I know. Aaaargh!
I'm running 2.4.21-121-smp4G on a older dual Celeron, and some time ago (a couple of kernels ago actually) they broke something in scsi so that my tape-backup can't sense and of tape anymore. Wrote to Mantel about it, (its one of his kernels) but no answer. -- _____________________________________ John Andersen
John Andersen <jsa@pen.homeip.net> [Sat, 31 Jan 2004 00:52:41 -0900]:
Wrote to Mantel about it, (its one of his kernels) but no answer.
The correct address for such questions is http://www.suse.de/feedback. Hubert gets hundreds of mails per day (not only relating to the test kernels he offers) just because he has a well known mail address. That this doesn't please him should be understandable. So *please* use feedback if at all possible. Philipp
On Saturday 31 January 2004 08:19, Philipp Thomas wrote:
John Andersen <jsa@pen.homeip.net> [Sat, 31 Jan 2004 00:52:41 -0900]:
Wrote to Mantel about it, (its one of his kernels) but no answer.
The correct address for such questions is http://www.suse.de/feedback. Hubert gets hundreds of mails per day (not only relating to the test kernels he offers) just because he has a well known mail address. That this doesn't please him should be understandable. So *please* use feedback if at all possible.
Philipp
But Feedback just laughs as you when you send mail about a mantel kernel.... Catch 22. The shipped kernel does not have this problem, but the Mantel kernel does. It seemed natural to notify Mantel about his kernel. Perhaps I should notify Kernel.org, or Linus himself? Hubert's page on the ftp site said feedback was welcome. I took him at his word. -- _____________________________________ John Andersen
* David Krider <david@davidkrider.com> [01-30-04 22:30]:
I can't believe this nonsense. I have been abusing myself for something like 5 years with "Linux on the desktop," always thinking that the next release would be "it." Today, I'm trying to burn a CD. JUST BURN A CD! And on two separate -- though very similar -- computers, I'm getting the exact same nonsense. (Which is to say that it's not my hardware, both of which have worked just fine the last time I tried on each.)
I haven't burned any cd for a while and today got a new version of gnoppix, gnome knoppix. Made four coasters trying two different writers on the same box. Just on a hunch, I disabled dma to one drive and again tried to burn another copy. And it worked! David, you might try this. My box is a 733 PIII with a 133 bus and 768mb The drives are both atapi, hp9100 & PelxCombo 20/10/40-12A Both have scsi emulation The successful write was done on the plex it will never cease to amaze ...... -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org
participants (6)
-
Carlos E. R. -
David Krider -
John Andersen -
Patrick Shanahan -
Philipp Thomas -
Richard Atcheson