Bug #4401


remove xen netfront driver until it can handle altq

Added by Grischa Zengel over 8 years ago. Updated almost 8 years ago.

Operating System
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


Since 2.2 (freeBSD 10.1) pfsense always detect xen on booting and uses pv(hvm) drivers (xn#).
xn0 is unusable without traffic shaping and tagging.

There is no way to go back to use emulated NICs (em#), because xen_platform_pci=0 will produce kernel panic.

This bug is related to #4345.

Actions #1

Updated by Ermal Luçi over 8 years ago

XN driver does not support ALTQ at all though it should not be hard to implement it.

Actions #2

Updated by Chris Linstruth over 8 years ago

xn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether be:f5:19:d5:81:bb
inet netmask 0xffffff00 broadcast
inet6 fe80::bcf5:19ff:fed5:81bb%xn0 prefixlen 64 scopeid 0x5
media: Ethernet manual
status: active

No altq, no vlans.

Actions #3

Updated by Grischa Zengel over 8 years ago

Is there a way to disable xen detection while booting?
I had to remove traffic shaping from my local pfsense and now we are unable to work properly.
If there is no quick solution I have to use bare metal.

I can not update our cloud servers, because each have a virtual pfsense and are chained in vlans.

Actions #4

Updated by Chris Buechler over 8 years ago

  • Status changed from New to Rejected

We will get ALTQ support into xn for 2.2.2. We'll track that on the original ticket for that problem, #4345

We're not going to remove xn. A slew of people upgraded Xen VMs to 2.2 and updated their configurations accordingly. Traffic shaping is a minority.

We're not going to break the significant majority for the needs of the minority. If you must have ALTQ traffic shaping in Xen, you'll have to stick with 2.1.5 for the moment. Many circumstances can be accommodated with limiters rather than ALTQ, and limiters will work fine in Xen with 2.2.

Actions #5

Updated by Grischa Zengel over 8 years ago

If it's come with 2.2.2 I can wait.
But if not I think 100% update success is better than 80% faster running systems and 20% waste.

The most systems I use have traffic shaping because of VoIP and other time critical services (RDP, VNC, SQL, ...).

If I understand cmb right in his post pfsense shouldn't never use xn, because it's not xen which change things it's pfsense:

Where is the source code for the changes?

Actions #6

Updated by Chris Buechler over 8 years ago

Removing this would not result in 100% upgrade success, it'd result in 100% of already upgraded and fixed systems breaking when upgrading 2.2 to 2.2.1, then 100% breaking again going from 2.2.1 to 2.2.2. That's unacceptable. The big warning in the upgrade guide is there for Xen users, who should have all noted that and changed things in the process.

My post in that linked thread (I'm cmb) is opposite what you said. It's Xen's stupid behavior of changing your NIC type out from under you without any ability to control what it's presenting the OS at the root of this issue.

The source in question that makes Xen do this is in stock FreeBSD 10.1. You can remove that from the kernel config and build your own kernel. That's in tools, details for reaching it here:

Actions #7

Updated by Grischa Zengel over 8 years ago

You make a really good job and if XN+ALTQ is working in 2.2.2 we'll never spoke about that.

It's never xen which changes the NIC. From first days on xen gives the DomU the ability to choose the right NIC and pfsense chooses the wrong one since 2.2.

It would be better not to integrate netfront until it supports ALTQ. But now it's integrated and to remove it and integrate it again with 2.2.2 is unnecessary.
Perhaps for good will you can create an unofficial release without netfront. If you have an early 2.2.2 for testing ALTQ I would test it.

Actions #8

Updated by Chris Buechler about 8 years ago

  • Target version deleted (2.2.1)
Actions #9

Updated by Andreas Pflug almost 8 years ago

2.2.4 running, still no ALTQ...
I don't see any traffic on about xn, so it appears that we can't expect it to be fixed in some near or mid future.

Actions #10

Updated by Andreas Pflug almost 8 years ago

I've been told that there has been posted a patch that will give us the switch we need:
xen: allow disabling PV disks and nics

I'd love this to be included in the next 2.2.5 release.

Actions #11

Updated by Jim Thompson almost 8 years ago

  • Assignee set to Renato Botelho
  • Target version set to 2.3
Actions #12

Updated by Chris Buechler almost 8 years ago

  • Target version deleted (2.3)
  • Affected Version deleted (2.2)

Guessing Jim re-assigned target and to Renato to get 286999 implemented. Rejected is a closed status, so this won't show. Subject and original topic isn't happening, so I opened #5452 to cover 286999.


Also available in: Atom PDF