Workaround for network issues for Dell Latitude laptop

[Erik Edin]

Hello!

I have a Dell Latitude 5520 laptop that I've used to run Qubes RC2, RC3 and 1.0. It has worked very well, except that the network has required minor tweaks. I thought I'd repeat them here in case anyone else has the same issue.

In all three versions, RC2, RC3, and 1.0, I've had to manually add my network cards PCI device id to the netvm for it to pick up the network card. I'm not sure if I'm expected to do this or if it should work automatically when Qubes is installed. I haven't tried Qubes with any other machines. I check the lspci output and then I add the device to the netvm, as below.

$ lspci

... <abbreviated> ...

0a:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5761 Gigabit Ethernet PCIe (rev 10)

$ qvm-pci -a netvm 0a:00.0

For Qubes RC2 and RC3 this was all I had to do to get the network running. In Qubes 1.0 however I had another issue with the network. The netvm would see the network card, but no Ethernet device was created. The device uses the tg3 driver, and dmesg in the netvm showed an error message.

$ dmesg | grep tg3

[    5.055864] tg3.c:v3.121 (November 2, 2011)

[    5.056103] tg3 0000:00:00.0: enabling device (0000 -> 0002)

[    5.056574] tg3 0000:00:00.0: Xen PCI mapped GSI18 to IRQ43

[    5.057567] tg3 0000:00:00.0: setting latency timer to 64

[    5.122742] tg3 0000:00:00.0: phy probe failed, err -19

[    5.128783] tg3 0000:00:00.0: Problem fetching invariants of chip, aborting

By googling the issue I came up with three links that provided the clues for a workaround.

http://lists.xen.org/archives/html/xen-devel/2007-12/msg00461.html

https://groups.google.com/forum/?fromgroups=#!searchin/qubes-devel/xend-pci-permissive/qubes-devel/gwk4JMSJ6Io/ec2xGnRnQ9UJ

http://wiki.xen.org/wiki/Xen_PCI_Passthrough#Permissive_mode_for_xl

The problem seems to be that the driver attempts to write to some configuration space at a read only location, or something. I know very little about these things. In short, I worked around the issue by writing the  numeric device id (with 0000: prepended) to a sys file, before netvm was started. 

$ echo 0000:0a:00.0 > /sys/bus/pci/drivers/pciback/permissive

$ cat /sys/bus/pci/drivers/pciback/permissive

0000:0a:00.0

With this workaround the tg3 driver succeeds in creating the Ethernet device, and the network works. To automate it on startup I added it to the file, in dom0, /etc/rc.d/init.d/qubes_netvm right before the line that started the netvm, so that it looks like this

  echo 0000:0a:00.0 > /sys/bus/pci/drivers/pciback/permissive # ADD THIS LINE HERE

  echo -n $"Starting default NetVM:"

  DISPLAY=:0 sg qubes "qvm-start -q --no-guid $NETVM" || exit

I have no idea what the security implications are, if any, of this workaround. Furthermore, instead of manually writing to that sys file it should be possible (according to the third link above) to do this with the xl command.

[charlotte...@gmail.com]

Thank you so much for writing this!

I have been trying to get networking working on Qubes RC3 all day and after going through countless forum posts I came across this post, which finally fixed it!

For reference, I have the same Ethernet controller (Broadcom Corporation NetXtreme BCM5761) and am using the tg3 driver. The network card was already being detected and added to the NetVM automatically, so that wasn't an issue, but as happened to the original poster, no Ethernet device was being created, and I was getting the same error messages in dmesg.

I shut down the NetVM, ran:

$ echo 0000:06:00.0 > /sys/bus/pci/drivers/pciback/permissive

Started the NetVM back up, and problem solved!

[pdi...@gmail.com]

Hi,

Just wanted to point out that this workaround was still necessary for Qubes R3.1 on a Dell Studio 1537
(C2D, 4gb RAM, ethernet controller Broadcom BCM5784M).

Since Fedora 23 is now using the systemd init style, the way I found to make this workaround work on every boot is to
edit the file located at  /etc/systemd/system/qubes_netvm.service and add

echo 0000:08:00.0 >/sys/bus/pci/drivers/pciback/permissive;

to the beginning of the ExecStart directive, before the commands that start the sys-net qube.