What    |Removed                     |Added
                 CC|                            |

--- Comment #33 from ---
(In reply to Hiren Panchasara from comment #31)

> Most interesting frames are these 2:
> #22 0xffffffff80a6c546 in ether_input (ifp=<optimized out>, m=0x0) at 
> /d2/hiren/freebsd/sys/net/if_ethersubr.c:759
> #23 0xffffffff804e2b3c in igb_rx_input (rxr=<optimized out>, 
> ifp=0xfffff80115614800, m=0xfffff8014eee7600, 
>    ptype=<optimized out>) at /d2/hiren/freebsd/sys/dev/e1000/if_igb.c:4957
> #23 has an mbuf while #22 has it null.

> Does this point to your hunch of
> "device-driver bugs involving modifications to the mbuf chain after 
> submitting the mbuf to the network stack (e.g., due to concurrency bugs in 
> the device driver)" ?

This is just result of compiler optimisation and stack decoding.
Compiler use for m same register as passed at call time and do

while (m) {  
 mn = m->m_nextpkt;
 m = mn;

as result m (as decoded argument) will be incorectly displayed.
Actualy this is just last loop iteration with last mbuf in chain.

You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to