From owner-freebsd-net@freebsd.org Wed Aug 31 17:32:21 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61D6DBCAF9C for ; Wed, 31 Aug 2016 17:32:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 518B59FA for ; Wed, 31 Aug 2016 17:32:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7VHWL0g061385 for ; Wed, 31 Aug 2016 17:32:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 212283] network watchdog timeout with some raw sockets usage Date: Wed, 31 Aug 2016 17:32:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RC1 X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 17:32:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212283 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |glebius@FreeBSD.org, | |hselasky@FreeBSD.org --- Comment #3 from Andrey V. Elsukov --- >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.=