Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a serious problem with a SAN storage array connected to a Linux box through Fibre Channel. Here is the configuration :

  • Debian with plain vanilla linux 2.6.27.25
  • Fibre controller QLogic 4Gb dual port ( ISP2432 based)

Basically the problem is: how to get this #?@!! FC controller/driver to recognize properly configuration changes (new or removed LUNs) of the storage array?

  1. when I create a new LUN on my array (typically a snapshot of some existing LUN) and map it to my HBA, I can't get it recognized properly : rescan-scsi-bus -l -w -r actually detects something ( a generic /dev/sgXX device) however no block device is created ( /dev/sdXX).
  2. same thing when issuing a LIP and rescan manually:

    echo 1 > /sys/class/fc_host/host6/issue_lip

    echo "- - -" > /sys/class/scsi_host/host6/scan

  3. if I remove an existing LUN, neither issuing LIPs and rescans or rescan-scsi-bus have any effect. The previous devices remain there and of course don't work ( "file -s /dev/sdXX -> I/O error").

  4. reloading the qla2xxx driver works. However it's completely unworkable in a production environment.

Apparently this is a very common problem with QLogic. Some sort of solution exists that works only when using the QLogic issued driver available only for RedHat and Suse enterprise distros : see this explanation.

Additional info :

Here is the scsi devices before LIP and rescan:

# sg_map -x
/dev/sg0  0 0 0 0  0  /dev/sda
/dev/sg1  0 0 1 0  5  /dev/scd0
/dev/sg2  1 0 0 0  0  /dev/sdb
/dev/sg3  6 0 0 0  0  /dev/sdc
/dev/sg4  6 0 0 1  0  /dev/sdd
/dev/sg5  6 0 0 2  3

After a LIP and rescan, I have a new sg device, but no matching drive. If I reload the driver, a drive appear:

# sg_map -x
/dev/sg0  0 0 0 0  0  /dev/sda
/dev/sg1  0 0 1 0  5  /dev/scd0
/dev/sg2  1 0 0 0  0  /dev/sdb
/dev/sg3  6 0 0 0  0  /dev/sdc
/dev/sg4  6 0 0 1  0  /dev/sdd
/dev/sg5  6 0 0 2  3
/dev/sg6  6 0 0 3  3

~# sg_map -x
/dev/sg0  0 0 0 0  0  /dev/sda
/dev/sg1  0 0 1 0  5  /dev/scd0
/dev/sg2  1 0 0 0  0  /dev/sdb
/dev/sg3  8 0 0 0  0  /dev/sdc
/dev/sg4  8 0 0 1  0  /dev/sdd
/dev/sg5  8 0 0 2  0  /dev/sde
/dev/sg6  8 0 0 3  3

Edit: OK, obviously this is a tough nut to crack. I'll ask the LKML and report here.

share|improve this question
    
That QLogic issued driver you're talking about can be compiled for other distros too -- it isn't a binary blob. –  Captain Segfault Aug 14 '09 at 17:15
    
Fine, where can I find it then? I compiled the whole kernel, one more driver isn't a problem at all. –  wazoox Aug 14 '09 at 20:08
    
I'm having this problem, did you manage to find out anything? –  ThatGraemeGuy Jun 13 '12 at 11:21
    
Sorry, no info yet. –  wazoox Jun 15 '12 at 15:30

2 Answers 2

In the off chance that the block device is being detected, but no /dev/ device is being created, you can manually create the device. This isn't optimal, but might limp you along. The major and minor numbers are presented in /proc/partitions, and you can create your own block devices through the mknod command.

 # mknod /dev/sdg4 104 17

However, I feel your pain. QLogic offers driver download for RHEL and SUSE but it seems no other distros. OpenSUSE just might have the QLogic-branded drivers but I can't be certain of it. I'll check closer when I get to work.

Edit: I'm at work, and it does seem that the QLogic drivers on my SLES boxes are all the QLogic supplied one. Their OS support grid:

http://filedownloads.qlogic.com/files/Driver/71098/readme_driver_80223.html#os_support

And yet, when I download the bog-standard 2.6.27.25 kernel and look in the ./drivers/scsi/qla2xxx/qla_version.h file it is nearly the same version numbers as I have on my Novell distros (both SLES, and the free openSUSE). Which suggests that the solution you found for SLES/RHEL may actually work with a standard 2.6.27.25 kernel.

share|improve this answer
    
Unfortunately it can't work, because it mention using a file that is non existent ( /proc/scsi/qla2xxx/...) and a command (scsi-qlascan) that doesn't appear in the driver source code. –  wazoox Aug 14 '09 at 20:11

Hey Wazoox I was faceing same pro with my SAN box i have google and some tips which follow if can try i think it will start working 1 there is one tools call emcgrab tools u can run this tool to find out the driver of your qlogic driver is working or not.

which san box r u using?

there are some tips as follow.. http://forums.novell.com/novell-product-support-forums/suse-linux-enterprise-server-sles/sles-configure-administer/362473-lun-not-visible.html

http://forums13.itrc.hp.com/service/forums/bizsupport/questionanswer.do?admit=109447627+1250262043169+28353475&threadId=1154098

http://www.linuxquestions.org/questions/linux-enterprise-47/connect-debian-etch-to-ibm-san-meaning-of-sns-scan-failed-570598/

http://solutions.qlogic.com/KanisaSupportSite/search.do?cmd=displayKC&docType=kc&externalId=9223615&sliceId=SAL%5FPublic&dialogID=4725381&stateId=0%200%204711370

share|improve this answer
    
Yes, lots of tips on google but most if not all of them are about RedHat/SuSe and the Qlogic proprietary driver... However one of your links gave me an idea, I'll be back :) –  wazoox Aug 14 '09 at 20:15
    
Well, uh, I tried with the latest firmware, but no luck... –  wazoox Aug 14 '09 at 20:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.