AMD fails to activate my Broadcom network card during the interface identification procedure.
When Broadcom 10Gb card is connected to a mismatched link speed, a warning message occurs:
WARNING: Autonegotiation is not supported for following inactive network interface(s): eth5 eth6 eth7 Rtminst will attempt to match link speed. Please make sure there is a cable connected to every interface and press ENTER.
The cause of this speed mismatch is Broadcom card's inability to automatically negotiate the link speed. Configuring the link speed requires that you perform an additional step.
Before performing this step, make sure that there is a cable connected to every interface then press
[ENTER]. AMD then automatically adjust the card's speed configuration to match the link speed and attempts to identify the network interface again.
The process of matching the link speed to the card's speed will cycle through all interfaces unable to autonegotiate.
--------------------------------------------- The autonegotiation is not supported for eth5 --------------------------------------------- Validating the link speed for eth5 The link is not up for eth5 Set alternate link speed for eth5 Current speed: 10000 Mb/s New speed: 1000 Mb/s New link speed set succesfully for eth5
Once the link speed has been successfully matched, the AMD attempts to activate it.
eth5 has been activated
If the link still cannot be activated, an error message displays.
In case where the speed cannot be successfully matched and the link activated, it is advised that you repeat the identification procedure while the Broadcom card is connected to its designated 10Gb link. The default link speed on the card will be automatically matched to the link speed of the connected cable.
Since the newly negotiated link speed is not optimal for the activated Broadcom 10Gb card, it is not saved as part of the network configuration. The AMD attempts to autonegotiate the link speed once again, if it is restarted. If your targeted link speed is less than 10Gb and you require to force a specific link speed configuration, use the option for configuring link parameters located in the network configuration menu. For more information, see Driver, Network, and Interface Configuration.
No traffic seen on sniffing ports on PCIe cards
When you install a PCIe card on AMD 11.5 and 11.6 on Red Hat Enterprise Linux 5.3, 5.4, or 5.5, you may see the following symptoms:
No traffic on sniffing ports when you run the
/var/messages file, for each eth on the PCIe card, a message such as
msi interrupt test failed, using legacy interrupt ...ethX...
If this occurs, set the kernel option
pci=nomsi in the
/boot/grub/grub.conf file and then reboot the machine.
ro root=LABEL=/ vga=0x317 rhash_entries=8192 crashkernel=64M@16M pci=nomsi
How can I fix restarting monitoring process on my Sun Fire X4450?
rtm process keeps restarting approximately every 20 minutes and generating the following (or similar) information in the
L3 2008-05-28 18:24:16.167 0@commsrv/CommServer.cpp:285 CommServer cl:3586 UNREGISTER_CLIENT L0 2008-05-28 18:24:16.168 0@commsrv/CommServer.cpp:138 Client id=3586 unregistered No free packet buffers size=1536 anlzr thread locked probe version: ndw.10.3.200 os version: RHEL5 i386 compiled with: CFLAGS=-O3 -march=i686 -pipe -fno-strict-aliasing -DLINUX26 -g3 -D_DEBUG -I. -I./include -I/usr/local/openssl-0.9.7/include -I/usr/kerberos/include -I./lib/libpcap-0.9.4 -DU_STATIC_IMPLEMENTATION -D_REENTRANT -D_LINUX_THREADS -DRTM_VPN -DNO_LICENSES -Wall -Wno-format -W -Wpointer-arith -Wcast-qual -Wcast-align -Wuninitialized -Wparentheses created: Tue May 20 11:25:30 CEST 2008 build: mkwap@cwpl-ap011-dev5:/home/mkwap/common/ndw/rtm Begin Stack Frame Dump /usr/adlex/rtm/bin/rtm[0x83e0470] [0x97b420] [0x97b402] /lib/libc.so.6(nanosleep+0x46)[0x8c9846] /lib/libc.so.6(usleep+0x3c)[0x9026ac] /usr/adlex/rtm/bin/rtm[0x80a54f6] /usr/adlex/rtm/bin/rtm[0x83e0d24] /usr/adlex/rtm/bin/rtm[0x83e0f21] /lib/libpthread.so.0[0x3fa43b] /lib/libc.so.6(clone+0x5e)[0x908fde] End Stack Frame Dump All stack addresses list: 0x083e0470 0x0097b420 0x0097b402 0x008c9846 0x009026ac 0x080a54f6 0x083e0d24 0x083e0f21 0x003fa43b 0x00908fde L3 2008-05-28 18:24:17.377 0@commsrv/CommServer.cpp:270 CommServer cl:3594 REGISTER_CLIENT_NO_DIAG
This issue is specific to Sun Fire X4450 hardware configuration. The CPU frequency scaling causes
tsc (time stamp counter)
clocksource to be unreliable. There are several other
clocksource choices that can be used instead of the
tsc. Use the following procedure to examine your system for the available
clocksource and to modify the
grub.conf file to specify a different
Log in to your AMD as
Determine your current
clocksource name. Execute the following command at the prompt:
The response from the system should be:
Examine the availability of
clocksource options on your machine. Display the content of the
available_clocksource object located in
The system response should list the available
acpi_pm jiffies tsc pit
clocksource is available, edit the
/boot/grub/grub.conf file and add
acpi_pm to the line describing kernel boot parameters.
The following line should be appended to each kernel line in the
Example of the
grub.conf file with
clocksource configured for
acpi_pm using the
Figure 1. Editing the grub.conf File
# grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You do not have a /boot partition. This means that # all kernel and initrd paths are relative to /, eg. # root (hd0,0) # kernel /boot/vmlinuz-version ro root=/dev/VolGroup00/LogVol00 # initrd /boot/initrd-version.img #boot=/dev/hda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Red Hat Enterprise Linux Client (2.6.18-92.el5PAE) root (hd0,0) kernel /boot/vmlinuz-2.6.18-53.el5 ro root=/dev/VolGroup00/LogVol00 clocksource=acpi_pm initrd /boot/initrd-2.6.18-53.el5.img
The above example lists two kernels installed:
(2.6.18-92.el15). For more information, see Why do I need a PAE kernel and how do I install it?. You should append the same
clocksource parameter for each kernel installed.
Save the modified
grub.conf file and reboot the AMD.
Once the AMD reboots, log in as
root user and confirm the current
There is no system driver in Red Hat Enterprise Linux 5.1 for an Intel 10-GbE card. How can I install such a card?
The Linux kernel installed by Red Hat Enterprise Linux 5.1 has no built-in support for the adapters that use the Intel 82598EB controller (the
ixgbe kernel module is the device driver for these NICs).1
If you cannot use the Ethernet drivers provided by Compuware and you want to use Intel 10 Gb adapter, you must obtain and compile the native driver.2 If you are sure the
ixgbe module is the driver for your adapter, go directly to the driver download page.
After downloading the archive containing the source files for the driver, unpack it in a suitable location (for example, in
/usr/local/src), find the
README file, and follow the instructions it contains. Compilation of this driver does not require rebuilding the whole kernel, because the driver is supported only as a loadable module.
Note that most of the actions described below require
root user privileges.
The building and installation of drivers is a typical source compiling task in Linux and generally involves executing a sequence of commands ending with the
make install command in the driver source directory. For example:
tar xvzf ixgbe-126.96.36.199.tar.gz#
For 2.6 kernels, the driver can be found in
It is also possible to build an
rpm package straight from the tar archive. To do that, install the
rpm-build package on the AMD machine either from a network repository or from the Red Hat Enterprise Linux installation disk (be ready to provide software dependencies for the
rpm-build package if you are not using an automated update program such as
When you use the command
ixgbe-[DRIVER_VERSION].tar.gz, the kernel module is compiled and the
rpm package is created in a standard location. To enable support for the Intel adapter in the system, you must install the
rpm package. For example:
After the kernel module is installed in the file system, there is no need to load the module. The AMD software will find and load it automatically.
For more information on optional module load parameters, refer to system manual page:
When I use
snmp daemon stops responding while
snmpd.log continues to consume disk space (approximately 5 MB/sec).
For more information, visit the Red Hat support center at Red Hat Global Support Services. For a workaround:
Log in to your AMD as a
snmpd.config file by executing the following command:
Append the following lines at the end of the file:
view all excluded mib-2.ip view all excluded mib-2.host
These lines exclude the object identifiers (OIDs) that cause the daemon to stop responding.
Save the file and restart the
snmpd daemon by executing the following command:
When I attempt to view
snmpd status, I receive the following message:
“snmpd dead but subsys locked”.
The reason why
snmpd does not start is that the
net-snmp-utils packages have different version numbers. Ensure that the versions numbers are uniform and that the SELinux is disabled. For more information, see Disabling Security-Enhanced Linux.
For more information about identifying your adapter, see the Adapter & Driver ID Guide at: http://support.intel.com/support/network/adapter/pro100/21397.htm. For the latest Intel network drivers for Linux, refer to the following website. In the search field, enter your adapter name or type, or use the following link to search for your adapter: http://downloadcenter.intel.com/default.aspx.
Before continuing, ensure that development software is installed. Check whether the compiler was removed from your system. For more information, see Managing Development Packages.