Aarrgh - it was a hardware failure. <excuses> As this disk was fresh out of the box, I did not give much consideration to the possibility it was the source of the problem. More exotic sources of failure were so much more tempting. :) Also, I did not have access to a replacement until just yesterday. </excuses> The new disk (an identical model, also fresh out of the shrink wrap) was recognized properly at all levels. This time, during device discovery, the new disk (scsi1:0:1:0) was automatically mapped to the sdb device file name. I subsequently was able to partition it and create and mount a filesystem. For the record, I did try moving the SCSI id of the original disk from '0' to '1', but with no effect. I did not try the new disk at '0'. Scrutiny of the dmesg output below will show that Linux relocated my pre-existing external disk (scsi2:0:1:0) from sdb to sdc, due to the hierarchy of device mapping and SCSI id values. Brief panic ensued on boot when the OS tried and failed to mount the filesystem of this other disk to its 'old' device (sdb). Also get a load of that transfer rate (80MB/s! via LVD adapter, disk, _and_ terminator). Experimenting with a single-ended terminator dropped the negotiated throughput of the channel down to 40MB/s. dmesg output: <snip> (scsi1:0:1:0) Synchronous at 80.0 Mbyte/sec, offset 15. Vendor: SEAGATE Model: ST136475LC Rev: 0001 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sdb at scsi1, channel 0, id 1, lun 0 (scsi2:0:1:0) Synchronous at 20.0 Mbyte/sec, offset 15. Vendor: SEAGATE Model: ST34371N Rev: 0484 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sdc at scsi2, channel 0, id 1, lun 0 <snip> Thanks for all the input. -Mark -- To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject.
