PCI网卡和主板eth端口无法被操作系统使用的可能原因?

PCI网卡和主板eth端口无法被操作系统使用的可能原因?

大家好,我有一个旧的 Linux 服务器,由于特定原因而复活,我用以前用于这些服务器的 redhat 6 映像刷新了该服务器。这样做后,虽然操作系统不会使放置在 pci 扩展插槽中的 pci 网卡可用,但我什至无法使用 ifconfig 将其视为设备,现在我可以在 ifconfig 中看到连接到主板的 2 个端口,但这些端口也不可用或由网络管理器服务管理。这就是我从我的角度所看到的。

>ifconfig
eth4      Link encap:Ethernet  HWaddr B4:96:91:4E:13:F1  
          UP BROADCAST MULTICAST  MTU:9000  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Memory:fb100000-fb200000 

eth5      Link encap:Ethernet  HWaddr B4:96:91:4E:13:F0  
          inet addr:192.9.200.11  Bcast:192.9.200.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:9000  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Memory:fb200000-fb300000 

这是我从 dmesg 中提取的看起来相关的内容

pci 0000:09:00.0: [8086:1533] type 0 class 0x000200
pci 0000:09:00.0: reg 10: [mem 0xce800000-0xce87ffff]
pci 0000:09:00.0: reg 18: [io  0x5000-0x501f]
pci 0000:09:00.0: reg 1c: [mem 0xce880000-0xce883fff]
pci 0000:09:00.0: PME# supported from D0 D3hot D3cold
pci 0000:09:00.0: PME# disabled
pci 0000:00:1c.2: PCI bridge to [bus 09-09]
pci 0000:00:1c.2:   bridge window [io  0x5000-0x5fff]
pci 0000:00:1c.2:   bridge window [mem 0xce800000-0xce8fffff]
pci 0000:0a:00.0: [8086:1533] type 0 class 0x000200
pci 0000:0a:00.0: reg 10: [mem 0xce700000-0xce77ffff]
pci 0000:0a:00.0: reg 18: [io  0x4000-0x401f]
pci 0000:0a:00.0: reg 1c: [mem 0xce780000-0xce783fff]
pci 0000:0a:00.0: PME# supported from D0 D3hot D3cold
pci 0000:0a:00.0: PME# disabled


pci 0000:81:00.0: [8086:1521] type 0 class 0x000200
pci 0000:81:00.0: reg 10: [mem 0xfb200000-0xfb2fffff]
pci 0000:81:00.0: reg 1c: [mem 0xfb304000-0xfb307fff]
pci 0000:81:00.0: PME# supported from D0 D3hot D3cold
pci 0000:81:00.0: PME# disabled
pci 0000:81:00.0: reg 184: [mem 0x00000000-0x00003fff 64bit pref]
pci 0000:81:00.0: reg 190: [mem 0x00000000-0x00003fff 64bit pref]
pci 0000:81:00.1: [8086:1521] type 0 class 0x000200
pci 0000:81:00.1: reg 10: [mem 0xfb100000-0xfb1fffff]
pci 0000:81:00.1: reg 1c: [mem 0xfb300000-0xfb303fff]
pci 0000:81:00.1: PME# supported from D0 D3hot D3cold
pci 0000:81:00.1: PME# disabled
pci 0000:81:00.1: reg 184: [mem 0x00000000-0x00003fff 64bit pref]
pci 0000:81:00.1: reg 190: [mem 0x00000000-0x00003fff 64bit pref]

NET: Registered protocol family 10
igb 0000:81:00.1: changing MTU from 1500 to 9000
ADDRCONF(NETDEV_UP): eth4: link is not ready
igb 0000:81:00.0: changing MTU from 1500 to 9000
ADDRCONF(NETDEV_UP): eth5: link is not ready
type=1400 audit(1628863781.555:4): avc:  denied  { sys_tty_config } for  pid=6008 comm="kexec" capability=26  scontext=system_u:system_r:kdump_t:s0 tcontext=system_u:system_r:kdump_t:s0 tclass=capability
type=1400 audit(1628863781.556:5): avc:  denied  { write } for  pid=6008 comm="kexec" path="/dev/pts/0" dev=devpts ino=3 scontext=system_u:system_r:kdump_t:s0 tcontext=syste


dca service started, version 1.12.1
Intel(R) Gigabit Ethernet Network Driver - version 3.2.10-k
Copyright (c) 2007-2011 Intel Corporation.
igb 0000:81:00.0: PCI INT A -> GSI 50 (level, low) -> IRQ 50
igb 0000:81:00.0: setting latency timer to 64
igb 0000:81:00.0: irq 110 for MSI/MSI-X
igb 0000:81:00.0: irq 111 for MSI/MSI-X
igb 0000:81:00.0: irq 112 for MSI/MSI-X
igb 0000:81:00.0: irq 113 for MSI/MSI-X
igb 0000:81:00.0: irq 114 for MSI/MSI-X
igb 0000:81:00.0: irq 115 for MSI/MSI-X
igb 0000:81:00.0: irq 116 for MSI/MSI-X
igb 0000:81:00.0: irq 117 for MSI/MSI-X
igb 0000:81:00.0: irq 118 for MSI/MSI-X
igb 0000:81:00.0: Intel(R) Gigabit Ethernet Network Connection
igb 0000:81:00.0: eth0: (PCIe:5.0Gb/s:Width x4) b4:96:91:4e:13:f0
igb 0000:81:00.0: eth0: PBA No: H47819-003
igb 0000:81:00.0: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
igb 0000:81:00.1: PCI INT B -> GSI 52 (level, low) -> IRQ 52
igb 0000:81:00.1: setting latency timer to 64
igb 0000:81:00.1: irq 119 for MSI/MSI-X
igb 0000:81:00.1: irq 120 for MSI/MSI-X
igb 0000:81:00.1: irq 121 for MSI/MSI-X
igb 0000:81:00.1: irq 122 for MSI/MSI-X
igb 0000:81:00.1: irq 123 for MSI/MSI-X
igb 0000:81:00.1: irq 124 for MSI/MSI-X
igb 0000:81:00.1: irq 125 for MSI/MSI-X
igb 0000:81:00.1: irq 126 for MSI/MSI-X
igb 0000:81:00.1: irq 127 for MSI/MSI-X
igb 0000:81:00.1: Intel(R) Gigabit Ethernet Network Connection
igb 0000:81:00.1: eth1: (PCIe:5.0Gb/s:Width x4) b4:96:91:4e:13:f1
igb 0000:81:00.1: eth1: PBA No: H47819-003
igb 0000:81:00.1: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)

所以我可以看到它们都在那里以及 pci id 我还检查了以确保设备驱动程序存在并且已加载

lsmod | grep igb
igb                   113015  0 
dca                     6877  1 igb

我看到 igb 内核驱动程序用于扩展卡,但不是主板上的板载以太网端口,这是否会导致它们全部无法访问?任何有关如何纠正操作系统无法使用我的端口问题的建议将不胜感激

因此,我验证了板载以太网控制器是 intel i210 8086:1533,它也使用 igb 驱动程序,因此我开始卸载并重新安装 igb 驱动程序。内核是 3.2 rt,所以 igb 从 2.6+ 开始受到支持,我认为我很好,但是在运行 rmmod igb 然后尝试从最新 igb 版本的 tar 文件运行“make install”后,make 失败了冲突,因为“netdev_features_t”已经存在等等。我认为好吧,这可能是以前安装的 igb 驱动程序留下的,当我运行以下命令来完成删除 igb 时

rpm -q igb

rpm -e igb //or igb<kernel version>

rpm 找不到要卸载的模块或不存在,所以有人知道在哪里可以找到部分卸载的设备驱动程序的剩余部分吗?我已经清除了我所知道的所有 igb 文件,但 make 仍然失败。已删除的文件列表

/usr/src/kernel/<kernelversion>/drivers/net/ethernet/intel/igb //wiped out whole directory containing the original makefile

/lib/modules/kernel/<kernelversion>/drivers/net/ethernet/intel/igb //dir containing the .ko file 

是否还有另一个地方原始 .o 文件仍然存在,我还启动了一个实时 Fedora 映像,它看到了所有 4 个端口并使用了 igb,没有任何问题,所以我觉得它必须是驱动程序。

答案1

通常ifconfig不带选项仅显示配置的网卡;您还需要ifconfig -a查看未配置的。如果卡未配置(例如,因为卡的 MAC 地址与现有配置中列出的地址不匹配),则驱动程序也不会为其保留任何资源,这可能就是您的dca使用计数仅为 的原因1

检查/etc/udev/rules.d/70-persistent-net.rules是否有任何线路将具有特定 MAC 地址的 NIC 与特定eth*名称相关联。如果磁盘映像不是来自该特定系统,您很可能会发现一些 MAC 地址引用该映像所在系统的 NIC。您可以注释掉这些行,或者如果您想为特定的 NIC 分配特定的名称,也可以编辑它们。

然后还要检查所有/etc/sysconfig/network-scripts/ifcfg-eth*文件中的 MAC 地址引用。他们会看起来像HWADDR=<MAC address here>。这些可能存在,也可能不存在:这曾经是确保持久 NIC 命名的传统 RedHat 方式,早于 udev 的70-persistent-net.rules.我建议HWADDR=完全删除所有行并让 udev 规则处理 NIC 名称分配。

如果您有HWADDR=“丢失”NIC 的行,您可能会在系统日志中找到与ifup此模板匹配的一两条消息:

"Device ${DEVICE} has MAC address ${FOUNDMACADDR}, instead of configured address ${HWADDR}. Ignoring."

RHEL 6 会这样说:“哇,这个网络配置与这个硬件不匹配。我不会触碰该 NIC 上的任何东西;让系统管理员来解决这个问题。”

相关内容