latst amird driver and lsi 320-xx raid cards
brian_at_aljex.com
Date: 01/30/05
- Previous message: Boyd Lynn Gerber: "UnixWare 7.x.x (OpenUNIX 8) Frequently Asked Questions (FAQ)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 30 Jan 2005 02:30:18 -0800
Just had a doozy I figured I'd publicize the final fix.
keywords: amird 2.24 btldinstall upgrade update boot fail
I received several new servers from my vendor with LSI MegaRaid 320-1,
320-2, and 320-2X cards in them, and as a matter of course I verified
that the raid cards firmwares were up to date as well as the driver in
the OS. I've had a few problems with these cards before and updating
the firmware fixed them.
The OS (osr 5.0.6 and 5.0.7) turned out to have amird version 2.18
installed, and the lsi web site offers 2.24 in btld floppy form.
So I btldinstall, relink, and after that the box can't boot.
Specifically, the kernel loads and can't find th host adapters nor any
disks on them.
The fix was found after doing a fresh install using the newer btld
floppy and noticing a difference between the mscsi files on two
identical hardware and OS version boxes.
under the old driver, a single adapter card, from any model in the
series, with a single logical drive configured, would result in a line
like this in /etc/conf/cf.d/mscsi
amird Sdsk 0 0 0 0
under the new driver, without changing anything else about the systems
hardware or software, the same line in mscsi needs to be changed, and
the change is different depending of the model of controller. I only
know 3 examples:
if the adapter is a 320-1, the the above line needs to be changed to:
amird Sdsk 0 16 0 0
if the adapter is a 320-2 or 320-2X then the above line needs to be
changed to:
amird Sdsk 0 32 0 0
If you have more adapters then the other numbers in the line only
change the same way they normally would, example, I have one box,
5.0.6, with both a 320-2X and a 320-1, and the 320-2X is the boot array
and is detected as adapter 1 (2nd adapter)
so mscsi on that box used to look like this:
amird Sdsk 1 0 0 0
amird Sdsk 0 0 0 0
the same box, without changing any hardware or doing anything to the
raid arrays like reinstalling or reconfiguring in the bios or anything,
had to be manually edited to look like this and a kernel relinked:
amird Sdsk 1 32 0 0
amird Sdsk 0 16 0 0
Another box that is all the same except it has a 320-2 instead of a
320-2X, needed the same mscsi as this. The same box, with the 320-1
removed so that the 320-2 or 2X is detected as adapter 0 instead of
adapter 1, still needed the ID field to say "32"
If you boot from unix.old or simply make the changes before rebooting
in the first place, run link_unix, then all is well.
I found this by doing fresh installs with the newer btld on identical
boxes and looking for differences. Later I discovered that the magic
number "16" or "32" shows up in the initial kernel hardware detection
and you don't actually have to go through an install or even a full
boot, and so don't need a spare box, just your existing box and the sco
install cd and the new btld and crash out of the install once you've
read the number from the kernel boot messages.
disk vec=- dma=- type=S ha=0 id=16 lun=0 bus=0 ht=amird
These numbers don't make any sense to me either. I think it must be a
bug in the driver. The disks and logical drives involved are NOT scsi
target id 16 or 32, they are 0 in all cases and this behaviour does not
agree with any manuals or on-screen prompts anywhere. I don't know what
ID you are supposed to use when you add another logical drive. IE, if
real id 0 is called 16 or 32 by the driver depending on adapter model,
what is real 1? 17/33? or 15/31?
- Previous message: Boyd Lynn Gerber: "UnixWare 7.x.x (OpenUNIX 8) Frequently Asked Questions (FAQ)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
