Hi,
after updating an production system, one of my router went offline (failover system is running very well, btw)
In "dmesg" i found these:
re1: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0xef00-0xefff mem 0xfebff000-0xfebfffff,0xcfff0000-0xcfffffff irq 17 at device 0.0 on pci2
re1: Using 1 MSI-X message
re1: Chip rev. 0x3c000000
re1: MAC rev. 0x00400000
miibus1: <MII bus> on re1
re1: Using defaults for TSO: 65518/35/2048
re1: Ethernet address: xx:xx:xx:xx:xx:xx:xx
re1: link state changed to UP
re1: link state changed to DOWN
re1: link state changed to UP
re1: link state changed to DOWN
re1: link state changed to UP
re1: <Realtek PCIe GBE Family Controller> port 0xef00-0xefff mem 0xfebff000-0xfebfffff,0xcfff0000-0xcfffffff irq 17 at device 0.0 on pci2
re1: Using Memory Mapping!
re1: couldn't map interrupt
device_attach: re1 attach returned 6
Its an onboard gigabit bord with 2 ports. the second (re0) for lan is up and running...
is there an workaround or solution?
Some hours ago, i've updated to the latest firmware.
Regards,
Dominik
Hi,
that looks very similar to what I'm seeing (but along with another issue given in https://forum.opnsense.org/index.php?topic=4533.0 (https://forum.opnsense.org/index.php?topic=4533.0)):
dmesg | grep -iE re1
re1: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0xd000-0xd0ff mem 0xfe300000-0xfe300fff,0xd0800000-0xd0803fff irq 40 at device 0.0 on pci5
re1: Using 1 MSI-X message
re1: Chip rev. 0x2c000000
re1: MAC rev. 0x00200000
miibus1: <MII bus> on re1
re1: Using defaults for TSO: 65518/35/2048
re1: Ethernet address: 14:cc:20:....
re1: netmap queues/slots: TX 1/256, RX 1/256
re1: link state changed to DOWN
re1: promiscuous mode enabled
re1: promiscuous mode disabled
re1: promiscuous mode enabled
re1: promiscuous mode disabled
re1: promiscuous mode enabled
re1: <Realtek PCIe GBE Family Controller> port 0xd000-0xd0ff mem 0xfe300000-0xfe
re1: Using Memory Mapping!
re1: Using 1 MSI-X message
re1: ASPM disabled
re1: version:1.93
re1: Ethernet address: 14:cc:20:....
re1: Ethernet address: 14:cc:20:....
re1: link state changed to DOWN
re1: promiscuous mode enabled
re1: promiscuous mode disabled
re1: promiscuous mode enabled
re1: promiscuous mode disabled
re1: promiscuous mode enabled
re1: <Realtek PCIe GBE Family Controller> port 0xd000-0xd0ff mem 0xfe300000-0xfe
re1: Using Memory Mapping!
re1: unknown device
device_attach: re1 attach returned 6
these are different failures ...
re1: unknown device and re1: couldn't map interrupt
Currently i'am searching for the driver source to check these messages ...
Curious, It's only re1? not both re0 and re1. Could there only be one interrupt assigned for both ports? Is re1 down?
Edit: I see in the msg that it is down.
Curious, It's only re1? not both re0 and re1. Could there only be one interrupt assigned for both ports? Is re1 down?
Yes, its just re1 and it is down (there is no interface for re1 in ifconfig (and in opnsense config)
re0 is up and working very well ...
Looks like our first issue with Realtek's latest driver release... I will look into the differences here and report back.
The debug message tells us the latest Realtek driver doesn't know the device, but doesn't print which one it sees, so we can't tell which one is missing.
For now, you could go back to the 17.1.1 kernel to use the old driver:
# opnsense-update -kr 17.1.1
# /usr/local/etc/rc.reboot
Cheers,
Franco
Quote from: franco on February 27, 2017, 11:59:16 PM
The debug message tells us the latest Realtek driver doesn't know the device, but doesn't print which one it sees, so we can't tell which one is missing.
For now, you could go back to the 17.1.1 kernel to use the old driver:
# opnsense-update -kr 17.1.1
# /usr/local/etc/rc.reboot
Cheers,
Franco
Hi franco,
re1 is working well on this kernel! thanks!
Can you see the difference in kernel source? (to fix this)
Regards,
Dominik
Has anything been discovered about this?