Re: network locks up with udp traffic
> On 23 янв. 2015 г., at 21:58, Adrian Chadd wrote: > > Hi, > > When this next happens, please do this as root: > > procstat -ka > > That'll hopefully provide enough information to figure out which > processes are blocking where and how they got there. > > Hello, I am attaching procstat -ka output (and top output to see snmpd process in "*udp" state). ifconfig process was started with "net0" argument (net0 is a renamed igb0 in my case). last pid: 4686; load averages: 0.71, 0.69, 0.68 up 0+03:44:3212:53:43 55 processes: 1 running, 52 sleeping, 2 lock Mem: 4647M Active, 37G Inact, 2293M Wired, 635M Cache, 1655M Buf, 1985M Free Swap: 49G Total, 29M Used, 49G Free PID USERNAME THR PRI NICE SIZERES STATE C TIMEWCPU COMMAND 4658 mitya 9 210 1099M 521M uwait 3 0:30 0.00% ngram_m 4656 mitya 9 210 843M 566M uwait 15 0:30 0.00% ngram_m 4660 mitya 9 200 1100M 523M uwait 5 0:26 0.00% ngram_m 4659 mitya 9 210 764M 486M uwait 4 0:19 0.00% ngram_m 4662 mitya 9 200 678M 441M uwait 5 0:18 0.00% ngram_m 4661 mitya 9 210 772M 491M uwait 4 0:18 0.00% ngram_m 4657 mitya 9 200 762M 484M uwait 3 0:17 0.00% ngram_m 4666 mitya 9 200 678M 440M uwait 15 0:17 0.00% ngram_m 4663 mitya 9 200 682M 448M uwait 4 0:17 0.00% ngram_m 4665 mitya 9 200 688M 446M uwait 14 0:17 0.00% ngram_m 4664 mitya 9 200 673M 432M uwait 14 0:15 0.00% ngram_m 830 root1 200 64512K 4244K *udp3 0:06 0.00% snmpd 660 root1 200 14508K 1312K select 5 0:00 0.00% syslogd 912 root 11 200 83972K 3616K uwait 7 0:00 0.00% collect 864 root2 200 123M 24324K select 15 0:00 0.00% ruby19 810 root1 200 25456K 2220K select 4 0:00 0.00% ntpd 874 www 1 200 28616K 2324K kqread 12 0:00 0.00% nginx 875 www 1 200 28616K 2324K kqread 14 0:00 0.00% nginx PIDTID COMM TDNAME KSTACK 0 10 kernel swapper mi_switch sleepq_timedwait _sleep swapper btext 0 100055 kernel firmware taskq mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100059 kernel thread taskq mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100060 kernel ffs_trim taskq mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100065 kernel aiod_bio taskq mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100066 kernel acpi_task_0 mi_switch sleepq_wait msleep_spin_sbt taskqueue_thread_loop fork_exit fork_trampoline 0 100067 kernel acpi_task_1 mi_switch sleepq_wait msleep_spin_sbt taskqueue_thread_loop fork_exit fork_trampoline 0 100068 kernel acpi_task_2 mi_switch sleepq_wait msleep_spin_sbt taskqueue_thread_loop fork_exit fork_trampoline 0 100069 kernel kqueue taskq mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100087 kernel em0 rxq mi_switch sleepq_wait msleep_spin_sbt taskqueue_thread_loop fork_exit fork_trampoline 0 100089 kernel em0 txq mi_switch sleepq_wait msleep_spin_sbt taskqueue_thread_loop fork_exit fork_trampoline 0 100092 kernel em1 rxq mi_switch sleepq_wait msleep_spin_sbt taskqueue_thread_loop fork_exit fork_trampoline 0 100094 kernel em1 txq mi_switch sleepq_wait msleep_spin_sbt taskqueue_thread_loop fork_exit fork_trampoline 0 100136 kernel mca taskqmi_switch sleepq_wait msleep_spin_sbt taskqueue_thread_loop fork_exit fork_trampoline 0 100138 kernel dummynet mi_switch sleepq_wait msleep_spin_sbt taskqueue_thread_loop fork_exit fork_trampoline 0 100139 kernel CAM taskqmi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 1 11 init -mi_switch sleepq_catch_signals sleepq_wait_sig _sleep kern_wait6 sys_wait4 amd64_syscall Xfast_syscall 2 100062 cam doneq0 mi_switch sleepq_wait _sleep xpt_done_td fork_exit fork_trampoline 2 100063 cam doneq1 mi_switch sleepq_wait _sleep xpt_done_td fork_exit fork_trampoline 2 100064 cam doneq2 mi_switch sleepq_wait _sleep xpt_done_td fork_exit fork_trampoline 2 100140 cam scanner mi_switch sleepq_wait _sleep xpt_scanner_thread fork_exit fork_trampoline 3 100137 sctp_itera
[Bug 191520] [PATCH] Implementation of draft-ieft-tcpm-newcwv-06
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191520 Kubilay Kocak changed: What|Removed |Added Keywords||feature, needs-qa, patch -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: network locks up with udp traffic
Hi, Can you compile your kernel with WITNESS and repeat this test? It looks like it's stuck in some lock ordering thing between some UDP paths and an inpcb lookup. It should log in dmesg the first time a LOR occurs, regardless of whether it actively causes a hang. (And yes, this is definitely critical enough to be a FreeBSD PR... :) Thanks! -adrian On 24 January 2015 at 02:14, Dmitry Sivachenko wrote: > >> On 23 янв. 2015 г., at 21:58, Adrian Chadd wrote: >> >> Hi, >> >> When this next happens, please do this as root: >> >> procstat -ka >> >> That'll hopefully provide enough information to figure out which >> processes are blocking where and how they got there. >> >> > > > Hello, > > I am attaching procstat -ka output (and top output to see snmpd process in > "*udp" state). > ifconfig process was started with "net0" argument (net0 is a renamed igb0 in > my case). > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: network locks up with udp traffic
> On 24 янв. 2015 г., at 20:29, Adrian Chadd wrote: > > Hi, > > Can you compile your kernel with WITNESS and repeat this test? It > looks like it's stuck in some lock ordering thing between some UDP > paths and an inpcb lookup. > > It should log in dmesg the first time a LOR occurs, regardless of > whether it actively causes a hang. Here is what I got in dmesg just before my net locked up: lock order reversal: 1st 0x80e79008 pcbinfohash (pcbinfohash) @ /opt/WRK/src/sys/netinet6/udp6_usrreq.c:1202 2nd 0x80e78fb0 udp (udp) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:614 lock order reversal: 1st 0x80e79008 pcbinfohash (pcbinfohash) @ /opt/WRK/src/sys/netinet6/udp6_usrreq.c:1202 2nd 0x80e78d58 tcp (tcp) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:614 lock order reversal: 1st 0x80e79008 pcbinfohash (pcbinfohash) @ /opt/WRK/src/sys/netinet6/udp6_usrreq.c:1202 2nd 0x80e781c0 rip (rip) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:614 When I was saving this dmesg output to disk, I got another LOR: lock order reversal: 1st 0xfe0baf12fd78 bufwait (bufwait) @ /opt/WRK/src/sys/kern/vfs_bio.c:3065 2nd 0xf80011416c00 dirhash (dirhash) @ /opt/WRK/src/sys/ufs/ufs/ufs_dirhash.c:284 Please tell me if I can provide more information to help tracking this down. Thanks! ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: network locks up with udp traffic
Hi! To be clear: * is your kernel modified in any way; and * did witness give you a full stacktrace as part of the lock order reversal? All of that would be good. Thanks, On 24 January 2015 at 09:53, Dmitry Sivachenko wrote: > >> On 24 янв. 2015 г., at 20:29, Adrian Chadd wrote: >> >> Hi, >> >> Can you compile your kernel with WITNESS and repeat this test? It >> looks like it's stuck in some lock ordering thing between some UDP >> paths and an inpcb lookup. >> >> It should log in dmesg the first time a LOR occurs, regardless of >> whether it actively causes a hang. > > > > Here is what I got in dmesg just before my net locked up: > > lock order reversal: > 1st 0x80e79008 pcbinfohash (pcbinfohash) @ > /opt/WRK/src/sys/netinet6/udp6_usrreq.c:1202 > 2nd 0x80e78fb0 udp (udp) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:614 > lock order reversal: > 1st 0x80e79008 pcbinfohash (pcbinfohash) @ > /opt/WRK/src/sys/netinet6/udp6_usrreq.c:1202 > 2nd 0x80e78d58 tcp (tcp) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:614 > lock order reversal: > 1st 0x80e79008 pcbinfohash (pcbinfohash) @ > /opt/WRK/src/sys/netinet6/udp6_usrreq.c:1202 > 2nd 0x80e781c0 rip (rip) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:614 > > When I was saving this dmesg output to disk, I got another LOR: > > lock order reversal: > 1st 0xfe0baf12fd78 bufwait (bufwait) @ > /opt/WRK/src/sys/kern/vfs_bio.c:3065 > 2nd 0xf80011416c00 dirhash (dirhash) @ > /opt/WRK/src/sys/ufs/ufs/ufs_dirhash.c:284 > > > Please tell me if I can provide more information to help tracking this down. > > Thanks! ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: network locks up with udp traffic
> On 24 янв. 2015 г., at 21:56, Adrian Chadd wrote: > > Hi! > > To be clear: > > * is your kernel modified in any way; and No, it isn't > * did witness give you a full stacktrace as part of the lock order > reversal? All of that would be good. > I provided the full output I saw on console. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 188897] [dc] dc ethernet driver seems to prevent the detection of other NIC chipsets
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188897 --- Comment #7 from c...@eugeneweb.com --- Created attachment 152106 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=152106&action=edit This is a verbose dmesg for another dc quadport card, a DFE-570TX -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 194515] Fatal Trap 12 Kernel with vimage
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194515 --- Comment #19 from Craig Rodrigues --- (In reply to darius from comment #18) I'm OK with merging this to stable/10, but I would like to get some feedback from PF users on the state of things in CURRENT before merging. What is your experience with this patch? Herbert Skuhra has provided good feedback, but getting a few more people to try it and report would be great. Herbert found another bug in CURRENT: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195859 That is a bug in the bridge code, and not part of the VIMAGE + PF fixes. However, all this stuff is interrelated. It would be nice to get a fix in for PR 195859, so provide a consistent testing environment for VIMAGE in CURRENT. That will make it easier to backport patches to stable/10. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: network locks up with udp traffic
Ah, try adding STACK to your config? -a On 24 January 2015 at 11:45, Dmitry Sivachenko wrote: > >> On 24 янв. 2015 г., at 21:56, Adrian Chadd wrote: >> >> Hi! >> >> To be clear: >> >> * is your kernel modified in any way; and > > > No, it isn't > > >> * did witness give you a full stacktrace as part of the lock order >> reversal? All of that would be good. >> > > > I provided the full output I saw on console. > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 226 lines] D1641: Implement PCI SR-IOV initialization methods
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY Implement the two new PCI methods used to initialize and uninitialize SR-IOV on a PF. On initialization, the PF must allocate a VEB, which is a virtual switch instance implemented by the hardware. The PF's interface is made a child of this switch. REVISION DETAIL https://reviews.freebsd.org/D1641 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl.h sys/dev/ixl/ixl_pf.h To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 118 lines] D1642: Implement PCI SR-IOV method to initialize individual VFs
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY For each VF that has been allocated, the PF driver must allocate a Virtual Switch Interface (VSI), which is a virtual port on the virtual Fortville switch (VEB). In device_attach() for the PF, we now have to initialize all RX and TX queues instead just those that will be used by the PF, as there is no way of know how many will be allocated at runtime for the VFs. REVISION DETAIL https://reviews.freebsd.org/D1642 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl.h sys/dev/ixl/ixl_pf.h sys/dev/ixl/ixlv.h To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 225 lines] D1643: Implement resetting a VF
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY Add the ability to do a full reset of a VF's state. This involves stopping the VF in hardware, releasing all resources, re-allocating a new VSI, and finally allocating the VSI's queue resources. REVISION DETAIL https://reviews.freebsd.org/D1643 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl.h To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 1, 330 lines] D1640: Refactor network stack state separate from VSI state
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY Currently the ixl driver has a struct ixl_vsi that it uses to track both network stack interface state (e.g. the ifnet) and Virtual Station Interface (VSI) state in the hardware. However, when the ixl driver is acting as a PF device for SR-IOV, we will allocate VSIs for the VFs, but won't have any network stack state for those VSIs in the ixl driver itself (instead the ixlv driver will attach to the VF device, which has its own state independent of the PF driver). Fix this by introducing a new structure, ixl_ifx, which will be used to track network stack state. Refactor both the ixl and ixlv drivers to move their network stack state into this new structure, and retain the ixl_vsi structure to track only information related to details of the VSI allocated from the hw. REVISION DETAIL https://reviews.freebsd.org/D1640 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/if_ixlv.c sys/dev/ixl/ixl.h sys/dev/ixl/ixl_pf.h sys/dev/ixl/ixl_txrx.c sys/dev/ixl/ixlv.h sys/dev/ixl/ixlvc.c To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 21 lines] D1645: Add support for VERSION VC message
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY The VC message format is versioned. Implement the VERSION VC message, which the VF uses to discover the version of the VC protocol implemented by the PF. The VF will not be able to come up if the PF's version is incompatible. REVISION DETAIL https://reviews.freebsd.org/D1645 AFFECTED FILES sys/dev/ixl/if_ixl.c To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 32 lines] D1647: Add support for GET_VF_RESOURCES VC message
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY This message is sent by the VF driver to discover the capabilities of the VF, like the number of rx/tx queues supported. REVISION DETAIL https://reviews.freebsd.org/D1647 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl_pf.h To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 152 lines] D1644: Add infrastructure for handling the VC msg channel from VFs
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY The VF drivers do not have unrestricted access to the hardware. To configure the VF (e.g. set the MAC address), they are required to send a message the PF requesting the configuration. These messages are passed over the "Virtual Channel" (VC). Add the infrastructure required to receive Admin Queue interrupts indicating that a VC message has been received. Also add functions for sending responses back to the VFs. At this stage no VC messages are actually handled. Implementation of individual VC messages will be added in subsequent commits. REVISION DETAIL https://reviews.freebsd.org/D1644 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl_pf.h To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: network locks up with udp traffic
> On 25 янв. 2015 г., at 0:10, Adrian Chadd wrote: > > Ah, try adding STACK to your config? > It's already there. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 68 lines] D1651: Add support for ENABLE/DISABLE_QUEUES VC messages
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY These messages are sent by the VF to enable or disable packet reception and transmission from its queues. Despite the fact that a bitmask of queues is provided in the message, this is ignored and all queues are either enabled or disabled. This matches the behaviour of the Linux PF driver. REVISION DETAIL https://reviews.freebsd.org/D1651 AFFECTED FILES sys/dev/ixl/if_ixl.c To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 38 lines] D1648: Add stubs for deprecated VC messages
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY There are a couple of VC message types defined in the enum that seem to have been deprecated early in the Fortville SR-IOV development process. Explicitly implement them to return an error to document that these are intentionally not supported. REVISION DETAIL https://reviews.freebsd.org/D1648 AFFECTED FILES sys/dev/ixl/if_ixl.c To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 19 lines] D1646: Add support for RESET_VF VC message
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY This VC message is used by the VF driver to request a full reset of the VF state. Unlike all other VC messages, no response is sent to the message. REVISION DETAIL https://reviews.freebsd.org/D1646 AFFECTED FILES sys/dev/ixl/if_ixl.c To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 165 lines] D1650: Add support for CONFIG_IRQ_MAP VC message
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY This message is used by the VF to request that its RX and TX queues be associated with particular MSI-X vectors. This configuration is performed via a fairly complicated linked-list mechanism in the hardware. The linked list is built up backwards (from the tail to the head) as it turns out to simplify the logic significantly. REVISION DETAIL https://reviews.freebsd.org/D1650 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl.h To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 161 lines] D1652: Add support for ADD/DEL_ETHER_ADDRESS VC messages
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY The ADD message is sent by the VF to request that a MAC address filter be added to the Fortville switch to direct packets destined to that MAC be routed to the VF's VSI. The DEL message deletes a MAC address filter that was previously established. This has security implications in a VM environment (a VM could listen in on packets that it's not entitled to see), so the VF has to have this capability enabled on it. REVISION DETAIL https://reviews.freebsd.org/D1652 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl.h sys/dev/ixl/ixl_pf.h To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 49 lines] D1654: Add support for CONFIG_PROMISCUOUS_MODE VC message
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY This message is sent by the VF driver to request that the VSI be placed in or taken out of promiscuous mode. REVISION DETAIL https://reviews.freebsd.org/D1654 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl_pf.h To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 177 lines] D1649: Add support for CONFIG_VSI_QUEUES VC message
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY This message is sent by the VF to request that the PF configure its RX and TX queues. The PF is required to validate that the request is sane before applying the configuration. REVISION DETAIL https://reviews.freebsd.org/D1649 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl.h To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 41 lines] D1655: Add support for GET_STATS VC message
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY The Fortville hardware tracks a small number of per-VSI counters, like packet and byte counters. The GET_STATS message is sent by the VF driver to request a copy of the current value of those counters. REVISION DETAIL https://reviews.freebsd.org/D1655 AFFECTED FILES sys/dev/ixl/if_ixl.c To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 121 lines] D1653: Add support for ADD/DEL_VLAN VC messages
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY These messages are sent by the PF to change configuration related to the hardware vlan filtering and stripping. If a VF is subscribed to one or more vlans then the vlan header will be stripped by the hardware, and other vlans will be filtered in hardware. REVISION DETAIL https://reviews.freebsd.org/D1653 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl_pf.h To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 34 lines] D1657: Allow VFs to run while the PF is admin down
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY Ensure that the admin queue interrupt stays enabled as long as we have VFs. It is a requirement that the VFs be able to keep running correctly even if the PF ifnet is admin down. REVISION DETAIL https://reviews.freebsd.org/D1657 AFFECTED FILES sys/dev/ixl/if_ixl.c To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 65 lines] D1656: Handle VFLR events from VFs
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY If a VF resets itself via a Function Level Reset (FLR) bit, the PF receives an interrupt with a VFLR event. The PF is required to re-initialize the VF state when this happens. REVISION DETAIL https://reviews.freebsd.org/D1656 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl.h sys/dev/ixl/ixl_pf.h To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 24 lines] D1659: Register ixl as an SR-IOV-capable driver during attach
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY Now that the driver's SR-IOV implementation is complete, during attach register the device as being SR-IOV capable. This will cause the SR-IOV infrastructure to create the device node in /dev/iov used to configure SR-IOV on this device, making it possible for the administrator to enable SR-IOV. REVISION DETAIL https://reviews.freebsd.org/D1659 AFFECTED FILES sys/dev/ixl/if_ixl.c To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 34 lines] D1658: Add sysctls for per-VF hardware counters
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY For debugging purposes, add sysctls that reflect the value of each VF's hardware counters. REVISION DETAIL https://reviews.freebsd.org/D1658 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl_pf.h To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 23 lines] D1661: Add some security-related config parameters
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY Allow the administrator to prevent VFs from sending packets with a source MAC that is not the VF's MAC (anti-spoof). Default this to on. Allow the administrator to give VFs the ability to override the MAC address that was specified at creation time. By default VFs will not be permitted to do this. Allow the administrator to give the VFs the ability to enter promiscuous mode. REVISION DETAIL https://reviews.freebsd.org/D1661 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl_pf.h To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Request, 21 lines] D1660: Add support for mac-addr parameter
rstone created this revision. rstone added a reviewer: jfvogel. rstone added a subscriber: freebsd-net. REVISION SUMMARY Implement a mac-addr SR-IOV configuration parameter, which the administrator can specify to force a VF to use a particular MAC address. By default, the VF driver cannot change its MAC address if it has been specified by the administrator. REVISION DETAIL https://reviews.freebsd.org/D1660 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl.h To: rstone, jfvogel Cc: freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: network locks up with udp traffic
On 24 January 2015 at 14:45, Dmitry Sivachenko wrote: > >> On 25 янв. 2015 г., at 0:10, Adrian Chadd wrote: >> >> Ah, try adding STACK to your config? >> > > > It's already there. Hm, not sure why you're not getting the full stacks in the witness dump. Maybe try KDB and KDB_TRACE ? -adrian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: network locks up with udp traffic
> On 25 янв. 2015 г., at 1:45, Dmitry Sivachenko wrote: > > >> On 25 янв. 2015 г., at 0:10, Adrian Chadd wrote: >> >> Ah, try adding STACK to your config? >> > > > It's already there. Ah, sorry, it is options DDB that was missing. Now we have full stack: lock order reversal: 1st 0x80ea5588 pcbinfohash (pcbinfohash) @ /opt/WRK/src/sys/netinet6/ud p6_usrreq.c:1202 2nd 0x80ea5530 udp (udp) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:614 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0c581c1270 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0c581c1320 witness_checkorder() at witness_checkorder+0xc04/frame 0xfe0c581c13a0 _rw_wlock_cookie() at _rw_wlock_cookie+0x45/frame 0xfe0c581c13e0 in6_pcbnotify() at in6_pcbnotify+0x12e/frame 0xfe0c581c1480 udp6_common_ctlinput() at udp6_common_ctlinput+0x111/frame 0xfe0c581c14e0 pfctlinput2() at pfctlinput2+0x7d/frame 0xfe0c581c1520 ip6_output() at ip6_output+0x15b8/frame 0xfe0c581c1780 udp6_send() at udp6_send+0x75c/frame 0xfe0c581c1910 sosend_dgram() at sosend_dgram+0x30b/frame 0xfe0c581c1980 kern_sendit() at kern_sendit+0x191/frame 0xfe0c581c1a30 sendit() at sendit+0x225/frame 0xfe0c581c1a80 sys_sendmsg() at sys_sendmsg+0x68/frame 0xfe0c581c1ae0 amd64_syscall() at amd64_syscall+0x244/frame 0xfe0c581c1bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0c581c1bf0 --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x803ec5eaa, rsp = 0x7fffdf5f6848, rbp = 0x7fffdf5f6880 --- lock order reversal: 1st 0x80ea5588 pcbinfohash (pcbinfohash) @ /opt/WRK/src/sys/netinet6/udp6_usrreq.c:1202 2nd 0x80ea52d8 tcp (tcp) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:614 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0c581c1240 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0c581c12f0 witness_checkorder() at witness_checkorder+0xc04/frame 0xfe0c581c1370 _rw_wlock_cookie() at _rw_wlock_cookie+0x45/frame 0xfe0c581c13b0 in6_pcbnotify() at in6_pcbnotify+0x12e/frame 0xfe0c581c1450 tcp6_ctlinput() at tcp6_ctlinput+0x1a5/frame 0xfe0c581c14e0 pfctlinput2() at pfctlinput2+0x7d/frame 0xfe0c581c1520 ip6_output() at ip6_output+0x15b8/frame 0xfe0c581c1780 udp6_send() at udp6_send+0x75c/frame 0xfe0c581c1910 sosend_dgram() at sosend_dgram+0x30b/frame 0xfe0c581c1980 kern_sendit() at kern_sendit+0x191/frame 0xfe0c581c1a30 sendit() at sendit+0x225/frame 0xfe0c581c1a80 sys_sendmsg() at sys_sendmsg+0x68/frame 0xfe0c581c1ae0 amd64_syscall() at amd64_syscall+0x244/frame 0xfe0c581c1bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0c581c1bf0 --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x803ec5eaa, rsp = 0x7fffdf5f6848, rbp = 0x7fffdf5f6880 --- lock order reversal: 1st 0x80ea5588 pcbinfohash (pcbinfohash) @ /opt/WRK/src/sys/netinet6/udp6_usrreq.c:1202 2nd 0x80ea4740 rip (rip) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:614 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0c581c12b0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0c581c1360 witness_checkorder() at witness_checkorder+0xc04/frame 0xfe0c581c13e0 _rw_wlock_cookie() at _rw_wlock_cookie+0x45/frame 0xfe0c581c1420 in6_pcbnotify() at in6_pcbnotify+0x12e/frame 0xfe0c581c14c0 rip6_ctlinput() at rip6_ctlinput+0x70/frame 0xfe0c581c14e0 pfctlinput2() at pfctlinput2+0x7d/frame 0xfe0c581c1520 ip6_output() at ip6_output+0x15b8/frame 0xfe0c581c1780 udp6_send() at udp6_send+0x75c/frame 0xfe0c581c1910 sosend_dgram() at sosend_dgram+0x30b/frame 0xfe0c581c1980 kern_sendit() at kern_sendit+0x191/frame 0xfe0c581c1a30 sendit() at sendit+0x225/frame 0xfe0c581c1a80 sys_sendmsg() at sys_sendmsg+0x68/frame 0xfe0c581c1ae0 amd64_syscall() at amd64_syscall+0x244/frame 0xfe0c581c1bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0c581c1bf0 --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x803ec5eaa, rsp = 0x7fffdf5f6848, rbp = 0x7fffdf5f6880 --- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: network locks up with udp traffic
ok, cool. You definitely have enough for a freebsd bug report. Would you mind adding it? https://bugs.freebsd.org/submit/ -a On 24 January 2015 at 15:07, Dmitry Sivachenko wrote: > >> On 25 янв. 2015 г., at 1:45, Dmitry Sivachenko wrote: >> >> >>> On 25 янв. 2015 г., at 0:10, Adrian Chadd wrote: >>> >>> Ah, try adding STACK to your config? >>> >> >> >> It's already there. > > > Ah, sorry, it is options DDB that was missing. Now we have full stack: > > > lock order reversal: > 1st 0x80ea5588 pcbinfohash (pcbinfohash) @ > /opt/WRK/src/sys/netinet6/ud > p6_usrreq.c:1202 > 2nd 0x80ea5530 udp (udp) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:614 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0c581c1270 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0c581c1320 > witness_checkorder() at witness_checkorder+0xc04/frame 0xfe0c581c13a0 > _rw_wlock_cookie() at _rw_wlock_cookie+0x45/frame 0xfe0c581c13e0 > in6_pcbnotify() at in6_pcbnotify+0x12e/frame 0xfe0c581c1480 > udp6_common_ctlinput() at udp6_common_ctlinput+0x111/frame 0xfe0c581c14e0 > pfctlinput2() at pfctlinput2+0x7d/frame 0xfe0c581c1520 > ip6_output() at ip6_output+0x15b8/frame 0xfe0c581c1780 > udp6_send() at udp6_send+0x75c/frame 0xfe0c581c1910 > sosend_dgram() at sosend_dgram+0x30b/frame 0xfe0c581c1980 > kern_sendit() at kern_sendit+0x191/frame 0xfe0c581c1a30 > sendit() at sendit+0x225/frame 0xfe0c581c1a80 > sys_sendmsg() at sys_sendmsg+0x68/frame 0xfe0c581c1ae0 > amd64_syscall() at amd64_syscall+0x244/frame 0xfe0c581c1bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0c581c1bf0 > --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x803ec5eaa, rsp = > 0x7fffdf5f6848, rbp = 0x7fffdf5f6880 --- > > > lock order reversal: > 1st 0x80ea5588 pcbinfohash (pcbinfohash) @ > /opt/WRK/src/sys/netinet6/udp6_usrreq.c:1202 > 2nd 0x80ea52d8 tcp (tcp) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:614 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0c581c1240 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0c581c12f0 > witness_checkorder() at witness_checkorder+0xc04/frame 0xfe0c581c1370 > _rw_wlock_cookie() at _rw_wlock_cookie+0x45/frame 0xfe0c581c13b0 > in6_pcbnotify() at in6_pcbnotify+0x12e/frame 0xfe0c581c1450 > tcp6_ctlinput() at tcp6_ctlinput+0x1a5/frame 0xfe0c581c14e0 > pfctlinput2() at pfctlinput2+0x7d/frame 0xfe0c581c1520 > ip6_output() at ip6_output+0x15b8/frame 0xfe0c581c1780 > udp6_send() at udp6_send+0x75c/frame 0xfe0c581c1910 > sosend_dgram() at sosend_dgram+0x30b/frame 0xfe0c581c1980 > kern_sendit() at kern_sendit+0x191/frame 0xfe0c581c1a30 > sendit() at sendit+0x225/frame 0xfe0c581c1a80 > sys_sendmsg() at sys_sendmsg+0x68/frame 0xfe0c581c1ae0 > amd64_syscall() at amd64_syscall+0x244/frame 0xfe0c581c1bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0c581c1bf0 > --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x803ec5eaa, rsp = > 0x7fffdf5f6848, rbp = 0x7fffdf5f6880 --- > > > > lock order reversal: > 1st 0x80ea5588 pcbinfohash (pcbinfohash) @ > /opt/WRK/src/sys/netinet6/udp6_usrreq.c:1202 > 2nd 0x80ea4740 rip (rip) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:614 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0c581c12b0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0c581c1360 > witness_checkorder() at witness_checkorder+0xc04/frame 0xfe0c581c13e0 > _rw_wlock_cookie() at _rw_wlock_cookie+0x45/frame 0xfe0c581c1420 > in6_pcbnotify() at in6_pcbnotify+0x12e/frame 0xfe0c581c14c0 > rip6_ctlinput() at rip6_ctlinput+0x70/frame 0xfe0c581c14e0 > pfctlinput2() at pfctlinput2+0x7d/frame 0xfe0c581c1520 > ip6_output() at ip6_output+0x15b8/frame 0xfe0c581c1780 > udp6_send() at udp6_send+0x75c/frame 0xfe0c581c1910 > sosend_dgram() at sosend_dgram+0x30b/frame 0xfe0c581c1980 > kern_sendit() at kern_sendit+0x191/frame 0xfe0c581c1a30 > sendit() at sendit+0x225/frame 0xfe0c581c1a80 > sys_sendmsg() at sys_sendmsg+0x68/frame 0xfe0c581c1ae0 > amd64_syscall() at amd64_syscall+0x244/frame 0xfe0c581c1bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0c581c1bf0 > --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x803ec5eaa, rsp = > 0x7fffdf5f6848, rbp = 0x7fffdf5f6880 --- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 197059] network locks up with IPv6 udp traffic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197059 Bug ID: 197059 Summary: network locks up with IPv6 udp traffic Product: Base System Version: 10.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-b...@freebsd.org Reporter: de...@freebsd.org CC: adr...@freebsd.org, freebsd-net@FreeBSD.org Hello! I am using FreeBSD-10/stable. We have a program at work that transmits data via UDP. When I run several instances of this program simultaneously, after a few seconds network stops working. If I login from console, I see some network daemons like ntpd, snmpd are in "*udp" state. If I try to deal with network interface (ifconfig igb0 for instance), ifconfig utility stuck in "L" state (Marks a process that is waiting to acquire a lock.). I found the only way to fix that: reboot. What can be the cause for such a behaviour? lock order reversal: 1st 0x80ea5588 pcbinfohash (pcbinfohash) @ /opt/WRK/src/sys/netinet6/ud p6_usrreq.c:1202 2nd 0x80ea5530 udp (udp) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:614 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0c581c1270 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0c581c1320 witness_checkorder() at witness_checkorder+0xc04/frame 0xfe0c581c13a0 _rw_wlock_cookie() at _rw_wlock_cookie+0x45/frame 0xfe0c581c13e0 in6_pcbnotify() at in6_pcbnotify+0x12e/frame 0xfe0c581c1480 udp6_common_ctlinput() at udp6_common_ctlinput+0x111/frame 0xfe0c581c14e0 pfctlinput2() at pfctlinput2+0x7d/frame 0xfe0c581c1520 ip6_output() at ip6_output+0x15b8/frame 0xfe0c581c1780 udp6_send() at udp6_send+0x75c/frame 0xfe0c581c1910 sosend_dgram() at sosend_dgram+0x30b/frame 0xfe0c581c1980 kern_sendit() at kern_sendit+0x191/frame 0xfe0c581c1a30 sendit() at sendit+0x225/frame 0xfe0c581c1a80 sys_sendmsg() at sys_sendmsg+0x68/frame 0xfe0c581c1ae0 amd64_syscall() at amd64_syscall+0x244/frame 0xfe0c581c1bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0c581c1bf0 --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x803ec5eaa, rsp = 0x7fffdf5f6848, rbp = 0x7fffdf5f6880 --- lock order reversal: 1st 0x80ea5588 pcbinfohash (pcbinfohash) @ /opt/WRK/src/sys/netinet6/udp6_usrreq.c:1202 2nd 0x80ea52d8 tcp (tcp) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:614 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0c581c1240 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0c581c12f0 witness_checkorder() at witness_checkorder+0xc04/frame 0xfe0c581c1370 _rw_wlock_cookie() at _rw_wlock_cookie+0x45/frame 0xfe0c581c13b0 in6_pcbnotify() at in6_pcbnotify+0x12e/frame 0xfe0c581c1450 tcp6_ctlinput() at tcp6_ctlinput+0x1a5/frame 0xfe0c581c14e0 pfctlinput2() at pfctlinput2+0x7d/frame 0xfe0c581c1520 ip6_output() at ip6_output+0x15b8/frame 0xfe0c581c1780 udp6_send() at udp6_send+0x75c/frame 0xfe0c581c1910 sosend_dgram() at sosend_dgram+0x30b/frame 0xfe0c581c1980 kern_sendit() at kern_sendit+0x191/frame 0xfe0c581c1a30 sendit() at sendit+0x225/frame 0xfe0c581c1a80 sys_sendmsg() at sys_sendmsg+0x68/frame 0xfe0c581c1ae0 amd64_syscall() at amd64_syscall+0x244/frame 0xfe0c581c1bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0c581c1bf0 --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x803ec5eaa, rsp = 0x7fffdf5f6848, rbp = 0x7fffdf5f6880 --- lock order reversal: 1st 0x80ea5588 pcbinfohash (pcbinfohash) @ /opt/WRK/src/sys/netinet6/udp6_usrreq.c:1202 2nd 0x80ea4740 rip (rip) @ /opt/WRK/src/sys/netinet6/in6_pcb.c:614 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0c581c12b0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0c581c1360 witness_checkorder() at witness_checkorder+0xc04/frame 0xfe0c581c13e0 _rw_wlock_cookie() at _rw_wlock_cookie+0x45/frame 0xfe0c581c1420 in6_pcbnotify() at in6_pcbnotify+0x12e/frame 0xfe0c581c14c0 rip6_ctlinput() at rip6_ctlinput+0x70/frame 0xfe0c581c14e0 pfctlinput2() at pfctlinput2+0x7d/frame 0xfe0c581c1520 ip6_output() at ip6_output+0x15b8/frame 0xfe0c581c1780 udp6_send() at udp6_send+0x75c/frame 0xfe0c581c1910 sosend_dgram() at sosend_dgram+0x30b/frame 0xfe0c581c1980 kern_sendit() at kern_sendit+0x191/frame 0xfe0c581c1a30 sendit() at sendit+0x225/frame 0xfe0c581c1a80 sys_sendmsg() at sys_sendmsg+0x68/frame 0xfe0c581c1ae0 amd64_syscall() at amd64_syscall+0x244/frame 0xfe0c581c1bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0c581c1bf0 --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x803ec5eaa, rsp = 0x7fffdf5f6848, rbp = 0x7fffdf5f6880 --- -- You are receiving this mail because: You are on the CC list for the bug. ___
