[Bug 229727] On install, Broadcom chipset doesn't receive DHCPOFFER
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229727 --- Comment #12 from Stephan Neuhaus --- Created attachment 195139 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=195139&action=edit DCHPOFFER for recalcitrant bge0 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 229727] On install, Broadcom chipset doesn't receive DHCPOFFER
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229727 --- Comment #13 from Stephan Neuhaus --- I reply to Eugene Grosbein from comment #8 I've attached a pcap containing the DHCPOFFER. I've also dropped into a shell from the installer. The interface name is indeed bge0 and this is what i see when I manually dhclient bge0: DHCPDISCOVER on bge0 to 255.255.255.255 port 67 interval 6 DHCPDISCOVER on bge0 to 255.255.255.255 port 67 interval 15 bge0 link state up -> down bge0 link state down -> up DHCPDISCOVER on bge0 to 255.255.255.255 port 67 interval 3 DHCPDISCOVER on bge0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on bge0 to 255.255.255.255 port 67 interval 9 bge0 link state up -> down bge0 link state down -> up And so on ad infinitum. (Sorry, I relaise this is pertinent information, but I didn't see that from the installer and it only now occurred to me to drop into a shell.) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 229727] On install, Broadcom chipset doesn't receive DHCPOFFER
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229727 --- Comment #14 from Stephan Neuhaus --- Attribution on comment #13 is wrong. Should be comment #9 instead. Sorry. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 229727] On install, Broadcom chipset doesn't receive DHCPOFFER
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229727 --- Comment #15 from Eugene Grosbein --- (In reply to Stephan Neuhaus from comment #13) It seems your box does not really receive a reply from DHCP server despite it is being sent. Please verify this by entering shell again and running commands: killall dhclient; dhclient -b bge0; tcpdump -npi bge0 udp src port 67 I'm afraid you'll see no packets from server's DHCP port 67. If so, you should digress from DHCP for a while and make sure if your link is stable while using static IP address instead. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 229727] On install, Broadcom chipset doesn't receive DHCPOFFER
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229727 --- Comment #16 from Stephan Neuhaus --- Replying to comment #15 Yep, you're right, no DHCPOFFER seen by the NIC. Here is what I see. (Possibility of slight typos as I'm typing this by hand.) One thing I find odd is that the interface has the SIMPLEX flag initially and keeps that flag even after attempting DHCP. # dmesg | grep bge0 bge0: mem 0xd310 at device 0.0 on pci3 bge0: CHIP ID 0x5784100; ASIC REV 0x5784; CHIP REV 0x57841; PCI-E miibus0: on bge0 bge0: Using defaults for TSO: 65518/35/2048 bge0: Eyjernet address: c8:bc:c8:a4:f3:30 # ifconfig bge0 bge0: flags=8802 metric 0 mtu 1500 options=c019b ether c8:bc:c8:a4:f3:30 nd6 options=29 # killall dhclient No matching processes were found # dhclient -b bge0 # tcpdump -npi bge0 udp port 67 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bge0, link-type EN10MB (Ethernet), capture size 262144 bytes 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c8:bc:c8:a4:f3:30, length 300 [ this repeats ] ^C 7 packets captured 7 packets received by filter 0 packets dropped by kernel # ifconfig bge0 bge0: flags=8843 metric 0 mtu 1500 options=c019b inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255 ether c8:bc:c8:a4:f3:30 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active A further "dmesg | grep bge0" yields many repetitions of these lines: bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP Again, this laptop works fine when I install Debian on it, so it's very unlikely to be the hardware. Do you have any ideas? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 219428] em network driver broken in current
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219428
--- Comment #14 from commit-h...@freebsd.org ---
A commit references this bug:
Author: marius
Date: Sun Jul 15 19:04:26 UTC 2018
New revision: 336313
URL: https://svnweb.freebsd.org/changeset/base/336313
Log:
Assorted TSO fixes for em(4)/iflib(9) and dead code removal:
- Ever since the workaround for the silicon bug of TSO4 causing MAC hangs
was committed in r295133, CSUM_TSO always got disabled unconditionally
by em(4) on the first invocation of em_init_locked(). However, even with
that problem fixed, it turned out that for at least e. g. 82579 not all
necessary TSO workarounds are in place, still causing MAC hangs even at
Gigabit speed. Thus, for stable/11, TSO usage was deliberately disabled
in r323292 (r323293 for stable/10) for the EM-class by default, allowing
users to turn it on if it happens to work with their particular EM MAC
in a Gigabit-only environment.
In head, the TSO workaround for speeds other than Gigabit was lost with
the conversion to iflib(9) in r311849 (possibly along with another one
or two TSO workarounds). Yet at the same time, for EM-class MACs TSO4
got enabled by default again, causing device hangs. Therefore, change the
default for this hardware class back to have TSO4 off, allowing users
to turn it on manually if it happens to work in their environment as
we do in stable/{10,11}. An alternative would be to add a whitelist of
EM-class devices where TSO4 actually is reliable with the workarounds in
place, but given that the advantage of TSO at Gigabit speed is rather
limited - especially with the overhead of these workarounds -, that's
really not worth it. [1]
This change includes the addition of an isc_capabilities to struct
if_softc_ctx so iflib(9) can also handle interface capabilities that
shouldn't be enabled by default which is used to handle the default-off
capabilities of e1000 as suggested by shurd@ and moving their handling
from em_setup_interface() to em_if_attach_pre() accordingly.
- Although 82543 support TSO4 in theory, the former lem(4) didn't have
support for TSO4, presumably because TSO4 is even more broken in the
LEM-class of MACs than the later EM ones. Still, TSO4 for LEM-class
devices was enabled as part of the conversion to iflib(9) in r311849,
causing device hangs. So revert back to the pre-r311849 behavior of
not supporting TSO4 for LEM-class at all, which includes not creating
a TSO DMA tag in iflib(9) for devices not having IFCAP_TSO4 set. [2]
- In fact, the FreeBSD TCP stack can handle a TSO size of IP_MAXPACKET
(65535) rather than FREEBSD_TSO_SIZE_MAX (65518). However, the TSO
DMA must have a maxsize of the maximum TSO size plus the size of a
VLAN header for software VLAN tagging. The iflib(9) converted em(4),
thus, first correctly sets scctx->isc_tx_tso_size_max to EM_TSO_SIZE
in em_if_attach_pre(), but later on overrides it with IP_MAXPACKET
in em_setup_interface() (apparently, left-over from pre-iflib(9)
times). So remove the later and correct iflib(9) to correctly cap
the maximum TSO size reported to the stack at IP_MAXPACKET. While at
it, let iflib(9) use if_sethwtsomax*().
This change includes the addition of isc_tso_max{seg,}size DMA engine
constraints for the TSO DMA tag to struct if_shared_ctx and letting
iflib_txsd_alloc() automatically adjust the maxsize of that tag in case
IFCAP_VLAN_MTU is supported as requested by shurd@.
- Move the if_setifheaderlen(9) call for adjusting the maximum Ethernet
header length from {ixgbe,ixl,ixlv,ixv,em}_setup_interface() to iflib(9)
so adjustment is automatically done in case IFCAP_VLAN_MTU is supported.
As a consequence, this adjustment now is also done in case of bnxt(4)
which missed it previously.
- Move the reduction of the maximum TSO segment count reported to the
stack by the number of m_pullup(9) calls (which in the worst case,
can add another mbuf and, thus, the requirement for another DMA
segment each) in the transmit path for performance reasons from
em_setup_interface() to iflib_txsd_alloc() as these pull-ups are now
done in iflib_parse_header() rather than in the no longer existing
em_xmit(). Moreover, this optimization applies to all drivers using
iflib(9) and not just em(4); all in-tree iflib(9) consumers still
have enough room to handle full size TSO packets. Also, reduce the
adjustment to the maximum number of m_pullup(9)'s now performed in
iflib_parse_header().
- Prior to the conversion of em(4)/igb(4)/lem(4) and ixl(4) to iflib(9)
in r311849 and r335338 respectively, these drivers didn't enable
IFCAP_VLAN_HWFILTER by default due to VLAN events not being passed
through by lagg(4). With iflib(9), IFCAP_VLAN_HWFILTER was turned on
by default but also lagg(4) was fixed in that rega
Problem reports for n...@freebsd.org that need special attention
To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status |Bug Id | Description +---+--- In Progress |221146 | [ixgbe] Problem with second laggport New |204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New |205592 | TCP processing in IPSec causes kernel panic New |206053 | kqueue support code of netmap causes panic New |213410 | [carp] service netif restart causes hang only whe Open|165622 | [ndis][panic][patch] Unregistered use of FPU in k Open|193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc Open|202510 | [CARP] advertisements sourced from CARP IP cause Open|206544 | sendmsg(2) (sendto(2) too?) can fail with EINVAL; Open|73 | igb(4): Kernel panic (fatal trap 12) due to netwo Open|227720 | Kernel panic in ppp server 11 problems total for which you should take action. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 229727] bge watchdog timeout with MacBook Pro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229727 Eugene Grosbein changed: What|Removed |Added Summary|On install, Broadcom|bge watchdog timeout with |chipset doesn't receive |MacBook Pro |DHCPOFFER | --- Comment #17 from Eugene Grosbein --- SIMPLEX flag is pretty normal and should be. It just says the NIC does not get incoming copies of frames it have just sent and system does not need to filter them out. Almost all modern ethernet interfaces have this flag. So, your real problem are "bge watchdog timeouts" and not DHCP. These point to some kind of driver problem or hardware problem (cables, ethernet switch and/or ports etc.) Are you having no problems with Debian and EXACTLY same set of hardware including cables? If no, try replacing hardware with known working set. If yes, this rules out hardware problem and points to driver problem. There is Korean blog article http://hyogeollee.blogspot.com/2011/11/ of year 2011 describing similar problem with FreeBSD on MacBook Pro (2010). It says: "In case of bge which is Ethernet driver, watchdog timeout occurs and it is not operated. However, if you add the polling option to the kernel configuration, it will work normally. Maybe there is a problem on the driver side. If you build by adding options DEVICE_POLLING to the kernel configuration, and then boot to the new kernel, it works fine." The kernel option DEVICE_POLLING prevents usage of MSI within bge(4) driver that may be source of this problem due to wrong interrupt handling. There are other ways to disable usage of MSI. You should try to escape to bootloader prompt at early stage while booting installation media and do: set hw.pci.enable_msi=0 set hw.pci.enable_msix=0 boot Then check if this works to run using static IP address. If so, re-check with DHCP. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 229727] bge watchdog timeout with MacBook Pro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229727 --- Comment #18 from Eugene Grosbein --- OTOH, you should first try with "set dev.bge.0.msi=0" instead of disabling hw.pci.enable_msi/hw.pci.enable_msix. This way, you only disable MSI for bge and not for all other drivers in the system. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 229727] bge watchdog timeout with MacBook Pro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229727 --- Comment #19 from Stephan Neuhaus --- Now I get # killall dhclient No matching processes were found # dhclient bge0 DHCPDISCOVER on bge0 to 255.255.255.255 port 67 interval 6 DHCPDISCOVER on bge0 to 255.255.255.255 port 67 interval 8 DHCPOFFER from 192.168.0.253 DHCPREQUEST on bge0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.253 bound to 192.168.0.10 -- renewal in 43200 seconds So it seems indeed to be some kind of watchdog issue, although I don't understand why the first DHCPDISCOVER did not yield a DHCPOFFER, or at least not one that the NIC could see. Now the question is, how do I make this permanent? But thanks already for the huge help. I would not have been able to get to this point without your help. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 229727] bge watchdog timeout with MacBook Pro (Mid-2010)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229727 Stephan Neuhaus changed: What|Removed |Added Summary|bge watchdog timeout with |bge watchdog timeout with |MacBook Pro |MacBook Pro (Mid-2010) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 229727] bge watchdog timeout with MacBook Pro (Mid-2010)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229727 Eugene Grosbein changed: What|Removed |Added Status|New |Open --- Comment #20 from Eugene Grosbein --- (In reply to Stephan Neuhaus from comment #19) After successfull installation, do: echo dev.bge.0.msi=0 >> /boot/loader.conf Note no "set" this time. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 229727] bge watchdog timeout with MacBook Pro (Mid-2010)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229727 --- Comment #21 from Stephan Neuhaus --- (Replying to Eugene Grosbein from comment #20) Yup, that did it. I now have a working install, even though there is a speedbump when bge0 is activated on boot: the switch shows only 100 MBit/s initially, then the link goes DOWN then UP again (this time with 1000 MBit/s), and the DHCP takes a while, probably because the first DHCPOFFER doesn't get through. I doubt that this is expected behaviour, but I can live with it. Since that fixes the issue for me (at least for now), shall we close it? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 229727] bge watchdog timeout with MacBook Pro (Mid-2010)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229727 --- Comment #22 from Stephan Neuhaus --- Replying to my own comment #21 If you can spare the time, could you explain to me what the "bge watchdog" does? But anyway, thanks a lot for walking this newbie through a difficult process, with clear instructions and a lot of patience :-) Cheers, Stephan -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 229727] bge watchdog timeout with MacBook Pro (Mid-2010)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229727 --- Comment #23 from Eugene Grosbein --- Created attachment 195169 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=195169&action=edit proposed fix Attached patch disables MSI for this revision of the NIC. Stephan, could you please test the patch? After installation, make sure you have kernel sources installed, then: 1) fetch the patch 2) cd /usr/src && patch < /path/to/patch 3) rebuild and reinstall the kernel, comment out the workaround in /boot/loader.conf, reboot with new kernel and it should just work. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 229727] bge watchdog timeout with MacBook Pro (Mid-2010)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229727 --- Comment #24 from Eugene Grosbein --- (In reply to Stephan Neuhaus from comment #22) "watchdog timeout" is an indication of some unexpected interrupt processing problem. I do not know anything about Broadcom's chip internals, sorry. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
