Have the interface been configured to start during boot? just because they are down doesn't mean they are not recognized.
Have the interface been configured to start during boot? just because they are down doesn't mean they are not recognized.
I've been working for some time to get a couple of 361T dual NIC cards running on some DL20 Gen9 servers running Debian 7 with the Jessie backports kernel 3.16. The inlcuded IGB driver in that build is the Intel 5.0.5 driver, but that was failing to load the cards with a "probe failed" message and a -5 return code.
Looking at the HP download website for this card, I see that binary "HPE Intel igb Drivers" version 5.3.5.3 are available for RHEL and SUSE, but that the source provided is version 4.0.17, which is vastly too old for this hardware. I tried compiling and installing the 5.3.5.4 driver from the Intel-provided source, but is is still failing to load the cards (same error). It seems that the PCI addressing scheme or something is different between what the Intel driver expects and what HP has done with these cards (I tracked the failing line of code to be an ioremap call in the igb_probe function of the driver).
HP must have some specific tweaks to the IGB driver to accommodate their hardware. As a result, I believe I need to get the source code for the 5.3.5.3 version of the HP driver (I have the 1.10.8 firmware version installed on the cards), so I can compile it for our specific Debian kernel. However, I cannot find that available (the Intel IGB driver is GPL licensed, so HP should be providing the source of any binary releases), and the official HP support channel has been less than helpful so far.
Does anyone have any ideas as to where I cna find this source? Or, perhaps I'm totally off track and my question should instead be does anyo0ne have any other ideas what is wrong and how to get this to work? I'm honestly at the point of bailing on HP to get something that'll work with in-tree drivers...
Even though there are HPE drivers, the inbox drivers normally work fine. I checked with my counterpart who does the Ubuntu certifications. 12.04, 14.04 and 16.04 work just fine with the inbox driver. I mentioned you had Debian 7 with Jessie backports and he also said that should work without issue.
The Intel drivers you are using (both the one in Debian and the one you downloaded) are correct for this device. If the system is still under warranty, you could file a support ticket on it to determine whether there is a problem with the device itself or the PCI riser.
It's interesting to hear that this supposedly should work. I thought it might be bad hardware as you suggest, except I have the same problem on two different boxes with two different cards, I've tried both slots in the PCI risers, AND on top of all that, the cards work without issue in the Intelligent Provisioning utility.
Thanks for the replies.
I'm still pulling my hair out with this one, but I think I can safely conclude it is not the driver that's the problem, but seemingly a kernel bug. I found that booting into the older Wheezy stable kernel (3.2) is fine with these cards, but the 3.16 from Jessie is not. Even booting the live CD into Jessie proper does not work with the cards.
I did find a 332T lying around, and that seems to work without issue at the moment. Might just ditch the Intel-based cards so I can get this up and running.
Sorry you're losing hair over this, but I'm glad to learn you have identified the more likely source of the problem. Please let us know when you get it figured out. You are not likely to be the only one experiencing the issue.
Yeah, I certainly can't imagine I'd be the first with this problem.
Unfortunately, I probably won't be the last either. I found a 332T Broadcom-based card in one of our older spare servers and popped that in for a go. No problems at all. So it looks like for the sake of time we won't be solving this one, at least not right now. While we'd like to use the I350-based NICs, the 332T will work well enough.
Now I only wish I'd thought of trying the 332T a week ago....
Hi,
Sorry for this late answer.
I agree with you : if the job is correctly done @ creation time, well ... the job is done.
But, my problem is mostly later in the time : "what, if the initial job has not been done thoughtfully ?" Not sure that existing tools are enough to analyzes & corrects problems
Eric
This method is good but again you have no out of system backup for your configuration done on the system.
Hi folks,
Ihave 5x DL380 Gen9 servers running Cent OS 7.
Now I want to update the HPE driver software using yum.
Any idea?
Henrik_Nowak wrote:Hi folks,
Ihave 5x DL380 Gen9 servers running Cent OS 7.
Now I want to update the HPE driver software using yum.
Any idea?
What HPE specific drivers are you looking to update? If running CentOS 7.3 the drivers (NIC, disk controller, iLO, watchdog) are in the distribution.
You can use the HPE SDR (Software Delivery Repository) to get HPE drivers and tools, look at the SPP and the MCP information
https://downloads.linux.hpe.com/
https://downloads.linux.hpe.com/SDR/project/spp/
https://downloads.linux.hpe.com/SDR/project/mcp/
HPE does not release drivers specirfically for CentOS. The RHEL driver we release can generally be used with CentOS.
What specific device(s) do you want to support with out of box driver(s)?
I don't think HP has a central repository for yum-type installations and updates. The DL380G9 drivers are in tar format and must be downoladed individually from
http://h20564.www2.hpe.com/hpsc/swd/public/readIndex?sp4ts.oid=7271242&swLangOid=8&swEnvOid=4184
Usually inside the tar files you find rpm files and documents. You may be able to create your own local repository if you want to use yum or use yum or rpm with local rpm files..
Eventhough CentOS-7 is not listed in the supported OSes in the quickspecks, there are CentOS-7 specific drivers in the URL I included in my previous reply.
TTr wrote:I don't think HP has a central repository for yum-type installations and updates. The DL380G9 drivers are in tar format and must be
Yes there is a central repository to use native Linux tools like yum, apt, and zypper to access HP drivers, utilities and firmware
HPE Software Delivery Repository http://downloads.linux.hpe.com/
"The Software Delivery Repository hosts yum and apt repositories for Linux-related software packages. Much of this content is also available from various locations at hpe.com in iso or tgz format, but if you would prefer to use your Linux-native software configuration manager, you may subscribe your systems to some or all of these repositories for quick and easy access to the latest rpm/deb packages from HPE."
> HPE Software Delivery Repository http://downloads.linux.hpe.com/
Though not an extensive repository, it's good to know. Thanks
TTr wrote:> HPE Software Delivery Repository http://downloads.linux.hpe.com/
Though not an extensive repository, it's good to know. Thanks
It contains the contents of the SPP, is something missing?
Hi ,
Can anyone help, i have a z820 workstation install with redhat linux ws 6.7 . Someone install some apps on it and now after reboot a graphics screen show with mouse cursor but gdm login screen not showing . So i bypass it by using key ctrl alt f2 and I can login from prompt in text mode. There , I try to run startx which the gui started and I can see the desktop icon only inside the gnome-panel is not visible. Can someone advice??
Regards
Vincent
At first look, i guess it is because of corrupted or missing "nautilus" package. Check and re-install this package..