ES80+EVA3000

[Michael Schulte zur Sur]

Hi all,

I installed 5.1B PK5 on an ES80 and have a problem. The ES80 does see a presented disk only if booted with genvmunix. Building a new kernel does not help. Can anyone help me?

Michael

[Hein van den Heuvel]

[Ah, duplicate to 1189057. This seems a better place. Since the drives are visible with genvmunix, we may conclude that this is NOT and EVA nor ES80 Alphaserver problem, but strictly an TRU64 issues. Hein]

Are some EVA luns visible?

What does hwmgr -show scsi (-full) show?

One 'normally' does not need to rebuild a kernel for new fibre scsi devices. Not even a reboot needed. Just use hwmgr:

# hwmgr -scan scsi
# hwmgr -show scsi


Since yiou rebuilt the kernel.. did you put it in place as /vmunix?
# ls -l /*vmunix*

Good luck!
Hein.

[Michael Schulte zur Sur]

Dear Hein,

thanks for your post. It seems indeed to be a pure TRU64 problem. When I presented the vdisk to a WIN2k3 server, it saw it right away.
When I boot the normal kernel, the disks show up but as invalid, with no path.
I did place the kernel in /.
hwmgr -scan and show did not change anything.
I have seen in another post hwmgr -scan comp cluster used but I do not have access to the machine right now.
The ES80 has firmware 7.2 or 7.3.
The FCA-2684 involved has 2.14 as much as I can remember.
The ES80 has 8 cpus and 32GB memory.
We use a HP switch with 8 ports and 2GB speed.
Right not the machine runs on the genvmunix, which I copied to vmunix.
Any more ideas?

Michael

[Hein van den Heuvel]

Michael,
I'd like to understand a little more about the history to perhaps explain what you are seeing.
Like whether you ever used an EVA device with that kernel. That is, are you just trying to add an additional lun, or is this a first usage. Is there anything else succesfully being used on the fibre adapter.

>> When I boot the normal kernel, the disks show up but as invalid, with no path.

This is with hwmgr? It knows what they are, how big and such, but no path huh? Does it list a WWID. hwmgr -get attribute -id X ?
I'd be tempted to delete those HWID's and scan again.

Sounds like the device database is confused, but I'm not sure at what point the files used by genvmunix start to differ from the regular kernel. I would think the same device special files are used.

You most likely used 'doconfig -c NAME'.
What if you drop the -c and build a whole new kernel. Will that work?
Maybe someone overly aggresively tuned the config to remove/disable components which were not expected to be needed?

I've never used doconfig -d, but supposedly that option is there for a reason. Might it help?

Maybe you can share some relevant hwmgr output in a text attachment

As you see, no firm answers. Sorry. Just places I'd look or thinks I woudl try.

Good luck,
Hein.

[Michael Schulte zur Sur]

Hein,

thanks again. I do not have access to the machine at the moment. So I can tell you only what I did. I installed 5.1B and NHD7 which included PK5. I have not made any changes in the sysconfigtab in the direction you mentioned. The first time, the machine saw the devices was when I used genvmunix. When I switched back to vmunix, the dsfmgr did not show the devices and mount failed with errors.
When I switch back to genvmunix, everything is alright again. hwmgr -scan completes successfully under vmunix but does not see any additional devices.
I will try doconfig when possible and look into the -d option.
Until then, thanks for your efforts.

Michael

[Pieter 't Hart]

Michael,

from what you report i read the bootdisk is NOT on the EVA. is that correct?
then it looks like even though the HBA is present in the system, support for this device is not yet build into the kernel.
you allready use genvmunix at this moment, so
use "sizer -n (filename)" and compare the created config file with that used to build the kernel.
or use "sizer -m" with the old kernel

Pieter

[Rob Leadbeater]

Hi Michael,

I'm with Pieter. More than likely the kernel configuration file (/sys/conf/) is missing the line:

config_driver emx

Just building a new kernel won't add this line in...

Hope this helps,

Regards,

Rob

[jim owens_1]

genvmunix is able to bypass some problems that make a normal kernel fail.

check the EVA configuration for the HOST.

ensure all fibre ports are defined and correct.

most important...

Operating System Type must be Tru64 UNIX

the default is WINDOWS and this fails on tru64.

[Chris Ellam]

The problem is that sysconfigtab has not been updated with the emx entries. Both NHD7 and/or PK5 should have done this as both include the latest definitions for the newer F/C controllers and the new genvmunix built by NHD7 has the support and worked.

For some unknown reason the update was not made and the new kernel generated didn't provide the F/C support.

[Hein van den Heuvel]

Chris, you sound authorative. Did you work with Michael and establish this to be a fact, or is this your best bet basde on other systems perhaps?

I thought Jim also had a pretty good suggestion with the EVA host type setting.
That would nicely explain the device being visible to windoze yet not to the rebuild vmunix. But it would require genvmunix to be less 'picky' about device attributes than the real kernel which would be a surprise kinda.

fwiw (not much :-),
Hein.

[Michael Schulte zur Sur]

Hi all,

thanks for posting. For those waiting for points, I have no access to the machine now, so I will have to wait to check on the qualitity of the posts.

@Rob, I have looked into the config file and I remember having seen the config_driver emx line.

@Jim, the fibre ports are defined correctly and the OS is defined as Tru64. Wouldn't Tru64 fail also in genvmunix, if it weren't so?
The 2/8 EL Fibre Switch from HP is seeing both ends.

@Chris, what do you suggest? Going for PK6?

@Hein, your statement also makes sense.

Please have patience, I will return as soon as possible.

Michael

[Chris Ellam · Accepted solution]

Hallo Hein and Michael,

my answer was based on previous experience where a newly installed F/C controller was not recognized by the current Kernel. I also had problems with new Tru64 installs where the OS CD Kernel didn't recognize my F/C world. I fixed this by creating my own OS Install CD where I provided some additional scripts and a newer generic kernel based on NHD7.

I was also at this customer site and after going through my old notes and looking at a sysconfigtab that I had from another ES80 with an EVA3K found that if I added the following to emx: in sysconfigtab and then used doconfig to create a new kernel, replaced the old one and rebooted.

I also looked in /sys/data/pci_option_data.c to check that it had been updated to HDH7 and had the new entries for bcm and emx options.

#
# KGPSA Fibre Channel Adapter
#
emx:
# PCI_Option = PCI_SE_Rev - 0x210, Vendor_Id - 0x10df, Device_Id - 0x1ae5, Driver_Name - emx, Type - A, Adpt_Config - N
# PCI_Option = PCI_SE_Rev - 0x210, Vendor_Id - 0x10df, Device_Id - 0xf700, Driver_Name - emx, Type - A, Adpt_Config - N
# PCI_Option = PCI_SE_Rev - 0x210, Vendor_Id - 0x10df, Device_Id - 0xf800, Driver_Name - emx, Type - A, Adpt_Config - N
# PCI_Option = PCI_SE_Rev - 0x210, Vendor_Id - 0x10df, Device_Id - 0xf900, Driver_Name - emx, Type - A, Adpt_Config - N
# PCI_Option = PCI_SE_Rev - 0x210, Vendor_Id - 0x10df, Device_Id - 0xf980, Driver_Name - emx, Type - A, Adpt_Config - N
# PCI_Option = PCI_SE_Rev - 0x210, Vendor_Id - 0x10df, Device_Id - 0xfa00, Driver_Name - emx, Type - A, Adpt_Config - N

[Michael Schulte zur Sur]

Hi all,

Chris solution worked.

thanks for posting!

Michael