NVIDIA RTX 20XX

[Frédéric Pierret]

Hi,

Does anyone succeeded to have a working/non-crashing system with a
nvidia RTX 20XX, specifically 2080TI in my case? Currently having
instant reboot issues on Qubes 4.0 whereas on Windows it currently works
pretty well so I don't expect having GPU hardware issue.

Thank you in advance,

Frédéric

[Ralph Alexander Bariz]

Have the same problem with a rtx 2070. My temporary solution is to put a cheap gpu into my pc(nvidia geforce 710) into the second pci port and cut of the power of the 2070 when using qubes.
the problem is simple. The included nouveau driver does not support it. You could install the properitary one whats a security problem.
my attemp to solve it, when I've got time, will be to compile the newest nouveau driver in a fedora 25 qubes and install it to dom0.
For sure its necessary to ensure cube nit getting compromised in the process.

BR

[Frédéric Pierret]

Hi,

Thank you for your feedback. I just tested under R4.1 in development and
I succeeded to have a kernel log thanks to Marek and few hacks in dom0.

Here is the bug report: https://bugzilla.kernel.org/show_bug.cgi?id=206299

FYI, I tried few months ago to build NVIDIA module under Qubes but I hit
a problem of allocating buffers. It was the same problem than a one
reported on NVIDIA dev forum by another person using Xen as a desktop
machine (not Qubes).

Best,

Frédéric

[Frédéric Pierret]

Hi,

We debugged this problem with Marek and found a simple temporary
workaround:
https://mirror.notset.fr/qubes/repo/notset/yum/r4.0/unstable/dom0/fc25/rpm/

If you want to try and tell us it solves the problem on your side too,
you can find the built kernel with this path on my mirror:
https://mirror.notset.fr/qubes/repo/notset/yum/r4.0/unstable/dom0/fc25/rpm/
signed with my bot signature
https://mirror.notset.fr/qubes/repo/notset/RPM-GPG-KEY-notset

Best,

Frédéric

[Ralph Alexander Bariz]

well, trying to test it but I'm actually hanging at... how the hell do I add your repo without modifying my qubes-dom0.repo manually

any way? if not, your repo does not contain thiy metalink stuff

[Ralph Alexander Bariz]

sorry, if I'm acting stupid. coming from debian world, there I probably would figure it out myself. also do not really find anything to that

[Ralph Alexander Bariz]

for manual installation of the rpm packages I lack the information of which are the ones to install

[Frédéric Pierret]

Hi,
Without too much intrusion into your dom0, just download the rpms manually, check the signature if you want and copy the rpms into your dom0 then use dnf to install rpm.

Else, I will provide you repo file latter.

Best,
Frédéric

--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.

[Lipan Ovidiu]

I've been tried your method but without success. After reboot, the display freezes.

I must mention I didn't tried under legacy since my laptop doesn't support it.

I have an AW area 51M rtx 2080.

I also tried to install the property driver, the installation was successful, no errors, but again, after reboot, I got a black screen. I've been tried rpmfusion either, imported the GPG key and enable repos directly in dom0(i know that's not a safe method, but I've try it for testing proposes), again, the installation went smooth, no issues at all, but again, screen error.

that was for qubes 4.0.

I've been tried the same, for qubes 4.1, dom0 FC31, all methods with no luck.

I must mention it works perfectly under fedora 31(both proprietary driver downloaded from nvidia and rpm fusion method). This is so embarrassing, I'm starting to regret I've bought this laptop. I'm trying to sort it since August, 2019. I had a MSI with an RTX 1080 and I didn't had any issues(legacy enabled). If you find a solution or a workaround, please help. I'll be more then glad to try any method or any suggestions.

On qubes 4.1, it boots only if the nomodeset is enabled(rd.driver.blacklist-nouveau doesn't work in my case). Also, using nomodeset, I get full resolution(1920x1080). I was thinking is something about DPI settings or something. Any help will be greatly appreciated.

[Frédéric Pierret]

Hi,
I should have replied to this thread. Current kernel-latest 5.5.6 on Qubes repos is integrating the patch as it is in upstream. It's the same for latest kernel 5.4.23. So there is no more kernel freeze/oops.

On 2020-03-03 11:16, Lipan Ovidiu wrote:
> I've been tried your method but without success. After reboot, the display freezes.
> I must mention I didn't tried under legacy since my laptop doesn't support it.
> I have an AW area 51M rtx 2080.
> I also tried to install the property driver, the installation was successful, no errors, but again, after reboot, I got a black screen. I've been tried rpmfusion either, imported the GPG key and enable repos directly in dom0(i know that's not a safe method, but I've try it for testing proposes), again, the installation went smooth, no issues at all, but again, screen error.
> that was for qubes 4.0.
> I've been tried the same, for qubes 4.1, dom0 FC31, all methods with no luck.

Can you post kernel logs?

> I must mention it works perfectly under fedora 31(both proprietary driver downloaded from nvidia and rpm fusion method). This is so embarrassing, I'm starting to regret I've bought this laptop. I'm trying to sort it since August, 2019. I had a MSI with an RTX 1080 and I didn't had any issues(legacy enabled). If you find a solution or a workaround, please help. I'll be more then glad to try any method or any suggestions.

I was about to do the same in few days/weeks because I already tried this by few years ago but it was clearly a problem related to NVIDIA driver + Xen. From what I remember it was a problem of buffer allocation. I also saw the same issue on the NVIDIA dev forum.

> On qubes 4.1, it boots only if the nomodeset is enabled(rd.driver.blacklist-nouveau doesn't work in my case). Also, using nomodeset, I get full resolution(1920x1080). I was thinking is something about DPI settings or something. Any help will be greatly appreciated.

Try to provide some kernel logs if you can. BTW while debugging the initial problem with Marek, I wrote some tools https://github.com/fepitre/kernel-devel/tree/devel that I'm going to write a little doc. Globally it helps building kernel from source easily and copy/install it to dom0 directly thanks to enabling network into dom0 (yes it's for devel/test purpose).

Stay tuned :)

Frédéric

> --
> 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...@googlegroups.com <mailto:qubes-devel...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/99a260a9-78b1-4caa-99ca-6df5aa8dd0d5%40googlegroups.com <https://groups.google.com/d/msgid/qubes-devel/99a260a9-78b1-4caa-99ca-6df5aa8dd0d5%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Lipan Ovidiu]

Unfortunately I don't have the Qubes on PC anymore so I cannot provide the logs, but I will re install it later today and provide it. I will use qubes 4.1 fc 31 and use both methods(nvidia and rpmfusion). 

Apart of that, I believe indeed it's a kernel issue.

I had fedora 31, installed in my computer. The installer works with no modeset only and after the installation is done, I can install nvidia.run also rpmfusion.

However, I've just finished to install fedora 32, a few minutes ago. They are using Kernel 5.6.0-0.rc3.git0.1.fc32.x86_64 as default, and my graphic card was automatically and correctly loaded. No freezing, no parameters on kernel line and correct resolution given.

The latest kernel available on kernel.org is 5.6-rc4. Is there any way to get the latest(beta) kernel from kernel.org and install it somehow on qubes? as soon as this kernel will arrive in qubes repos, I truly believe this will sort the issues. Anyway, I will come back with the logs.

[Ovidiu]

I will install 4.1 now and compile and install the latest kernel directly from kernel.org. I will keep you posted.

[Ovidiu]

Right, so method 1, rpmfusion:

Freshly installed qubes 41(20200214):

dom0: sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing -y && sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing kernel-latest kernel-latest-devel gedit -y && sudo reboot

(gedit package to edit rpmfusion repos easily)

The system is up to date and has kernel-lates-5.5.7-1.qubes.x86_64 and kernel-latest-devel-5.5.7-1.qubes.x86_64.

In sys-firewall's browser I'm getting the rpm fusion keys for fedora 31 and the repos:

Keys:

https://rpmfusion.org/keys?action=AttachFile&do=get&target=RPM-GPG-KEY-rpmfusion-free-fedora-31

https://rpmfusion.org/keys?action=AttachFile&do=get&target=RPM-GPG-KEY-rpmfusion-nonfree-fedora-31

Repos:

https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-31.noarch.rpm

https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-31.noarch.rpm

in sys-firewall opened file manger and made an archive with all files(the keys and rpm's)(to simplify the transfer to dom0 process)

select all => compressed and named 1.zip

moved the zip to dom0:

dom0: qvm-run --pass-io sys-firewall "cat /home/user/Downloads/1.zip" > /home/test/Downloads/1.zip

unzipping the files:

dom0: unzip /Donwloads/1.zip

installing GPG keys:

dom0: cd Downloads

dom0: sudo rpmkeys --import RPM-GPG-KEY-rpmfusion-free-fedora-31 RPM-GPG-KEY-rpmfusion-nonfree-fedora-31

verifying the packages:

dom0: rpm -K *.rpm

all good:

rpmfusion-free-release-31.noarch.rpm: digests signatures OK
rpmfusion-nonfree-release-31.noarch.rpm: digests signatures OK

installing the repos:

dom0: sudo rpm -i *.rpm --nodeps

so far , so good. Now I'm going to /etc/yum.repo.d/ to replace "$releasever" with 31 and "$basearch" with x86_64

in all rpmfusion's repos(for some reasons, if I'm trying to install akmod-nvidia via dom0, the rpmfusion takes fedora 4.1 version).

dom0: sudo thunar

/etc/yum.repo.d/

and opening all rpmfusion repos using gedit, replacing and save.

now:

dom0: sudo qubes-dom0-update akmod-nvidia -y

with the output:

Dependencies resolved.
================================================================================
 Package                       Arch   Version           Repository         Size
================================================================================
Installing:
 akmod-nvidia                  x86_64 3:440.64-1.fc31   qubes-dom0-cached  27 k
Installing dependencies:
 akmods                        noarch 0.5.6-24.fc31     qubes-dom0-cached  23 k
 egl-wayland                   x86_64 1.1.4-1.fc31      qubes-dom0-cached  32 k
 fakeroot                      x86_64 1.24-2.fc31       qubes-dom0-cached  92 k
 fakeroot-libs                 x86_64 1.24-2.fc31       qubes-dom0-cached  37 k
 grubby                        x86_64 8.40-36.fc31      qubes-dom0-cached  38 k
 kmodtool                      noarch 1-37.fc31         qubes-dom0-cached  13 k
 libglvnd-opengl               x86_64 1:1.1.1-5.fc31    qubes-dom0-cached  49 k
 libvdpau                      x86_64 1.3-1.fc31        qubes-dom0-cached  17 k
 mesa-libGLES                  x86_64 19.2.8-1.fc31     qubes-dom0-cached  15 k
 mesa-vulkan-drivers           x86_64 19.2.8-1.fc31     qubes-dom0-cached 2.5 M
 nvidia-settings               x86_64 3:440.64-1.fc31   qubes-dom0-cached 1.8 M
 rpmdevtools                   noarch 8.10-9.fc31       qubes-dom0-cached  90 k
 vulkan-loader                 x86_64 1.2.131.1-1.fc31  qubes-dom0-cached 122 k
 xorg-x11-drv-nvidia           x86_64 3:440.64-1.fc31   qubes-dom0-cached 2.5 M
 xorg-x11-drv-nvidia-cuda-libs x86_64 3:440.64-1.fc31   qubes-dom0-cached  23 M
 xorg-x11-drv-nvidia-kmodsrc   x86_64 3:440.64-1.fc31   qubes-dom0-cached  13 M
 xorg-x11-drv-nvidia-libs      x86_64 3:440.64-1.fc31   qubes-dom0-cached  64 M

Transaction Summary
================================================================================
Install  18 Packages

Total size: 107 M
Installed size: 346 M
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                        1/1
  Installing       : kmodtool-1-37.fc31.noarch                             1/18
  Installing       : vulkan-loader-1.2.131.1-1.fc31.x86_64                 2/18
  Installing       : mesa-vulkan-drivers-19.2.8-1.fc31.x86_64              3/18
  Installing       : xorg-x11-drv-nvidia-kmodsrc-3:440.64-1.fc31.x86_64    4/18
  Installing       : xorg-x11-drv-nvidia-cuda-libs-3:440.64-1.fc31.x86_    5/18
  Installing       : nvidia-settings-3:440.64-1.fc31.x86_64                6/18
  Installing       : mesa-libGLES-19.2.8-1.fc31.x86_64                     7/18
  Installing       : libvdpau-1.3-1.fc31.x86_64                            8/18
  Installing       : libglvnd-opengl-1:1.1.1-5.fc31.x86_64                 9/18
  Installing       : grubby-8.40-36.fc31.x86_64                           10/18
  Running scriptlet: grubby-8.40-36.fc31.x86_64                           10/18
  Installing       : fakeroot-libs-1.24-2.fc31.x86_64                     11/18
  Installing       : fakeroot-1.24-2.fc31.x86_64                          12/18
  Running scriptlet: fakeroot-1.24-2.fc31.x86_64                          12/18
  Installing       : rpmdevtools-8.10-9.fc31.noarch                       13/18
  Running scriptlet: akmods-0.5.6-24.fc31.noarch                          14/18
  Installing       : akmods-0.5.6-24.fc31.noarch                          14/18
  Running scriptlet: akmods-0.5.6-24.fc31.noarch                          14/18
  Installing       : egl-wayland-1.1.4-1.fc31.x86_64                      15/18
  Installing       : xorg-x11-drv-nvidia-libs-3:440.64-1.fc31.x86_64      16/18
  Running scriptlet: xorg-x11-drv-nvidia-3:440.64-1.fc31.x86_64           17/18
  Installing       : xorg-x11-drv-nvidia-3:440.64-1.fc31.x86_64           17/18
  Running scriptlet: xorg-x11-drv-nvidia-3:440.64-1.fc31.x86_64           17/18
  Installing       : akmod-nvidia-3:440.64-1.fc31.x86_64                  18/18
  Running scriptlet: akmod-nvidia-3:440.64-1.fc31.x86_64                  18/18
  Verifying        : akmod-nvidia-3:440.64-1.fc31.x86_64                   1/18
  Verifying        : akmods-0.5.6-24.fc31.noarch                           2/18
  Verifying        : egl-wayland-1.1.4-1.fc31.x86_64                       3/18
  Verifying        : fakeroot-1.24-2.fc31.x86_64                           4/18
  Verifying        : fakeroot-libs-1.24-2.fc31.x86_64                      5/18
  Verifying        : grubby-8.40-36.fc31.x86_64                            6/18
  Verifying        : kmodtool-1-37.fc31.noarch                             7/18
  Verifying        : libglvnd-opengl-1:1.1.1-5.fc31.x86_64                 8/18
  Verifying        : libvdpau-1.3-1.fc31.x86_64                            9/18
  Verifying        : mesa-libGLES-19.2.8-1.fc31.x86_64                    10/18
  Verifying        : mesa-vulkan-drivers-19.2.8-1.fc31.x86_64             11/18
  Verifying        : nvidia-settings-3:440.64-1.fc31.x86_64               12/18
  Verifying        : rpmdevtools-8.10-9.fc31.noarch                       13/18
  Verifying        : vulkan-loader-1.2.131.1-1.fc31.x86_64                14/18
  Verifying        : xorg-x11-drv-nvidia-3:440.64-1.fc31.x86_64           15/18
  Verifying        : xorg-x11-drv-nvidia-cuda-libs-3:440.64-1.fc31.x86_   16/18
  Verifying        : xorg-x11-drv-nvidia-kmodsrc-3:440.64-1.fc31.x86_64   17/18
  Verifying        : xorg-x11-drv-nvidia-libs-3:440.64-1.fc31.x86_64      18/18

Installed:
  akmod-nvidia-3:440.64-1.fc31.x86_64                                          
  akmods-0.5.6-24.fc31.noarch                                                  
  egl-wayland-1.1.4-1.fc31.x86_64                                              
  fakeroot-1.24-2.fc31.x86_64                                                  
  fakeroot-libs-1.24-2.fc31.x86_64                                             
  grubby-8.40-36.fc31.x86_64                                                   
  kmodtool-1-37.fc31.noarch                                                    
  libglvnd-opengl-1:1.1.1-5.fc31.x86_64                                        
  libvdpau-1.3-1.fc31.x86_64                                                   
  mesa-libGLES-19.2.8-1.fc31.x86_64                                            
  mesa-vulkan-drivers-19.2.8-1.fc31.x86_64                                     
  nvidia-settings-3:440.64-1.fc31.x86_64                                       
  rpmdevtools-8.10-9.fc31.noarch                                               
  vulkan-loader-1.2.131.1-1.fc31.x86_64                                        
  xorg-x11-drv-nvidia-3:440.64-1.fc31.x86_64                                   
  xorg-x11-drv-nvidia-cuda-libs-3:440.64-1.fc31.x86_64                         
  xorg-x11-drv-nvidia-kmodsrc-3:440.64-1.fc31.x86_64                           
  xorg-x11-drv-nvidia-libs-3:440.64-1.fc31.x86_64                              

Complete!
[test@dom0 Downloads]$

so theoretically nvidia driver is installed.

The /etc/default/grub file looks like:

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="gfxterm"
GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-7c53187e-64b2-44bb-bc09-78839d93a7c2 rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap plymouth.ignore-serial-consoles  rhgb quiet rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1"
GRUB_DISABLE_RECOVERY="true"
GRUB_THEME="/boot/grub2/themes/qubes/theme.txt"
GRUB_CMDLINE_XEN_DEFAULT="console=none dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx ucode=scan smt=off"
GRUB_DISABLE_OS_PROBER="true"
GRUB_ENABLE_BLSCFG=true

generating the grub:

dom0: sudo grub2-mkconfig -o /boot/efi/EFI/qubes/grub.cfg with output:

Generating grub configuration file ...
Found theme: /boot/grub2/themes/qubes/theme.txt
Found linux image: /boot/vmlinuz-5.4.5-1.qubes.x86_64
Found initrd image: /boot/initramfs-5.4.5-1.qubes.x86_64.img
Found linux image: /boot/vmlinuz-5.4.5-1.qubes.x86_64
Found initrd image: /boot/initramfs-5.4.5-1.qubes.x86_64.img
done

[Ovidiu]

Stupid question - Where can I find the kernel logs?

[Frédéric Pierret]

On 2020-03-03 16:19, Ovidiu wrote:
> Stupid question - Where can I find the kernel logs?

Ideally, I would suggest you to first add to your kernel cmdline in grub: "... rhgb quiet loglevel=8 and systemd.log_level=debug". Then, in a dom0 terminal, you can do something like 'dmesg > kernel.log'. That should dump all errors (before freeze). If we don't see anything relevant, we would have need to identify what's happening during freeze.

> --
> 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...@googlegroups.com <mailto:qubes-devel...@googlegroups.com>.

> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/f3cdb164-0bc9-4d42-99bf-a608f797ddf2%40googlegroups.com <https://groups.google.com/d/msgid/qubes-devel/f3cdb164-0bc9-4d42-99bf-a608f797ddf2%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Ovidiu]

it is not actually freezing, a distorted image appear with small characters (like the display was broken) but when I press ctrl alt f12, something is moving on display. However, I will follow your steps and upload the kernel log as soon as I get back home. thank you for your help!!!

[Frédéric Pierret]

On 2020-03-03 17:30, Ovidiu wrote:
> it is not actually freezing, a distorted image appear with small characters (like the display was broken) but when I press ctrl alt f12, something is moving

I would say that if it's not freezing or kernel oops is not occurring that's certainly helping.

on display. However, I will follow your steps and upload the kernel log as soon as I get back home. thank you for your help!!!

Your welcome.

[Ovidiu]

Finally managed to get the log(bling because I didn't see anything on display)/

Here is the kernel log:

https://pastebin.com/YwQrMePB

Thank you

[Ovidiu]

This is how it looks

[Frédéric Pierret]

The relevant parts are probably the 'nouveau' logs. I would say that you should submit it to upstream through bugzilla too. Attach you log file to it. Maybe they would have an idea of what's going on.

On 2020-03-03 18:07, Ovidiu wrote:
> Finally managed to get the log(bling because I didn't see anything on display)/
>
> Here is the kernel log:

> *https://pastebin.com/YwQrMePB*
> *
> *
> Thank you

>
> --
> 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...@googlegroups.com <mailto:qubes-devel...@googlegroups.com>.

> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/bd0f432b-d918-4bc3-b761-08b6bbf081d8%40googlegroups.com <https://groups.google.com/d/msgid/qubes-devel/bd0f432b-d918-4bc3-b761-08b6bbf081d8%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Ovidiu]

hello again and I'm sorry for the delay. is the nouveau log the same with xorg log? or where can I find it?

thanks

[Frédéric Pierret]

On 2020-03-04 14:14, Ovidiu wrote:
> hello again and I'm sorry for the delay. is the nouveau log the same with xorg log? or where can I find it?

All X related logs are location in ~/.xsession-errors. Be careful with this file. There is sensitive informations like VM names etc because qubes-guid is writing things into.

> thanks
>

[Ovidiu]

Thank you. I have no sensitive information in this file since this system is for testing purpose only. Here is the file(files actually, I have xsession-errors and xsession-errors.old)

xsession-errors:

https://pastebin.com/VyQj9S5E

xsession-errors.old:

https://pastebin.com/s5Yh88Sa

Once again, thank you for your help

[Ovidiu]

Hi again,

I've made a new attempt today, using the negativo17 repo. the results are better then before. I didn't get the blur screen anymore, but it remains stuck before opening the lightdm.

kernel.log:

https://pastebin.com/sjpV8ZF7

xorg.log:

https://pastebin.com/RTu9LH2A

xsession-errors:

https://pastebin.com/V9atGwTm

xsessions-errors.old:

https://pastebin.com/Ud1uPFXR

Any ideas?

I will give a try with proprietary driver too, and I will paste the logs.

Thank You

[Ovidiu]

no luck using

1. dom0:   qubes-dom0-update gcc kernel-devel kmod kernel-headers; (qubes-dom0-update --enablerepo=qubes-dom0-unstable if using newer kernel)

2. appvm:  download NVIDIA-Linux-375.20-install.run (any appvm)

3. dom0:   qvm-run --pass-io <APPVM> 'cat /PATH/TO/NVIDIA.run' > NVIDIA.run; chmod +x NVIDIA.run;

4. dom0:   ./NVIDIA.run --ui=none --no-x-check --keep --extract-only

5: dom0:   cd NVIDIA-*/kernel/; make module IGNORE_XEN_PRESENCE=y CC="gcc -DNV_VMAP_4_PRESENT -DNV_SIGNAL_STRUCT_RLIM";
6: dom0:   sudo cp nvidia.ko /lib/modules/4.4.31-11.pvops.

qubes.x86_64/extra/.
7: dom0:   sudo depmod -a; modinfo nvidia (all working will show up fine)
8: dom0:   EDIT GRUB or EFI; add rd.driver.blacklist=nouveau (to kernel options)
9: dom0;   reboot and enjoy nvidia support. (First boot will likely take a while.)

At this point I believe the only solution is to compile and install the kernel 5.6-rc4 directly from kernel.org. I hope I don't get any errors while compiling, I doubt about that but I'll give a try.

[Frédéric Pierret]

You can use my branch I used to build it for you: https://github.com/fepitre/qubes-linux-kernel/tree/5.6-rc4
You can find the built kernel here too: https://mirror.notset.fr/qubes/repo/notset/yum/r4.1/unstable/dom0/fc31/rpm/

>
> --
> 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...@googlegroups.com <mailto:qubes-devel...@googlegroups.com>.

> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/2f5eddad-fe26-41e7-a8db-66f9ae81d983%40googlegroups.com <https://groups.google.com/d/msgid/qubes-devel/2f5eddad-fe26-41e7-a8db-66f9ae81d983%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Ovidiu]

Wow. Million thanks.

So basically I need to replace the baseurl:

https://yum.qubes-os.org/r$releasever/current/dom0/fc31

with

https://mirror.notset.fr/qubes/repo/notset/yum/r4.1/unstable/dom0/fc31

and

metalink:

https://yum.qubes-os.org/r$releasever/current/dom0/fc31/repodata/repomd.xml.metalink

with

https://mirror.notset.fr/qubes/repo/notset/yum/r4.1/unstable/dom0/fc31/repodata/repomd.xml.metalink

in qubes-dom0-repo

import your key

https://mirror.notset.fr/qubes/repo/notset/RPM-GPG-KEY-notset

using

dom0: sudo rpmkeys --import RPM-GPG-KEY-notset(after copying to dom0)

also copying your key to

/etc/pki/rpm-gpg and link it to

gpgkey = file:///etc/.../your-key

and sudo qubes-dom0-update

Is that correct?

Thank you

[Frédéric Pierret]

Yes or clone the current .repo file and adapt names.

WARNING: This 'unstable' repo is very unstable/dev packages content. Don't update your system with this repo :). Basically, this 'unstable' serves me for installing and testing devel branches for Qubes. So some packages are broken. But here, the kernel packages are fine especially the one your are seeking for.

On 2020-03-05 14:47, Ovidiu wrote:
> Wow. Million thanks.
> So basically I need to replace the baseurl:
> https://yum.qubes-os.org/r$releasever/current/dom0/fc31
> with
> https://mirror.notset.fr/qubes/repo/notset/yum/r4.1/unstable/dom0/fc31
> and
> metalink:
> https://yum.qubes-os.org/r$releasever/current/dom0/fc31/repodata/repomd.xml.metalink
> with
> https://mirror.notset.fr/qubes/repo/notset/yum/r4.1/unstable/dom0/fc31/repodata/repomd.xml.metalink
>
> in qubes-dom0-repo
>
> import your key
>

> https://mirror.notset.fr/qubes/repo/notset/RPM-GPG-KEY-notset <https://mirror.notset.fr/qubes/repo/notset/RPM-GPG-KEY-notset>

>
> using
> dom0: sudo rpmkeys --import RPM-GPG-KEY-notset(after copying to dom0)
> also copying your key to
> /etc/pki/rpm-gpg and link it to
> gpgkey = file:///etc/.../your-key
>
> and sudo qubes-dom0-update
> Is that correct?
>
> Thank you
>

> --
> 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...@googlegroups.com <mailto:qubes-devel...@googlegroups.com>.

> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/3de8f15e-c771-4eb5-b578-26ed095fd65e%40googlegroups.com <https://groups.google.com/d/msgid/qubes-devel/3de8f15e-c771-4eb5-b578-26ed095fd65e%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Frédéric Pierret]

On 2020-03-05 14:55, Frédéric Pierret wrote:
> Yes or clone the current .repo file and adapt names.
>
> WARNING: This 'unstable' repo is very unstable/dev packages content. Don't update your system with this repo :). Basically, this 'unstable' serves me for installing and testing devel branches for Qubes. So some packages are broken. But here, the kernel packages are fine especially the one your are seeking for.
>
> On 2020-03-05 14:47, Ovidiu wrote:
>> Wow. Million thanks.
>> So basically I need to replace the baseurl:
>> https://yum.qubes-os.org/r$releasever/current/dom0/fc31
>> with
>> https://mirror.notset.fr/qubes/repo/notset/yum/r4.1/unstable/dom0/fc31
>> and
>> metalink:
>> https://yum.qubes-os.org/r$releasever/current/dom0/fc31/repodata/repomd.xml.metalink
>> with

BTW, you can simply use baseurl:

baseurl = https://mirror.notset.fr/qubes/repo/notset/yum/r4.1/unstable/dom0/fc31

[Ovidiu]

something is wrong:

Qubes Dom0 Repository (unstable)                380  B/s | 162  B     00:00   
Error: Failed to download metadata for repo 'qubes-dom0-unstable': Cannot prepare internal mirrorlist: Status code: 404 for https://mirror.notset.fr/qubes/repo/notset/yum/r4.1/unstable/dom0/fc31/repodata/repomd.xml.metalink

I will try to make a new repo file and disable all others.

[Frédéric Pierret]

Look at my second response:

"""
BTW, you can simply use baseurl:

baseurl = https://mirror.notset.fr/qubes/repo/notset/yum/r4.1/unstable/dom0/fc31
"""

> --
> 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...@googlegroups.com <mailto:qubes-devel...@googlegroups.com>.

> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/9a6c0eca-072f-45d4-b67d-8764300f4839%40googlegroups.com <https://groups.google.com/d/msgid/qubes-devel/9a6c0eca-072f-45d4-b67d-8764300f4839%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Ovidiu]

I've made a new file: notset.repo

It looks like:

[notset-dom0-unstable]
name = Notset Repository
#baseurl = https://mirror.notset.fr/qubes/repo/notset/yum/r4.1/unstable/dom0/fc31
metalink = https://mirror.notset.fr/qubes/repo/notset/yum/r4.1/unstable/dom0/fc31/repodata/repomd.xml.metalink
enabled = 1
metadata_expire = 7d
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-notset

Your GPG key was imported and copied to /etc/pki/rpm-gpg/

all other repos was disabled, now:

dom0: sudo qubes-dom-update kernel-latest kernel-latest-devel

[Ovidiu]

same result:

Notset Repository                               286  B/s | 162  B     00:00   
Error: Failed to download metadata for repo 'notset-dom0-unstable': Cannot prepare internal mirrorlist: Status code: 404 for https://mirror.notset.fr/qubes/repo/notset/yum/r4.1/unstable/dom0/fc31/repodata/repomd.xml.metalink
Ignoring repositories: notset-dom0-unstable
No match for argument: kernel-latest
No match for argument: kernel-latest-devel
Error: Unable to find a match: kernel-latest kernel-latest-devel

[Ovidiu]

the respond.xml.metalink file doesn't exists

[Ovidiu]

repomd.xml.metalink I mean

[Frédéric Pierret]

Don't use metalink. Use baseurl. Metalink is not generated and will be not (no other mirror than mine).

> --
> 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...@googlegroups.com <mailto:qubes-devel...@googlegroups.com>.

> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/f52858c6-1207-4e50-8aab-deb0f0b17d85%40googlegroups.com <https://groups.google.com/d/msgid/qubes-devel/f52858c6-1207-4e50-8aab-deb0f0b17d85%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Ovidiu]

[notset-dom0-unstable]
name = Notset Repository
#baseurl = https://mirror.notset.fr/qubes/repo/notset/yum/r4.1/unstable/dom0/fc31

enabled = 1
metadata_expire = 7d
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-notset

result:

Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
Error: Cannot find a valid baseurl for repo: notset-dom0-unstable

Ignoring repositories: notset-dom0-unstable
No match for argument: kernel-latest
No match for argument: kernel-latest-devel
Error: Unable to find a match: kernel-latest kernel-latest-devel

I will download it manually and get the dependencies...

[Ovidiu]

Is the repo file correct?

[notset-dom0-unstable]
name = Notset Repository
#baseurl = https://mirror.notset.fr/qubes/repo/notset/yum/r4.1/unstable/dom0/fc31

enabled = 1
metadata_expire = 7d
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-notset

I don't know what are the deps for kernel and kernel-devel and since I'm using rpm to install files, I will not get it from the other repos. neither using dnf install package...

[Frédéric Pierret]

On 2020-03-05 16:13, Ovidiu wrote:
> Is the repo file correct?
>
> [notset-dom0-unstable]
> name = Notset Repository

> #baseurl = https://mirror.notset.fr/qubes/repo/notset/yum/r4.1/unstable/dom0/fc31 <https://mirror.notset.fr/qubes/repo/notset/yum/r4.1/unstable/dom0/fc31>

This should not be commented. Not "#baseurl = .." , simply "baseurl=https://mirror.notset.fr/qubes/repo/notset/yum/r4.1/unstable/dom0/fc31"

> enabled = 1
> metadata_expire = 7d
> gpgcheck = 1
> gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-notset
>
> I don't know what are the deps for kernel and kernel-devel and since I'm using rpm to install files, I will not get it from the other repos. neither using dnf install package...
>

> --
> 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...@googlegroups.com <mailto:qubes-devel...@googlegroups.com>.

> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/1977fe6a-d4f8-46e9-8232-7ca57c00ba72%40googlegroups.com <https://groups.google.com/d/msgid/qubes-devel/1977fe6a-d4f8-46e9-8232-7ca57c00ba72%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Ovidiu]

Thank you for your patience. It works but for some reasons it verifies a different version of kernel:

[test@dom0 Downloads]$ sudo qubes-dom0-update kernel-latest kernel-latest-devel --nogpgcheck


Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...


Fedora 31 - x86_64 - Updates                     22 kB/s |  23 kB     00:01   
Fedora 31 - x86_64                               34 kB/s |  25 kB     00:00   
Notset Repository                                12 kB/s | 2.9 kB     00:00   
Qubes Dom0 Repository (updates)                 9.3 kB/s | 2.7 kB     00:00   
Qubes Templates repository                      6.5 kB/s | 1.9 kB     00:00   
Dependencies resolved.
================================================================================
 Package             Arch   Version                  Repository            Size
================================================================================
Installing:
 kernel-latest       x86_64 1000:5.6.0-0.rc4.1.qubes notset-dom0-unstable  58 M
 kernel-latest-devel x86_64 1000:5.6.0-0.rc4.1.qubes notset-dom0-unstable  13 M
Installing dependencies:
 elfutils-libelf-devel
                     x86_64 0.178-7.fc31             updates               26 k
 zlib-devel          x86_64 1.2.11-20.fc31           updates               44 k

Transaction Summary
================================================================================
Install  4 Packages

Total size: 71 M
Installed size: 71 M
DNF will only download packages for the transaction.
Downloading Packages:
[SKIPPED] elfutils-libelf-devel-0.178-7.fc31.x86_64.rpm: Already downloaded   
[SKIPPED] zlib-devel-1.2.11-20.fc31.x86_64.rpm: Already downloaded            
[SKIPPED] kernel-latest-5.6.0-0.rc4.1.qubes.x86_64.rpm: Already downloaded    
[SKIPPED] kernel-latest-devel-5.6.0-0.rc4.1.qubes.x86_64.rpm: Already downloaded
Complete!
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
*** ERROR while receiving updates:
Error while verifing kernel-latest-5.4.16-1.qubes.x86_64.rpm signature: /var/lib/qubes/updates/rpm/kernel-latest-5.4.16-1.qubes.x86_64.rpm: DIGESTS SIGNATURES NOT OK

--> if you want to use packages that were downloaded correctly, use dnf directly now
[test@dom0 Downloads]$


[Frédéric Pierret]

On 2020-03-05 16:37, Ovidiu wrote:
> Thank you for your patience. It works but for some reasons it verifies a different version of kernel:

Not sure it's related. I suggest to:

1) restart your update VM for cleaning stuff (here I'm seeing sys-firewall)

2) ensure clean too by appending '--clean' to update:
sudo qubes-dom0-update --clean kernel-latest

> --
> 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...@googlegroups.com <mailto:qubes-devel...@googlegroups.com>.

> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/9d827616-8da3-45c9-9093-6149741ae427%40googlegroups.com <https://groups.google.com/d/msgid/qubes-devel/9d827616-8da3-45c9-9093-6149741ae427%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Ovidiu]

you made my day!!!!! It works perfectly now. no public issues. I forget to disable the old dom0 repo. A small issue:))) I have no wireless connection now but I will sort it somehow. once again, thank you

[Frédéric Pierret]

On 2020-03-05 16:53, Ovidiu wrote:
> you made my day!!!!! It works perfectly now. no public issues. I forget to disable the old dom0 repo. A small issue:))) I have no wireless connection now but

If running in VM the RC kernel, what you can test is to run only 5.6-rc4 in dom0 and use any other kernel for VM by setting it in VM properties.

I will sort it somehow. once again, thank you
>

Your welcome.

[Ovidiu]

I'm using an older kernel(5.4.5-1) in sys-net but for some reasons, it doesn't see any wifi.
at sudo dmesg I've got the following errors:

I can't paste it because I have no internet connection

[Ovidiu]

the kernel is the issue again. I'm using a intel wireless ac 9260. I will try to recompile the kernel by myself using the old configuration from earliest kernel...I will also try to get the fedora 32 updates over dom0 fc31(basically to update the fc31 to 32 under dom0) and their compiled kernel.

[Ovidiu]

I really cannot find any solution for wifi, neither for ethernet. I was trying to install a completely new operating system (ubuntu). I guess I need to wait until the next kernel 5.6 is available in final the version and it is uploaded in qubes repo. I've been tried with 4.0 as well, no luck at all.
thank you for your time and patience

[Me]

I believe I found the issue. The patch:

0014-xen-pciback-add-attribute-to-allow-MSI-enable-flag-w.patch

is not found on your branch.

According to Marek. this patch is essential for pass-trough.

I will try to add it and re compile the kernel now.

Thank you

[Frédéric Pierret]

The patch is in upstream for 5.6. The issue would be only under R4.0 with older Xen.

That's the reason of his question. I let Marek correct me if I'm wrong.

Best,

--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Mar 13, 2020 at 08:40:58PM +0100, Frédéric Pierret wrote:
> The patch is in upstream for 5.6. The issue would be only under R4.0 with older Xen.
>
> That's the reason of his question. I let Marek correct me if I'm wrong.

That's correct, 5.6 indeed contains slight different version of the
patch. It's different enough to not work with R4.0 (because of a
different sysfs attribute name), but should be fine for R4.1. On the
other hand, I can't exclude possibility it is different enough to be
broken...
Frédéric, can you build a kernel with that upstream commit reverted and
original patch applied?

- --
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/THMrX1ywFAl5r5aMACgkQ24/THMrX
1ywZJwf+MOIeblU9/kNkl0gAJENcliPOlyQAKjVH+G9eymEqk497zoJaL65nKJ7x
DVY/whHePBJiJGrzUrbDXAF7aovlEtoJ5GjrnEkOCz67JfYTIxK8ucjsE5esLglu
Curafm6TQ5fhtdfWFBf85nNVFG9IGLhNNP98rMH3N4ShWeTbKI6RlAgST4VniBhq
EwH9bq0TWgnFeLgNa6uZZ5YUU0Ji6vvmF+lOKIbx2Ni2EBVYO5C+3TW5nuYaKNtS
5y4rst+YyXXjCl/tEE0rJxlS9mh6zX9EfXTYOL4Mj4NRjOSVUKWcVgSTAzFb7rIL
6dkJ/+YQhx1MpNlzcXx4kMyOiM7uHw==
=Gmo3
-----END PGP SIGNATURE-----

[Frédéric Pierret]

On 2020-03-13 20:57, Marek Marczykowski-Górecki wrote:

> Frédéric, can you build a kernel with that upstream commit reverted and
> original patch applied?

The kernel is built and available on my mirror as a second release or 5.6-rc4 on my mirror. The branch is also updated on github to see the revert then applying the previous 0014 patch.

[Me]

Thank you. I will give a try now

[Me]

It works now. Both, the graphic card and wi-fi.

I have no words to thank you enough.

[Frédéric Pierret]

On 2020-03-13 23:55, Me wrote:
> It works now. Both, the graphic card and wi-fi.
> I have no words to thank you enough.
>

You are welcome. Don't hesitate to give us feedback if anything is working wrong.

Best

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Mar 13, 2020 at 03:55:30PM -0700, Me wrote:
> It works now. Both, the graphic card and wi-fi.
> I have no words to thank you enough.

Ok, so the patch for 5.6 seems broken. Can you post some more info about
the system? Specifically:

in dom0: sudo lspci -v
(you can limit to the wifi card only)
in sys-net: sudo lspci -v
in dom0: /var/log/xen/console/guest-sys-net-dm.log

- --
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/THMrX1ywFAl5sEVoACgkQ24/THMrX
1yyduAf+N4d4H5fXFGDOJ0MRBYpE3mVoeB465i5uDqGdp68N/BjVcpiMjdJvDOMa
8v3X5oW3FSH8zHss6LHDWoQ+U8OeyWy8rwU0q60ftS3fn77r05fL40ztwfD3VTnA
O41fdy/w/EQ7ixEzzv7exJfrkqMbYhCVWjwChMfNgAehBbtw0kJrk+8wkYIMhRYI
77ZyTdB/oz+XGEFmxmswQVMLNvu5zI6p7+FiU+5aWZw2hwku6xYKjIGo+wBGJTX8
KatIOfUzjAh8wnCnwJfFTn6p88s84i1hGB6syy/N/tsFjQgq6hsDu1a0wOvTbE16
J/Cxn9t8+DZ4HCluoD9Z/XFkfJtvJg==
=WTgX
-----END PGP SIGNATURE-----

[Me]

Yes. The latest one works fine(the new one compiled tonight).

Sure:

in dom0: sudo lspci -v

45:00.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29)
    Subsystem: Bigfoot Networks, Inc. Device 1550
    Flags: bus master, fast devsel, latency 0, IRQ 19
    Memory at c9c00000 (64-bit, non-prefetchable) [size=16K]
    Capabilities: [c8] Power Management version 3
    Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
    Capabilities: [40] Express Endpoint, MSI 00
    Capabilities: [80] MSI-X: Enable- Count=16 Masked-
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [14c] Latency Tolerance Reporting
    Capabilities: [154] L1 PM Substates
    Kernel driver in use: pciback
    Kernel modules: iwlwifi

sys-net: sudo lspci -v

00:06.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29)
    Subsystem: Bigfoot Networks, Inc. Device 1550
    Physical Slot: 6
    Flags: bus master, fast devsel, latency 0, IRQ 71
    Memory at f2010000 (64-bit, non-prefetchable) [size=16K]
    Capabilities: [c8] Power Management version 3
    Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
    Capabilities: [40] Express Endpoint, MSI 00
    Kernel driver in use: iwlwifi
    Kernel modules: iwlwifi

 and guest-sys-net-dm.log is attached

 so again, with 0014-xen-pciback-add-attribute-to-allow-MSI-enable-flag-w.patch works fine.

Thanks

 

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Mar 13, 2020 at 05:58:26PM -0700, Me wrote:
> Yes. The latest one works fine(the new one compiled tonight).
> Sure:
> in dom0: sudo lspci -v
>
> 45:00.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29)
> Subsystem: Bigfoot Networks, Inc. Device 1550
> Flags: bus master, fast devsel, latency 0, IRQ 19
> Memory at c9c00000 (64-bit, non-prefetchable) [size=16K]
> Capabilities: [c8] Power Management version 3
> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Capabilities: [40] Express Endpoint, MSI 00
> Capabilities: [80] MSI-X: Enable- Count=16 Masked-
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [14c] Latency Tolerance Reporting
> Capabilities: [154] L1 PM Substates
> Kernel driver in use: pciback
> Kernel modules: iwlwifi

Hmm, this looks like something that should work with the previous (5.6)
version too. Could you also show `sudo lspci -vv` - just the "Control:"
line?

If you have the previous (broken) kernel still installed, could you also
check the same info (both lspci -v and "Control:" from -vv) from there?

> sys-net: sudo lspci -v
>
> 00:06.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29)
> Subsystem: Bigfoot Networks, Inc. Device 1550
> Physical Slot: 6
> Flags: bus master, fast devsel, latency 0, IRQ 71
> Memory at f2010000 (64-bit, non-prefetchable) [size=16K]
> Capabilities: [c8] Power Management version 3
> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Capabilities: [40] Express Endpoint, MSI 00
> Kernel driver in use: iwlwifi
> Kernel modules: iwlwifi
>
> and guest-sys-net-dm.log is attached
> so again, with
> 0014-xen-pciback-add-attribute-to-allow-MSI-enable-flag-w.patch works fine.

- --
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/THMrX1ywFAl5sMRMACgkQ24/THMrX
1yxntwgAhzuVat/sbSlxZy4NUwmQtHZtIHl8NS+TOTqTHwItE76E5Rwj2GLV68KU
JTvvy1j0DHnZf6Bosfh7aDOPDOubNsGMwDpvu6Ri1I4A4KCVEFHUTRoXI3DqQlMl
mGL0XnGUVudtgAfImELTGeEBGxrYXsuuYpnq4uGHLMIYkXAB+OaDrsPsxR0h+YNM
PW8giNIPM00jRYr16zGDLwABjd+jBG1a8twIW7/H4ajN1q/KwI5Uc4qKTg32z55A
N3sOQuTw/MoMMJwbru13UHFuS2S1jU0xd0f7wI/EI2Xeh4KmpQ3vWhFGH1xEiYNA
98hg6YdnbA+1yDq5BVmCF0AZK/vc0Q==
=7FKO
-----END PGP SIGNATURE-----

[Me]

Kernel 5.6 latest(2)

dom0: sudo lspci -vv

45:00.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29)
    Subsystem: Bigfoot Networks, Inc. Device 1550

    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
sys-net: sudo lspci -vv

00:06.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29)
    Subsystem: Bigfoot Networks, Inc. Device 1550
    Physical Slot: 6

    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+

[Frédéric Pierret]

A little note for ease following things, you can refer your kernel version with respect to
5.6-rc4.1 or 5.6-rc4.2, which are respectively, first release(first non working build) and second release (second working build).

Thank you :)

> --
> 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...@googlegroups.com <mailto:qubes-devel...@googlegroups.com>.

> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/3144b502-c4d2-4d59-9d78-61ec5c84ed0d%40googlegroups.com <https://groups.google.com/d/msgid/qubes-devel/3144b502-c4d2-4d59-9d78-61ec5c84ed0d%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Mar 14, 2020 at 02:15:15AM -0700, Me wrote:
> Kernel 5.6 latest(2)
>
> dom0: sudo lspci -vv
> 45:00.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29)
> Subsystem: Bigfoot Networks, Inc. Device 1550
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-

This looks like the issue:

DisINTx-

while on the sys-net side...

> sys-net: sudo lspci -vv
> 00:06.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29)
> Subsystem: Bigfoot Networks, Inc. Device 1550
> Physical Slot: 6
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx+

... it is DisINTx+

And indeed on of the differences between those two patches is the 5.6
one verify if DisINTx+ is set.
I'll try to find where it got desynchronized.

- --
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/THMrX1ywFAl5sqUkACgkQ24/THMrX
1yyh/wf+Md4fu46xwSo0Sfr4IQ+FQBLXfGYd8/KNSClH1loq5cnPnLN8r7hT4hNS
DqnLvgz4i70S6o4QNMVm/7goC2+vcUVG1UzEbKVPQHnEbZfaNNG/8iXnrkZaDXQl
guvgYDVn0ro3v5QP3Vt8AS1SeoKbQhOWTweCoXuains/WTPoUbvLr+uICacKdAuU
B9EE3Nbv6OaD9UMylD6HwtQY5M1+pxTYTBoOahsUL8vgPg5pMj45Ra/2gCzofVUk
3jpVAz+WYNdEtaNBsWxfrsbYv1DF78OqLUTj6pieLjwvrmXAA11FUTueB95LFajO
r4Ab/Yg6ZEc3VWUt7gN4xa4TpJptjQ==
=p0wx
-----END PGP SIGNATURE-----

[Me]

kernel 5.6-rc4.1:

dom0: sudo lspci -v

45:00.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29)
    Subsystem: Bigfoot Networks, Inc. Device 1550

    Flags: bus master, fast devsel, latency 0, IRQ 19
    Memory at c9c00000 (64-bit, non-prefetchable) [size=16K]
    Capabilities: [c8] Power Management version 3

    Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+

    Capabilities: [40] Express Endpoint, MSI 00
    Capabilities: [80] MSI-X: Enable- Count=16 Masked-
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [14c] Latency Tolerance Reporting
    Capabilities: [154] L1 PM Substates
    Kernel driver in use: pciback
    Kernel modules: iwlwifi

dom0: sudo lspci -vV

45:00.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29)
    Subsystem: Bigfoot Networks, Inc. Device 1550

    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+

sys-net: sudo lspci -v

00:06.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29)
    Subsystem: Bigfoot Networks, Inc. Device 1550
    Physical Slot: 6

    Flags: bus master, fast devsel, latency 0, IRQ 71
    Memory at f2010000 (64-bit, non-prefetchable) [size=16K]
    Capabilities: [c8] Power Management version 3

    Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+

    Capabilities: [40] Express Endpoint, MSI 00
    Kernel driver in use: iwlwifi
    Kernel modules: iwlwifi

sys-net: sudo lspci -vv
00:06.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29)
    Subsystem: Bigfoot Networks, Inc. Device 1550
    Physical Slot: 6
    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+

and the guest-sys-net-dm.log attached.

Thank you

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Mar 14, 2020 at 10:52:09AM +0100, Marek Marczykowski-Górecki wrote:
> On Sat, Mar 14, 2020 at 02:15:15AM -0700, Me wrote:
> > Kernel 5.6 latest(2)
> >
> > dom0: sudo lspci -vv
> > 45:00.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29)
> > Subsystem: Bigfoot Networks, Inc. Device 1550
> > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> > Stepping- SERR- FastB2B- DisINTx-
>
>
> This looks like the issue:
>
> DisINTx-
>
> while on the sys-net side...
>
> > sys-net: sudo lspci -vv
> > 00:06.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29)
> > Subsystem: Bigfoot Networks, Inc. Device 1550
> > Physical Slot: 6
> > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> > Stepping- SERR- FastB2B- DisINTx+
>
> ... it is DisINTx+
>
> And indeed on of the differences between those two patches is the 5.6
> one verify if DisINTx+ is set.
> I'll try to find where it got desynchronized.

Found it and sent the patch upstream[1]. Lets hope it will made it into
the final 5.6.

[1] https://lore.kernel.org/lkml/20200319040648....@invisiblethingslab.com/

- --
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/THMrX1ywFAl5y8QYACgkQ24/THMrX
1yxSegf/VxvivgREaPlZFGE5hlg1xU25CVztbbd5AFvoHEHWNHtRBhRO2oq9291I
8bRTJEbm3JYnkkfB+g+jS0SRFm2kAecEL/xKaScOO0ADedVOFVXgyVqzXSF9dxaq
7m/vEdnkGrS9Wy/B9CPnb4rV7d5XwfMAD3LCTE3wa01ZRSyqOAnDFHII6y3x9oSK
hshnLq2WcNznWUZWUlgYaZkCmNIUh4+4JD61ZN3brATHMzeCuPQlzfQNNKQsB6fx
ftd2vC3eivNeaTKDAjMnTOWvV2wNQeXEeEFaZhyp8KOANsu8/k3aN3RukEsA0ySW
F58KtXJeRBCUnrwNIFKUKrm3ETR3Pw==
=4LbM
-----END PGP SIGNATURE-----