Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upWindow contents gets trashed #1028
Comments
marmarek
added
bug
C: gui-virtualization
P: major
labels
Jun 15, 2015
marmarek
added this to the Release 3.0 milestone
Jun 15, 2015
marmarek
self-assigned this
Jun 15, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
nrgaway
Jun 15, 2015
nrgaway
commented
Jun 15, 2015
|
I would be interested to know what video hardware people are using that
have this issue.
It used to happen to me all the time, but it has not happened, not even
once, since I made changes to the Debian templates back in January.
I have an Intel on-board GPU. I also make additional UI changes via salt
configuration scripts which are available in my repo for Debian and Fedora.
This behaviour did start to re-appear yesterday in a Fedora-21 template I
upgraded from Fedora-20 and I am not sure if it's an isolated incident or
not since I been working in Debian AppVMs all day.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Jun 15, 2015
Member
On Mon, Jun 15, 2015 at 12:23:10AM -0700, nrgaway wrote:
I would be interested to know what video hardware people are using that
have this issue.It used to happen to me all the time, but it has not happened, not even
once, since I made changes to the Debian templates back in January.I have an Intel on-board GPU. I also make additional UI changes via salt
configuration scripts which are available in my repo for Debian and Fedora.This behaviour did start to re-appear yesterday in a Fedora-21 template I
upgraded from Fedora-20 and I am not sure if it's an isolated incident or
not since I been working in Debian AppVMs all day.
I think I've found the problem: Xorg server on Debian cannot mlock()
memory of the windows (this is done by qubes driver) and if there is no
enough physical memory - it gets swapped and some other data are placed
in the same "physical" space - most likely some other process. But dom0
still thinks that those pages contains window content.
You can check that by connecting to Xorg with strace -e mlock -e signals= -p``pidof Xorg``. On Fedora mlock works flawlessly, but on Debian it
fails with ENOMEM. According to/proc/.../limits, Xorg process have
locked memory limited to 64kb. Both on Debian and Fedora. But on Fedora
Xorg is running as root and apparently this limit isn't enforced (you
can check that in/proc/.../status,VmLckfield - its much bigger
than 64kb). The fix would be to increase the limit (simple ulimit call
in/usr/bin/qubes-run-xorg.sh?)
Given above information it is probable that the issue occurs only in
some VMs (with less memory) and if you have a lot of memory it may not
occur at all.
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?
|
On Mon, Jun 15, 2015 at 12:23:10AM -0700, nrgaway wrote:
I think I've found the problem: Xorg server on Debian cannot mlock() You can check that by connecting to Xorg with Given above information it is probable that the issue occurs only in Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
nrgaway
Jun 15, 2015
On 15 June 2015 at 05:51, Marek Marczykowski-Górecki <
notifications@github.com> wrote:
On Mon, Jun 15, 2015 at 12:23:10AM -0700, nrgaway wrote:
I would be interested to know what video hardware people are using that
have this issue.It used to happen to me all the time, but it has not happened, not even
once, since I made changes to the Debian templates back in January.I have an Intel on-board GPU. I also make additional UI changes via salt
configuration scripts which are available in my repo for Debian and
Fedora.This behaviour did start to re-appear yesterday in a Fedora-21 template I
upgraded from Fedora-20 and I am not sure if it's an isolated incident or
not since I been working in Debian AppVMs all day.I think I've found the problem: Xorg server on Debian cannot mlock()
memory of the windows (this is done by qubes driver) and if there is no
enough physical memory - it gets swapped and some other data are placed
in the same "physical" space - most likely some other process. But dom0
still thinks that those pages contains window content.You can check that by connecting to Xorg with
strace -e mlock -e signals= -p``pidof Xorg``. On Fedora mlock works flawlessly, but on Debian it
fails with ENOMEM. According to/proc/.../limits, Xorg process have
locked memory limited to 64kb. Both on Debian and Fedora. But on Fedora
Xorg is running as root and apparently this limit isn't enforced (you
can check that in/proc/.../status,VmLckfield - its much bigger
than 64kb). The fix would be to increase the limit (simple ulimit call
in/usr/bin/qubes-run-xorg.sh?)Given above information it is probable that the issue occurs only in
some VMs (with less memory) and if you have a lot of memory it may not
occur at all.
Very interesting.
I usually assign 6-8GB to each VM and therefore might not be experiencing
the problem because of that. For giggles, I cut back one of the VM's to 3GB
and ran some intensive disk operations and did begin to experience some
mild artifacts.
The Fedora-21 issue I spoke about earlier also had limited memory
assigned. Isn't xorg run as user now in Fedora-21?
nrgaway
commented
Jun 15, 2015
|
On 15 June 2015 at 05:51, Marek Marczykowski-Górecki <
Very interesting. I usually assign 6-8GB to each VM and therefore might not be experiencing The Fedora-21 issue I spoke about earlier also had limited memory |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
mig5
Jun 21, 2015
Since disabling swap in my biggest Debian VM, I no longer reproduce this issue whereas I reliably did beforehand.
Though I also noted the machine settings had 'memory management' disabled, so not sure if turning that on was enough mitigation either. I will continue to test as I wish for most of my AppVMs to be Debian, and update here if it occurs again.
Mig
mig5
commented
Jun 21, 2015
|
Since disabling swap in my biggest Debian VM, I no longer reproduce this issue whereas I reliably did beforehand. Though I also noted the machine settings had 'memory management' disabled, so not sure if turning that on was enough mitigation either. I will continue to test as I wish for most of my AppVMs to be Debian, and update here if it occurs again. Mig |
marmarek
closed this
in
marmarek/old-qubes-gui-agent-linux@13ec90b
Jun 23, 2015
added a commit
to marmarek/old-qubes-gui-agent-linux
that referenced
this issue
Jul 14, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
The issue is back on R3.1, not only Debian. |
marmarek
reopened this
Jan 4, 2016
marmarek
modified the milestones:
Release 3.1,
Release 3.0
Jan 4, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Jan 10, 2016
Member
Generally description in #1028 (comment) still apply. Dom0 has MFN numbers of pages with window composition buffers. The bug happens because something else is written to that memory (identified by physical address), without gui-agent knowledge. It may be the same process, but may be totally different (which was the case before). Finding what is written there is not as interesting as why. But may be some lead.
Some useful debugging information would be getting memory map (which memory page is used for what). Anyone have an idea how?
But first step would be verifying if all the composition buffers are really mlocked (the mlock call is here if that matters).
/cc @woju
|
Generally description in #1028 (comment) still apply. Dom0 has MFN numbers of pages with window composition buffers. The bug happens because something else is written to that memory (identified by physical address), without gui-agent knowledge. It may be the same process, but may be totally different (which was the case before). Finding what is written there is not as interesting as why. But may be some lead. Some useful debugging information would be getting memory map (which memory page is used for what). Anyone have an idea how? /cc @woju |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
woju
Jan 15, 2016
Member
Attached one such case. Screenshot was done from the dom0. Every fourth byte is forced to 0xFF, so there is some guessing. Of particular interest is first block (endian-swapped), which at its end contains something which looks like argv and environment from the bottom of stack:
00000c80: ff00 0000 ff00 0000 ff00 0000 ff00 2f62 ............../b
00000c90: ff6e 2f73 ff00 2f75 ff72 2f6c ff62 2f71 .n/s../u.r/l.b/q
00000ca0: ff62 6573 ff73 796e ff2d 6e74 ff2d 636c .bes.syn.-nt.-cl
00000cb0: ff63 6b00 ff44 475f ff45 5353 ff4f 4e5f .ck..DG_.ESS.ON_
00000cc0: ff44 3d63 ff32 3032 ff48 4f53 ff4e 414d .D=c.202.HOS.NAM
00000cd0: ff3d 6973 ff72 6100 ff48 454c ff3d 2f62 .=is.ra..HEL.=/b
00000ce0: ff6e 2f62 ff73 6800 ff49 5354 ff49 5a45 .n/b.sh..IST.IZE
00000cf0: ff31 3030 ff00 5152 ff58 4543 ff52 454d .100..QR.XEC.REM
00000d00: ff54 455f ff4f 4d41 ff4e 3d64 ff6d 3000 .TE_.OMA.N=d.m0.
Looks like QREXEC_REMOTE_DOMAIN=dom0 /bin/sh /usr/lib/qubes/sync-ntp-clock. The domain in question is a netvm. It is still running and the artifacts are still present as I type, and I suspect they will remain there unless I disturb the window somehow (move, resize). I have other terminal window to poke inside.
Attempting to take a screenshot from inside of the VM yields no artifacts.
I can only paste this image, github says it does not support raw files:
|
Attached one such case. Screenshot was done from the dom0. Every fourth byte is forced to Looks like Attempting to take a screenshot from inside of the VM yields no artifacts. I can only paste this image, github says it does not support raw files: |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
woju
Jan 15, 2016
Member
The offsets (from the beginning of the window) are:
0x00171538
0x001b2538
0x001bc538
0x001cb538
0x00292538
Size of each artifact is one page (4096 B).
|
The offsets (from the beginning of the window) are: Size of each artifact is one page (4096 B). |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Ok, so this is clearly another process, not X server. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Does X server have any page swapped out (check in |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
woju
Jan 15, 2016
Member
[user@iskra ~]$ ps auxfw | fgrep X
...
user 1025 0.0 15.0 367028 40368 ? SLl Jan05 0:06 \_ /usr/libexec/Xorg :0 -nolisten tcp vt07 -wr -config xorg-qubes.conf
...
[user@iskra ~]$ cat /proc/1025/status
Name: Xorg
State: S (sleeping)
Tgid: 1025
Ngid: 0
Pid: 1025
PPid: 1024
TracerPid: 0
Uid: 1000 1000 1000 1000
Gid: 1000 1000 1000 1000
FDSize: 256
Groups: 98 1000
NStgid: 1025
NSpid: 1025
NSpgid: 1025
NSsid: 992
VmPeak: 371180 kB
VmSize: 367028 kB
VmLck: 29308 kB
VmPin: 0 kB
VmHWM: 44636 kB
VmRSS: 40372 kB
VmData: 163348 kB
VmStk: 136 kB
VmExe: 2152 kB
VmLib: 56264 kB
VmPTE: 504 kB
VmPMD: 12 kB
VmSwap: 4484 kB
Threads: 9
SigQ: 0/1004
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000301200
SigCgt: 00000001d18064cf
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000003fffffffff
Seccomp: 0
Cpus_allowed: ff
Cpus_allowed_list: 0-7
Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 22454
nonvoluntary_ctxt_switches: 220
|
added a commit
to marmarek/old-qubes-gui-agent-linux
that referenced
this issue
Jan 15, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Jan 17, 2016
Member
Some useful debugging information would be getting memory map (which memory page is used for what). Anyone have an idea how?
http://www.mjmwired.net/kernel/Documentation/vm/pagemap.txt
It gives an information about virtual->physical memory map. More details here: http://stackoverflow.com/a/13949855
http://www.mjmwired.net/kernel/Documentation/vm/pagemap.txt It gives an information about virtual->physical memory map. More details here: http://stackoverflow.com/a/13949855 |
marmarek
changed the title from
Window contents gets trashed (Debian)
to
Window contents gets trashed
Jan 25, 2016
marmarek
referenced this issue
Jan 25, 2016
Closed
Xorg pages locking problem strikes back on FC23 #1688
marmarek
added
P: critical
and removed
P: major
labels
Jan 25, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Jan 25, 2016
Member
I think it happened for me also on some old VM not updated for a long time (but running on "default kernel"). So the issue could be there for a long time, or could be unrelated to VM software, but rather kernel version.
|
I think it happened for me also on some old VM not updated for a long time (but running on "default kernel"). So the issue could be there for a long time, or could be unrelated to VM software, but rather kernel version. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Feb 2, 2016
Member
Added some more debugging, namely full dumps of whole MFN_DUMP message (MFN of composition buffer for particular window). And apparently some pages are changed, regardless of mlock call.
Example:
Feb 02 22:56:49 testvm qubes-gui[18158]: MFNDUMP for 0x1a009bc (352, 722x498): 003ECC91 001634F1 00073F37 003ED25B 00427B7C 00037643 000455E8 00412038 0036B147 0003C0E9 00274239 00331692 0027BD8D 003C985C 001251C1 003EC16E 0013A101 00233DC3 000727BE 00039B9E 00073E3F 0037159E 0040CAA2 003E7747 00332D73 0003A02E 0003BCA0 00073E11 0003B36C 00167533 000776FE 002284BE 0003B97A 00389431 0030F600 00336C81 0015B7DC 0035AB24 000727AD 0011390B 0036A210 000728A8 0003BCE2 0042A188 00068151 0003F708 000698AE 002294CD 00077616 002295B9 0033B282 00314987 003EC061 00077604 003B1D0A 0003A1DB 0036C38B 002423FC 0024809D 0041213F 00069194 0007F6A8 0022C6A1 00206335 0007F8D0 004172F4 00022B15 00404FDA 001C1440 001C1406 000BCD6A 0008DCDD **003AB505** 000776E2 0008E886 0003BA4C 0003402A 00401FF3 003EC956 00035C82 0006A971 0030F5D0 00305D94 00331694 00068644 0003EA85 00402EE6 0038C724 00068BF3 00312C38 00429906 0003A341 0021BAAE 00074D9F 0007775C 00369525 002B0D02 00319E21 002C0953 002617B8 001D5DB8 003913EB 0031E8D4 003B6645 00308D8A 002D16A1 0007F62B 0007C1F6 00165879 0020B368 0026C2CC 0020B8E4 0020B8E8 0020B8EC 0020B8F0 0014B28A 0014EB7D 003F3C3A 003F3C5E 003835D7 003EE3CB 003D1F47 0024876C 0027DC45 0027DC49 00220021 00248085 00382840 002DD9BC 002BD78A 003AC1AE 0021A14F 003CFC48 00272981 00272998 0032F79F 003A3A89 003A3A8B 003A3A8D 003A3A8F 003A3A91 003CFC49 002AAC38 002AAC39 00396C1B 00383FF1 00406CEE 003DA26E 0030DFB8 00223E1D 0034AA97 00360BF9 0026AE3D 003B4A03 002663A8 0029B767 00266E29 0003C457 0008E7E4 003368BF 00204CF0 00301D8B 0015CE88 001429E9 002BDA8A 00407D7F 003C3844 002ADE12 003B0FAD 004120E8 00303AF1 00232225 0008E2A0 0030F1F0 002AE91C **00305416** 0033259E 0020EC25 0039ACE3 003F95E4 002D3811 003AF53B 0029FFB9 0007763F 0039AD8B 003A471E 0030F604 0022C6B3 00344052 002EA569 0031580F 002294B7 0022AD81 0022920E 0036F1E1 00073F49 0007762F 003055EF 0022C172 0024B758 002294B3 00236FD8 0010B7F5 003F57BA 00390844 0026B942 00414ECB 002BD789 002FBE8D 00292C8B 0031D21C 0030D2CB 003BC56F 003B7F19 0023EAA6 003D007A 00264724 00390645 0039167A 00287EA0 00073F12 0026657F 003E7815 003DA486 003991BF 001567B3 003E168B 002294BF 0031411C 002A0CCE 002736B0 003551C8 003E73F3 003359B7 003B2571 0008DBF7 003B7907 00334A19 003C134C 00349AE4 002391D2 003A2FF9 00077635 0007763B 002AAFBA 00398F8F 00077633 00077636 00077637 002BABD6 002A9450 00380956 00380957 0020CBED 0027DC67 0003DC82 0003DC79 0040F94B 0040F95C 002ADEFA 00232D7C 003AB662 003AB663 0020B6E2 0032039D 002600B0 003B19C2 002AF1BA 002AF1BD 00314D22 00314D2B 00077630 00077631 00388CA5 00388CA6 00232296 00275A70 0030F1F1 00305CA4 003B5248 003B5244 00077638 00077639 0031857A 003B59CE 0031781D 00248BD8 0027165F 002719D8 00287EB1 002EA568 002456B7 0036C3D8 003EE33C 003CFBFA 0021B222 003D0DDB 0025DDF5 0020812C 0020871C 0021DFB5 00287EA1 00287EAA 00287EAB 00287EB0 00338014 0031EE3E 002BF2C6 00332B2C 0033CED8 0033ABB4 0033C2FC 003B7894 0036D9DB 0036D84A 0036D9AB 0036453B 003368DA 002E3463 0033BB8C 0020B82F 00332CDB 002AD65D 0033631B 0039AC8D 00330459 0032F786 00333865 00277D9D 00277D9F 00359B77 00277D9E 00359B76 0031FD41 0002FAF3 00339AA2 0033B4EA 0038EABB 0038EA6B 0038EA6C 00200FD5 003354A5 003354A7 0039B2C5 003354A6 0039B2C4 0038EA6D 0038EA6E 0038871D 00312E9A 002A5EC6 00335180
Feb 02 23:43:09 testvm qubes-gui[18158]: MFNDUMP for 0x1a009bc (352, 722x498): 003ECC91 001634F1 00073F37 003ED25B 00427B7C 00037643 000455E8 00412038 0036B147 0003C0E9 00274239 00331692 0027BD8D 003C985C 001251C1 003EC16E 0013A101 00233DC3 000727BE 00039B9E 00073E3F 0037159E 0040CAA2 003E7747 00332D73 0003A02E 0003BCA0 00073E11 0003B36C 00167533 000776FE 002284BE 0003B97A 00389431 0030F600 00336C81 0015B7DC 0035AB24 000727AD 0011390B 0036A210 000728A8 0003BCE2 0042A188 00068151 0003F708 000698AE 002294CD 00077616 002295B9 0033B282 00314987 003EC061 00077604 003B1D0A 0003A1DB 0036C38B 002423FC 0024809D 0041213F 00069194 0007F6A8 0022C6A1 00206335 0007F8D0 004172F4 00022B15 00404FDA 001C1440 001C1406 000BCD6A 0008DCDD **0035A947** 000776E2 0008E886 0003BA4C 0003402A 00401FF3 003EC956 00035C82 0006A971 0030F5D0 00305D94 00331694 00068644 0003EA85 00402EE6 0038C724 00068BF3 00312C38 00429906 0003A341 0021BAAE 00074D9F 0007775C 00369525 002B0D02 00319E21 002C0953 002617B8 001D5DB8 003913EB 0031E8D4 003B6645 00308D8A 002D16A1 0007F62B 0007C1F6 00165879 0020B368 0026C2CC 0020B8E4 0020B8E8 0020B8EC 0020B8F0 0014B28A 0014EB7D 003F3C3A 003F3C5E 003835D7 003EE3CB 003D1F47 0024876C 0027DC45 0027DC49 00220021 00248085 00382840 002DD9BC 002BD78A 003AC1AE 0021A14F 003CFC48 00272981 00272998 0032F79F 003A3A89 003A3A8B 003A3A8D 003A3A8F 003A3A91 003CFC49 002AAC38 002AAC39 00396C1B 00383FF1 00406CEE 003DA26E 0030DFB8 00223E1D 0034AA97 00360BF9 0026AE3D 003B4A03 002663A8 0029B767 00266E29 0003C457 0008E7E4 003368BF 00204CF0 00301D8B 0015CE88 001429E9 002BDA8A 00407D7F 003C3844 002ADE12 003B0FAD 004120E8 00303AF1 00232225 0008E2A0 0030F1F0 002AE91C **001DCFEE** 0033259E 0020EC25 0039ACE3 003F95E4 002D3811 003AF53B 0029FFB9 0007763F 0039AD8B 003A471E 0030F604 0022C6B3 00344052 002EA569 0031580F 002294B7 0022AD81 0022920E 0036F1E1 00073F49 0007762F 003055EF 0022C172 0024B758 002294B3 00236FD8 0010B7F5 003F57BA 00390844 0026B942 00414ECB 002BD789 002FBE8D 00292C8B 0031D21C 0030D2CB 003BC56F 003B7F19 0023EAA6 003D007A 00264724 00390645 0039167A 00287EA0 00073F12 0026657F 003E7815 003DA486 003991BF 001567B3 003E168B 002294BF 0031411C 002A0CCE 002736B0 003551C8 003E73F3 003359B7 003B2571 0008DBF7 003B7907 00334A19 003C134C 00349AE4 002391D2 003A2FF9 00077635 0007763B 002AAFBA 00398F8F 00077633 00077636 00077637 002BABD6 002A9450 00380956 00380957 0020CBED 0027DC67 0003DC82 0003DC79 0040F94B 0040F95C 002ADEFA 00232D7C 003AB662 003AB663 0020B6E2 0032039D 002600B0 003B19C2 002AF1BA 002AF1BD 00314D22 00314D2B 00077630 00077631 00388CA5 00388CA6 00232296 00275A70 0030F1F1 00305CA4 003B5248 003B5244 00077638 00077639 0031857A 003B59CE 0031781D 00248BD8 0027165F 002719D8 00287EB1 002EA568 002456B7 0036C3D8 003EE33C 003CFBFA 0021B222 003D0DDB 0025DDF5 0020812C 0020871C 0021DFB5 00287EA1 00287EAA 00287EAB 00287EB0 00338014 0031EE3E 002BF2C6 00332B2C 0033CED8 0033ABB4 0033C2FC 003B7894 0036D9DB 0036D84A 0036D9AB 0036453B 003368DA 002E3463 0033BB8C 0020B82F 00332CDB 002AD65D 0033631B 0039AC8D 00330459 0032F786 00333865 00277D9D 00277D9F 00359B77 00277D9E 00359B76 0031FD41 0002FAF3 00339AA2 0033B4EA 0038EABB 0038EA6B 0038EA6C 00200FD5 003354A5 003354A7 0039B2C5 003354A6 0039B2C4 0038EA6D 0038EA6E 0038871D 00312E9A 002A5EC6 00335180
(differences marked with stars)
I guess Xorg and consequently gui-agent is not notified about those changes. Not sure why would be. Ideally we would like to force somehow kernel (or Xen?) to not change mlocked pages, but if not possible, to at least be notified of such change.
|
Added some more debugging, namely full dumps of whole MFN_DUMP message (MFN of composition buffer for particular window). And apparently some pages are changed, regardless of Example: (differences marked with stars) I guess Xorg and consequently gui-agent is not notified about those changes. Not sure why would be. Ideally we would like to force somehow kernel (or Xen?) to not change |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Feb 3, 2016
Member
Hmm, my previous comment is probably dead end, I've just got another example, where window content got "fixed", without sending any MSG_MFNDUMP message - so MFNs of composition buffer are the same.
Or maybe, for some reason kernel give back the original MFNs? In any case it looks like mlock doesn't work as it should (or more precise: as we expect).
|
Hmm, my previous comment is probably dead end, I've just got another example, where window content got "fixed", without sending any MSG_MFNDUMP message - so MFNs of composition buffer are the same. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Feb 3, 2016
Member
Interestingly, none of MFNs in that MSG_MFNDUMP messages matches those from /proc/.../pagemap (using page-collect program mentioned earlier). Probably a bug in one or another method...
|
Interestingly, none of MFNs in that MSG_MFNDUMP messages matches those from |
marmarek
referenced this issue
Feb 7, 2016
Closed
Garbage artifacts on VMs windows with low memory allocated #1727
marmarek
modified the milestones:
Release 3.1,
Release 3.1 updates
Feb 8, 2016
added a commit
to QubesOS/qubes-gui-agent-linux
that referenced
this issue
Feb 29, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Jul 28, 2016
Member
Very useful message from HW42:
The problem is that the pages with the windows content need to be pinned
to a physical page when being mapped with xc_map_foreign_pages. To
archive this the current code calls mlock(). Unfortunately this only
ensures that the page doesn't get swapped out but the kernel can still
move the page.From 0:
A page that has been locked into memory with a call like mlock() is
required to always be physically present in the system's RAM. [...].
But there is nothing that requires a locked page to always be present
in the same place; the kernel is free to move a locked page if the
need arises.So when a VM window looks corrupted the VM kernel has moved the page and
it has now a new physical address and in dom0 you now see the new
content of the old physical page.If you want to monitor the effect you can use the attached script. It
shows the mapping of virtual addresses to physical addresses of a given
memory range for a given process. So call strace on Xorg to get the
mlock() call and pass those arguments to the script. Now either wait
until you have "luck" or provoke it by
'echo 1 > /proc/sys/vm/compact_memory'Unfortunately the patch from 0 didn't got into the kernel, so there
is no easy way to pin a page similar to mlock().One workaround is to disable memory compactation of unevictable (i.e.
mlocked) pages:echo 0 > /proc/sys/vm/compact_unevictable_allowed
This has two downsides:
a) While I didn't observed the effect anymore with this setting I'm not
sure if this prevents all cases in which the kernel moves pages. (A
bit grepping suggest that it ignores this flag when allocating
hugepages but I'm not sure about this.)b) Given that VMs in Qubes are often low on memory I'm a bit uneasy to
change memory management options without knowing the side effects.Properly pinning is not that easy since there seems to be no way to flag
a page as unmovable. The common way seems to be to call
get_user_pages() to increment the reference counter and thereby pin it.
The problem is that then the u2mfn module needs to be changed
significantly to track allocation and deallocation since else the pages
never get freed.If somebody (who is familiar with the linux kernel) knows another
solution this would be great.#2185 mentions that you want do get rid of u2mfn anyway. How does the
new solution should work?Unless somebody knows a better way to lock pages the best thing for R3.2
is probably to use the above mentioned work-around and implement a
better solution in R4.HW42
|
Very useful message from HW42:
|
marmarek
closed this
in
marmarek/old-qubes-gui-agent-linux@9c53381
Aug 2, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Aug 2, 2016
Member
Automated announcement from builder-github
The package qubes-gui-agent_3.2.4+deb8u1 has been pushed to the r3.2 testing repository for the Debian jessie template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing jessie-testing, then use the standard update command:
sudo apt-get update && sudo apt-get dist-upgrade
|
Automated announcement from builder-github The package |
marmarek
added
r3.2-fc24-stable
and removed
r3.2-fc24-cur-test
labels
Aug 31, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Aug 31, 2016
Member
Automated announcement from builder-github
The package qubes-gui-agent_3.2.5+deb8u1 has been pushed to the r3.2 stable repository for the Debian jessie template.
To install this update, please use the standard update command:
sudo apt-get update && sudo apt-get dist-upgrade
|
Automated announcement from builder-github The package |
marmarek
added
r3.2-jessie-stable
and removed
r3.2-jessie-cur-test
labels
Aug 31, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Aug 31, 2016
Member
Automated announcement from builder-github
The package qubes-gui-agent_3.2.5+deb9u1 has been pushed to the r3.2 stable repository for the Debian stretch template.
To install this update, please use the standard update command:
sudo apt-get update && sudo apt-get dist-upgrade
|
Automated announcement from builder-github The package |
marmarek
added
r3.2-stretch-stable
and removed
r3.2-stretch-cur-test
labels
Aug 31, 2016
added a commit
to QubesOS/qubes-core-admin
that referenced
this issue
Nov 20, 2016
added a commit
to QubesOS/qubes-gui-agent-linux
that referenced
this issue
Nov 20, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 20, 2016
Member
Automated announcement from builder-github
The package qubes-gui-vm-3.1.8-1.fc21 has been pushed to the r3.1 testing repository for the Fedora fc21 template.
To test this update, please install it with the following command:
sudo yum update --enablerepo=qubes-vm-r3.1-current-testing
|
Automated announcement from builder-github The package |
marmarek
added
the
r3.1-fc21-cur-test
label
Nov 20, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 20, 2016
Member
Automated announcement from builder-github
The package qubes-gui-vm-3.1.8-1.fc22 has been pushed to the r3.1 testing repository for the Fedora fc22 template.
To test this update, please install it with the following command:
sudo yum update --enablerepo=qubes-vm-r3.1-current-testing
|
Automated announcement from builder-github The package |
marmarek
added
the
r3.1-fc22-cur-test
label
Nov 20, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 20, 2016
Member
Automated announcement from builder-github
The package qubes-gui-vm-3.1.8-1.fc23 has been pushed to the r3.1 testing repository for the Fedora fc23 template.
To test this update, please install it with the following command:
sudo yum update --enablerepo=qubes-vm-r3.1-current-testing
|
Automated announcement from builder-github The package |
marmarek
added
the
r3.1-fc23-cur-test
label
Nov 20, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 20, 2016
Member
Automated announcement from builder-github
The package qubes-gui-agent_3.1.8+deb8u1 has been pushed to the r3.1 testing repository for the Debian jessie template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing jessie-testing, then use the standard update command:
sudo apt-get update && sudo apt-get dist-upgrade
|
Automated announcement from builder-github The package |
marmarek
added
the
r3.1-jessie-cur-test
label
Nov 20, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 20, 2016
Member
Automated announcement from builder-github
The package qubes-gui-agent_3.1.8+deb9u1 has been pushed to the r3.1 testing repository for the Debian stretch template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing, then use the standard update command:
sudo apt-get update && sudo apt-get dist-upgrade
|
Automated announcement from builder-github The package |
marmarek
added
the
r3.1-stretch-cur-test
label
Nov 20, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 20, 2016
Member
Automated announcement from builder-github
The package qubes-gui-agent_3.1.8+deb7u1 has been pushed to the r3.1 testing repository for the Debian wheezy template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing wheezy-testing, then use the standard update command:
sudo apt-get update && sudo apt-get dist-upgrade
|
Automated announcement from builder-github The package |
marmarek
added
the
r3.1-wheezy-cur-test
label
Nov 20, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Dec 4, 2016
Member
Automated announcement from builder-github
The package qubes-gui-vm-3.1.9-1.fc21 has been pushed to the r3.1 stable repository for the Fedora fc21 template.
To install this update, please use the standard update command:
sudo yum update
|
Automated announcement from builder-github The package |
marmarek
added
r3.1-fc21-stable
and removed
r3.1-fc21-cur-test
labels
Dec 4, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Dec 4, 2016
Member
Automated announcement from builder-github
The package qubes-gui-vm-3.1.9-1.fc22 has been pushed to the r3.1 stable repository for the Fedora fc22 template.
To install this update, please use the standard update command:
sudo yum update
|
Automated announcement from builder-github The package |
marmarek
added
r3.1-fc22-stable
and removed
r3.1-fc22-cur-test
labels
Dec 4, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Dec 4, 2016
Member
Automated announcement from builder-github
The package qubes-gui-vm-3.1.9-1.fc23 has been pushed to the r3.1 stable repository for the Fedora fc23 template.
To install this update, please use the standard update command:
sudo yum update
|
Automated announcement from builder-github The package |
marmarek
added
r3.1-fc23-stable
and removed
r3.1-fc23-cur-test
labels
Dec 4, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Dec 4, 2016
Member
Automated announcement from builder-github
The package qubes-gui-agent_3.1.8+deb8u1 has been pushed to the r3.1 stable repository for the Debian jessie template.
To install this update, please use the standard update command:
sudo apt-get update && sudo apt-get dist-upgrade
|
Automated announcement from builder-github The package |
marmarek
added
r3.1-jessie-stable
and removed
r3.1-jessie-cur-test
labels
Dec 4, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Dec 4, 2016
Member
Automated announcement from builder-github
The package qubes-gui-agent_3.1.8+deb9u1 has been pushed to the r3.1 stable repository for the Debian stretch template.
To install this update, please use the standard update command:
sudo apt-get update && sudo apt-get dist-upgrade
|
Automated announcement from builder-github The package |
marmarek
added
r3.1-stretch-stable
and removed
r3.1-stretch-cur-test
labels
Dec 4, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Dec 4, 2016
Member
Automated announcement from builder-github
The package qubes-gui-agent_3.1.8+deb7u1 has been pushed to the r3.1 stable repository for the Debian wheezy template.
To install this update, please use the standard update command:
sudo apt-get update && sudo apt-get dist-upgrade
|
Automated announcement from builder-github The package |
marmarek commentedJun 14, 2015
On Debian VMs, after some time window contents gets trashed with some random horizontal stripes - usually black. According to https://groups.google.com/d/msgid/qubes-users/20150612065419.014e75f7%40hunecke.me it happens especially on heavy VM load.
Example window (extreme state, often there are only few stripes):
On Fedora VMs this problem does not occur.