Request for feedback: 4.9 Kernel

[Reg Tiangha]

People may not have noticed, but there is now a 4.9 kernel in
current-testing (4.9.28 to be specific).

If the release schedule holds, then that should be migrated to stable
soon, however, before that happens, some feedback on that kernel would
be useful before it gets pushed to the majority of users.

Specifically, it'd be nice to know if:

1) Hardware that used to work with 4.4 or 4.8 no longer works with 4.9.

2) Hardware that didn't work with 4.4 or 4.8 still doesn't work.

3) If newer Intel platforms (i.e. Haswell or newer) works with this
kernel (I took out the Intel ME driver and the newest machine I have
access to is a Sandy Bridge machine; I have no issues, but I wonder if
Haswell or newer is tied more strongly to the Intel ME such that it
actually needs that driver in order t work properly). If there are Intel
hardware issues with this kernel, then I'll re-enable the driver in my
next Pull Request.

4) General feedback on the 4.9 kernel.

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.

[Foppe de Haan]

Done and did run into something somewhat important (usb keyboard/mouse pass-through no longer functioning properly). I have the same issue with my own kernel/vm-kernel builds, not yet figured out what's causing this.

[Marek Marczykowski-Górecki]

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

On Tue, May 23, 2017 at 03:41:37AM -0700, Foppe de Haan wrote:
> Done and did run into something somewhat important (usb keyboard/mouse pass-through no longer functioning properly). I have the same issue with my own kernel/vm-kernel builds, not yet figured out what's causing this.

Do you have 'uinput' kernel module loaded in dom0?

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJZJDhoAAoJENuP0xzK19csLngH/0aSj71l1Dy+XFj7uL3tdGab
SQ+Z2qy5G7ebYVxHzBJh3z9ly6k9IwAHgF7x3fzU1N53RHxnT07wI+cVsoLnCfGi
rcuWDqZnL2u15Zsv6nm/6wtd3ePhRcXQg/NrnpSJNqJNQW7SvSTS8pC3OndiwhJe
Yg11yS1+O5Kv1eiKYx5kR11VfSJlEjgAj7zGSwU7uYa9je9CjIPOfhMYUoIs241n
+atnVIQAfOSO/3AerND9ECUEyG2MVBFZ7f8bst6jvpBMWVi3cx7hKyR9dT9S3tKB
UOO2pjP23kVSrnQB5QvtxETwp6Cc6RFT2GlOb99JuzIUZ2VeW8bitVNhkKKkHiU=
=eMqW
-----END PGP SIGNATURE-----

[Foppe de Haan]

No. Am currently building a new kernel myself to see if that is the problem. Will post once I know more

[Reg Tiangha]

On 05/23/2017 04:41 AM, Foppe de Haan wrote:
> Done and did run into something somewhat important (usb keyboard/mouse pass-through no longer functioning properly). I have the same issue with my own kernel/vm-kernel builds, not yet figured out what's causing this.
>

Do you use a sys-usb and have your keyboard/mouse piped in through that,
or do you use the USB devices connected directly to dom0?

I have a sys-usb with a USB mouse on both my desktop and laptop, and it
works as expected. But I use a PS/2 keyboard on the desktop and whatever
the laptop uses for its keyboard and haven't tested much with a USB
keyboard. But I would assume that if the USB mouse works, the keyboard
will too. That said, I haven't tested at all with a USB set up that uses
dom0 directly, so maybe that's the difference?

[Foppe de Haan]

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.

[Reg Tiangha]

On 05/23/2017 09:59 AM, Foppe de Haan wrote:
> 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.

That's good to know. So the 4.9.28 that's in current-testing then, does
that work properly too, or does it fail to load the uinput module?
Looking at the kernel .config file in the tree, CONFIG_UINPUT=m so that
module should be present. And module loading is enabled too, so there
shouldn't be any obvious reason why uinput wouldn't load. But there
might be some corner cases that I hadn't considered in my testing, so it
would be nice to iron those out if they're present before the 4.9 branch
gets pushed out to the masses.

[Foppe de Haan]

It failed to load that module on my PC. (That is, modprobe gave a 'not found' error, and keyboard didn't work.)

[Reg Tiangha]

On 05/23/2017 10:37 AM, Foppe de Haan wrote:
> It failed to load that module on my PC. (That is, modprobe gave a 'not found' error, and keyboard didn't work.)

Would you be willing to compile the version found here and help test to
see if it also occurs with this version of the tree:

https://github.com/rtiangha/qubes-linux-kernel/tree/stable-4.9

It's updated to 4.9.29 but I could use a sanity check for this issue
before I start digging deeper.

[Foppe de Haan]

That one works here

[Reg Tiangha]

Thanks! I'll assume things are good then, at least when it comes to this.

[cyrinux]

Hi,

I have a T450s, and it works well, just this:

Seems to have a problem for me, i often miss wireless after suspend.
I need to stop firewall and wlan vm to reload iwlwifi driver.
No easy to unload iwlwifi, faster to stop and start.
I don't remember i have this problem before.

No other problems.

Thx

[Reg Tiangha]

On 05/24/2017 12:37 PM, cyrinux wrote:
> Hi,
>
> I have a T450s, and it works well, just this:
>
> Seems to have a problem for me, i often miss wireless after suspend.
> I need to stop firewall and wlan vm to reload iwlwifi driver.
> No easy to unload iwlwifi, faster to stop and start.
> I don't remember i have this problem before.
>
> No other problems.
>
> Thx

Thanks for the feedback. There should be a work-around in the next
kernel release, so keep an eye out for a 4.9.29 or higher to appear in
one of the Qubes repositories and try that one when it comes out. I
*think* the kernel workaround will work, but it could use some testing
when it's out.

In the meantime, you can also work around it locally by blacklisting the
iwlwifi power management module. In your sys-net, edit
/rw/config/suspend-module-blacklist and add:

iwlmvm iwlwifi

and then reboot the vm. According to other people, that should make the
wifi stuff work again too.

[Chris Laprise]

4.9 is working OK so far. I was using 4.8 prior to this.

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Cyril]

Problem disappears following https://www.qubes-os.org/doc/wireless-troubleshooting/ 

[cyrinux]

Thanks I have done this, i will try next 4.9.29 ;)

[Pablo Di Noto]

Hello,

> 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

[Patrik Hagara]

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

On Thu, Jun 1, 2017 at 2:55 PM, Pablo Di Noto <pdi...@gmail.com> wrote:
> Hello,
>
>> 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

This can be avoided by adding "iwldvm iwlwifi" line to
the following file in your WiFi NetVM:
/rw/config/suspend-module-blacklist

>> 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.

I, too, encountered this issue and was unable to find
the cause. Had to revert to 4.4.67-12 kernel. :(


Cheers,
Patrik

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZMBWaAAoJEFwecd8DH5rl770P/3pKQQaOvDil2NVOy9Id5UWt
7nQ5FmY2gflcHpVnKZP4i7aczEsekd675v+LtoNUVNGvuW+6D5Ytz8mrGtADUz+E
NOI4fFoL/aRw7Xi7aeWseYhsIMOoRbD4S60edMxsTzrlVMjvsg/lo9LrhRVt3wNm
FoQZbXJoshByy+vsAJ/lbqIck0O8yYCbnLh1EMmHtbbol9uIrkSHHgzL9R2LGef/
IqFqhUemqAx8TtGe4WuczU8JOHNSQaMcKEUngkxhfhcPrUwWiwzygwpMPPax6fPE
Omqo5WeMl2zcsHv2bcbObVSzTyBuiLaH+iB07IWf9qCTCCjzgq84lvbMhWB/p07+
tx+4kYfNrWujzcg8BvSVgRUv7wX++q1j1oBQKZKwyi8RZRwFZa4+CybxWsaa3iof
/BsSs+I8j7hJ7uUi+zEfKvBnvnhLAHQ+tDTXZSS4D6gAltCmTFpM78YR/uNLTCWt
eZ2Ep8OT/2RbUbLRAP7CZ8Gkhc9T1v/8SK7WkbT6qWNOkMjJvMMcnj+ShcIntt9A
QV4MIUNKcIKDbV16CFhcOldPvv6ry09EMZ3HhQJM83CxPtsVc26GUDd64pkJueC/
voIN391r7gv81d3MsrDfx2fE0lZUV+baMaWWrF6jf0EuoyDwXXoqipnoByTxVMUm
1YYLBsylBtHXKWSJeoPb
=aqNW
-----END PGP SIGNATURE-----

[Pablo Di Noto]

> > Experiencing consistently the "no wifi after resume" which was working fine with 4.4.x
>
> This can be avoided by adding "iwldvm iwlwifi" line to
> the following file in your WiFi NetVM:
> /rw/config/suspend-module-blacklist

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

[Reg Tiangha]

On 2017-06-01 6:55 AM, Pablo Di Noto wrote:
> Hello,
>
>> 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

There's a 4.9.29 in current-testing now, try that and see if that works
better. Otherwise, blacklist your module like Patrik Hagara suggested in
his follow up.

The reason why I *think* this is happening is that somewhere in between
4.4 and 4.9, Intel introduced some power management functionality for
wifi cards, but it's buggy. Users of other distros blacklist those
modules to work around it, and other distros like Fedora and Ubuntu have
now resorted to not enabling that option in their kernels. So I took it
out of this one. So try 4.9.29 if you haven't installed it already and
see if that works, although it'll probably not affect wifi cards from
other manufacturers that are having the same issue since it's an
Intel-only option.

>> 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.

Honestly, I have been encountering SSH issues with GitHub recently, but
I've been running 4.9/4.10 and 4.11 kernels on my two machines for
months now, and it's only started happening in the last couple of weeks.
Since it clears up if I wait for a bit (and it's intermittent), I'm not
confident it's a kernel issue unless a regression was introduced
upstream recently. Are your SSH issues just with GitHub, or are they
with other sites as well?

I haven't really noticed the web browsing issues either, so more info or
reports would be useful. Off the top of my head, I can't see how the
kernel would affect that, although I haven't looked into it in depth too
much yet. But my gut tells me that could be a different issue not
related to the kernel.

[Patrik Hagara]

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

On Thu, Jun 1, 2017 at 4:00 PM, Pablo Di Noto <pdi...@gmail.com> wrote:
>> >> 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.

Not sure how generic it really is since I'm using Lenovo
hardware too (T420s). Was most frequently happening with
sites like Facebook and GMail for me (I guess due to
open websocket connections; eg. GMail would report
connectivity issues after a minute or two and never
recover) and occassionally direct IMAP connections via
isync. Haven't used SSH with the new kernel but I guess
result would be the same. Mosh sessions (over UDP) worked
fine IIRC, so this issue might only be affecting TCP
connections.

Cheers,
Patrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZMCbYAAoJEFwecd8DH5rlwbEP/jfbLMiGHux0Lx3iNQtDfWOz
UwTxe1+HIUqfvc0bIj+sJlmDO7w4Be4L8SYlaPUJ4vOwxO7nqf2DvPclJn9Ob0+p
5+obl4Twom5i/gP47SafO+sj09ZqKmLbJLJRtDr0h1+mavMyyzmFfjHtl0pQBiuC
ElPWqGMCO9JQfydcu1zbLFdiVFzryvdufx9wRRTsUPxp8To0j0eFjCqHTCRY7Fy7
lm1/ME0B6APd7krCOtVAMvCyDaQrAwrn6ADAEu2JPu0u4/I6qrNT2993wx/4SXvc
0Y2vE62TodpowE3A6mSYh+IHb+hnkqhwcq8xY9N0RF3D4UltyJwbdSVY11S9Eyw3
3UH1Qv8osIor/kVI29xV+8f2xEBqDeA42i3IdI2Fz5JZPqLVg8h6xELGchjPqXW1
v9GbP5mlUUzW2lnE4+24w7OgNfKdV/nvi/fcWEd9yx9xdw9bl3HV0RkhxSjymrp6
Pta+DzMZ7OwAmPZhOoGXLclE6AEKsvgTN/MFZK+fyZWeqWlTMCm2ob3ZADhvgv/r
dJ1xBTfWdsXOe1wYPf3vx/eCg48U8L5/mp6MXzJs99GUXynK5FwrOnfLM6CnsXTS
TBobbGTf84qsOabQ3Q0LlVWsM9y/MM7jYTD3E1u02K2XPS5/HEu3fEwxMmquImWZ
4qB0xR3AHrMiXWAWmi2f
=GLNA
-----END PGP SIGNATURE-----

[Reg Tiangha]

On 06/01/2017 06:55 AM, Pablo Di Noto wrote:
> 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.

For anyone encountering SSL issues with the 4.9.29 kernel, could you add
slub_debug=- to your VM's kernelopts and restart the VM to see if that
helps and report back? The issue may have been identified, but it could
use more feedback.


View your current kernel options:

qvm-prefs -l <vmname> kernelopts

Set new kernel options:

qvm-prefs -s <vmname> kernelopts "slub_debug=- (and anything else that
was output above)"


Thanks.

[Zrubi]

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

On 05/20/2017 09:42 PM, Reg Tiangha wrote:
> People may not have noticed, but there is now a 4.9 kernel in
> current-testing (4.9.28 to be specific).
>
> If the release schedule holds, then that should be migrated to
> stable soon, however, before that happens, some feedback on that
> kernel would be useful before it gets pushed to the majority of
> users.
>
> Specifically, it'd be nice to know if:
>
> 1) Hardware that used to work with 4.4 or 4.8 no longer works with
> 4.9.

My Lenovo T450 working fine with kernel 4.4
Jut tried the latest 4.9.31 and has some interesting graphic related
issues:

Under KDE, the application icons in the taskbar are messed up. Means
broken application images are displayed. Broken means some kind of
transition between the last visited desktop icons and the current one.
The problem disappear (probably refreshing to a valid icon) by the
time. But messing up again if I switch virtual desktops. Which I do
very often.

A refresh is surely occures if I switch out to a CLI terminal and
back. But the result is just temporary, as if I switching virtual
desktops the icons are getting messed up again and again.

Switched back to kernel 4.4 solved these problems, so it is less
likely a hardware bug.


- --
Zrubi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZQnItAAoJEH7adOMCkunmQd4QAKMmqPxeCEw7MYJSUvwPQKl1
vbnIb/Mw4emE8wtsYOe9kHBZBrw6qMMxXYFZRPH3BBTQiZo+EgMLNBw2E+VsC490
mMovL9JmSHB1KcHqkmXjqhz7q5Qrpbh10CApGpRKl5seNFKH9MT5L4GAJ+r6CUx9
YMdQu++P85xZJ4sSa/3vmp2hU4rljgr9KbCSojTjnLw0B+o+WlMxA84OSh/gHkLu
qM+gIJHUkCCRVA7XPUQMldgYDSOpLErtfoQqvK9WExqjuLqzGc6c9swt96fsj8Ah
BuLR9ekcoYFq3mD+TbcPx6BxJL2awcibYC17yYWw5PUwoQKsWTboLGDorha7faAe
nNfoOf35OSI3qaJlcbAo6dJ6nKZgeGtVGt6Gckqn+IGw8+cmjEq1AwRW0Agwhgq3
YRBc9kRApLTSDhu1ze+Io6/CejZ/xK655WQ/mvZthVSkfxsvyCrDYHrlPiD7KT+v
NJaDZks5H/s+ukim7kEqnqInt0E6+c0tmsspj2l7+nH6tXQNzR8cauT+y+C+Skkj
OAse+ZyRA2EBBHDRzCuTAe1teLjnSEUhnsEfmfB9WRgCQj2D1+wKiMC4PWOKs/sn
5j6FGpGq/w3vNVgYhS1iDffw90obYZVH1HZIcxbIV8H157ftpN1ZXHgYJa6raLhf
5V9+wHj/2pbdSXLHsSAU
=xp8D
-----END PGP SIGNATURE-----

[Reg Tiangha]

On 06/15/2017 05:40 AM, Zrubi wrote:
> My Lenovo T450 working fine with kernel 4.4
> Jut tried the latest 4.9.31 and has some interesting graphic related
> issues:
>
> Under KDE, the application icons in the taskbar are messed up. Means
> broken application images are displayed. Broken means some kind of
> transition between the last visited desktop icons and the current one.
> The problem disappear (probably refreshing to a valid icon) by the
> time. But messing up again if I switch virtual desktops. Which I do
> very often.
>
> A refresh is surely occures if I switch out to a CLI terminal and
> back. But the result is just temporary, as if I switching virtual
> desktops the icons are getting messed up again and again.
>
> Switched back to kernel 4.4 solved these problems, so it is less
> likely a hardware bug.
>

Curious: For those apps that exhibit that behavior, are they running on
Debian 9 or Fedora 25 templates?

I'll be honest, I primarily run Debian templates and in anticipation of
the official release of Debian 9 this week, I've been slowly migrating
my Debian 8 templates to Debian 9, and I've started to notice that
behaviour as well. It does *not* happen under Debian 8 on kernel 4.9.
And I've been running 4.9 kernels in dom0 since December. I *have* been
running Debian 9 as my sys-net for months, though, and the
NetworkManager applet seems fine. I haven't tested extensively, but for
me, the IBus (for keyboard langauge switching) icon has a black overlay,
and when I play music through Rhythmbox on Debian 9, the pop up message
that displays when a new song is played is a little corrupted (but that
never happened on the same kernel on Debian 8).

Since it works fine in Debian 8 (I haven't tested much with any
Fedoras), I'm wondering if it's less a kernel issue and more of an issue
with newer X or how Qubes integrates with newer X (but I guess if it
works properly on 4.4, it may be a combination of the three; don't know
how to fix it though).

Intel Sandy Bridge is my system; haven't tested on other hardware.

[Reg Tiangha]

And to follow up, I just installed 4.9.32 and haven't noticed it as
much, but I've only put in 10 minutes of testing so I can't say for sure
if it was a regression in 4.9.31.

I can't play around with this until later today, but in the meantime,
what graphics hardware are you running, Zrubi? And which version of 4.4
are you running where things work fine? And finally if you can, if it's
an Intel card, can you try booting with this kernel option to see if it
makes a difference?

i915.preliminary_hw_support=0

[Zrubi]

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

On 06/15/2017 06:34 PM, Reg Tiangha wrote:

> Curious: For those apps that exhibit that behavior, are they
> running on Debian 9 or Fedora 25 templates?

Nope.
Fedora 24 mainly, and Debian 8
The later is only for sys-net, so all my taskbar icons coming from a
F24 based template.

> Since it works fine in Debian 8 (I haven't tested much with any
> Fedoras), I'm wondering if it's less a kernel issue and more of an
> issue with newer X or how Qubes integrates with newer X (but I
> guess if it works properly on 4.4, it may be a combination of the
> three; don't know how to fix it though).

Maybe it is a know issue, but:
online netvm change on a disposable VM is also broken on the latest
4.9 VM kernel. (Qubes Manager shows it is changed, but not working in
practice)

> I can't play around with this until later today, but in the
> meantime, what graphics hardware are you running, Zrubi? And which
> version of 4.4 are you running where things work fine? And finally
> if you can, if it's an Intel card, can you try booting with this
> kernel option to see if it makes a difference?
>
> i915.preliminary_hw_support=0

I believe this setting will not affect this chipset. But will try if I
have a chance. (This is my only Qubes Laptop atm and using it for
production)

HW details:

Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
Intel Corporation Broadwell-U Host Bridge -OPI [8086:1604] (rev 09)
Intel Corporation HD Graphics 5500 [8086:1616] (rev 09) (prog-if 00

SW versions:
Qubes 3.2
xen: 4.6.5
kernel: 4.4.62-12

- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZQuWeAAoJEH7adOMCkunmxSoP+wRG6dt5ovD+LktfW+jIlPgH
Ayg29hOBsoiflSU2yFzzx7borLNSscyL2JjqBuQguXigrjyni2w+EpUgm6K/cfhG
J2pqpTdeS+pihWDMjnw8TQM5gWNz1tr0IJA2pgxjAouFu0JFV1ZY1YWKsCJSGmYe
CLTB+gd4w6qY8ipP96QUBWtg/fVDq/+xC6v+MIg0hP/j7Nk/8OOBIE34k2E31vrl
VPFEPWQX7HfKr6FyOO/nyK0eaiEUIhyr24L/Dq3ARdrotlRQqwLZ3C514HJOZr2N
UnYD2AzwnWj2JiSrKX1G8K3dORy0AuRq8P5KbwS0PiG1Vn8iUxgFBczX2Z8pjrM7
pnd8R8NPzStqGyw6h+yDUQ+xDAFhA3Md+EgkxMoRlgu/F0P2A44EzBKr0geafOvG
FIsBoi1DlqMOfU0YlMgboESL/xilDCZlW8YLflm6x+osupD8jcg6cCVJV0jOpx51
f/ICnp6435+DRlcRkO54SP5AolsBpWjVPAVU8skJIFsAkXVMxky+NY96GnNA0fvJ
O51SlnjD4XjMDx9lJo0oI2xOmg2IcGqTzARsGeeBRbFOB/KJ1hGidHPXgKllrAyA
vtePMFBCvpffn265vDg89qQH+/3iAaSjQ+XtHmRs1okH2ttiO8rDD+E3ZfFUKHLs
FGtEToYHE1mwcNECubng
=uAxB
-----END PGP SIGNATURE-----

[Reg Tiangha]

On 06/15/2017 01:53 PM, Zrubi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 06/15/2017 06:34 PM, Reg Tiangha wrote:
>
>> Curious: For those apps that exhibit that behavior, are they
>> running on Debian 9 or Fedora 25 templates?
> Nope.
> Fedora 24 mainly, and Debian 8
> The later is only for sys-net, so all my taskbar icons coming from a
> F24 based template.
>

Thanks. I don't really use Fedora, but I'll set up a test VM once my
laptop is finished converting this Debian 8 template to 9. Can you list
some apps that this happens with so I can test across a variety of
templates? I'm still leaning towards an X issue, but maybe it's always
been there since Fedora 24, even under kernel 4.9. But I would assume if
that was the case, then more people would have spoken up by now.

>> Since it works fine in Debian 8 (I haven't tested much with any
>> Fedoras), I'm wondering if it's less a kernel issue and more of an
>> issue with newer X or how Qubes integrates with newer X (but I
>> guess if it works properly on 4.4, it may be a combination of the
>> three; don't know how to fix it though).
> Maybe it is a know issue, but:
> online netvm change on a disposable VM is also broken on the latest
> 4.9 VM kernel. (Qubes Manager shows it is changed, but not working in
> practice)
>

I've *never* ever had this work for me (although it might have worked
once in R3.0 or something old like that); I've always had to shut down
the Disp VM first, alter the dvm template, and then start up a new one
in order to change NetVMs.

>> I can't play around with this until later today, but in the
>> meantime, what graphics hardware are you running, Zrubi? And which
>> version of 4.4 are you running where things work fine? And finally
>> if you can, if it's an Intel card, can you try booting with this
>> kernel option to see if it makes a difference?
>>
>> i915.preliminary_hw_support=0
> I believe this setting will not affect this chipset. But will try if I
> have a chance. (This is my only Qubes Laptop atm and using it for
> production)
>
> HW details:
>
> Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
> Intel Corporation Broadwell-U Host Bridge -OPI [8086:1604] (rev 09)
> Intel Corporation HD Graphics 5500 [8086:1616] (rev 09) (prog-if 00
>
> SW versions:
> Qubes 3.2
> xen: 4.6.5
> kernel: 4.4.62-12
>

It might; if you could try it in both dom0 and vm (and maybe different
combinations if you have the time), that'd be useful to help rule things
out. It's toggled on by default to work around this:

https://www.phoronix.com/scan.php?page=news_item&px=intel-skl-prelim-support

but maybe it's no longer an issue with 4.9.

[Zrubi]

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

On 06/15/2017 10:02 PM, Reg Tiangha wrote:
> On 06/15/2017 01:53 PM, Zrubi wrote:

>> Maybe it is a know issue, but: online netvm change on a
>> disposable VM is also broken on the latest 4.9 VM kernel. (Qubes
>> Manager shows it is changed, but not working in practice)
>>
> I've *never* ever had this work for me (although it might have
> worked once in R3.0 or something old like that); I've always had to
> shut down the Disp VM first, alter the dvm template, and then start
> up a new one in order to change NetVMs.

well this is such a basic feature I would go crazy if that would not
work...

I'm using this feature from the beginning. And it was always working
in general. I remember for some broken kernel releases. But this
feature should work in general. As it is working with my setup, in
case of kernel VM 4.4 - but not in case of VM kernel 4.9


Do we already have any git issues about 4.9 and its currently known
problems?

- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZQvNTAAoJEH7adOMCkunm484P/inwOl/oiI4H/3wOyBc7bASj
tGws7IwJCIiIzfzFYk1yBncSI0bKkgIMR9r1PnYZ/UcW0P2Ixs6a6hYS553t8GpZ
Y9UJbNgfOUbicfozsO53YBaonyo6sapp/1juQ6NIHcTqlJzBkk5s/oKjYWfln0jB
9sn2pT+4fZSn2w0c10cTxSVYPGHmUh2aIeMhuqQPcckCiOmgl/Fqz07d3EA6JI3y
WZR3DOG8B0D1WXGnhcqSH3J5yqpPjaQ7QwWlcDNj9mFqqBAeRiQyRvgDxcyL6JXX
rjEmnnF+XE4ULa+eV2Cpz/p1Ws43ga0YOWCEi51Ie1JBQIABkN5ngdX2KjlOFjZn
NxLQ3ga6AK0q2hk8e9IjJUEus8cLjqSVTvXSpiqaQBO/eEsNWp2LqC63xnxpeiqE
2bDbrvMpqiHUZ2Qrqsx8M21tjngNLNI4og2LipJTMQD6X01qgJBw8+J8EQePdn+E
hsdRetkXjPY7afEtky+Qp5Z3lHQOEz1XEbvjVRRZpFEIFB1WcWXvY8QVqDkugPi2
zXQBgJcr5fqqXMkk6JjDdVCaRieS6UtbPT6An9Ih0jZN+5mCXbax0eLPvWrSa+mT
Zc8bsCoj6l7+EDyo9kGDOToMATmr82mXQLDJgXx/RwTelvH3PafNs98700NLpMag
thWMU8mtF7cS9MPIrTsV
=z98C
-----END PGP SIGNATURE-----

[Reg Tiangha]

On 06/15/2017 02:51 PM, Zrubi wrote:
> Do we already have any git issues about 4.9 and its currently known
> problems?
>

Nothing centralized that tracks all 4.9 issues/regressions that I'm
aware of, outside of this message thread. Some tickets have been opened
up as needed for specific issues (for example, full-range slub_debug
being enabled exposing a kernel bug that breaks SSL connections) though.

Sometimes comments or feedback are posted under the relevant kernel
update ticket whenever a new one is pushed out:

https://github.com/QubesOS/updates-status/issues

One thing to test would be a variety of different 4.9 releases; while
I'm still leaning towards an X or interaction with newer X issue, it
could also be a regression that was introduced upstream. And it would be
nice to know if this issue is happening on video cards that *aren't*
Intel. Really, the only kernel config option that changed between 4.4
and 4.9 for Intel cards is that preliminary hardware support option
being changed to enabled by default. If disabling that doesn't fix it,
there there are either bigger issues at play in the kernel *or* the
issue is somewhere else.

Also, a greater list of specific KDE apps to test would be helpful if
you could provide that.

[Reg Tiangha]

Finally, another idea: I believe it was Vik who said that on newer Intel
video cards, the i915 driver actually *wasn't* being used in 4.4 because
it did not support newer cards, and a generic video driver was being
automatically used instead. So maybe that i915 support for newer
hardware exists in 4.9 and is actually being used, but is buggy on
Haswell or newer which is why it only appears now.

That said, again, I've been running 4.9 on Sandy Bridge for months and
the issue didn't show up until I started using Debian 9 templates, so
I'm not completely convinced yet that it's 4.9 alone that is the issue.
It could be a combination of things, or Qubes video code interacting
with newer X alongside the i915 driver included in the 4.9 kernel.

Which is why it would really be useful if someone with an AMD or Nvidia
video card could try the same set up and see if this rendering issue
appears or not. If it doesn't, then it'd help rule out if this is a
general problem, or just a problem that appears with Intel video cards.

Another thing you could test is running that app suite on a Fedora 23
template (and even Debian 8 if those apps exist there) to see if the
problem appears. If it does not, then it's more evidence that newer
versions of X might be part of the issue.

[Vít Šesták]

Not using i915 driver on new CPU is my experience with i7-7500U (Intel HD graphics 620). But Haswell is not so new and I believe even Skylakes should be covered by i915.preliminary_hw_support=1.

Regards,
Vít Šesták 'v6ak'

[motech man]

I have a kabi-xxx??? cpu 7700 4.2GHz system with a 4.4 kernel. It uses the i915 driver with the Intel HD 630 mobo graphics. I'g going to recompile the kernel after I get more familiar with Qubes. I just got it installed for the first time only a couple of hours ago.

[Qubed One]

Reg Tiangha:

I have no problem with this myself. 3.2, kernels 4.4, 4.9, 4.10. The
difference I think is that my dvm templates net-vm is set to none, so
each dispvm I start which requires net access is set manually. Is it
common for you or others to change a given dispvms net-vm more than
once? Im just curious.

[Marek Marczykowski-Górecki]

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

On Thu, Jun 15, 2017 at 09:53:11PM +0200, Zrubi wrote:
> On 06/15/2017 06:34 PM, Reg Tiangha wrote:
>
> > Curious: For those apps that exhibit that behavior, are they
> > running on Debian 9 or Fedora 25 templates?
>
> Nope.
> Fedora 24 mainly, and Debian 8
> The later is only for sys-net, so all my taskbar icons coming from a
> F24 based template.

Make sure you have up to date qubes-gui-agent (qubes-gui-vm). There were
some issues recently affecting integrity of window content affecting
F24 (or F25 - depending on gui-agent version ;) ).

> > Since it works fine in Debian 8 (I haven't tested much with any
> > Fedoras), I'm wondering if it's less a kernel issue and more of an
> > issue with newer X or how Qubes integrates with newer X (but I
> > guess if it works properly on 4.4, it may be a combination of the
> > three; don't know how to fix it though).
>
> Maybe it is a know issue, but:
> online netvm change on a disposable VM is also broken on the latest
> 4.9 VM kernel. (Qubes Manager shows it is changed, but not working in
> practice)

Can you provide more details (and even better: create an issue on
github)?

I've just tried and cannot reproduce. I've tried two scenarios:

1. fedora-25-dvm with netvm=sys-firewall, then new DispVM switched to
another netvm (sys-whonix) - it works
2. fedora-25-dvm with netvm=none, then new DispVM switched to
sys-firewall - it works

After changing netvm for fedora-25-dvm you need to regenerate DispVM
savefile.
All of this using 4.9 kernel (some .28, some .31).

> > I can't play around with this until later today, but in the
> > meantime, what graphics hardware are you running, Zrubi? And which
> > version of 4.4 are you running where things work fine? And finally
> > if you can, if it's an Intel card, can you try booting with this
> > kernel option to see if it makes a difference?
> >
> > i915.preliminary_hw_support=0
>
> I believe this setting will not affect this chipset. But will try if I
> have a chance. (This is my only Qubes Laptop atm and using it for
> production)
>
> HW details:
>
> Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
> Intel Corporation Broadwell-U Host Bridge -OPI [8086:1604] (rev 09)
> Intel Corporation HD Graphics 5500 [8086:1616] (rev 09) (prog-if 00
>
> SW versions:
> Qubes 3.2
> xen: 4.6.5
> kernel: 4.4.62-12

I've seen some graphics issues (different than yours) on Broadwell-based
hardware, on 4.9 kernel. Adding iommu=no-igfx to Xen cmdline helped. See
here:
https://github.com/QubesOS/qubes-issues/issues/2836

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJZRurmAAoJENuP0xzK19csFNoH/1DYra+sHUObaQnIIxCWG+sv
7ET5hQmwEyT+JazddANq/JHDlwIbqrIc+f4FE/IA59kkruZiprmvWAh7mEd87zEz
9eh5cx5P0KOhSxbf1FQ5S4109/8kTUXm2rfGhJa0OQduvKk97zJ9AoiC8KdDMb4U
Xdh9EcYYr1kHgTKFWE17qi0i6urXYvl52pRUeLB6Qp0uSXL/zqqOFylSSzWdVq2c
hHQHmxrNGTd8y54M2ME3QzD28mzPdhdKSiy30mptFMr1f2cNad3mHl6/DI5PNxgA
QZW/I0Ljt6SzDAA/HJRjjK2+6fCafuuedCuqXYl/Jq5qRA5zquSr2OxZZOslUwY=
=giIk
-----END PGP SIGNATURE-----

[Zrubi]

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

On 06/18/2017 11:04 PM, Marek Marczykowski-Górecki wrote:

> Make sure you have up to date qubes-gui-agent (qubes-gui-vm). There
> were some issues recently affecting integrity of window content
> affecting F24 (or F25 - depending on gui-agent version ;) ).

Now I'm pretty sure I hit by bug describe in #1495

> After changing netvm for fedora-25-dvm you need to regenerate
> DispVM savefile.

FYI: that was the missing step. which is a general issue about
changing VM kernels, which is not 4.9 specific issue.


>>> i915.preliminary_hw_support=0

> I've seen some graphics issues (different than yours) on
> Broadwell-based hardware, on 4.9 kernel. Adding iommu=no-igfx to
> Xen cmdline helped. See here:
> https://github.com/QubesOS/qubes-issues/issues/2836

Thanks, will try both xen and the mentioned kernel parameters.



- --
Zrubi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZR9nzAAoJEH7adOMCkunmIV0P/1V2kV/ZHcrayjpg9majij97
+L3wSwx8+5f/LS7/zj0/83VhJBrHr0uRkT1dKKC7Cgy4u6UTeaW42gFno9kC02E4
rm7Aesa90rNdOJwMMpWZxSo1C75x+cYu/byfiD/hUfK1WjKRgnHC0dPDm4OvfHOk
JU5pWr0YuoAzenM5AOSc8R2H4pnhKCsx53J1913s4+cSK5v7yhv7WIC1UsTmn21l
9hU9ebzcnpF5ZQDIlzsJ7awvw8Qj0nJbIYQ4owOFJeSDiesSL9ebmt70b6CgcOfL
bkV5/4EssVZGiVTC8wIhA+uAmRc4cbF7uNTRUoneKQC2H4c15UvuVKp4vGti+zk7
jicn65PMhw+XIwYGbiaksF3KQJ/smoUO/hXwLAk1SLnhOcwR/+t8UeAewp6V/w29
lI5EC+5Jof5tp9fKm6Tg73gAStBBPpcFr/xYnFVefyEu4P3UpTm0OgiDzkjzslBw
xlkhjWdkkXJxKzLynJ7g3zJvg+2/T4Y9NT4W6NipMYNRFU+V4skp2umy/5+MZwou
Xc/uutvY/F2eJC0907ZjKK+boP7PsTPNnNH61RDDgRJS6BoVzlyFvmhS74NG3b9F
Jd2R2QOMndthDd7kwIg8+4+Pn8SpOC8C3nOAhvJITXjm29XywzRosbmtvIJgCWR3
ioikpXvKnvzu9zMwAil8
=dNg2
-----END PGP SIGNATURE-----

[Chris Laprise]

On 05/24/2017 03:51 PM, Chris Laprise wrote:
> 4.9 is working OK so far. I was using 4.8 prior to this.

Additional note: 4.9 seems to resolve a zombie process issue I was
having with 4.8 (domU), and the 4.9.33-18 security update is working
well so far.

[Ryan Tate]

On Thursday, June 1, 2017 at 10:00:09 AM UTC-4, Pablo Di Noto wrote:
> > >> 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.

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.

[motech man]

> 4) General feedback on the 4.9 kernel.
>

> 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.

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.

[motech man]

On Thursday, June 22, 2017 at 12:49:59 PM UTC-5, motech man wrote:
> > 4) General feedback on the 4.9 kernel.
> >
> > 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.
>
> 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 is a "kaby-lake" CPU

[Reg Tiangha]

On 2017-06-22 11:49 AM, motech man wrote:
> 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 ;-/

It's not hard. If you're familiar with compiling a normal kernel, all
you need to do is to grab Qubes kernel source here:

https://github.com/QubesOS/qubes-linux-kernel/tree/stable-4.9

Run 'make get-sources && make verify-sources' to download the vanilla
kernel source.

Take the config file from the Qubes kernel root directory and run 'make
menuconfig' on that (extract the kernel source with tar Jxf, copy that
config file to .config in the kernel source directory, run 'make
menuconfig') and customize it to your liking. When you're done, copy
that updated .config file to replace the old config file in the root
Qubes kernel directory.

Then run 'make rpms' to compile the whole thing. Outputted rpms will be
in the rpms/x86_64 directory.

Finally, copy them to dom0 and install them using rpm -ivh --force.

If you're feeling adventurous, I've got a 4.11 branch on my GitHub
account, if you want to see if that'll fix your suspend issues.

https://github.com/rtiangha/qubes-linux-kernel/tree/devel-4.11

I've been running it on my desktop since its release and it seems to
work fine.

[motech man]

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?

[motech man]

On Saturday, May 20, 2017 at 2:42:50 PM UTC-5, Reg Tiangha wrote:
> People may not have noticed, but there is now a 4.9 kernel in
> current-testing (4.9.28 to be specific).
>
> If the release schedule holds, then that should be migrated to stable
> soon, however, before that happens, some feedback on that kernel would
> be useful before it gets pushed to the majority of users.
>

> Specifically, it'd be nice to know if:

>
> 1) Hardware that used to work with 4.4 or 4.8 no longer works with 4.9.
>

> 2) Hardware that didn't work with 4.4 or 4.8 still doesn't work.
>
> 3) If newer Intel platforms (i.e. Haswell or newer) works with this
> kernel (I took out the Intel ME driver and the newest machine I have
> access to is a Sandy Bridge machine; I have no issues, but I wonder if
> Haswell or newer is tied more strongly to the Intel ME such that it
> actually needs that driver in order t work properly). If there are Intel
> hardware issues with this kernel, then I'll re-enable the driver in my
> next Pull Request.

>
> 4) General feedback on the 4.9 kernel.
>
> 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.

Doh! Sorry for the last reply, I see that 4.11 is > 4.4

[Reg Tiangha]

On 2017-06-22 12:22 PM, motech man wrote:
> 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.
>

Nope, didn't mistype anything. You can see the various
officially-supported-by-upstream kernels and what versions they're at by
visiting https://kernel.org. 4.11.6 is the latest in the 4.11 branch.

> Are there any specific options or patches in that 4.11 code that
relate to suspend issues?

No idea. But Kaby Lake is a relatively new platform and it usually takes
a few major kernel releases before hardware support in the kernel
catches up. So maybe it'll fix things for you, or maybe it won't (but
might later on). Video card support should be better, though, since the
Intel video driver is newer.

[Chris Laprise]

On 06/15/2017 04:51 PM, Zrubi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 06/15/2017 10:02 PM, Reg Tiangha wrote:
>> On 06/15/2017 01:53 PM, Zrubi wrote:
>
>>> Maybe it is a know issue, but: online netvm change on a
>>> disposable VM is also broken on the latest 4.9 VM kernel. (Qubes
>>> Manager shows it is changed, but not working in practice)
>>>
>> I've *never* ever had this work for me (although it might have
>> worked once in R3.0 or something old like that); I've always had to
>> shut down the Disp VM first, alter the dvm template, and then start
>> up a new one in order to change NetVMs.
>
> well this is such a basic feature I would go crazy if that would not
> work...
>
> I'm using this feature from the beginning. And it was always working
> in general. I remember for some broken kernel releases. But this
> feature should work in general. As it is working with my setup, in
> case of kernel VM 4.4 - but not in case of VM kernel 4.9

I noticed this, too. So reverting a dispVM's template back to 4.4 should
fix it?

[Zrubi]

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

On 06/29/2017 04:57 AM, Chris Laprise wrote:

> I noticed this, too. So reverting a dispVM's template back to 4.4
> should fix it?

Yes - but this is a general kernel changing issue, not related to any
specific kernel version.

Workaround:
After changing the kernel, you need to regenerate DispVM
savefile.

- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZVKz/AAoJEH7adOMCkunmqjgP/0mTXBtVPu+5aKUBp8PeK+Uu
qDopO/xn1r9gacDaddXQjoB8GYZwtM6W7Idr11AlvKaNVytbDJquZNY+EKmcPBdC
HYjRCpPHRA2UPODznOKl9TDn3i7AUJ9hxCwql7UvQ3aMntHERzI5/gRTOVjfr7+r
cavMAB/ujl1Iy3pYwH4PCoI2hZgWZC4MVUcGltVldWTNfAh5Mgv/SjiS/LOcztmY
ycfUssHM2J1NJEqE7FbAtXJutEGmyB00mam1oIEcXbhC6ASGitdK1Ahaxc/KXt4P
c5fzuh3ekxrEVNxM9NwXHd0GQGByg/RvySgnflSGfvx993UC486LrCTY4m0OEOiI
IpVniXbLn20l7A0ZQf+tF3fvB8ou+G2D7A2Tdv5wx1miV9hGZT0Uz3nUHnVg21U1
CEFICLRf37hEg1UTz5b2QUngJ5KMSSysWSA93ck+FiMYFbSe3V2cnyVQmrykidwV
dSedWu81amVHulX+nYv0lUIU9+RvvT7u+xm2Itm19kJixkqUaJQ6e8n54L+F69EE
fh0Y5Y3E/BynqGFUhIU/Ph/bgRdWLg3n8pxlBv7Oq4RgDS4a2Lh/Pu/L6MoU6lXJ
PfZDoXdOBo36rT+kymtHXrDtILCEEMz4JvAt0h1zqjXU+TZBHReT8Z9smdqtWkrO
2eg82sIDSmsPrczFl1iy
=ZBm4
-----END PGP SIGNATURE-----

[0spin...@gmail.com]

fyi: this kernel built as-is will cause kernel panics on (some, common) Ryzen motherboards. Issue is described here among other places: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1671360
This happens as soon as config_pinctrl_amd is set to 'm' in the build config. Un-setting it should evade the issue (as I've not yet seen a proper fix for it).

[Reg Tiangha]

On 06/29/2017 04:59 AM,

0spin...@gmail.com wrote:
> fyi: this kernel built as-is will cause kernel panics on (some, common) Ryzen motherboards. Issue is described here among other places: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1671360
> This happens as soon as config_pinctrl_amd is set to 'm' in the build config. Un-setting it should evade the issue (as I've not yet seen a proper fix for it).
>

I've now disabled it in my branch. But reading through the thread, they
say it's been fixed but I can't figure out what part in their changelog
addresses it. Did they merely disable the kernel option as well, or was
there an actual patch? Latest 4.9 version is now 4.9.35 and there
doesn't seem to be anything obvious in the .34 and .35 changlogs that I
can see that addresses it either. But then again, maybe I don't know
what I'm looking for.

[0spin...@gmail.com]

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.

[Ryan Tate]

Actually, this did not work. The issue has returned, is maddening, and makes Qubes close to unusable. I am trying to debug it, but really have no idea where to start. Anyway, no one should have false hope that F25 fixes any of this network stalling stuff, is the only reason I’m posting.

[0spin...@gmail.com]

fyi: Ryzen pinctrl/gpio issue should be fixed in 4.11.9; not yet backported to 4.9:

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

[Epitre]

Dear all,

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

[Ed Welch]

On 05/20/2017 03:42 PM, Reg Tiangha wrote:

1) Hardware that used to work with 4.4 or 4.8 no longer works with 4.9.

I have a 4th Generation Lenovo X1 Carbon (Skylake), and I've been running the 4.8.12-12 kernel from the unstable repo for many months now.  I just recently upgraded to 4.9.35-19 and post upgrade resume from sleep(suspend) is no longer reliable.  Resume was a huge issue when first setting up this laptop and I only had success with the 4.8.12-12 kernel (and also I had to completely disabled TPM in bios), but after that initial setup it's been rock solid.  Post upgrade however, every 2nd or 3rd sleep it will fail to resume and I'm forced to hold the power button down.

Regards,
Ed

[tsad...@gmx.net]

I have been trying to set up screen rotation on the Yoga 900. As far as I know, this requires the "iio/accel/hid-sensor-accel-3d" driver which is present in 4.4.14 but not in 4.9.35.

Cheers,
Torsten

[Epitre]

Hello, just a small ping to know if it is the good place to ask this question. Thank you.

[Marek Marczykowski-Górecki]

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

Generally this is the right place to ask. According to quick google, the
first message(s) ("[Firmware Bug]: cpu 15, try to use APIC510 (LVT
offset 1) for vector 0xf9, but the register is already in use for vector
0x0 on this cpu") should be unrelated to graphics issues. Those with
"nouveau" prefix looks related. Especially "bus: MMIO write of 80000130
FAULT at 10eb14 [ IBUS ]".
You may try luck asking on xen-...@lists.xen.org (please cc me, or
this list), providing transcription of those "nouveau" messages - maybe
there is some xen command line option to work around this issue.

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJZdcDKAAoJENuP0xzK19csme4H/jXXyXG8Y+BQ58bGatO6kbnr
yYdtpk8RXtud4N98BFyEpAKM0ldHAFD51ZkGiEXQ6CM6pA7hgMs+iH4MxuVKu9/3
89lHLYrWjKGnfj9+UON5TJqQxkyW0FSiApwxBr6AAUECi6xd/sBjBaUdRjPN4evs
mSrcxjHDELxv7tIKMASvTSXnRt9KS5XzPRa6BD35TARgbU0jE/hNqITXd1SNJ+R2
U3oAeu1Tg0uPZQotwEhQ/omLSNqTJFqiLhL+9R2aswcis0wuHJkP2kWniONO841r
gA1Ux+WeGGqf85ZkZ//L/S1/xOMERtiJd3q+p2PvUwJPfFqwCb6xnNjaI5MmyLk=
=TtPM
-----END PGP SIGNATURE-----

[Vincent Adultman]

Specifically, it'd be nice to know if:

2) Hardware that didn't work with 4.4 or 4.8 still doesn't work.

Having just tried 4.9.35-19, this has the same problem as every other 4.x kernel on my HP Elitebook 2540p (Intel HD graphics), that is as soon as the Qubes boot screen comes up, the graphics are corrupted. It was possible to enter the encryption password however the machine rebooted itself very soon after. Again this is consistent with every other 4.x kernel, either it reboots before the password prompt, or soon after. Only once has it ever got to the point of trying to start X.

Is there anything useful I can provide given that the machine doesn't have a docking port or a serial port?

[Kristian Elof Sørensen]

On Sat, 2017-05-20 at 13:42 -0600, Reg Tiangha wrote:
> People may not have noticed, but there is now a 4.9 kernel in
> current-testing (4.9.28 to be specific).

Running kernel 4.9.35-19 now

> 1) Hardware that used to work with 4.4 or 4.8 no longer works with
> 4.9.

None observed

> 2) Hardware that didn't work with 4.4 or 4.8 still doesn't work.

Same as with the 4.8.12-12 

That means quite a lot of hardware does not work or are not recognised
by the kernel.

This is on a very recent i5-7200U based ASUS B9440U laptop with its
accompaining USB-C dock.

Powermanagemet in general is sorely missing on laptop with Qubes.
(batterylife is 3-4 hours instead of approx. 10, the monitor backlight
never turns off despite the screensaver turning the screen black, the
keyboard backlight does not work and the fan runs nearly all the time.

> 4) General feedback on the 4.9 kernel.
>

Well I look forward to kernel 4.10 and 4.11 and hope to see them soon
on Qubes.

Othervise I will have to end my Qubes experiment on this laptop and
install something else, in order to get actual work done.

Kristian

[Fabian Wloch]

Hello,
I just wanted to give some positive feedback on the kernel.
I'm using a i7-6700K CPU and a AMD RX 480 GPU, and kernel-4.9.35-19 is the first kernel version which runs with my dedicated graphics card. This *should* have been the case starting with kernel 4.8, but until now it never did. Always had to switch default gpu to iGPU and cables from the graphics card to the mainboard connectors. Thanks for removing this mess with the new kernel :)

Also I just did my usual stuff like checking emails etc. and it worked fine on my Skylake-S CPU with Z170 chipset.

[lok...@gmail.com]

The machine I'm testing on is a Dell Latitude E7470.

> 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.

[lok...@gmail.com]

On Monday, 31 July 2017 11:11:58 UTC+8, lok...@gmail.com wrote:

> > 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.

[0spin...@gmail.com]

Since I doubt Marek or others will have time, I'd suggest building your own 4.11-based kernel per the instructions found in this thread. :)
https://groups.google.com/forum/#!topic/qubes-users/yBeUJPwKwHM

[the2nd]

Am Samstag, 20. Mai 2017 21:42:50 UTC+2 schrieb Reg Tiangha:
> People may not have noticed, but there is now a 4.9 kernel in
> current-testing (4.9.28 to be specific).
>

> If the release schedule holds, then that should be migrated to stable
> soon, however, before that happens, some feedback on that kernel would
> be useful before it gets pushed to the majority of users.
>

> Specifically, it'd be nice to know if:
>

> 1) Hardware that used to work with 4.4 or 4.8 no longer works with 4.9.
>

> 2) Hardware that didn't work with 4.4 or 4.8 still doesn't work.

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.