![]() |
Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Thanks Tony, It does appear to be an issue with the default CentOS/RHEL Brocade driver. I was able to reverse engineer the installer for IBMs RHEL version, and it works fine once the OEM driver is in place. On Tue, Mar 6, 2012 at 3:00 PM, Tony Koker <tkoker at gmail.com> wrote: > Jason, > > It sounds like a config/driver issue. If there was an arbitrated loop > or hardware issue you would most likely not see LUNs at all. > Not any experience with CentOS, but this seems like issues we've had > with Linux (RHEL and Solaris, even Windows) before. > Also haven't used Brocade HBA, but Emulex and QLogic. Still seems like > config/driver though. > > with gratitude and in service, > Tony Koker > ~~~~~ > > > On Tue, Mar 6, 2012 at 1:19 PM, Jason Normand <jay at lentecs.com> wrote: > >> We are working on setting up some new hardware for our db servers, but I >> am >> having trouble getting the Fibre Channel LUN recognized by CentOS 5.7. We >> are running on an IBM x3550 with dual Brocade HBAs, and have them >> connected >> to an IBM DS3524 with dual controllers. Each controller is direct >> attached >> to one HBA. I am able to get Cent to see the LUN if i power cycle the >> controllers, however it will not see it after a system reboot. The HBAs >> are recognized after reboot but rescanning the scsi bus does not help. >> Only a power cycle on the controllers or a reset of the LUN will get Cent >> to recognize it. >> >> Now I have little experience with Fibre Channel and was looking for some >> pointers in the right direction. Does this sound like a hardware issue or >> a Cent config/driver issue? >> >> Thanks >> Jason >> _______________________________________________ >> Discuss mailing list >> Discuss at blu.org >> http://lists.blu.org/mailman/listinfo/discuss >> > >
![]() |
|
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |