> > David, please consider reverting > > > > 1e918876853aa85435e0f17fd8b4a92dcfff53d6 > > (r8169: add support for Byte Queue Limits) > > > > and > > > > 0bec3b700d106a8b0a34227b2976d1a582f1aab7 > > (r8169: add support for xmit_more) > > > > I cannot reproduce any hangs (tried for 2days with 40 parallel > > netperfs using both 100mbit and 1gbit receiver). > > > > And I don't see anything wrong with the change either. > > Seems like some revisions of the HW are just dodgy? > > > > I hate giving up, but I have no means to diagnose this any further. > > Even reporter says it doesn't affect all of his r8169 nics. > > > > So I think the change is correct per se, but might be revealing some > > HW/firmware bug. > > Hold on. > > I believe there is one race in the way you access skb->xmit_more _after_ > > txd->opts1 = cpu_to_le32(status); > > After this point, TX might have completed and TX completion already have > freed skb > > Could Tomas try following fix ? > > diff --git a/drivers/net/ethernet/realtek/r8169.c > b/drivers/net/ethernet/realtek/r8169.c > index ad0020af2193..f2764366a36c 100644 > ...
Sure, just did. Unfortunately, 3.19.0 + 0bec3b70 + this patch results in a driver that retains the problem. Sorry, -- Tomas Szepe <sz...@pinerecords.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
