I think so - certainly for as long as I can remember. It's kinda buried in
the cards configuration but used to be (mildly) useful if you only had a
single device as it supposedly runs a bit faster if you set "Disconnection"
to No.
I've never set it myself, only come across it causing problems!
Mark
> Mark,
>
> Amazing. I've never configure that ever. Do all the Adaptec
> cards support these settings?
>
> mht
>
> On Sat, 7 Jun 2003, Mark Bradshaw (BTOpenWorld) wrote:
>
>> Hi Frank,
>>
>> I've seen a similar problem on a StorageTek L80 with LTO drives and a
>> Windows machine. In my case the problem was with the settings made in the
>> NVRAM of the SCSI cards themselves. For whatever reason the cards had been
>> configured for disk access not tape access and gave sporadic SCSI timeouts
>> because of this. Might be worth checking....
>>
>> To check you will need to reboot your system and go into the BIOS of *each*
>> SCSI card. Don't know anything about the cards you have, but on my Adaptec
>> cards here you would select:
>>
>> - Configure/View Host Adapter Settings
>> --- SCSI Device Configuration
>>
>> Then check the setting for "Enable Disconnection" for each SCSI ID the card
>> supports. A setting of "Yes" is a good thing for tapes, a setting of "No"
>> means that you'll get lots of nasty SCSI timeouts especially if you have
>> more than one device on each SCSI channel.
>>
>> Hope this helps....
>>
>> Mark
>>
>>> hi again,
>>>
>>> It seems that i don't have any time to celebrate any little success,
>>> since it doesn't take long time for the next problem to appear :-(
>>>
>>> Since some weeks i sometimes see SCSI errors in the system log file,
>>> like these:
>>>
>>> Jun 1 12:45:12 r2d2 kernel: scsi : aborting command due to timeout : pid
>>> 213591 32, scsi2, channel 0, id 0, lun 0 Inquiry 00 00 00 ff 00
>>>
>>> In the beginning, there was only scsidev 0,0,0 (the first of five
>>> LTO ultrium tape devices) that got the error.
>>> Because i assumed the error in the SCSI card, i disabled this drive
>>> until i can contact a StorageTek professional to check it.
>>>
>>> But now i see SCSI errors on all five tape devices. The tapes are
>>> distributed to three Tekram DC-390U3W cards.
>>> So i don't think that the cards are causing the errors, but i don't
>>> have any clue where to search now.
>>>
>>> Additionally to the above entry, i'm getting a lot of these now:
>>>
>>> Jun 4 08:40:30 r2d2 kernel: sym53c1010-33-0-<6,*>: target did not report
>>> SYNC.
>>> Jun 4 08:40:31 r2d2 kernel: scsi : aborting command due to timeout : pid
>>> 30973041, scsi5, channel 0, id 4, lun 0 Inquiry 00 00 00 f f 00
>>> Jun 4 08:40:31 r2d2 kernel: sym53c8xx_abort: pid=30973041
>>> serial_number=30972996 serial_number_at_timeout=30972996
>>>
>>>
>>> I know this is slightly off-topic, but it's a great problem for me,
>>> and btw. NetWorker of course refuses to work if a tape devices keeps
>>> hanging in the 'verifying label' state due to scsi timeouts...
>>>
>>> Well, to the hardware:
>>>
>>> 3 x Tekram DC-390 U3W Ultra 160 SCSI cards
>>> 5 x IBM LTO Ultrium drives, builtin to a StorageTek L700 tape library
>>> 1 x ASUS PR-DLSW Dual Intel Xeon-based motherboard
>>> 2 x Intel Xeon 2 GHz
>>> 1 x 1024 MB RAM
>>> 1 x Redhat Linux 7.3 (Valhalla)
>>>
>>> [root@r2d2 root]# cat /proc/scsi/scsi
>>> Attached devices:
>>> Host: scsi0 Channel: 00 Id: 05 Lun: 00
>>> Vendor: easyRAID Model: F8 Rev: 0001
>>> Type: Direct-Access ANSI SCSI revision: 03
>>> Host: scsi0 Channel: 00 Id: 06 Lun: 00
>>> Vendor: STK Model: L700 Rev: 0301
>>> Type: Medium Changer ANSI SCSI revision: 03
>>> Host: scsi2 Channel: 00 Id: 00 Lun: 00
>>> Vendor: IBM Model: ULTRIUM-TD1 Rev: 27Q1
>>> Type: Sequential-Access ANSI SCSI revision: 03
>>> Host: scsi2 Channel: 00 Id: 01 Lun: 00
>>> Vendor: IBM Model: ULTRIUM-TD1 Rev: 27Q1
>>> Type: Sequential-Access ANSI SCSI revision: 03
>>> Host: scsi2 Channel: 00 Id: 02 Lun: 00
>>> Vendor: IBM Model: ULTRIUM-TD1 Rev: 27Q1
>>> Type: Sequential-Access ANSI SCSI revision: 03
>>> Host: scsi5 Channel: 00 Id: 03 Lun: 00
>>> Vendor: IBM Model: ULTRIUM-TD1 Rev: 27Q1
>>> Type: Sequential-Access ANSI SCSI revision: 03
>>> Host: scsi5 Channel: 00 Id: 04 Lun: 00
>>> Vendor: IBM Model: ULTRIUM-TD1 Rev: 27Q1
>>> Type: Sequential-Access ANSI SCSI revision: 03
>>>
>>> With kind regards,
>>>
>>> Frank Altpeter
>>>
>>> --
>>> Note: To sign off this list, send a "signoff networker" command via email
>>> to listserv AT listmail.temple DOT edu or visit the list's Web site at
>>> http://listmail.temple.edu/archives/networker.html where you can
>>> also view and post messages to the list.
>>> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
>>
>> --
>> Note: To sign off this list, send a "signoff networker" command via email
>> to listserv AT listmail.temple DOT edu or visit the list's Web site at
>> http://listmail.temple.edu/archives/networker.html where you can
>> also view and post messages to the list.
>> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
>>
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
