Bug #3038
closed
Intel Ethernet Could not Connect to Network
Added by newnix over 7 years ago.
Updated over 7 years ago.
Description
Upon trying to install DragonFly BSD 4.8 on a new Dell Optiplex 7040, I found that em0 would not receive any DHCPOFFER packets when trying to connect via DHCP and tcpdump found no traffic either after ensuring that the interface was up and active.
While in the IRC chat, it was suggested to run `ifconfig em0 polling` which resolved the issue, it's believed that the problem was with the interrupt not being mapped correctly for the hardware. As suggested, I've attached my verbose dmesg logs as well as the output from pciconf to help in fixing this problem. In the meantime, I've found that adding ifconfig_em0="DHCP npolling" to my /etc/rc.conf has taken care of this problem, allowing me to use my system as normal.
dmesg_verbose.txt - booting with verbose logging enabled, no special settings in /etc/rc.conf regarding em0
dmesg_verbose_dhcp.txt - booting with verbose logging, this time with ifconfig_em0="DHCP" set in /etc/rc.conf
Files
Try this patch:
https://leaf.dragonflybsd.org/~sephe/em_pciaf.diff
If it still not work, please post the dmesg and pciconf.
Thanks,
sephe
On Thu, May 18, 2017 at 10:33 PM,
<bugtracker-admin@leaf.dragonflybsd.org> wrote:
Issue #3038 has been reported by newnix.
----------------------------------------
Bug #3038: Intel Ethernet Could not Connect to Network
http://bugs.dragonflybsd.org/issues/3038
- Author: newnix
- Status: New
- Priority: Normal
- Assignee:
- Category: Networking
- Target version: Latest stable
----------------------------------------
Upon trying to install DragonFly BSD 4.8 on a new Dell Optiplex 7040, I found that em0 would not receive any DHCPOFFER packets when trying to connect via DHCP and tcpdump found no traffic either after ensuring that the interface was up and active.
While in the IRC chat, it was suggested to run `ifconfig em0 polling` which resolved the issue, it's believed that the problem was with the interrupt not being mapped correctly for the hardware. As suggested, I've attached my verbose dmesg logs as well as the output from pciconf to help in fixing this problem. In the meantime, I've found that adding ifconfig_em0="DHCP npolling" to my /etc/rc.conf has taken care of this problem, allowing me to use my system as normal.
dmesg_verbose.txt - booting with verbose logging enabled, no special settings in /etc/rc.conf regarding em0
dmesg_verbose_dhcp.txt - booting with verbose logging, this time with ifconfig_em0="DHCP" set in /etc/rc.conf
---Files--------------------------------
dmesg_verbose.txt (58.3 KB)
dmesg_verbose_dhcp.txt (121 KB)
pciconf.txt (8.83 KB)
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
--
Tomorrow Will Never Die
- Status changed from New to Resolved
Sorry I didn't get back to you sooner, just rebuilt with the patch, no longer need to set ifconfig_em0="DHCP polling" in /etc/rc.conf, the patch appears to have solved the problem entirely.
Also available in: Atom
PDF