DEGPA-TA on ES40 version 4.0G

[Mohamed K Ahmed]

Hi all,

I have installed a new NIC copper card DEGPA-TA to an ES40 system running Tru64 UNIX version 4.0G latest patch
The documentation on this card says it is supported under 4.0G, but while booting the system, I get the following message:

" DEGPA-TA has no matching in the PCI table"

ANy suggestions?

Mohamed

[Ralf Puchner]

For UNIX:
During installation of DEGPA driver, only one adapter per PCI bus allowed. After installing target kernel, additional adapters may be installed on same PCI bus. Rebuilding kernel not necessary.
v4.0F:
Patch Kit 6 (BL17): DUV40FAS0006-20010620.tar required. See most up-to-date patch information.
v4.0G:
Patch Kit 3 (BL17): T64V40GAS0003-20010613.tar required. See most up-to-date patch information.
v5.0A:
Patch Kit 2: T64V50AAS0002-20001004.tar required. See most up-to-date patch information.
v5.1:
Patch kit 1: T64V51AS0002-20001204.tar required. See most up-to-date patch information.

[Mohamed K Ahmed]

What you mean is I have to take out all NIC adaptors that are on the same bus as the DEGPA?
Can I place the other NIC cards on other bus (I have model 2 ES40 with 10 PCI slots)

OR

You mean any adapter

Mohamed

[Ralf Puchner]

It means only one DEGPA-TA is allowed during first installation!

[Mohamed K Ahmed]

Yeah, Now I got it, I have another DEGPA-SA (fiber NIC card) just above the DEGPA-TA.

I will move the card to the other bus and try again.

One last question, I have another ES40 but running OpenVMS7.3-1, I have the cards DEGPA-SA and DEGPA-TA in two consecutive slots, but they are working, so this rule only applies for UNIX??

Mohamed

[Ralf Puchner]

This instruction is for DEGPA-TA only. The information for DEGPA-SA for unix is:

Only ONE DEGPA-SA per PCI bus allowed during driver installation. After driver installation, additional adapters may be added to the same PCI bus

There is no restriction for OpenVMS (DEGPA-TA and SA).

[Mohamed K Ahmed]

The UNIX system has the following

PCI 1 slot 3 DEGPA-SA
PCI 1 clot 4 DEGPA-TA

and the DEGPA-TA is not recognizable by the system with the message " DEGPA-TA has no matching in the PCI table" while booting the system

Would this be becasue they are on the same bus?

Mohamed

[Ralf Puchner]

please split the adapter across the pci busses. A gigabit card is very cpu and bandwith intensive. The whole limit of a pci bus is 132MB/s splittet over the cards.

please install the named patchkit and reboot with generic kernel. If problem persists, remove the second adapter.

[Dave Bechtold]

Hi Mohamed,

This error is generally returned when the PCI ID for the card is not what we expected when quired from the driver or the pci_option_data.c is missing or incorrect. The pci_option_data.c is provided i nthe latest PK 4. Try the following:


- Make sure the latest Patch installed (PK4) has the following subset installed - OSFPAT00111100445.
# setld -i | grep OSFPAT001111

OSFPAT00111100445 installed Patch: (SSRT1-45U, SSRT2439, SSRT2341, SSRT0740U
)(Security Related Patches)

- Make sure you boot "genvmunix" and see if the same error is reported. If not, you need to run "doconfig" to rebuild the kernel and build in the device.

- From the SRM Console execute "SHOW CONFIG" and review the information for the DEGPA and let me know how it is reported. It should show-up as a "DEGPA-TA". We have had reports that the PCI ID on some of the earlier options was incorrect and under SHOW CONFIG it reported incorrectly, not as "DEGPA".

FYI... the DEGPA-** uses the alt.mod driver, so it should show-up as alt0 for the first instance of the card/option.

Hope that helps,
Dave Bechtold

[Mohamed K Ahmed]

Dave,

It is strange, I just noticed that this security Patch did not install for the following reason:


Problem installing:

- Tru64_UNIX_V4.0G / Security Related Patches:
Patch 01111.00 - (SSRT1-45U, SSRT2439, SSRT2341, SSRT0740U)
./usr/lbin/adm_lk:
its origin can not be identified.

./usr/lbin/binex:
its origin can not be identified.

./usr/lbin/cliscript4:
its origin can not be identified.

./usr/lbin/getswxcrrev:
its origin can not be identified.

./usr/lbin/ra200info:
its origin can not be identified.

./usr/lbin/sysconf:
its origin can not be identified.

./usr/sbin/sys_check:
its origin can not be identified.

This patch will not be installed.
-------------------

* The following 3 patch(es) failed in prerequisite/file applicability check:

Press RETURN to proceed...

- Tru64_UNIX_V4.0G / Filesystem Patches:
Patch 00050.00 - Prevents vold from dumping core

- Tru64_UNIX_V4.0G / Security Related Patches:
Patch 00621.00 - Corrects buffer overflow problem
Patch 01111.00 - (SSRT1-45U, SSRT2439, SSRT2341, SSRT0740U)

And there are other patches that were related to it and didn't get installed either.

how can I install these lost patches

Mohamed

[Dave Bechtold · Accepted solution]

Hi Mohamed,

OK, makes sense now.

I suspect the system has a newer version of sys_check installed, like 1.29 or higher, that's where the "files of unknown origin" are from.

You have 2 options.

1) Remove the newer version of Sys_Check (setld -d), re-install the patch, then re-install sys_check.

2) Run dupatch and select to Baseline feature to enable these files to be over-written. Then install the patch.

Hope that helps,
Dave Bechtold

[Mohamed K Ahmed]

What does sys_check has to do with the cards, sorry i can't get a connection here
Can you clarify?

I am planning to move the card to another bus this weekend

Mohamed

[Michael Schulte zur Sur]

Hi,

sys_check has nothing to do with the cards, but dupatch cheks, if all command are as it assumes, so it does not bring inconsistencies into the os, when patching.
Since sys_check is newer, it does not match the info dupatch expects.

hence the error,

Michael

[Dave Bechtold]

Hello,

The installation of the newer version of sys_check caused the patch to not completely install. When the patch did not install you did not get the updated/supported driver for the NIC. It's a domino effect of dupatch and prerequsite patches.

Hope that helps,
Dave Bechtold

[Mohamed K Ahmed]

I solved this problem and thought about giving you a summary of what I did...
- I uninstalled sys_check
- moved the card to a different bus
- ran dupatch and based-line the system
- reinstalled the patch kit, it accepted all the patches including Patch 1111 and all related ones
- The card was seen ok

Everything works fine now, Thanks for Dave and Mike for their support

Mohamed

[Mohamed K Ahmed]

Oh....Thanks for Ralf too :))

[Douglas Walker]

I noticed that you mentioned the use of the alt.mod driver for degpa cards. I don't seem to have that file and when I try to compile the new kernel is lets me know. Where do you get this driver file?

[Mohamed K Ahmed]

Douglas,
When you plug in teh card , see what t is called, or what does the system sees it as.
Some of my systems see it as bcm0 and some others sees it as alt0

Mohamed

[Douglas Walker]

From the console it shows as a alt0.

[Mohamed K Ahmed]

What version of UNIX do you have, there are requirements for this card like certain version and patches

How do you build the Kernel?
From the Console
P00> boot -fl s -fi /genvmunix
BUILD A NEW KERNEL AND REPLACE THE OLD ONE
REBOOT THE SYSTEM

check if it is seen

[Douglas Walker]

I am still running 40D due to app reqs. I have done the kernel rebuild (doconfig -c ipsaxp) but the card is still not showing in the OS. When I added the psuedo-device alt to the config file i keep getting an error about alt.mod not being there.

[Douglas Walker]

Here is the error I get when I try to compile:

# doconfig -c IPSAXP2

*** KERNEL CONFIGURATION AND BUILD PROCEDURE ***

Saving /sys/conf/IPSAXP2 as /sys/conf/IPSAXP2.bck

Do you want to edit the configuration file? (y/n) [n]:


*** PERFORMING KERNEL BUILD ***
Working....Thu Apr 8 16:01:50 EST 2004

*** WARNING ***
An error has occurred during system configuration. A partial listing
of the error log file (./errs) follows:

cc -c -O2 -DLANGUAGE_C -std0 -g3 -G 4 -I -I. -I.. -I../include -DIDENT=IPSAXP2 -DDEC4100 -DSWAPTYPE=1 -DUERF -DMACH -DOSF -DCOMPc
cc -c -O2 -DLANGUAGE_C -std0 -g3 -G 4 -I -I. -I.. -I../include -DIDENT=IPSAXP2 -DDEC4100 -DSWAPTYPE=1 -DUERF -DMACH -DOSF -DCOMPc
cc -c -O2 -DLANGUAGE_C -std0 -g3 -G 4 -I -I. -I.. -I../include -DIDENT=IPSAXP2 -DDEC4100 -DSWAPTYPE=1 -DUERF -DMACH -DOSF -DCOMPc
cc -c -O2 -DLANGUAGE_C -std0 -g3 -G 4 -I -I. -I.. -I../include -DIDENT=IPSAXP2 -DDEC4100 -DSWAPTYPE=1 -DUERF -DMACH -DOSF -DCOMPc
cc -c -O2 -DLANGUAGE_C -std0 -g3 -G 4 -I -I. -I.. -I../include -DIDENT=IPSAXP2 -DDEC4100 -DSWAPTYPE=1 -DUERF -DMACH -DOSF -DCOMPc
cc -c -O0 -DLANGUAGE_C -std0 -g3 -G 4 -I -I. -I.. -I../include -DIDENT=IPSAXP2 -DDEC4100 -DSWAPTYPE=1 -DUERF -DMACH -DOSF -DCOMPc
cc -c -O2 -DLANGUAGE_C -std0 -g3 -G 4 -I -I. -I.. -I../include -DIDENT=IPSAXP2 -DDEC4100 -DSWAPTYPE=1 -DUERF -DMACH -DOSF -DCOMPc
rm -f IPSAXP2.mod
ld -dc -r -o IPSAXP2.mod vm_init.o init_main.o ipc_globals.o lockinfo.o alpha_init.o pmap_init.o startup.o steal_mem.o scb.o bootio
sh ../conf/newvers.sh ../conf/copyright `cat ../conf/version.type ../conf/version.major ../conf/version.minor ../conf/version."
cc -c -O2 -DLANGUAGE_C -std0 -g3 -G 4 -I -I. -I.. -I../include -DIDENT=IPSAXP2 -DDEC4100 -DSWAPTYPE=1 -DUERF -DMACH -DOSF -DCOMPc
rm -f vmunix vmunix.sys
loading vmunix.sys
ld:
Can't open: alt.mod (No such file or directory)
*** Exit 1 (ignored)
chmod 755 a.out
chmod: a.out: No such file or directory
*** Exit 4

Any ideas on this?

[Michael Schulte zur Sur]

Hi Douglas,

from the first posting of Ralf I assume that 4.0F is minimum requirement for your card. Please crosscheck with your documentation.

greetings,

Michael

[Douglas Walker]

The Degpa-SA card is supposed to work with 40D and I did get the kernel to compile by morving the alt.mod file into the IPSAXP directory first.

[Mohamed K Ahmed]

Douglas,
I thought you were talking about a DEGPA-TA (The copper geg NIC card)...
Any way, glad that it worked with you.
Next time, Please, post a new message in the forum, especially if your question is regarding soething else than discussed in the original question

Regards

Mohamed