Hi Jeff, Thanks for the quick reply. >> sym53c8xx: at PCI bus 3, device 12, function 0 >> sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up) >> sym53c8xx: 53c875 detected with Symbios NVRAM >> sym53c875-0: rev 0x26 on pci bus 3 device 12 function 0 irq 5 >> sym53c875-0: Symbios format NVRAM, ID 7, Fast-20, Parity Checking >> sym53c875-0: on-chip RAM at 0xfeafd000 >> sym53c875-0: restart (scsi reset). >> sym53c875-0: Downloading SCSI SCRIPTS. >> scsi1 : sym53c8xx-1.7.3c-20010512 >> blk: queue dc299c18, I/O limit 4095Mb (mask 0xffffffff) >> Vendor: SONY Model: SDT-7000 Rev: T306 >> Type: Sequential-Access ANSI SCSI revision: 02 >> blk: queue dc299a18, I/O limit 4095Mb (mask 0xffffffff) >> Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0 >> sr0: scsi3-mmc drive: 32x/32x writer dvd-ram cd/rw xa/form2 cdda tray >> st: Version 20030406, bufsize 32768, max init. bufs 4, s/g segs 16 >> Attached scsi tape st0 at scsi1, channel 0, id 0, lun 0 >> sym53c875-0-<0,*>: FAST-10 SCSI 10.0 MB/s (100.0 ns, offset 15) >> sym53c875-0: detaching ... >> sym53c875-0: resetting chip >> scsi : 1 host left. > Have you checked the scsi ID on both devices?? If they are the same it > WILL NOT work. I realize that, but am still in the early stages of testing, and only physically connect one device at a time (shutting down and powering off, before moving the cable to the other device). In the example above, the DAT was connected to the SCSI bus, and the DVD-RAM connected via IDE. Fedora allocated scsi0 to the 'SCSI host adapter emulation for IDE ATAPI devices' and scsi1 to the 53c875 hardware controller. The DVD-RAM is on (virtual) ID 0 of scsi0 and the DAT is on ID 0 of scsi1, so there should not be a conflict. I tried not connecting anything to the secondary IDE port; scsi0 is still assigned to emulation (with no devices), and the tape on scsi1 still does not work. Also tried the tape on ID 1, to no avail. I discovered that the problem is related to the 'detaching ...' that occurs. If I manually modprobe the adapter, the device gets attached again and it is accessible :) Unfortunately, this is not a complete workaround, because e.g. running Hardware Browser causes it to get detached again. Any ideas on why the detach occurs? Thanks, Stewart
