[Bug 212283] network watchdog timeout with some raw sockets usage

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212283

Andrey V. Elsukov <ae at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |glebius at FreeBSD.org,
                   |                            |hselasky at FreeBSD.org

--- Comment #3 from Andrey V. Elsukov <ae at 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. Since
DF flag also stored in the wrong byte order we fall into ip_fragment(), where
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. 
A driver calls m_collapse() and it fails. This leads to triggering of watchdog.

# 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      = "UNKNOWN" (0x00000EDC)
  program counter = 0x000222C4
  source line     = 0x00000AF4
  error data      = 0x0000000000000000
  branch link     = 0x0002224C0002224C
  interrupt link  = 0x0000D6BE00000000
  time            = 3419201031
driver status:
  tx ring  0: qid=0  cur=19  queued=9  
  tx ring  1: qid=1  cur=0   queued=0  
  tx ring  2: qid=2  cur=0   queued=0  
  tx ring  3: qid=3  cur=17  queued=0  
  tx ring  4: qid=4  cur=0   queued=0  
  tx ring  5: qid=5  cur=0   queued=0  
  tx ring  6: qid=6  cur=0   queued=0  
  tx ring  7: qid=7  cur=0   queued=0  
  tx ring  8: qid=8  cur=0   queued=0  
  tx ring  9: qid=9  cur=199 queued=0  
  tx ring 10: qid=10 cur=0   queued=0  
  tx ring 11: qid=11 cur=0   queued=0  
  tx ring 12: qid=12 cur=0   queued=0  
  tx ring 13: qid=13 cur=0   queued=0  
  tx ring 14: qid=14 cur=0   queued=0  
  tx ring 15: qid=15 cur=0   queued=0  
  tx ring 16: qid=16 cur=0   queued=0  
  tx ring 17: qid=17 cur=0   queued=0  
  tx ring 18: qid=18 cur=0   queued=0  
  tx ring 19: qid=19 cur=0   queued=0  
  rx ring: cur=60
iwn0: iwn_panicked: controller panicked, iv_state = 5; restarting

In your case seems re(4) behaves in the same way.

-- 
You are receiving this mail because:
You are the assignee for the bug.