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.