Reprobe unused SCSI Controller (Fiber obtical)

H

holm

Hi guys,

I have an 13.2-stable system running 24/7 and I have an fiber optical SCSI Controller with 2 channels in the system:
Code: 
isp0@pci0:38:0:0:       class=0x0c0400 rev=0x03 hdr=0x00 vendor=0x1077 device=0x2432 subvendor=0x1077 subdevice=0x0138
    vendor     = 'QLogic Corp.'
    device     = 'ISP2432-based 4Gb Fibre Channel to PCI Express HBA'
    class      = serial bus
    subclass   = Fibre Channel
isp1@pci0:38:0:1:       class=0x0c0400 rev=0x03 hdr=0x00 vendor=0x1077 device=0x2432 subvendor=0x1077 subdevice=0x0138
    vendor     = 'QLogic Corp.'
    device     = 'ISP2432-based 4Gb Fibre Channel to PCI Express HBA'
    class      = serial bus
    subclass   = Fibre Channel
A while ago I've tested successfully an IBM Ultrium5 Drive that came from an decommissioned TIVOLY Robot.
I could tar to and from the drive, set modes with mt and eject the cartridges..all good.

My problem is that I don't want do power the tape drive all the time, I've planning to build an Power switch
with an SSR so that the tape cold powered up and down from the System. No Problem so far, but since the drive
isn't detected at boot time, it doesn't get listet with camcontrol devlist, even the SCSI busses aren't listed so
that I couldn't do an camcontrol rescan or some such to get the drive online.
How can I kick the controller to reprobe it's busses?

Kind Regards,
Holm
 
It's been at least a decade since I last played with FC hardware. How is the drive connected to the HBA? Using a point-to-point connection, arbitrated loop, or on a fabric? If it is a fabric, you need to teach the switch in the fabric to do discovery for you. On a Brocade, that's done with the CLI-based user interface, and I don't remember the details at all. Then the switch has to tell the HBA that there is news, and I remember fighting lots of incompatibilities there. On the other hand, if it is point-to-point or arbitrated loop (either using looped fibers, which is quite unusual, or a loop hub), then in theory all devices on the loop (or the other side of the point-to-point) should see the status change, and report a LIP event. Try this: Make the system idle and quiescent, power up the drive without connecting it, then plug and unplug the fiber repeatedly. On the console, dmesg should be spitting out messages about LIPs. And everytime you plug the drive in, it should auto-create the /dev/ entry. I've done this A LOT (used to have dedicted ear-muffs for working in fibre channel labs), and I've seen it work.

If that fails, I would have a really nasty suggestion: Try the same thing on a good Linux distribution (RedHat, Suse) which has good support for the QLogic HBA. If you don't see LIP and auto-discovery there, then the QLogic firmware is probably not capable of supporting things; the fight to get the firmware upgraded might be really ugly. If you see LIPs there but not on FreeBSD ... then it gets even darker and uglier.

"How can I kick the controller to reprobe its busses"? In theory, you should not need to. If all pieces of the hardware, the HBA firmware and the OS device driver are up to snuff, it should just work. On Linux, there are tricks with writing certain things to bizarre files in /proc which cause the low-level SCSI subsystem to force a rescan, but (a) I don't know where these things are in FreeBSD, and (b) they shouldn't be needed. The LIP event should take care of it.
 
It's connected with a point to point connection, there is no other devise connected to the HBA.
The Problem IS that there is no other device, therefore ist no bus listet from camcontrol at all.

I don't have any computer where I cold put in an PCI Express HBA..and there is not other OS than FreeBSD
on my platters, so it's difficult to try something with Linux and sorry, I don't even know what a LIP
Event could be..

Regarding isp(4) the controller firmware gets loaded from the driver (ispfw(4)).

When I boot the machine with the tape powered up the controller and the drive are getting detected properly.
I can shut off and on the tape after that..and use it as I want .. since there is a bus that I can reset/reprobe with camcontrol.
The Problem is an reboot w/o an powered tape, there is no bus to reprobe at all... I have to shutdown the machine..don't think that it is meant that way..

Regards,
Holm
 
I just spent 15 minutes looking around, even finding the theory of ops for the isp driver, and there is nothing about forcing a rescan I can find.

I wonder what would happen if you unload the isp kernel module, then reload it (after the tape drive has been powered up). There are kldunload commands for that. Worth trying ... at worst you crash the machine (and then have to reboot, which you had to do anyway).
 
Currently I have the driver compiled in, so I have to build a kernel w/o it. Ok, I'll try that.
I remember some time ago one could hard wire a SCSI drive in a kernel to prevent mixing
up da0 against da1 when da1 is powered up before da0. Could something like this prevent
the SCSI bus from disappearing and does this feature still exist?

Regards,
Holm
 
You must log in or register to reply here.
Back
Top