On Fri, 2016-11-11 at 21:05 +0000, Russell King - ARM Linux wrote: > > 18:59:38.782818 IP (tos 0x0, ttl 52, id 35619, offset 0, flags [DF], proto > TCP (6), length 60) > 84.xx.xxx.196.61236 > 195.92.253.2.http: Flags [S], cksum 0x88db > (correct), seq 158975430, win 29200, options [mss 1452,sackOK,TS val > 1377914597 ecr 0,nop,wscale 7], length 0
... (MSS 1452) > 18:59:38.816371 IP (tos 0x0, ttl 64, id 25879, offset 0, flags [DF], proto > TCP (6), length 1500) > 195.92.253.2.http > 84.xx.xxx.196.61236: Flags [.], seq 1:1449, ack 154, > win 235, options [nop,nop,TS val 3363137952 ecr 1377914627], length 1448: > HTTP, length: 1448 > 18:59:38.816393 IP (tos 0x0, ttl 64, id 25880, offset 0, flags [DF], proto > TCP (6), length 1484) > 195.92.253.2.http > 84.xx.xxx.196.61236: Flags [.], seq 1449:2881, ack > 154, win 235, options [nop,nop,TS val 3363137952 ecr 1377914627], length > 1432: HTTP Can you instrument cp_start_xmit() in 8139cp.c and get it to print the value of 'mss' when this happens? All we do is take that value from skb_shinfo(skb)->gso_size, shift it a bit, and shove it in the descriptor ring. There's not much scope for a driver-specific bug. It's also *fairly* unlikely that the kernel in the guest has developed a bug and isn't setting gso_size sanely. I'm more inclined to suspect that qemu isn't properly emulating those bits. But at first glance at the code, it looks like *that's* been there for the last decade too... -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
