Networker

Re: [Networker] Red Hat ES 4 tape driver

2007-03-15 09:14:14
Subject: Re: [Networker] Red Hat ES 4 tape driver
From: Davina Treiber <DavinaTreiber AT PEEVRO.CO DOT UK>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Thu, 15 Mar 2007 13:11:34 +0000
I can confirm that Dag's solution works fine. I am using Gentoo Linux with a 2.6 kernel, and after patching according to Dag's instructions the annoying delay on nsrjb is gone.


Ronny Egner wrote:
Librado Pamintuan schrieb:
Hello to all,
We just recently upgraded from RH ES 3 to RH ES 4 using a Dell PowerEdge 2850 server. Our tape library is an ADIC Scala 100 with 2x IBM LTO-2 Ultrium tape drives. Somehow after the upgrade, when I issue nsrjb commands and inquire, it will take at least 5 minutes before it starts doing anything. On the previous version I was advised to use the IBM Tape driver for the tape drives, but with the new O/S here is what Tech. Support wants me to do (obviously they don't know anything about the Legato binaries, so I will just ignore that part).
Any comment or suggestions is greatly appreciated.

thanks in advance,

Librado Pamintuan
Technical Support Analyst II
Information Systems Div.
Operations Group
City of Regina

Phone:          (306) 777-7573
General Fax: (306) 777-6804
eFax:             (306) 546-6002
eMail:            lpamintuan AT regina DOT ca

Red Hat Global Support Services <noreply AT redhat DOT com> 13/Mar/2007 10:28:05 am >>>


---------------------------------------
|  Case Information  |
---------------------------------------
Case Title       : missing devices RHEL 4
Case Number      : 1336376
Case Open Date   : 12-MAR-2007
Problem Type     :
Last Update Comment as of 13-MAR-2007 12:28:05 : After taking a look at your sysreport, it looks like you still have all of the tape stuff install:

IBMtape
lgtoman
lgtoclnt
lgtonode
lgtoserv
lgtodrvr

You will need to remove all of these, reboot, and let anaconda rescan. To access your tape library, you will need to install the mtx package (up2date mtx) and use the mtx command to handle which drive is being controlled.

Patrick Connelly
RHCE
---------------------------------------

Thank you for your latest interaction with Red Hat Support. If you wish to reach Red Hat, please go to http://support.redhat.com/ for phone and web contact information appropriate to your region and support contract.

Red Hat Global Support Services is working a case associated to this email address as the primary point of contact. For tracking purposes, the case has been assigned a number of "1336376" and has the title "missing devices RHEL 4" . More information related to this specific case is attached to this message. If any of this is in error, please notify us immediately by calling our support line at the number specific to your region see https://www.redhat.com/support/service/GSS_phone.html


The purpose of this email is to notify you that the status of this case has transitioned to "Waiting On Customer" This means that the Red Hat associate working on this case may need more information from you in order to continue working on your case. Its critical that you please reply in a timely manner via the web portal at http://support.redhat.com.

If you update the case via the web portal (such as adding a note or adding an attachment), the case status will change back to "Waiting on Red Hat" and the Red Hat systems will route the case back to the Red Hat associate working on your case.

Note: Please do not reply to this email. If you wish to reach Red Hat, please go to http://support.redhat.com for phone and web contact information appropriate to your region and support contract.

Thank you so much and have a great day.


Red Hat Global Support Services




Hi,

In general *only* Networker 7.3.x is certified for Kernel
2.6 (i.e. SLES9, RedHat 4, and so on). I assume you are not using
Networker 7.3.x.

For Networker other than 7.3.x Dag Nygren wrote:


If you take a look at the st-driver you will see that if the open() is not
done with the flag O_NONBLOCK the driver will block for ST_BLOCK_SECONDS.

The easiest way to change this is to always add the O_NONBLOCK
flag to the open() call. In other words add a line with:

filp->f_flags |= O_NONBLOCK;

immediately at the start of the st_open() function.


[...]

In another post:



More info on this:

I just ran into a Suse installation myself and also noticed that Novell has
seen the timeout as a problem as they have patched the driver themselves. There is
an extra option to the st module that will achive the same thing called:
blocking_open.

In other words the problem can be fixed (in Suse only) by adding the
optionline:
options st buffer_kbs=256 max_sg_segs=128 blocking_open=0

to /etc/modprobe.conf.



--> From my point of view this might be a point to look at.


To sign off this list, send email to listserv AT listserv.temple DOT edu and type 
"signoff networker" in the body of the email. Please write to networker-request 
AT listserv.temple DOT edu if you have any problems with this list. You can access the 
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

<Prev in Thread] Current Thread [Next in Thread>