New 1Gb Broadcom Multifunction Win64 driver (7.8.6.0) is buggy

[waaronb]

Well, I haven't tried the 7.8.50.0 driver yet, but over the weekend I updated one of my dev environment DL360 G7 systems from Server 2012 to Server 2012 R2.

I had the working 7.4.14.0 driver on there before, but apparently during the upgrade to Server 2012 R2, it upgraded the network driver to 7.8.6.0.

I didn't notice, and my initial testing was just on the server itself, not any of the guest machines.

So I come in Monday morning and things are all out of whack on the test systems and I get a flurry of complaints from the developers.

I tried disabling the VMQ option on all of the adapters (they're all teamed together, so I did it on all 4 of the physical NICs). But that didn't do anything.

I also checked the MTU but since they're all teamed using the Server 2012 built-in teaming thing, there was just that one team adapter with IP4 bound to it, and it's MTU was 1500 just like it should be.

In other words, I checked the couple of things people mentioned might get this newer driver working, but with one or both of them, we still had a lot of problems where the virtual guest machines were having connection issues. Particularly when the packet of data is over a certain size. It seems like that points to an MTU issue, but I'm not sure.

For instance, I could remote desktop onto a virtual Windows machine okay, and maybe I was doing network retries I wasn't aware of, but it worked.

From that virtual guest, I was trying to access a web page that might return 10K of data or more. That was *always* failing. If I tried getting HTML that was small, like a few hundred bytes, then it worked.

It almost acted like the MTU was weird and it wasn't fragmenting properly. Like when you try a ping larger than the MTU and set the do-not-fragment bit.

But none of the IPv4 advanced settings I scanned over seemed strange, and simply installing the old version again fixed it, and I doubt downgrading the driver would change any network settings.

By that point I was not feeling brave enough to try that 7.8.50.0 version, especially since it doesn't mention anything in the fixes that seem relevant. It works on the older version and I'm just going to leave it there until I see the problem and solution mentioned in the release notes. :)

[Herr Franzen]

Hi there, we have had problems with NC382i on some HP Servers with Windows 2008 R2.

Check "ping -l 5000 <servername>", there may be no reply, means your server network card does not fragment the network data.

This may help for windows:

Start a cmd box with ping -t - l5000 <servername>

Now open Windows System Control and Open HP Network Control, the following windows shows HP Network Control Option, now look for then ping window and press in the HP Network Control the OK Button, maybe one or two seconds later the ping will start to respond.

At the Moment you click o.k. the Network Connection will be lost for a little moment, when it is back the problem is away too. Means the network card fragments the data. We have tested with server reboot, network card will work fine.

Please reply to me if this works for your configuration.

Greetings from Germany by Peter

[waaronb]

I'm not declaring success quite yet, but I did just update a couple of my servers to the 7.8.50.0 drivers, and so far it seems like it's working without doing any other modifications, fixes, workarounds, etc.

This was on a couple of DL360 G7's running Server 2012 (not R2).  Both the host OS and the guest Hyper-V systems seem to be doing okay.  No dropped packets or any of the other weird behavior I saw with 7.8.6.0.

I'll have a better idea tomorrow once these systems get a little more real world traffic under their belt, but the initial tests look promising.

[waaronb]

It's been about a week now running my Hyper-V hosts on the 7.8.50.0 version of the driver, and it does seem like the issue is gone.  Funny that the release notes didn't seem to say anything related to this problem.

The notes for 7.8.50.0 say this:

Fixes
- This driver corrects an issue that could result in halted traffic when configuring jumbo frame size to 9000.

- This driver corrects an issue that could result in a Windows Stop Error (BSOD) when a large number of ports are repeatedly disabled.

As a side note, on my Hyper-V hosts, these are Server 2012 systems and I use the native Microsoft teaming service, with all of the NIC ports set to Hyper-V Port load balancing (not aggregated or anything since they're connected to redundant switches on separate power feeds).  I don't know if that would make a difference or not.

We're not using jumbo frames, so that wouldn't apply.  I guess it's just some undocumented thing they slipped in or fixed silently.

[SebastianGrugel]

Hi waaronb can you tell me if after install version  7.8.50 value of MTU was still 1500 or change ?

In what exactly HP server and system this works ? Only Hyper-V Server 2012 ?

Grettings

[waaronb]

The MTU was still 1500.

The servers I have this running on now are a mix of DL360/DL380 for G5, G6 and G7.

The Hyper-V machines in particular are DL360 G7 and DL380 G7 running Server 2012. The rest of those older machines are just running Server 2008 R2.

I don't think I saw any connection issues on the non Hyper-V machines though. The only place I ever saw problems were on the Hyper-V virtual machines.

I never saw the MTU change even with the buggy version of the driver, it was always 1500.

[Ted Wood]

We had issues with Kerberos authentication for some applications  after installing 7.8.6.0 on our DCs.  Each of the DCs showed that the MTU was set to 1486 and UDP was not properly fragmenting.  As mentioned above opening the HP Network Configuration Utility solved the MTU issue; it was set back to 1500 after a momentary network drop. This "fix" does appear to survive a reboot.  We're thinking that running the Network Config Utility Version writes or corrects some registry setting involving the MTU, but could not pin down which setting that would be...or even if it is a registry setting that is involved.  Version 7.8.50.0 does not seem to have the problem.