https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275798
--- Comment #10 from Richard Scheffenegger <[email protected]> --- It appears that the issue may have to do with some LRO going on as well on the receiver side - which doesn't ACK each individual packet, but typically 2 consecutive one, even while the receiver knows loss/reordering is on-going. At that stage the receiver normally would ACK every packet received... The ultimate issue appears to happen after a RTO timeout, when the last outstanding (2-packet) hole is filled, and the cumulative ACK covering it all also contains a DSACK block at the beginning of the former hole... Normally, such a DSACK block should be discareded and ignored during the SACK update process - not really sure why it's apparently processed erraneously, leading to the panic... -- You are receiving this mail because: You are on the CC list for the bug.
