Bug 135178 - [xen] Xen domU outgoing data transfer stall when TSO is enabled
Summary: [xen] Xen domU outgoing data transfer stall when TSO is enabled
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-xen (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-02 15:50 UTC by Mr. Olli
Modified: 2015-05-18 19:22 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mr. Olli 2009-06-02 15:50:02 UTC
Transfering files larger than some size (presumably 2MB) via SSH with FreeBSD XEN para-virt domU stall after transfering 2112kb of data, when domU is source of transfer.

SSH transfers with the domU as target work properly.

Fix: 

As reported by "Anne Marcel Roorda" on freebsd-xen disable TCP Segmentation offloading solves the problem.

template-8_CURRENT# ifconfig xn0 -tso
template-8_CURRENT# scp /boot/kernel/kernel dante@10.30.1.15:/tmp
kernel                                          100% 4510KB   4.4MB/s   00:00    
template-8_CURRENT#
How-To-Repeat: 1) Enable TSO for xn0
2) transfer data (e.g. kernel file)

template-8_CURRENT# ifconfig xn0 tso
template-8_CURRENT# scp /boot/kernel/kernel dante@10.30.1.15:/tmp
Password: 
kernel                                                                                                  46% 2112KB   1.4MB/s - stalled -^CKilled by signal 2.
template-8_CURRENT#
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2009-06-02 18:36:18 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-xen

Over to maintainer(s).
Comment 2 Colin Percival freebsd_committer freebsd_triage 2010-11-28 15:17:25 UTC
This bug should have been fixed by SVN r208901 in June 2010 (merged to stable/8
as r209061).  Are you still seeing this with a recent tree?

-- 
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid
Comment 3 Colin Percival freebsd_committer freebsd_triage 2010-11-28 15:17:27 UTC
State Changed
From-To: open->feedback

Bug is probably fixed, place into state feedback in case the submitter 
can still reproduce.
Comment 4 Bryan Drewery freebsd_committer freebsd_triage 2015-05-18 17:40:01 UTC
This wasn't fixed, see Bug #192013 and Bug #154428.

I'm having this exact issue on EC2 10.1-GENERIC. Even with an empty pf.conf just enabling pf kills performance outbound and causes massive hangs.
Comment 5 Roger Pau Monné freebsd_committer freebsd_triage 2015-05-18 17:44:35 UTC
This bug is not about TSO + PF, just about TSO, which seems to work fine now (when not used in conjunction with PF).
Comment 6 Bryan Drewery freebsd_committer freebsd_triage 2015-05-18 17:45:52 UTC
(In reply to Roger Pau Monné from comment #5)
> This bug is not about TSO + PF, just about TSO, which seems to work fine now
> (when not used in conjunction with PF).


Ah. Sounds suspicious though. If PF is using TSO wrong why is it only causing problems with the Xen interface and not all?
Comment 7 Colin Percival freebsd_committer freebsd_triage 2015-05-18 19:22:55 UTC
PF is inserting bogus TCP checksums into TSO segments.  Some interfaces say "gee, some idiot didn't read the spec" and ignore the checksums, while other interfaces say "hey, this is not a TSO packet" and drop it.

The Xen network (at least as implemented in EC2) falls into the second category.