-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Thu, Jan 18, 2018 at 01:05:46AM +0000, mossy-nw wrote: > Marek Marczykowski-Górecki: > > On Wed, Jan 17, 2018 at 11:54:23PM +0000, mossy-nw wrote: > >> Dear Qubes community, > > > >> Has anyone using Qubes R4.0 been able to resolve any issues (e.g. with > >> wifi) by setting PCI permissive mode? (as described in:) > > > >> https://www.qubes-os.org/doc/assigning-devices/#pci-passthrough-issues > > > >> I successfully used this in Qubes R3.2 to get wifi working for dell xps > >> 13 9350 (bcm4350) but am having no luck using this method in R4.0_rc3. > > > >> This situation seems identical (driver errors that persist but > >> nonetheless wifi works using permissive mode) resolved by in a previous > >> (R3.2) qubes-users thread by miaoski -- > >> https://groups.google.com/forum/#!msg/qubes-users/m4GzpfOVBiQ/bf5XCEc-DQAJ > > > >> I'm hesitant to give up and go back to R3.2 on this machine, so I don't > >> have access to the R3.2 dom0 dmesg output for PCI spermissive mode, but > >> I recall before setting permissive mode dmesg suggested doing so. This > >> is not the case in R4.0_rc3 however. > > > >> Some dmesg output, if this gives anyone any ideas: > > > >> [dom0 ~] lspci | grep -i network > >> 3a:00.0 Network controller: Broadcom Limited BCM4350 802.11ac Wireless > >> Network Adapter (rev 08) > > > >> Before setting permissive mode: > >> [dom0 ~]$ sudo dmesg | grep > >> [ 7.222306] pci 0000:3a:00.0: [14e4:43a3] type 00 class 0x028000 > >> [ 7.222348] pci 0000:3a:00.0: reg 0x10: [mem 0xdc400000-0xdc407fff > >> 64bit] > >> [ 7.222379] pci 0000:3a:00.0: reg 0x18: [mem 0xdc000000-0xdc3fffff > >> 64bit] > >> [ 7.222618] pci 0000:3a:00.0: supports D1 D2 > >> [ 7.222619] pci 0000:3a:00.0: PME# supported from D0 D1 D2 D3hot D3cold > >> [ 7.222766] pci 0000:3a:00.0: System wakeup disabled by ACPI > >> [ 8.053279] pciback 0000:3a:00.0: seizing device > >> [ 68.211970] xen_pciback: vpci: 0000:3a:00.0: assign to virtual slot 0 > >> [ 68.212362] pciback 0000:3a:00.0: registering for 4 > >> [ 68.217475] pciback 0000:3a:00.0: enabling device (0000 -> 0002) > > > > Did you get anything after that message? Permissive mode helps mostly > > with cases reported in dom0 dmesg with message like this: > > > > pciback 0000:03:00.0: Driver tried to write to a read-only > > configuration space field at offset 0x110, size 4. This may be harmless, > > but if you have problems with your device: > > 1) see permissive attribute in sysfs > > 2) report problems to the xen-devel mailing list along with details of > > your device obtained from lspci. > > > > Interesting would be to see messages in sys-net about that device > > driver. > > You may also try updated kernel for VM, there is > > kernel-qubes-vm-4.14.13-1 package in current-testing repository: > > https://www.qubes-os.org/doc/software-update-dom0/#testing-repositories > > > > > > Thanks, Marek--I will try the updated kernel (though sys-net has the > appropriate driver binary file, and this was working under R3.2 for many > months i.e. with older kernels). Here are relevant messages from sys-net: > > [user@sys-net ~]$ lspci -k > 00:05.0 Network controller: Broadcom Limited BCM4350 802.11ac Wireless > Network Adapter (rev 08) > Subsystem: Dell Device 0023 > Kernel modules: brcmfmac > > [user@sys-net ~]$ sudo dmesg | grep brcmfmac > [ 1.703756] usbcore: registered new interface driver brcmfmac > [ 1.970170] brcmfmac: brcmf_chip_recognition: SB chip is not supported > [ 1.970185] brcmfmac: brcmf_pcie_probe: failed 14e4:43a3
Do you see other relevant kernel messages about that time (not necessary containing brcmfmac)? I assume this is after enabling permissive mode, right? Simon, is setting permissive mode in dom0 enough? Or maybe qemu in stubdomain perform some additional filtering? > [user@sys-net ~]$ modinfo brcmfmac | grep -E > '^(description|author|depends):' > description: Broadcom 802.11 wireless LAN fullmac driver. > author: Broadcom Corporation > depends: mmc_core,brcmutil,cfg80211 > > Trying advice from - > https://www.qubes-os.org/doc/wireless-troubleshooting - I tried > disabling/reenabling brcmfmac and some combinations of those others > (mmc_core,brcmutil,cfg80211; reversing remove/add order), but no luck. > > I also tried using as the sys-net template qubes-template-debian-9 with > broadcom-sta-dkms and others (which I recall got this working for > running non-Qubes debian on this laptop), to no avail. > > Thanks again, > > -m0ssy - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpf9Z0ACgkQ24/THMrX 1yz77gf+JxndavVwAAduAI/vwF6dHWtP9nrTCEESUh/4zna2lWZzWnhbvq8lufOe NmXQW67PqlytfKDr2s2dPVsslb9/HN1d3LCKvB3nyS5qOT986BQX8yAwNlUoObFk iFG1gmzVepvxWlPgKJ9AYpnyeXwyBxytymebwFrD21WdxnHo6ZGjzWw86Dfu6u5d KRXTcZms4l3COGqEjVlWU87fAqWJj3BmpeYt7zWXuD9mXf73GB8Pzk3gmSEtJZSG CnbBTskFqqtBMWJ63amTqoG9DjJUMsRK2dZMwbXvVxgWge1AasnPIBGT49FgLPxH ZiRdONBI33y9rBe6ky0UJBnAegG8ew== =41YY -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20180118011717.GS2653%40mail-itl. For more options, visit https://groups.google.com/d/optout.
