getting lan card to work -- HP 11.00 - missing btlan5 driver

[Kristopher March]

HP 11/ VClass server.

I've got this card installed:
--------------------------------------------------------------

lan 2 5/0/0 btlan UNCLAIMED UNKNOWN PCI Ethernet (10110019)

--------------------------------------------------------------

I attempted to install PHNE_25580, because I was informed that particular card should be using the btlan5 driver. During installation, I got the following:
--------------------------------------------------------------

NOTE: The patch fileset "PHNE_25580.100BT-FORMAT,r=1.0" may only be
installed upon a previously installed base fileset. The
specification for this base fileset is
"100BT-PCI-FMT.100BT-FORMAT,fr=B.11.00.01,v=HP". Since there
is no fileset on the target or selected from the source which
matches this specification, fileset
"PHNE_25580.100BT-FORMAT,r=1.0" will be excluded.
NOTE: The patch fileset "PHNE_25580.100BT-INIT,r=1.0" may only be
installed upon a previously installed base fileset. The
specification for this base fileset is
"100BT-PCI-RUN.100BT-INIT,fr=B.11.00.01,v=HP". Since there is
no fileset on the target or selected from the source which
matches this specification, fileset
"PHNE_25580.100BT-INIT,r=1.0" will be excluded.
NOTE: The patch fileset "PHNE_25580.100BT-KRN64,r=1.0" may only be
installed upon a previously installed base fileset. The
specification for this base fileset is
"100BT-PCI-KRN.100BT-KRN64,fr=B.11.00.01,v=HP". Since there
is no fileset on the target or selected from the source which
matches this specification, fileset
"PHNE_25580.100BT-KRN64,r=1.0" will be excluded.
NOTE: The patch fileset "PHNE_25580.100BT-RUN,r=1.0" may only be
installed upon a previously installed base fileset. The
specification for this base fileset is
"100BT-PCI-RUN.100BT-RUN,fr=B.11.00.01,v=HP". Since there is
no fileset on the target or selected from the source which
matches this specification, fileset
"PHNE_25580.100BT-RUN,r=1.0" will be excluded.

--------------------------------------------------------------

I honestly don't know what those messages mean exactly. I've been reading other posts here and some have mentioned installing a product from the HP CD. A5???somthing. I'm wondering if I should go this route next? My next oppurtunity is this Sunday so I'm looking for a quick solution.

I'd like to get off the existing Combo card we're using to see if it helps with some other problems we're having.

[Biswajit Tripathy]

The error is clearly explained by the following
statement:
----
"PHNE_25580.100BT-FORMAT,r=1.0" may only be
installed upon a previously installed base fileset. The
specification for this base fileset is
"100BT-PCI-FMT.100BT-FORMAT,fr=B.11.00.01,v=HP".
-----

You are trying to install a patch for a product that
is not installed on your system. You should be
looking for "btlan5" driver and install it. Once you
install the btlan5 driver, you would be able to install
the patch.

- Biswajit

[Sanjay_6]

Hi,

Looks like you first need to install the driver for the card. This should be on the application cd 1 of the application cd set for your version of OS. The depot bundle to be installed would bbe named same as the card. Say your card model is Axxxxx, then the s/w bundle to install fom the app cd 1 is Axxxxx.

Once you have installed the driver, then try to install the patch.

Hope this helps.

Regds

[Sanjay_6]

Hi,

This might help you in identifying the type of card on your system and the s/w bundle you need to install,

http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000073094363

The itrc doc id is N100BKBRC00009660.

Hope this helps.

Regds

[A. Clay Stephenson]

You first need to install the driver/LAN software appropriate to your card. These are found almost always on Disk 1 of any Applications CD Set. After you install the software, you should then be able to install the patch.

[Kristopher March]

Great! I mistakenly thought that PHNE_25580 patch was going to install the btlan5 driver.

Makes sense now. Thanks all.

[Kristopher March]

Can I knock out the software install (from CD) now without a reboot of the machine?

[Sanjay_6]

Hi,

I do not think so. The installation of this s/w would most likely rebuild the kernel and you'll have to reboot.

Hope this helps.

regds

[A. Clay Stephenson]

No, the driver install will require a reboot as well as the patch you mentioned. You need to wait until you have a scheduled downtime.

[Kristopher March]

Sanjay - good document. That will help me.

I hope to get this working on Sunday.

One last question: can the driver software be located somewhere other than the CD?

[Sanjay_6]

Hi,

The driver should be on application CD 1 of the application CD set. If you have the latest set of application CD, you should find the driver there. If we knew the type of card you have, we might have been in a better position to say something about the driver.

Normally, all the lan card drivers are on cd 1.

Hope this helps.

Regds

[A. Clay Stephenson]

I can't recall installing your particular card but it is possible though unlikely that that software is codeword protected. In that case a swinstall -s /cdrom would not list the package but a swlist -s cdrom would. If swlist displays it but swinstall does not then you will need to get a codeword after noting the part no. of the disk on which you found the package. Look at more than Disk 1 because the rule is than LAN9000 software is almost always found on Disk 1.

[Kristopher March]

At this point, I'm trying to determine which card we have installed.

Also, I have the Application CD's from yr 2000. I saw a part number on the cd's but there not in front of me.

[rick jones]

Others have already pointed-out the business about the driver. You should also make sure that when you patch the driver you get any dependent patches at the same time.

To see which card you have installed, you might try an "ioscan -fk" command, perhaps piping that to a grep of "lan"

The btlan5 driver drives the single-port RJ45 NIC. The btlan6 driver drives the combo card, and the btlan3 driver drives a "core" 10/100.

Now, having said that, once you upgrade to 11.11 (11i) those drivers are all merged into one, which is included in the core OS.

You mentioned you wanted to try this card to see if it resolved a problem you were having with an existing card - just what problem were you having?

[Kristopher March]

Rick - thanks. FWIW, installing the A5230A bundle from the #1 App Cd did not load the btlan5 driver into the kernel. I don't know why, it just didn't. I got HP Support to assist me this morning. I loaded J4253AA (which was not listed on the document provided above) from #1 App Cd and rebooted. At that point, I was able to see and configure the 10/100 card with an IP address and use it. :-) :\)

QUOTE: "You mentioned you wanted to try this card to see if it resolved a problem you were having with an existing card - just what problem were you having? "

Looking at our netstat output, we were not sure why we had so many retransmitts. I know this generally indicates a network issue, but our guys say we're clean in that area.

netstat -p tcp --> (uptime 47mins)
tcp:
14455 packets sent
7854 data packets (907599 bytes)
42 data packets (12789 bytes) retransmitted
6600 ack-only packets (224 delayed)
0 URG only packets
0 window probe packets
0 window update packets
1225 control packets
20125 packets received
7475 acks (for 908088 bytes)
517 duplicate acks
0 acks for unsent data
14172 packets (2012250 bytes) received in-sequence
0 completely duplicate packets (0 bytes)
29 packets with some dup, data (15385 bytes duped)
220 out of order packets (97824 bytes)
0 packets (0 bytes) of data after window
0 window probes
11779 window update packets
1 packet received after close
0 segments discarded for bad checksum
0 bad TCP segments dropped due to state change
358 connection requests
253 connection accepts
611 connections established (including accepts)
670 connections closed (including 90 drops)
90 embryonic connections dropped
6956 segments updated rtt (of 6956 attempts)
20 retransmit timeouts
0 connections dropped by rexmit timeout
0 persist timeouts
0 keepalive timeouts
0 keepalive probes sent
0 connections dropped by keepalive
0 connect requests dropped due to full queue
121 connect requests dropped due to no listener



What prompted a look at these numbers was another issue we're having with excessive HTTP 404 errors on our Sun web server. The web server makes a connection to the HP. So we've been pulling out our hair looking at everything from network resources/parameters to process resources, etc.

That's the jist of it. We're on the new card with our existing IP address, but there isn't any load on the system to get real testing out of it.

[rick jones]

That is a fairly high retransmission rate - I didn't check the out of order rate. Might take a look at the lanadmin statistics - make sure there are no late collisons or FCS errors, those may indicate a duplex mismatch.

ftp://ftp.cup.hp.com/dist/networking/briefs/annotated_netstat.txt

I'm not sure if I have put an annotated_lanadmin.txt out there or not.

[Kristopher March]

I'm throwing up the latest numbers:

netstat -p tcp
tcp:
101470451 packets sent
64492401 data packets (4094781550 bytes)
1776601 data packets (2016583543 bytes) retransmitted
37917744 ack-only packets (1735282 delayed)
0 URG only packets
359 window probe packets
978043 window update packets
16619 control packets
104070017 packets received
31172921 acks (for 4094769380 bytes)
14094826 duplicate acks
0 acks for unsent data
57897681 packets (1001452059 bytes) received in-sequence
14 completely duplicate packets (18065 bytes)
298 packets with some dup, data (278085 bytes duped)
7991401 out of order packets (2651652476 bytes)
1721717 packets (1922655424 bytes) of data after window
25341 window probes
58753310 window update packets
69 packets received after close
0 segments discarded for bad checksum
0 bad TCP segments dropped due to state change
5465 connection requests
2301 connection accepts
7766 connections established (including accepts)
8686 connections closed (including 947 drops)
931 embryonic connections dropped
29394109 segments updated rtt (of 29394109 attempts)
12792 retransmit timeouts
9 connections dropped by rexmit timeout
359 persist timeouts
278 keepalive timeouts
278 keepalive probes sent
1 connection dropped by keepalive
80 connect requests dropped due to full queue
1655 connect requests dropped due to no listener

%uptime
11:20am up 23:53, 1 user, load average: 0.13, 0.11, 0.10

LAN INTERFACE STATUS DISPLAY
Sun, Jan 9,2005 11:21:39

PPA Number = 2
Description = lan2 Hewlett-Packard 10/100 TX Full-Duplex Manual TT = 1500
Type (value) = ethernet-csmacd(6)
MTU Size = 1500
Speed = 100000000
Station Address = 0x306eeab43f
Administration Status (value) = up(1)
Operation Status (value) = up(1)
Last Change = 77365
Inbound Octets = 205306642
Inbound Unicast Packets = 1231554
Inbound Non-Unicast Packets = 31259
Inbound Discards = 908
Inbound Errors = 6734
Inbound Unknown Protocols = 0
Outbound Octets = 656814605
Outbound Unicast Packets = 1365618
Outbound Non-Unicast Packets = 908
Outbound Discards = 30
Outbound Errors = 0
Outbound Queue Length = 0
Specific = 655367

Ethernet-like Statistics Group

Index = 3
Alignment Errors = 0
FCS Errors = 6734
Single Collision Frames = 0
Multiple Collision Frames = 0
Deferred Transmissions = 0
Late Collisions = 0
Excessive Collisions = 0
Internal MAC Transmit Errors = 0
Carrier Sense Errors = 0
Frames Too Long = 0
Internal MAC Receive Errors = 0

I've never noticed the FCS Errors until you mentioned it, Rick.

I'll be looking at this more tomorrow.

[rick jones · Accepted solution]

I suspect you indeed have a duplex mismatch. The NIC is hardcoded to FD, and there are FCS errors - likely as not either the switch is set for auto, or hardcoded to HD.

When one side is hardcoded, and the other tries to auto, auto fails (per spec) and the side doing auto must go into HD (again per spec).

My initial inclination is to let the NIC autoneg and see what happens. Only if you find that after patching the driver (assuming it sin't up to date) and switch and determining that the switch is irrevocably fubar :) would I suggest hardcoding both sides to the same values.

The reason I am not fond of hardcoding is simple - rearrange the cables at the switch and poof, chaos and siaorder. Or, bring-in a new system and forget to hardcode its NICs when all the switch ports are hardcoded... etc etc

[Kristopher March]

Guess what, we discovered a duplex mismatch at the switch. It was HD.

Thanks, Rick, and to everyone else for helping me with this.

[Kristopher March]

Rick, I have no noticed that we have 80 connections dropped due to full queue.

We have tcp_conn_request_max set to: 10240 -- Is this even a valid number for this parameter?

What else to check?

4:11pm up 3 days, 4:44, 2 users, load average: 0.14, 0.16, 0.20

tcp:
194393282 packets sent
124823232 data packets (3584632568 bytes)
3386155 data packets (3814260020 bytes) retransmitted
71457622 ack-only packets (3371491 delayed)
0 URG only packets
385 window probe packets
1926046 window update packets
67786 control packets
199169936 packets received
61708261 acks (for 3584302023 bytes)
27034004 duplicate acks
0 acks for unsent data
111084919 packets (3189765120 bytes) received in-sequence
174 completely duplicate packets (27000 bytes)
803 packets with some dup, data (541921 bytes duped)
15356106 out of order packets (3054282903 bytes)
3269122 packets (3621843472 bytes) of data after window
56373 window probes
110308974 window update packets
162 packets received after close
0 segments discarded for bad checksum
0 bad TCP segments dropped due to state change
17469 connection requests
14844 connection accepts
32313 connections established (including accepts)
35661 connections closed (including 3498 drops)
3289 embryonic connections dropped
58304645 segments updated rtt (of 58304645 attempts)
30679 retransmit timeouts
60 connections dropped by rexmit timeout
385 persist timeouts
667 keepalive timeouts
667 keepalive probes sent
9 connections dropped by keepalive
80 connect requests dropped due to full queue
5760 connect requests dropped due to no listener
udp:
0 incomplete headers
0 bad checksums
0 socket overflows
ip:
7427665 total packets received
0 bad IP headers
0 fragments received
0 fragments dropped (dup or out of space)
0 fragments dropped after timeout
0 packets forwarded
0 packets not forwardable
icmp:
4588 calls to generate an ICMP error message
8 ICMP messages dropped
Output histogram:
echo reply: 4218
destination unreachable: 362
source quench: 0
routing redirect: 0
echo: 0
time exceeded: 0
parameter problem: 0
time stamp: 0
time stamp reply: 0
address mask request: 0
address mask reply: 0
0 bad ICMP messages
Input histogram:
echo reply: 1449
destination unreachable: 350
source quench: 0
routing redirect: 0
echo: 4218
time exceeded: 20
parameter problem: 0
time stamp request: 0
time stamp reply: 0
address mask request: 0
address mask reply: 0
4218 responses sent
igmp:
4 messages received
0 messages received with too few bytes
0 messages received with bad checksum
0 membership queries received
0 membership queries received with incorrect fields(s)
0 membership reports received
0 membership reports received with incorrect field(s)
0 membership reports received for groups to which this host belongs
4 membership reports sent

[rick jones]

Remember that the depth of the listen queue will be the minimum of _two_ things:

1) tcp_conn_request_max

and

2) the value the application sets in the listen() call

having said that, 80 out of the number of connections reported is rather small...

BTW, it would be good to start using snapshots over intervals and the beforeafter tool - many of the counters are still 32 bit and can roll-over.