Re: Request for feedback: 4.9 Kernel
386 views
Skip to first unread message
Foppe de Haan
May 23, 2017, 7:13:48 AM5/23/17
to qubes-users, qubes...@googlegroups.com, r...@reginaldtiangha.com
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.
cyrinux
May 24, 2017, 2:37:05 PM5/24/17
to qubes-users, qubes...@googlegroups.com, r...@reginaldtiangha.com
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
Le samedi 20 mai 2017 21:42:50 UTC+2, Reg Tiangha a écrit :
> 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.
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
Le samedi 20 mai 2017 21:42:50 UTC+2, Reg Tiangha a écrit :
> 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.
Chris Laprise
May 24, 2017, 3:51:36 PM5/24/17
to Reg Tiangha, qubes...@googlegroups.com, qubes...@googlegroups.com
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
--
Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
Cyril
May 24, 2017, 3:57:04 PM5/24/17
to qubes-devel, qubes...@googlegroups.com, r...@reginaldtiangha.com
Problem disappears following https://www.qubes-os.org/doc/wireless-troubleshooting/
cyrinux
May 24, 2017, 4:46:18 PM5/24/17
to qubes-users, qubes...@googlegroups.com, r...@reginaldtiangha.com
Thanks I have done this, i will try next 4.9.29 ;)
Le mercredi 24 mai 2017 20:43:11 UTC+2, Reg Tiangha a écrit :
> 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.
Le mercredi 24 mai 2017 20:43:11 UTC+2, Reg Tiangha a écrit :
> 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
> > 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
>
> 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.
Foppe de Haan
May 24, 2017, 9:39:50 PM5/24/17
to qubes-users, qubes...@googlegroups.com, r...@reginaldtiangha.com
On Tuesday, May 23, 2017 at 5:08:50 PM UTC+2, Reg Tiangha wrote:
> 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?
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.
> 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,
> > 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.
> >
>
> 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?
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.
Foppe de Haan
May 24, 2017, 9:39:50 PM5/24/17
to qubes-users, qubes...@googlegroups.com, r...@reginaldtiangha.com
On Tuesday, May 23, 2017 at 6:11:07 PM UTC+2, Reg Tiangha wrote:
> 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.
It failed to load that module on my PC. (That is, modprobe gave a 'not found' error, and keyboard didn't work.)
> 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
> > 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 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.
It failed to load that module on my PC. (That is, modprobe gave a 'not found' error, and keyboard didn't work.)
Foppe de Haan
May 24, 2017, 9:39:50 PM5/24/17
to qubes-users, qubes...@googlegroups.com, r...@reginaldtiangha.com
On Tuesday, May 23, 2017 at 6:40:47 PM UTC+2, Reg Tiangha wrote:
> 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.
That one works here
> 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
> > It failed to load that module on my PC. (That is, modprobe gave a 'not found' error, and keyboard didn't work.)
>
> 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.
That one works here
Pablo Di Noto
Jun 1, 2017, 8:55:23 AM6/1/17
to qubes-users, qubes...@googlegroups.com, r...@reginaldtiangha.com
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
> 1) Hardware that used to work with 4.4 or 4.8 no longer works with 4.9.
Experiencing consistently the "no wifi after resume" which was working fine with 4.4.x
> 4) General feedback on the 4.9 kernel.
- 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.
Cheers,
///Pablo
Patrik Hagara
Jun 1, 2017, 9:25:34 AM6/1/17
to Pablo Di Noto, qubes-users, qubes-devel, r...@reginaldtiangha.com
-----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-----
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
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.
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
Jun 1, 2017, 10:00:12 AM6/1/17
to qubes-users, pdi...@gmail.com, qubes...@googlegroups.com, r...@reginaldtiangha.com
> > 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.
> > 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. :)
>
> I, too, encountered this issue and was unable to find
> the cause. Had to revert to 4.4.67-12 kernel. :(
Maybe being a generic bug will make it worth debugging.
Cheers,
///Pablo
Patrik Hagara
Jun 1, 2017, 10:38:42 AM6/1/17
to Pablo Di Noto, qubes-users, qubes-devel, r...@reginaldtiangha.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
>> >> 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.
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
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-----
Zrubi
Jun 15, 2017, 7:40:46 AM6/15/17
to Reg Tiangha, qubes...@googlegroups.com, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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:
>
> 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
> 4.9.
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
Version: GnuPG v2
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-----
Zrubi
Jun 15, 2017, 3:53:18 PM6/15/17
to Reg Tiangha, qubes...@googlegroups.com, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 06/15/2017 06:34 PM, Reg Tiangha wrote:
Hash: SHA256
> 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
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-----
Zrubi
Jun 15, 2017, 4:51:44 PM6/15/17
to Reg Tiangha, qubes...@googlegroups.com, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 06/15/2017 10:02 PM, Reg Tiangha wrote:
Hash: SHA256
> 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
>> 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)
>>
> 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
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-----
Zrubi
Jun 16, 2017, 4:15:32 AM6/16/17
to Reg Tiangha, Marek Marczykowski-Górecki, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 06/15/2017 11:02 PM, Reg Tiangha wrote:
Hash: SHA256
> Also, a greater list of specific KDE apps to test would be helpful
> if you could provide that.
I guess it is nor KDE specific.
My apps that showed broken icons are:
KeePassX, Thunderbird, Firefox, Gnome-Terminal
(at least I'm used those when I noticed this bug)
However I also think that the bug is not a single one, or at least
this can be caused by the icon colorization thing which is Qubes OS
specific.
Because as I think about this issue I just realized that I have
another issue I'm already used to ignore:
The application icons are randomly exchanged between the opened apps
from the same VM. Means I have the terminal icon for Firefox. Firefox
icon for Thunderbird. Rarely see the right icon for an app, because
the icons are randomly changing around.
This issue is not new, but was not as annoying to track it down, or
even try to talk about this. Till now :)
@Marek do you have any idea what can be causing this issue?
and can be related to the completely broken image rendering happened
with kernel 4.9?
- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
ZnKHiaG+PsM1PbNaUevg0x/uWtkGuSywpEB3i46sls0eSMcGZH0tYMliLfV2EtDU
4i3R6Tfz9PLX5QEBNOwo15XNrX6CFGVvcv5eAiX1ukE2Qvcg9yK9Q1ZLHZH5iYKd
Z/Ntpznw6Rvpz3VQjpXTVQ+0mReQBCbYM2C1vkFlYvCAXWT5EH6DiiHWRpmhKyM4
ShjVcYUzPxS039H8XXQ/zqwehVCizNLQrsjRHTQ3fqgIlM8kMJxBgz2dzPEUnv0k
tXS3+efkjyd+KTWEqqnAFk8FkmJ3u6tdfrZVL1VIR6CApmCKfaJOJQNTPxUQPNvR
3WSo+2+lDBo5ETuBECb7YDhMxO8mneumrlb64wOQ1Angzbwqhel+2WxNeGd8z0C6
kEZM5u6P9SczSbSL8OlVa+D1lblYaaRJJIZgwwPcEPAcEEF4V2SpkXG2IaA2XOgT
3j7A4QqNjyewb2RJhzGko1HrcmKfTV6Nj56lhsdnr+rHE1a2+Cm4QuYvKh3DfVnq
C+cqsq8jurnboxk1QzwjdHQlhP6JiYdoIeDZw/dgw0hMmBALPB/n5v5mrhItKLdD
mcN+duc87kcCTaHlwQ4s2JYGyinQb1i/Twagh7yhw14xwnv0nyU6hgb/nj+Pe5OC
A1C0KO89DWldlNPaGiu5
=9u/r
-----END PGP SIGNATURE-----
Reg Tiangha
Jun 16, 2017, 5:06:23 AM6/16/17
to qubes...@googlegroups.com
On 06/16/2017 02:15 AM, Zrubi wrote:
>
> I guess it is nor KDE specific.
> My apps that showed broken icons are:
> KeePassX, Thunderbird, Firefox, Gnome-Terminal
> (at least I'm used those when I noticed this bug)
>
>
>
Wait, I just read through your original message; I was assuming you were
>
> I guess it is nor KDE specific.
> My apps that showed broken icons are:
> KeePassX, Thunderbird, Firefox, Gnome-Terminal
> (at least I'm used those when I noticed this bug)
>
>
>
running XFCE, but I guess you're running KDE5? If so, disregard what
I've been talking about thus far. My issue looks like it's a different
one (sometimes garbled icons in XFCE's notification tray on the upper
right-hand side of the screen, that's only really noticeable with Debian
9 templates).
I have *not* tested kernels on the KDE desktop at all, mainly because I
installed R3.2 from scratch on both my machines rather than upgrade from
R3.1 (I think I had some issues with doing that way) so I don't even
think KDE is installed in the first place.
Although honestly, I do think there are some graphical issues in general
that may or may not be related in conjunction with running an updated
kernel that an updated dom0 X stack might fix. Or it could just be a KDE
thing that'll never get fixed since FC23 is EOL. I wonder how the
breakdown of desktop environment among active Qubes users today looks
like. Has everyone migrated to XFCE by now, or are there lots of people
still running KDE?
Marek Marczykowski-Górecki
Jun 18, 2017, 5:04:46 PM6/18/17
to Zrubi, Reg Tiangha, qubes...@googlegroups.com, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
> 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.
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)
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
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
Version: GnuPG v2
7ET5hQmwEyT+JazddANq/JHDlwIbqrIc+f4FE/IA59kkruZiprmvWAh7mEd87zEz
9eh5cx5P0KOhSxbf1FQ5S4109/8kTUXm2rfGhJa0OQduvKk97zJ9AoiC8KdDMb4U
Xdh9EcYYr1kHgTKFWE17qi0i6urXYvl52pRUeLB6Qp0uSXL/zqqOFylSSzWdVq2c
hHQHmxrNGTd8y54M2ME3QzD28mzPdhdKSiy30mptFMr1f2cNad3mHl6/DI5PNxgA
QZW/I0Ljt6SzDAA/HJRjjK2+6fCafuuedCuqXYl/Jq5qRA5zquSr2OxZZOslUwY=
=giIk
-----END PGP SIGNATURE-----
Zrubi
Jun 19, 2017, 10:04:51 AM6/19/17
to Reg Tiangha, qubes...@googlegroups.com, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
> 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 ;) ).
> After changing netvm for fedora-25-dvm you need to regenerate
> DispVM savefile.
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
- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJZR9nzAAoJEH7adOMCkunmIV0P/1V2kV/ZHcrayjpg9majij97
Version: GnuPG v2
+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
Jun 21, 2017, 12:45:46 AM6/21/17
to qubes...@googlegroups.com, qubes...@googlegroups.com
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
> 4.9 is working OK so far. I was using 4.8 prior to this.
having with 4.8 (domU), and the 4.9.33-18 security update is working
well so far.
Chris Laprise
Jun 28, 2017, 10:57:43 PM6/28/17
to Reg Tiangha, qubes...@googlegroups.com, qubes...@googlegroups.com
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
> -----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
fix it?
Zrubi
Jun 29, 2017, 3:32:32 AM6/29/17
to Chris Laprise, qubes...@googlegroups.com, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
> I noticed this, too. So reverting a dispVM's template back to 4.4
> should fix it?
specific kernel version.
Workaround:
After changing the kernel, you need to regenerate DispVM
savefile.
- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
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
Jun 29, 2017, 7:18:33 AM6/29/17
to qubes-users, tas...@openmailbox.org, qubes...@googlegroups.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).
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).
0spin...@gmail.com
Jun 29, 2017, 6:05:04 PM6/29/17
to qubes-users, qubes...@googlegroups.com, r...@reginaldtiangha.com
On Thursday, June 29, 2017 at 10:10:43 PM UTC+2, Reg Tiangha wrote:
> On 06/29/2017 04:59 AM,
> 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.
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.
> 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
> > 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).
> >
>
> 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.
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
Jul 5, 2017, 12:57:52 PM7/5/17
to qubes-users, pdi...@gmail.com, qubes...@googlegroups.com, r...@reginaldtiangha.com
> On Jun 21, 2017, at 3:01 PM, Ryan Tate <ryan...@ryantate.com> wrote:
>
> 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.
> 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 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.
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
Jul 7, 2017, 2:12:01 AM7/7/17
to qubes-users, pdi...@gmail.com, qubes...@googlegroups.com, r...@reginaldtiangha.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
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
Jul 11, 2017, 3:11:54 AM7/11/17
to qubes-users, qubes...@googlegroups.com, r...@reginaldtiangha.com
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
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
Chris Laprise
Jul 14, 2017, 2:13:10 AM7/14/17
to qubes...@googlegroups.com
On 06/21/2017 12:45 AM, Chris Laprise wrote:
> 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.
>
The newer 4.9.35-19 kernel has a side-effect:
> 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.
>
The return of an old problem where netVMs refuse to start unless an
appVM has already been started. This means at boot I can't start
anything network-connected until I start a non-networked VM.
IIRC it was Qubes R3.0 that had this problem.
Epitre
Jul 24, 2017, 5:03:01 AM7/24/17
to qubes-devel, qubes...@googlegroups.com, r...@reginaldtiangha.com
Hello, just a small ping to know if it is the good place to ask this question. Thank you.
lok...@gmail.com
Aug 11, 2017, 9:20:43 PM8/11/17
to qubes-users, qubes...@googlegroups.com, r...@reginaldtiangha.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.
> 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.
I can now disable tap-to-click. Finally!
> 4) General feedback on the 4.9 kernel.
lok...@gmail.com
Aug 11, 2017, 9:20:43 PM8/11/17
to qubes-users, qubes...@googlegroups.com, r...@reginaldtiangha.com, 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.> > 2) Hardware that didn't work with 4.4 or 4.8 still doesn't work.
>
> I can now disable tap-to-click. Finally!
Kristian Elof Sørensen
Aug 11, 2017, 9:22:07 PM8/11/17
to qubes...@googlegroups.com, qubes...@googlegroups.com
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
> People may not have noticed, but there is now a 4.9 kernel in
> current-testing (4.9.28 to be specific).
> 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.
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.
>
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
0spin...@gmail.com
Aug 12, 2017, 3:06:20 AM8/12/17
to qubes-devel, qubes...@googlegroups.com, kris...@elof.dk
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
https://groups.google.com/forum/#!topic/qubes-users/yBeUJPwKwHM
Doesnt Work
Aug 15, 2017, 2:25:17 PM8/15/17
to qubes...@googlegroups.com
1) Hardware: noname laptop, same model as purism, intel skylake i7
After update, no AppVM would start, claiming "VM kernel does not exist:
/var/lib/qubes/vm-kernels/4.4.14-11/vmlinuz"
Settings in GUI VM-Manager showed new kernel, even VMs with manually set
kernel showed this behaivour, though the GUI reported the correct kernel
version. qvm-prefs showed kernel version 4.4.14-11 and setting it here
persisted while changing kernel-version in the GUI did nothing.
Furthermore I get black screens when waking up from sleep from time to
time, didn't find reproducible pattern. Computer completely hangs, can't
even change keyboard-lighting.
After update, no AppVM would start, claiming "VM kernel does not exist:
/var/lib/qubes/vm-kernels/4.4.14-11/vmlinuz"
Settings in GUI VM-Manager showed new kernel, even VMs with manually set
kernel showed this behaivour, though the GUI reported the correct kernel
version. qvm-prefs showed kernel version 4.4.14-11 and setting it here
persisted while changing kernel-version in the GUI did nothing.
Furthermore I get black screens when waking up from sleep from time to
time, didn't find reproducible pattern. Computer completely hangs, can't
even change keyboard-lighting.
the2nd
Aug 15, 2017, 9:22:11 PM8/15/17
to qubes-users, qubes...@googlegroups.com, r...@reginaldtiangha.com
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).
>
> 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:
>
> 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.
Reply all
Reply to author
Forward
0 new messages