ioscan -M to force a driver selection

[Ian M]

I am running a Qualstar TLS4440 tape library with 2 Sony AIT2 drives (SDX-500C). This unit was a hand-me-down from another office that outgrew it and was originally configured on a Solaris Box.

It was no problem getting the unit to work and run backups, but hardware compression has been another battle.

I located updated drivers for HP direct from Sony. The install went easily and the drivers are loaded at boot time. However the drives keep "attaching" themselves with the 'stape' driver instead of the 'sony_tape' that was installed.

I've read up what I could find (not much more than the man pages) on using ioscan to force a driver to a specific hardware path but I want to confirm the syntax for a hardware path.

Based on a module name of 'sony_tape' and the command 'ioscan -d stape' showing:
H/W Path Class Description
=================================================
0/0/1/0.1.0 tape SONY SDX-500C
0/0/1/0.2.0 tape SONY SDX-500C

Should the commands be:

ioscan -M sony_tape -H 0.1.0
ioscan -M sony_tape -H 0.2.0

That almost seems too easy...and "confidence is often the feeling you have before you understand".

I've got a very limited maintenance window starting late in the evening and with reboots of this server taking 15+ mins, I want to be sure I don't have to make too many attempts!

Thanks in advance for any info and assistance.

[RAC_1]

while you syntax seems ok, why don't you check your device files??

Run lssf on every device file and check what those reports. One of then should be reporting best density, compression etc.

Use appropraite file for compression.

Anil

[Ian M]

When I check the standard device files using lssf I get:

# lssf /dev/rmt/1m*
###########
stape card instance 0 SCSI target 1 SCSI LUN 0 at&t best density available at address 0/0/1/0.1.0 1m
stape card instance 0 SCSI target 1 SCSI LUN 0 berkeley best density available at address 0/0/1/0.1.0 1mb
stape card instance 0 SCSI target 1 SCSI LUN 0 at&t no rewind best density available at address 0/0/1/0.1.0 1mn
stape card instance 0 SCSI target 1 SCSI LUN 0 berkeley no rewind best density available at address 0/0/1/0.1.0 1mnb
###########

or using

# mt -f /dev/rmt/1m status
###########
Drive: SONY SDX-500C
Format:
Status: [0]
File: 9
Block: 0
###########

No mention of compression either way. (For brevity I only showed rmt/1m, rmt/2m returns the same).

Now, when I use mt to check the pre-existing DLT8000 drive this is replacing, I get:

# mt -f /dev/rmt/0m status
###########
Drive: QUANTUM DLT8000
Format:
Status: [41118985] BOT online compression immediate-report-mode
File: 0
Block: 0
###########


This one mentions compression. lssf however returns basically the same info as the AIT drives, only different hardware addresses.

[RAC_1]

run lssf on 0m drives and check if it reports compression device files.

We may need to create one.

[Ian M]

The output of lssf /dev/rmt/0m* seems to be identical to that of /dev/rmt/1m* and 2m*:

#############
stape card instance 6 SCSI target 6 SCSI LUN 0 at&t best density available at address 0/12/0/0.6.0 /dev/rmt/0m
stape card instance 6 SCSI target 6 SCSI LUN 0 berkeley best density available at address 0/12/0/0.6.0 /dev/rmt/0mb
stape card instance 6 SCSI target 6 SCSI LUN 0 at&t no rewind best density available at address 0/12/0/0.6.0 /dev/rmt/0mn
stape card instance 6 SCSI target 6 SCSI LUN 0 berkeley no rewind best density available at address 0/12/0/0.6.0 /dev/rmt/0mnb
#############

[RAC_1]

I think the best density is what the compression is. Put the tape in sony drive, and it should report same thing as of other drive.

[Ian M]

All drives report "best density" that has not tied into better compression though. I've tried using both the Berkley and ATT device files with the same result.

Qualstar's website points to the Sony site the drivers come from, and from other posts in the forums it seems that HP does not support AIT itself.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=335447

That's why I went looking for drivers from Sony, and installed them. During the install there were new device files created:

/dev/rmt/1sonym
/dev/rmt/1sonymb
/dev/rmt/1sonymn
/dev/rmt/1sonymnb

(and matching /dev/rmt/2sony*)

However, when I use lssf on those files, I receive the following error from all of them:
#########
lssf /dev/rmt/1sony*
lssf: Don't know how to handle driver "sony_tape"
lssf: Don't know how to handle driver "sony_tape"
lssf: Don't know how to handle driver "sony_tape"
lssf: Don't know how to handle driver "sony_tape"
#########

Which brings me back to getting the 'sony_tape' driver working properly and my question about forcing it to bind to the correct hardware.

Obviously I don't know for sure (or I wouldn't be here looking for tips), but it seems that trying to get standard HP device files and the stape driver to work might be a lost cause.

[RAC_1]

Does your sony_tape drive has a LED that says compression?
The "best density" device files will automatically switch on the data compression
, provided drive supports it.

Otherwise, every time you boot, you will have to bind sony_tape driver to sody tape drives and use them.

[Sudeesh]

Hi,
Few years back I faced same issue. HP suggested binding the device specific driver manually to that hardware path using /stand/system. This required a kernel rebuild. I was successful in doing this.

Explicit Device Driver Bindings

One or more driver to hardware path specifications is allowed. If a driver statement is provided, the specified software module is forced into the kernel I/O system at the given hardware path. This can be used to make the system recognize a device that could not be recognized automatically.

driver hw_path driver_name
Bind the driver into the kernel I/O system at the given hardware path. Arguments are interpreted as follows:

hw_path The hardware path representing the device to bind the software with.

driver_name The name of the software module to bind into the kernel at the specified hardware path.

1. cd /stand/build
/usr/lbin/sysadm/system_prep -s /stand/build/system

2.vi /stand/build/system : add
driver 0/0/1/0.1.0 sony_tape

3./usr/sbin/mk_kernel -s /stand/build/system
4.mv /stand/system /stand/system.prev
5.mv /stand/build/system /stand/system
6./usr/sbin/kmupdate


Sudeesh

[Ian M]

Sudeesh,

This looks like the long term solution I was hoping for. It was not apparent to me that using ioscan was a temporaty change.

I do have a question though (since I've never manually worked on a kernel in HP-UX before):

Would you expect that the kernel size would change? I notice that the old and new kernels are the same size:

$ ls -l vmunix build/vmunix_test
-rwxr-xr-x 1 root sys 18533920 Aug 11 14:41 build/vmunix_test
-rwxr-xr-x 1 root sys 18533920 Feb 10 2005 vmunix

I know this is adding reference to an external driver and not really changing the kernel, but it's not what I was expecting. Is that normal?

[Ian M]

Hmm. Something went wrong.

I got the following error during the rebuild:

$ /usr/sbin/mk_kernel -s /stand/build/system
Generating module: krm...
cpp: "./tune.h", line 197: warning 2019: Missing or illegal macro name.
Generating module: sony_tape...
Compiling conf.c...
cpp: "tune.h", line 197: warning 2019: Missing or illegal macro name.
Loading the kernel...
Generating kernel symbol table...

Line 197 is:

#define 0 0

---

I tried to boot off the new kernel and the Oracle DB was core dumping on startup and crashing over and over. Back to the old kernal and all is OK now.

I've not found anything relevant to explain what happened on line 197. May not be significant but it's the only error I recevied. Can anyone shed light on the problem?