Disk IDs (instances) changed when I installed a new mem carrier in RP5470?

[Brian M Rawlings]

I installed the second memory carrier and some additional RAM in an RP5470 chassis, running HP-UX 11i.

Upon powering up and watching the self-tests & boot process, the new memory was identified OK, but when LVM tried to activate the VGs, two of the four external Fibre Channel connections to the EMC Symmetrix array couldn't see any devices.

Upon looking into this with ioscan, it turns out that two of the FC adapter instances changed to new numbers (had been 6,8,10,12, now 6,8,14,16). All the old device files in /dev/dsk were still there, along with new ones for the "new" controllers.

I know this happens when you add or rearrange I/O cards, but can anyone explain why adding a memory carrier (the second of a possible two) and some additional memory might have caused this to happen?

Correcting the physical path info was not difficult, but it would be better not to have issues like this crop up unbeknownst, as it were. And for two of the four HBAs to exhibit the symptom is very strange. The PCI slots in use were 9,10,11, and 12 in this 12-slot chassis (top four slots).

Hypothesis is OK, may shed some light, but if anyone has seen this happen, I'd like to hear from you. Moreso if you can offer a real reason for the instance number change(s).

Thanks in advance! --bmr

[John Payne_2]

Occasionally, (Hopefully not very often, anymore...) when someone makes changes on our Storageworks EVA, the device numbers will change for the LUN's on a machine. (I think I have gotten them to stop doing this...) They did this twice to me on production data. On the EVA, you can take a LUN and present it in any number of premeutations of the order fo the LUNS. They added another LUN and presented it as LUN 1 and shifted all the others by 1. (They didn't think this would be a problem...) The device numbers changed, and viola! the volume groups went down.

Memory has a single path, and shouldn't change your id's on the machine.

Hope it helps

John

[Brian M Rawlings]

Hello, don't everybody chime in at once... Has nobody else had this happen? HP Guys? Bueller? Bueller? ...

[paul courry]

He's right. Memory carrier is a red herring.

Now I'm wondering where all the HPUX pirahnas have gone? Feeding on the Slammer worms? or helping their M$ admins patch their systems? (yet again...)

[Dietmar Konermann]

The kernel uses the /etc/ioconfig during bootup to determine if HW is "old" or "new".

If the HW path (as seen in ioscan) is already found in the ioconfig then it is considered as "old". If the HW path is not present, then it is considered as "new".

"old" HW adopts its old instance number, found in the ioconfig also.

"new" HW gets the next free instance number for its HW class respectively. "free" means "not already used" in the ioconfig file.

So if you get new instances assigned then either the HW paths changed or the /etc/ioconfig file was somehow corrupted and re-constructed during bootup.

Best regards...
Dietmar.

[Brian M Rawlings]

Paul: I tend to agree, but there is one and only one guy who admins this server, and its attached EMC box... and he says no LVM or EMC changes were made. He maintains this assertion under considerable duress (threats of bodily harm), so I tend to believe him.

Dietmar: thanks for the confirmation, that's what I had understood as far as instance number generation. Since each HW class has its own series of instance numbers, even if adding a memory carrier adds a second path to memory (another "device" under the memory category), that shouldn't change the FC HBA instances... right?

If nobody else has ever seen this (memory addition changing HBA instance numbers, which cause the "c#" in /dev/dsk/C?t?d? to change), and this is neither commonplace nor an expected or understood behavior, I'll have to chalk it up to the old "something changed, but the issue didn't show up until a reboot exposed it" answer.

I hate it when that happens. I prefer the explanation that "A Klingon ship entered the system, decloaked, hit us with a tachyon beam, cloaked, and left the system." Prove it didn't happen...

Anyone else? Anyone who's seen this behavior from a memory addition? Even from a CPU addition or other speculation or explanation?

Thanks for the consideration so far, I'd just like to rule this out as "normal behavior".

Regards, --bmr

[Dietmar Konermann]

The instances should not have changed, unless some HW paths changed.

You're talking about "had been 6,8,10,12, now 6,8,14,16". So I would be interested in the contents of your current ioconfig file, epspecially what HW paths occupy the slots for 10 and 12.

You can EMail the iconfig to me and I will have a look. Simply to forename.surname@hp.com.

Best regards...
Dietmar.