- Integrated Systems
- About Us
- Integrated Systems
- About Us
12-30-2007 02:08 PM
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?
Solved! Go to Solution.
12-31-2007 04:49 AM
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*
12-31-2007 05:18 AM
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?
12-31-2007 07:47 AM
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.
12-31-2007 12:28 PM
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.
01-02-2008 12:40 AM
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
01-02-2008 04:27 AM
I'm with Pieter. More than likely the kernel configuration file (/sys/conf/
Just building a new kernel won't add this line in...
Hope this helps,
01-02-2008 06:18 AM
check the EVA configuration for the HOST.
ensure all fibre ports are defined and correct.
Operating System Type must be Tru64 UNIX
the default is WINDOWS and this fails on tru64.
01-08-2008 02:32 AM
For some unknown reason the update was not made and the new kernel generated didn't provide the F/C support.
01-08-2008 05:41 AM
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 :-),
01-08-2008 09:24 AM
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.
01-15-2008 04:53 AMSolution
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
# 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