upgrade kernel + hp driver bcm5700

[Rob Mokkink]

I installed RHEL 4 on a dl360 g4.
I used the bcm5700 driver from hp instead of the tg3 driver, because that driver is no good.

But how about kernel updates.

If i update the kernel will the module bcm5700 still exists or do i need to reinstall it again.

[Vitaly Karasik_1]

you need to reinstall it.

(*sometimes* you can just copy binary module from your old kernel, but in general you should recompile)

[Rob Mokkink]

I thought that.
But the biggest concern for me is after i update the kernel and reboot the linux server.

I have to get a network connection.
Then i want to rebuild.

(and maybe reboot)

[Vitaly Karasik_1]

you can upgarde kernel sources first, make new binary module (AFAIK, you should hack makefile for this because by default make uses running kernel version), and after this you can reboot into new kernel with the new module.
It should work, but...

The second option is to edit modprobe file and put tg3. so after reboot with your new kernel you'll have network.

[Rob Mokkink]

i think i can use KERNELSOURCE variable or some kind of other tweak for this.

[Vitaly Karasik_1]

you should read make scripts. In fact, I don't remember - may be it just uses what you have under /usr/src/linux-2.6

[Rob Mokkink]

I looked it up:

make -C

I am curious when RHEL will have good drivers for the Broadcoms, the tg3 driver behave strange sometimes.

Problems with speed and duplex etc. etc.

[rick jones]

Given that Broadcom have ceased work on bcm5700 and have begun maintaining tg3 instead, it would probably be a really good idea to engage support and have the problems you are having with tg3 resolved.

Which, BTW, are what exactly?

[Rob Mokkink]

Its very difficult to let the tg3 module to be set to 100mb full duplex.

Even with options in /etc/modprobe.conf

Also on heavy load, network connection is lost.

So i will wait for the tg3 driver to be a 100% stable before i will switch to it.

I browsed the forum and have seen more problems with tg3.

[Alan_152]

Upgrade to rhel4u3 -- you'll find that the drivers you need have been tweaked a little bit in u3.

[rick jones]

Is it _really_ necessary to be hardcoding duplex settings? 99 times out of 10 I've found that folks still hardcoding are doing so more out of habit than actual need, and when one goes to gigabit speeds autoneg is required.

Some boiler-plate I bring-out from time to time on the topic of duplex:

How 100Base-T Autoneg is supposed to work:

When both sides of the link are set to autoneg, they will "negotiate"
the duplex setting and select full-duplex if both sides can do
full-duplex.

If one side is hardcoded and not using autoneg, the autoneg process
will "fail" and the side trying to autoneg is required by spec to use
half-duplex mode.

If one side is using half-duplex, and the other is using full-duplex,
sorrow and woe is the usual result.

So, the following table shows what will happen given various settings
on each side:

Auto Half Full

Auto Happiness Lucky Sorrow

Half Lucky Happiness Sorrow

Full Sorrow Sorrow Happiness

Happiness means that there is a good shot of everything going well.
Lucky means that things will likely go well, but not because you did
anything correctly :) Sorrow means that there _will_ be a duplex
mis-match.

When there is a duplex mismatch, on the side running half-duplex you
will see various errors and probably a number of _LATE_ collisions
("normal" collisions don't count here). On the side running
full-duplex you will see things like FCS errors. Note that those
errors are not necessarily conclusive, they are simply indicators.

Further, it is important to keep in mind that a "clean" ping (or the
like - eg "linkloop" or default netperf TCP_RR) test result is
inconclusive here - a duplex mismatch causes lost traffic _only_ when
both sides of the link try to speak at the same time. A typical ping
test, being synchronous, one at a time request/response, never tries
to have both sides talking at the same time.

Finally, when/if you migrate to 1000Base-T, everything has to be set
to auto-neg anyway.


Finally, while I don't have a pointer to the announcement, given that Broadcom have ceased working on bcm5700, HP are in a transition from bcm5700 being the "supported" driver to tg3 being the "supported" driver.

[Rob Mokkink]

forgot to says that its a gigabit nic, but the swithc only does 100mb and it's an cisco switch.

Cisco and auto speed and duplex don't work well together.

We have set the switch to auto and nic to auto but the performance is so crappy and would rather set it to 100 full.

[rick jones]

Well, HP have a solution to the problems with your Cisco switch(es) :)

http://www.hp.com/go/procurve

[Rob Mokkink]

i konw, but the place i am in now all have cisco.

And loads of problems when setting switches to auto. So they set everything to full.

Also the gigabit connections just fail when set to auto.

In the old days you just have 3com.
Plug in a cable and it works good, stable and fast.