Date: Wed, 31 Aug 2016 17:32:21 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 212283] network watchdog timeout with some raw sockets usage Message-ID: <bug-212283-2472-riYrcJJtsG@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-212283-2472@https.bugs.freebsd.org/bugzilla/> References: <bug-212283-2472@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212283 Andrey V. Elsukov <ae@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |glebius@FreeBSD.org, | |hselasky@FreeBSD.org --- Comment #3 from Andrey V. Elsukov <ae@FreeBSD.org> --- >From my ktrace results: 36643 ntraceroute CALL sendto(0x4,0x801270380,0x8021,0,0x614e14,0x10) 36643 ntraceroute GIO fd 4 wrote 4096 bytes 0x0000 4500 2180 0000 0040 0 sendto() does send 32801 bytes, but in the IP header this is 8576 bytes. Si= nce DF flag also stored in the wrong byte order we fall into ip_fragment(), whe= re we create several fragments. Then at the end of ip_fragment() we call m_adj= () to trim mbuf chain from the tail. But since real length is ~32801, after trimming we will still have several mbufs in the chain and a lot of data to send.=20 A driver calls m_collapse() and it fails. This leads to triggering of watch= dog. # dtrace -n 'fbt::m_collapse:return { printf("%p", (struct mbuf *)arg1); stack(10); }' dtrace: description 'fbt::m_collapse:return ' matched 1 probe CPU ID FUNCTION:NAME if_iwn.ko`iwn_tx_data+0x7d9 if_iwn.ko`iwn_transmit+0x9e kernel`ieee80211_parent_xmitpkt+0x13 kernel`ieee80211_vap_pkt_send_dest+0x29d kernel`ieee80211_vap_transmit+0x332 kernel`ether_output+0x763 kernel`ip_output+0x15f0 kernel`rip_output+0x2d3 kernel`sosend_generic+0x5e7 kernel`kern_sendit+0x22a 1 37159 m_collapse:return 0 if_iwn.ko`iwn_tx_data+0x7d9 if_iwn.ko`iwn_transmit+0x9e kernel`ieee80211_parent_xmitpkt+0x13 kernel`ieee80211_vap_pkt_send_dest+0x29d kernel`ieee80211_vap_transmit+0x332 kernel`ether_output+0x763 kernel`ip_output+0x15f0 kernel`rip_output+0x2d3 kernel`sosend_generic+0x5e7 kernel`kern_sendit+0x22a 1 37159 m_collapse:return 0 In console I see these messages: iwn0: iwn_tx_data: could not defrag mbuf iwn0: iwn_tx_data: could not defrag mbuf iwn0: iwn_tx_data: could not defrag mbuf iwn0: iwn_tx_data: could not defrag mbuf iwn0: iwn_intr: fatal firmware error firmware error log: error type =3D "UNKNOWN" (0x00000EDC) program counter =3D 0x000222C4 source line =3D 0x00000AF4 error data =3D 0x0000000000000000 branch link =3D 0x0002224C0002224C interrupt link =3D 0x0000D6BE00000000 time =3D 3419201031 driver status: tx ring 0: qid=3D0 cur=3D19 queued=3D9=20=20 tx ring 1: qid=3D1 cur=3D0 queued=3D0=20=20 tx ring 2: qid=3D2 cur=3D0 queued=3D0=20=20 tx ring 3: qid=3D3 cur=3D17 queued=3D0=20=20 tx ring 4: qid=3D4 cur=3D0 queued=3D0=20=20 tx ring 5: qid=3D5 cur=3D0 queued=3D0=20=20 tx ring 6: qid=3D6 cur=3D0 queued=3D0=20=20 tx ring 7: qid=3D7 cur=3D0 queued=3D0=20=20 tx ring 8: qid=3D8 cur=3D0 queued=3D0=20=20 tx ring 9: qid=3D9 cur=3D199 queued=3D0=20=20 tx ring 10: qid=3D10 cur=3D0 queued=3D0=20=20 tx ring 11: qid=3D11 cur=3D0 queued=3D0=20=20 tx ring 12: qid=3D12 cur=3D0 queued=3D0=20=20 tx ring 13: qid=3D13 cur=3D0 queued=3D0=20=20 tx ring 14: qid=3D14 cur=3D0 queued=3D0=20=20 tx ring 15: qid=3D15 cur=3D0 queued=3D0=20=20 tx ring 16: qid=3D16 cur=3D0 queued=3D0=20=20 tx ring 17: qid=3D17 cur=3D0 queued=3D0=20=20 tx ring 18: qid=3D18 cur=3D0 queued=3D0=20=20 tx ring 19: qid=3D19 cur=3D0 queued=3D0=20=20 rx ring: cur=3D60 iwn0: iwn_panicked: controller panicked, iv_state =3D 5; restarting In your case seems re(4) behaves in the same way. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-212283-2472-riYrcJJtsG>