[Bug 213606] LACP not working with qlogic BCM57800
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213606
Borja Marcos changed:
What|Removed |Added
CC||bor...@sarenet.es
--- Comment #8 from Borja Marcos ---
Deja vu with https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=150249
The main symptom was lagg refusing to work in LACP mode.
In this case, the reason was that the driver didn't detect media properly, and
the "paperwork" with the kernel failed: the interface wasn't marked as full
duplex. As a result, LACP (which checks the full-duplex flag for the interface)
refused to use it. Remember that full-duplex is a prerequisite for LACP.
This seems to be a case of incomplete paperwork as well, although the necessary
bits seem to be in place.
In my case this was the problem with LACP (ieee8023ad_lacp.c):
-
/*
* If the port is not an active full duplex Ethernet link then it can
* not be aggregated.
*/
if (IFM_TYPE(media) != IFM_ETHER || (media & IFM_FDX) == 0 ||
ifp->if_link_state != LINK_STATE_UP) {
lacp_port_disable(lp);
} else {
lacp_port_enable(lp);
}
-
But according to ifconfig the interface is marked as full duplex and media
seems to be Ethernet. I would add some printf's here to check if this is really
the case and some other check is failing.
What does ifconfig -m say of the interfaces? But that lack of options looks
like a driver bug. And it would help to see its capabilities as reported by
ifconfig.
This is an example with an "em" interface.
-
% ifconfig -m -v -v em0
em0: flags=8943 metric 0 mtu
1500
options=4219b
capabilities=15399b
ether 68:05:ca:XX:YY:ZZ
inet 192.168.1.202 netmask 0xff00 broadcast 192.168.1.255
inet 192.168.1.203 netmask 0x broadcast 192.168.1.203
nd6 options=23
media: Ethernet autoselect (1000baseT )
status: active
supported media:
media autoselect
media 1000baseT
media 1000baseT mediaopt full-duplex
media 100baseTX mediaopt full-duplex
media 100baseTX
media 10baseT/UTP mediaopt full-duplex
media 10baseT/UTP
-
--
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 213606] LACP not working with qlogic BCM57800
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213606 --- Comment #9 from Kristjan --- ifconfig -m bxe0 bxe0: flags=8843 metric 0 mtu 1500 capabilities=527bb ether b0:83:fe:e5:fa:82 nd6 options=29 media: Ethernet autoselect (10Gbase-SR ) status: active supported media: media autoselect media 10Gbase-SR mediaopt full-duplex -- 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 213606] LACP not working with qlogic BCM57800
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213606 --- Comment #10 from Borja Marcos --- And what if you try to mess with the options? Try this: ifconfig bxe0 -rxcsum ifconfig bxe1 -rxcsum I'm just wondering, maybe by doing that you can coerce the driver to complete the paperwork properly. -- 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 208343] [em] wake on lan not working with Intel I219 V2
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208343 Warren Block changed: What|Removed |Added CC||wbl...@freebsd.org --- Comment #7 from Warren Block --- Seeing the same symptoms with I217-LM (class=0x02 card=0x153a15d9 chip=0x153a8086 rev=0x05 hdr=0x00) and I210 (card=0x153315d9 chip=0x15338086 rev=0x03 hdr=0x00) interfaces on Supermicro X10SLL-F boards. The WOL capabilities do not appear in the list, and the system does not wake. Supermicro support says that WOL is enabled on these boards. There are no WOL options in the UEFI settings. -- 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"
Re: FreeBSD10.3-RELEASE. Kernel panic.
Hi Kubilay,
Yes, i think all issues are related with this one. I already attached many
info about these crashes there, but looks like nobody cares about it.
This PR is assigned to Ermal, but he's not working on it because his last
PR change was in January.
If you or someone else is interested to help to fix it, please take this
PR. I can provide any information that you need.
Thanks.
On Thu, Oct 20, 2016 at 2:22 AM, Kubilay Kocak wrote:
> On 19/10/2016 3:23 AM, Cassiano Peixoto wrote:
> > Hi guys,
> >
> > I have some update about this issue. After my last email i had 3 crashes.
> > Two of them had the same message on kernel debug:
> >
> > (kgdb) list *0x8228c918
> > 0x8228c918 is in trim_map_seg_compare
> > (/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/
> trim_map.c:108).
> > 103trim_map_seg_compare(const void *x1, const void *x2)
> > 104{
> > 105const trim_seg_t *s1 = x1;
> > 106const trim_seg_t *s2 = x2;
> > 107
> > 108if (s1->ts_start < s2->ts_start) {
> > 109if (s1->ts_end > s2->ts_start)
> > 110return (0);
> > 111return (-1);
> > 112}
> > Current language: auto; currently minimal
> > (kgdb) bt
> > #0 doadump (textdump=) at pcpu.h:221
> > #1 0x80ad8e69 in kern_reboot (howto=260) at
> > /usr/src/sys/kern/kern_shutdown.c:366
> > #2 0x80ad941b in vpanic (fmt=, ap= > optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759
> > #3 0x80ad9253 in panic (fmt=0x0) at
> > /usr/src/sys/kern/kern_shutdown.c:690
> > #4 0x80fa0d31 in trap_fatal (frame=0xfe02374957f0,
> > eva=4294967343) at /usr/src/sys/amd64/amd64/trap.c:841
> > #5 0x80fa0f23 in trap_pfault (frame=0xfe02374957f0,
> > usermode=0) at /usr/src/sys/amd64/amd64/trap.c:691
> > #6 0x80fa04cc in trap (frame=0xfe02374957f0) at
> > /usr/src/sys/amd64/amd64/trap.c:442
> > #7 0x80f84141 in calltrap () at
> > /usr/src/sys/amd64/amd64/exception.S:236
> > #8 0x8228c918 in trim_map_seg_compare (x1=0xfe0237495920,
> > x2=0x10007) at
> > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/trim_map.c:108
> > #9 0x821a98e1 in avl_find (tree=,
> > value=, where=0x0) at
> > /usr/src/sys/cddl/contrib/opensolaris/common/avl/avl.c:268
> > #10 0x8228ce9e in trim_map_write_start (zio= out>)
> > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/
> trim_map.c:363
> > #11 0x822592df in zio_vdev_io_start (zio=0xf802191ea000) at
> > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:2866
> > #12 0x82255b26 in zio_execute (zio=) at
> > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1556
> > #13 0x822551e9 in zio_nowait (zio=0xf802191ea000) at
> > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1610
> > #14 0x8223c738 in vdev_queue_io_done (zio=)
> at
> > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:884
> > #15 0x822594a9 in zio_vdev_io_done (zio=0xf8006daad000) at
> > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:2895
> > #16 0x82255b26 in zio_execute (zio=) at
> > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1556
> > #17 0x80b363ca in taskqueue_run_locked (queue= > out>) at /usr/src/sys/kern/subr_taskqueue.c:449
> > #18 0x80b372d8 in taskqueue_thread_loop (arg= out>)
> > at /usr/src/sys/kern/subr_taskqueue.c:703
> > #19 0x80a90055 in fork_exit (callout=0x80b371f0
> > , arg=0xf8001006b920,
> frame=0xfe0237495c00)
> > at /usr/src/sys/kern/kern_fork.c:1038
> > #20 0x80f8467e in fork_trampoline () at
> > /usr/src/sys/amd64/amd64/exception.S:611
> > #21 0x in ?? ()
> > (kgdb) up 8
> > #8 0x8228c918 in trim_map_seg_compare (x1=0xfe0237495920,
> > x2=0x10007) at
> > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/trim_map.c:108
> > 108if (s1->ts_start < s2->ts_start) {
> >
> > But my last crash had a different message:
> >
> > (kgdb) list *0x80b3a89c
> > 0x80b3a89c is in turnstile_broadcast
> > (/usr/src/sys/kern/subr_turnstile.c:837).
> > 832
> > 833/*
> > 834 * Transfer the blocked list to the pending list.
> > 835 */
> > 836mtx_lock_spin(&td_contested_lock);
> > 837TAILQ_CONCAT(&ts->ts_pending, &ts->ts_blocked[queue],
> td_lockq);
> > 838mtx_unlock_spin(&td_contested_lock);
> > 839
> > 840/*
> > 841 * Give a turnstile to each thread. The last thread gets
> > Current language: auto; currently minimal
> > (kgdb) bt
> > #0 doadump (textdump=) at pcpu.h:221
> > #1 0x80ad8e69 in kern_reboot (howto=260) at
> > /usr/src/sys/kern/kern_shutdown.c:366
> > #2 0x80ad941b in vpanic (fmt=, ap= > optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759
> > #3 0x80ad9253 in panic (fmt=0x0) at
> > /usr/src/sys
[Bug 186114] net/mpd5 hangs after a certain number of users connect
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186114 Cassiano Peixoto changed: What|Removed |Added CC||peixoto.cassi...@gmail.com --- Comment #18 from Cassiano Peixoto --- Created attachment 175989 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=175989&action=edit crash-bt -- You are receiving this mail because: You are on the CC list 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 186114] net/mpd5 hangs after a certain number of users connect
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186114 --- Comment #19 from Cassiano Peixoto --- Comment on attachment 175989 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=175989 crash-bt I'm having random crashes. BT attached. -- You are receiving this mail because: You are on the CC list 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"
Re: Adding RTL8153 support to rue(4) USB to Ethernet driver
On 10/19/16 11:25, Hans Petter Selasky wrote: > > Hi, > > Search the idVendor and idProduct values in the Linux kernel. I think you > need to implement some propritary miibus to > get it working. CDC ethernet does not define any miibus. > > --HPS > Thank you for the quick response. Do you mean that I need to implement a small driver at VID:PID (0bda:8153 for this device) using cfg 0 to initialize the built-in MII (using the Linux RTL8152/8153 driver as a model), and then switch to cfg 1 to use the CDC device for actual operation? Thanks, DH ___ 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"
