[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qubes-devel
Subject:    [qubes-devel] Re: Workaround for network issues for Dell Latitude laptop
From:       charlotte.e.hammond () gmail ! com
Date:       2016-01-12 15:54:39
Message-ID: be5a120a-a0ee-4a93-9d06-5ceb4c8ac2c3 () googlegroups ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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!




On Sunday, September 9, 2012 at 2:22:42 PM UTC+1, Erik Edin wrote:
> 
> 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.
> 

-- 
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group. To unsubscribe from this group and stop receiving emails from \
it, send an email to qubes-devel+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-devel@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-devel/be5a120a-a0ee-4a93-9d06-5ceb4c8ac2c3%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


[Attachment #5 (text/html)]

<div dir="ltr">Thank you so much for writing this!<br><br>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!<br><br>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&#39;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.<br><br>I shut down the NetVM, ran:<br><br>$ echo 0000:06:00.0 &gt; \
/sys/bus/pci/drivers/pciback/permissive<br><br>Started the NetVM back up, and problem \
solved!<br><br><br><br><br>On Sunday, September 9, 2012 at 2:22:42 PM UTC+1, Erik \
Edin wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: \
0.8ex;border-left: 1px #ccc solid;padding-left: \
1ex;"><div>Hello!</div><div><br></div><div>I have a Dell Latitude 5520 laptop that \
I&#39;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&#39;d repeat them here in case anyone \
else has the same issue.</div> <div><br></div><div>In all three versions, RC2, RC3, \
and 1.0, I&#39;ve had to manually add my network cards PCI device id to the netvm for \
it to pick up the network card. I&#39;m not sure if I&#39;m expected to do this or if \
it should work automatically when Qubes is installed. I haven&#39;t tried Qubes with \
any other machines. I check the lspci output and then I add the device to the netvm, \
as below.</div> <div><br></div><div>$ lspci</div><div>... &lt;abbreviated&gt; \
...</div><div>0a:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5761 \
Gigabit Ethernet PCIe (rev 10)</div><div><br></div><div>$ qvm-pci -a netvm \
0a:00.0</div> <div><br></div><div>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.</div> \
<div><br></div><div>$ dmesg | grep tg3</div><div>[      5.055864] tg3.c:v3.121 \
(November 2, 2011)</div><div>[      5.056103] tg3 0000:00:00.0: enabling device (0000 \
-&gt; 0002)</div><div>[      5.056574] tg3 0000:00:00.0: Xen PCI mapped GSI18 to \
IRQ43</div> <div>[      5.057567] tg3 0000:00:00.0: setting latency timer to \
64</div><div>[      5.122742] tg3 0000:00:00.0: phy probe failed, err -19</div><div>[ \
5.128783] tg3 0000:00:00.0: Problem fetching invariants of chip, aborting</div> \
<div><br></div><div>By googling the issue I came up with three links that provided \
the clues for a workaround.</div><div><br></div><div><a \
href="http://lists.xen.org/archives/html/xen-devel/2007-12/msg00461.html" \
target="_blank" rel="nofollow" \
onmousedown="this.href=&#39;http://www.google.com/url?q\75http%3A%2F%2Flists.xen.org%2 \
Farchives%2Fhtml%2Fxen-devel%2F2007-12%2Fmsg00461.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHqPP7pr2jtD9t1emmmlrt_d2L3ZQ&#39;;return \
true;" onclick="this.href=&#39;http://www.google.com/url?q\75http%3A%2F%2Flists.xen.or \
g%2Farchives%2Fhtml%2Fxen-devel%2F2007-12%2Fmsg00461.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHqPP7pr2jtD9t1emmmlrt_d2L3ZQ&#39;;return \
true;">http://lists.xen.org/archives/<wbr>html/xen-devel/2007-12/<wbr>msg00461.html</a></div>
 <div><a href="https://groups.google.com/forum/?fromgroups=#!searchin/qubes-devel/xend-pci-permissive/qubes-devel/gwk4JMSJ6Io/ec2xGnRnQ9UJ" \
target="_blank" rel="nofollow" \
onmousedown="this.href=&#39;https://groups.google.com/forum/?fromgroups\75#!searchin/qubes-devel/xend-pci-permissive/qubes-devel/gwk4JMSJ6Io/ec2xGnRnQ9UJ&#39;;return \
true;" onclick="this.href=&#39;https://groups.google.com/forum/?fromgroups\75#!searchi \
n/qubes-devel/xend-pci-permissive/qubes-devel/gwk4JMSJ6Io/ec2xGnRnQ9UJ&#39;;return \
true;">https://groups.google.com/<wbr>forum/?fromgroups=#!searchin/<wbr>qubes-devel/xend-pci-<wbr>permissive/qubes-devel/<wbr>gwk4JMSJ6Io/ec2xGnRnQ9UJ</a></div>
 <div><a href="http://wiki.xen.org/wiki/Xen_PCI_Passthrough#Permissive_mode_for_xl" \
target="_blank" rel="nofollow" \
onmousedown="this.href=&#39;http://www.google.com/url?q\75http%3A%2F%2Fwiki.xen.org%2F \
wiki%2FXen_PCI_Passthrough%23Permissive_mode_for_xl\46sa\75D\46sntz\0751\46usg\75AFQjCNHOdwcbWRDhA-2gme-YmhtwsjvaLQ&#39;;return \
true;" onclick="this.href=&#39;http://www.google.com/url?q\75http%3A%2F%2Fwiki.xen.org \
%2Fwiki%2FXen_PCI_Passthrough%23Permissive_mode_for_xl\46sa\75D\46sntz\0751\46usg\75AFQjCNHOdwcbWRDhA-2gme-YmhtwsjvaLQ&#39;;return \
true;">http://wiki.xen.org/wiki/Xen_<wbr>PCI_Passthrough#Permissive_<wbr>mode_for_xl</a></div><div><br></div><div>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.  </div> <div><br></div><div>$ echo \
0000:0a:00.0 &gt; /sys/bus/pci/drivers/pciback/<wbr>permissive</div><div>$ cat \
/sys/bus/pci/drivers/pciback/<wbr>permissive</div><div>0000:0a:00.0</div><div><br></div><div>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</div> <div><br></div><div>   echo 0000:0a:00.0 &gt; \
/sys/bus/pci/drivers/pciback/<wbr>permissive # ADD THIS LINE HERE</div><div>   echo \
-n $&quot;Starting default NetVM:&quot;</div><div>   DISPLAY=:0 sg qubes \
&quot;qvm-start -q --no-guid $NETVM&quot; || exit</div> <div><br></div><div>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.</div> </blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups \
&quot;qubes-devel&quot; group.<br /> To unsubscribe from this group and stop \
receiving emails from it, send an email to <a \
href="mailto:qubes-devel+unsubscribe@googlegroups.com">qubes-devel+unsubscribe@googlegroups.com</a>.<br \
/> To post to this group, send email to <a \
href="mailto:qubes-devel@googlegroups.com">qubes-devel@googlegroups.com</a>.<br /> To \
view this discussion on the web visit <a \
href="https://groups.google.com/d/msgid/qubes-devel/be5a120a-a0ee-4a93-9d06-5ceb4c8ac2 \
c3%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/ \
msgid/qubes-devel/be5a120a-a0ee-4a93-9d06-5ceb4c8ac2c3%40googlegroups.com</a>.<br /> \
For more options, visit <a \
href="https://groups.google.com/d/optout">https://groups.google.com/d/optout</a>.<br \
/>

------=_Part_740_1183260051.1452614079197--



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic