mouse+kb connected through sys-usb, yes. I have a ps/2 keyboard for 'emergencies', but since it's shit, I prefer not to use it. :)
Anyway, have rebuilt my own kernel with the option Marek mentioned enabled, and now it's working as intended.
It failed to load that module on my PC. (That is, modprobe gave a 'not found' error, and keyboard didn't work.)
That one works here
> 1) Hardware that used to work with 4.4 or 4.8 no longer works with 4.9.
Using it on a Lenovo X250 (i3-5010U), and other desktops.
Experiencing consistently the "no wifi after resume" which was working fine with 4.4.x
> 4) General feedback on the 4.9 kernel.
Oh, yeah... I have started experiencing quite annoying internet connectivity issues, very, very difficulty to troubleshot. Symptoms are:
- Web browsing fails with ERR_EMPTY_RESPONSE, pages load partially never reaching some of the content.
- SSH sessions can hang while exchanging keys, and if the recover can last for hours.
- Pinging sys-net from sys-firewall sometimes stops responding, but that does not happen consistently with the higher level issues (browsing from any VM can be impossible, and still ping works)
After 4 days of troubleshooting (switching browser versions, browser brands, changing templates, replacing openwrt+mwan3 home router with direct connections from ISP demarc to the machine, using different ISPs, doing all the same on a brand new R3.2 + "--enablerepo=qubes*testing", creating new sys-net+sys-firewall based on different templates, and so on...) y have just found that taking a failing setup and setting the kernels of all involved VMs to 4.4.67-12 makes the problem disappear.
It seems pretty repeatable, and would love to provide debugging info, although I do not know where to look for.
> 4.9.29 was just released today, so before I send in a Pull Request, let
> me know how 4.9.28 performs and if changes to the kernel config may need
> to be made.
Let me know if this makes sense and you can help me provide more meaningful debug info. Maybe this does not happen to anybody else. Drove me crazy the whole weekend, by the way :-)
Cheers,
///Pablo
Thanks! Found the specific thread (https://groups.google.com/d/msg/qubes-users/2iu5unw1bzY/zKYLCjduAAAJ) and already trying the fix.
> >> 4) General feedback on the 4.9 kernel.
> >
> > Oh, yeah... I have started experiencing quite annoying internet connectivity issues, very, very difficulty to troubleshot. Symptoms are:
> >
> > - Web browsing fails with ERR_EMPTY_RESPONSE, pages load partially never reaching some of the content.
> > ...((removed for brevity))
> > It seems pretty repeatable, and would love to provide debugging info, although I do not know where to look for.
>
> I, too, encountered this issue and was unable to find
> the cause. Had to revert to 4.4.67-12 kernel. :(
Oh, well. I am not crazy then. :)
Maybe being a generic bug will make it worth debugging.
Cheers,
///Pablo
I had these issues as well. Oddly, some domains would load perfectly in an AppVM, but then others that should be available (e.g. Google.com) would suddenly break, then come back 5 minutes later. Those same domains would load fine in curl on the netvm. This also hit non HTTP apps like email, messaging.
I was not able to revert my kernel as my wireless adapter fails under the old kernel. However, I was able to fix by installing the fedora 25 template and upgrading the stack of VMs involved (sys-net > sys-firewall > appvm) all to the fedora-25 template. This seems to have eliminated the constant network stalls.
I updated to 4.9.33 last night and it resolved low res display issue for my 7th gen intel 7700 MSI "Bazoka" mobo. It did NOT resolve returning from suspend however, which leaves USB keyboard & mouse dead. I need a hard reset to get the system back. Seems to work well in all other respects as far as I can tell.
I just used the qubes-dom9-update cli cmd. Still not sure how to change kernel config to tailor to my hardware. I have compiled any a Linux kernel but not sure the proper "qubes" way to do it. I'm just a newb after all ;-/
Probably not related, but in following one of the tutorial videos I added a package to the debian 8 template. When I created a VM from that template I had to run apt-get install in the created VM or the app wouldn't show up in the path. The apt-get said nothing to do however, 0 updates, 0 removals - already up to date etc.
It is a "kaby-lake" CPU
OK, sounds straightforward, I'll give it a shot.
As to the 4.11 offer, will that work for a kaby-lake system? Sound far older than the 4.4 kernel in the current 3.2 Qubes ISO. Unless you mistyped the version I suspect it would not work well.
Are there any specific options or patches in that 4.11 code that relate to suspend issues?
Doh! Sorry for the last reply, I see that 4.11 is > 4.4
I couldn't tell either, other than that they seem to have moved to a newer branch. Very messy bug thread, to be sure.
The option seems to be disabled in some distro-shipped kernels (such as f26, iirc), so not everyone runs into it either, which made it seem distro-specific.
commit 0ec03ce7d79dc9a5c47d26bab38c78075d42de9c
Author: Thomas Gleixner
Date: Tue May 23 23:23:32 2017 +0200
pinctrl/amd: Use regular interrupt instead of chained
commit ba714a9c1dea85e0bf2899d02dfeb9c70040427c upstream.
The AMD pinctrl driver uses a chained interrupt to demultiplex the GPIO
interrupts. Kevin Vandeventer reported, that his new AMD Ryzen locks up
hard on boot when the AMD pinctrl driver is initialized. The reason is an
interrupt storm. It's not clear whether that's caused by hardware or
firmware or both.
Using chained interrupts on X86 is a dangerous endavour. If a system is
misconfigured or the hardware buggy there is no safety net to catch an
interrupt storm.
Convert the driver to use a regular interrupt for the demultiplex
handler. This allows the interrupt storm detector to catch the malfunction
and lets the system boot up.
This should be backported to stable because it's likely that more users run
into this problem as the AMD Ryzen machines are spreading.
Reported-by: Kevin Vandeventer
Link: https://bugzilla.suse.com/show_bug.cgi?id=1034261
I'm experiencing the same problem as described here https://bugs.freedesktop.org/show_bug.cgi?id=94990 since kernel 4.9 (even with 4.10 and 4.11) with Qubes. Nouveau driver crash at boot time (see screenshot attached to the message). I tried almost all the proposed debug options and solutions but it's still not working. Typically, removing Nouveau from the kernel (nouveau.modeset=0 or rd.driver.blacklist=nouveau) allows to boot in runlevel 3 only.
In consequence, I setup a Fedora 25 on another disk and Nouveau on kernel 4.9 and 4.11 works fine. It seems to be something related to Qubes (Xen?).
I also tried to setup the 4.0 released by Marek but, as expected, it did reach graphical Anaconda installer.
I tried to build NVIDIA drivers with all the methods provided on the Qubes website or google groups but without success. This methods would not have been satisfactory either due to the use of proprietary softwares.
For information, my cpu is an AMD Ryzen 1800, my motherboard an Asrock X370 and I have a Nvidia GTX970 with 4Go.
Does anyone have an idea how can I debug or options I can pass to the kernel to successfully boot?
I'm very bothered because I going to be block for setup Qubes 4.0. Thank you in advance,
Epitre
1) Hardware that used to work with 4.4 or 4.8 no longer works with 4.9.
Cheers,
Torsten
Specifically, it'd be nice to know if:
2) Hardware that didn't work with 4.4 or 4.8 still doesn't work.
Also I just did my usual stuff like checking emails etc. and it worked fine on my Skylake-S CPU with Z170 chipset.
> 1) Hardware that used to work with 4.4 or 4.8 no longer works with 4.9.
The computer now greets me with a black screen (hung? I don't know) when coming out of sleep. Thankfully I don't usually put the machine to sleep, so I can live with it.
> 2) Hardware that didn't work with 4.4 or 4.8 still doesn't work.
I can now disable tap-to-click. Finally!
> 4) General feedback on the 4.9 kernel.
Other than the two things above, nothing has changed as far as I can tell.
> > 2) Hardware that didn't work with 4.4 or 4.8 still doesn't work.
>
> I can now disable tap-to-click. Finally!
Note that I quoted the wrong question here. It didn't work in the old version, but works with 4.9.
With 4.9 the touchpad of my Latitude E7470 (06DC) can be configured. This was not possible with any older kernel and i was forced to use "natural scrolling". Now i can configure all features via the KDE control center.