Fresh install of Fedora 22 in VMWare Workstation 11.1 (Windows 7 host). About every ten minutes gnome-shell crashes: [ 171.763807] [drm:vmw_generic_ioctl [vmwgfx]] *ERROR* Dropped master trying to access ioctl that requires authentication. [ 171.763812] [drm] IOCTL ERROR Command 65, Error -13. [ 171.763878] [drm:vmw_generic_ioctl [vmwgfx]] *ERROR* Dropped master trying to access ioctl that requires authentication. [ 171.763880] [drm] IOCTL ERROR Command 65, Error -13. [ 171.763897] [drm:vmw_generic_ioctl [vmwgfx]] *ERROR* Dropped master trying to access ioctl that requires authentication. [ 171.763901] [drm] IOCTL ERROR Command 87, Error -13. [ 171.763906] show_signal_msg: 210 callbacks suppressed [ 171.763908] gnome-shell[1003]: segfault at 20 ip 00007f2a8b1aa130 sp 00007ffc468b9268 error 4 in vmwgfx_dri.so[7f2a8ac03000+7b7000] [ 174.085165] hrtimer: interrupt took 3471920 ns [ 174.159730] gdm[707]: segfault at 8 ip 00007fcdaf421a20 sp 00007fffa3a923b0 error 4 in gdm[7fcdaf406000+5c000]
From a quick look it looks like a process that previously had been master dropped master and tries to render without reclaiming mastership. (Is this gdm on mutter/wayland?) That's a security problem and the vmwgfx driver catches that. Unfortunately the dri driver doesn't seem to cope well with the error. /Thomas
Default install of Fedora 22 (GNOME desktop).
I've been seeing this for a while, in bug 1222312 - looks as if I have similar errors in the log.
*** Bug 1222312 has been marked as a duplicate of this bug. ***
May 17 15:01:18 localhost.localdomain gnome-session[987]: VMware: vmw_ioctl_command error Permission denied. May 17 15:01:18 localhost.localdomain kernel: [drm:vmw_generic_ioctl [vmwgfx]] *ERROR* Dropped master trying to access ioctl that requires authentication. May 17 15:01:18 localhost.localdomain kernel: [drm] IOCTL ERROR Command 73, Error -13. May 17 15:01:18 localhost.localdomain kernel: [drm:vmw_generic_ioctl [vmwgfx]] *ERROR* Dropped master trying to access ioctl that requires authentication. May 17 15:01:18 localhost.localdomain kernel: [drm] IOCTL ERROR Command 76, Error -13. May 17 15:01:18 localhost.localdomain gnome-session[987]: (gnome-shell:1015): Cogl-ERROR **: Out of memory May 17 15:01:18 localhost.localdomain audit[1015]: <audit-1701> auid=4294967295 uid=42 gid=42 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 pid=1015 comm="gnome-shell" exe="/usr/bin/gnome-shell" sig=5 May 17 15:01:18 localhost.localdomain kernel: [drm:vmw_generic_ioctl [vmwgfx]] *ERROR* Dropped master trying to access ioctl that requires authentication. May 17 15:01:18 localhost.localdomain kernel: [drm] IOCTL ERROR Command 73, Error -13. May 17 15:01:18 localhost.localdomain kernel: do_trap: 15 callbacks suppressed May 17 15:01:18 localhost.localdomain kernel: traps: gnome-shell[1015] trap int3 ip:7f2ae0a2ed3b sp:7fffe603e050 error:0 May 17 15:01:19 localhost.localdomain polkitd[700]: Unregistered Authentication Agent for unix-session:c1 (system bus name :1.16, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8) (disconnected from bus) May 17 15:01:19 localhost.localdomain gnome-session[987]: Unrecoverable failure in required component gnome-shell-wayland.desktop May 17 15:01:19 localhost.localdomain /usr/libexec/gdm-wayland-session[978]: Activating service name='ca.desrt.dconf'
If I remember rightly, GDM was using wayland, and I was in an X11 GNOME session.
While I think the main problem lies in Gnome-Shell (mutter/wayland), you could perhaps try the following to hopefully work around the problem: https://fedoraproject.org/wiki/Documentation_Desktop_Beat
I installed F22 and then did a "dnf upgrade", logged into the Gnome Classic session (vs Gnome Wayland). So far I have not been able to reproduce this. Are there any other steps I should be doing?
(In reply to Thomas Hellström from comment #7) > While I think the main problem lies in Gnome-Shell (mutter/wayland), you > could perhaps try the following to hopefully work around the problem: > > https://fedoraproject.org/wiki/Documentation_Desktop_Beat The workaround seems to work; the problem is gone since I disabled Wayland for GDM.
(In reply to Sinclair Yeh from comment #8) > I installed F22 and then did a "dnf upgrade", logged into the Gnome Classic > session (vs Gnome Wayland). So far I have not been able to reproduce this. > Are there any other steps I should be doing? Interesting, because that is how I got the errors.
Hmm... I still cannot reproduce this issue. Can you provide the following info? 1. What is the kernel version in the VM? 2. What is the host, e.g. Windows, Mac, or Linux? 3. What is the Workstation (or Fusion) version?
Running VMware Player 6.0.7 on Windows 7, installed Fedora 22 from Live image, rebooted, ran dnf update. Left machine to it, after ~15 mins came back and had happened. Then rebooted with fresh updates and did dnf install elasticsearch from a terminal and loaded firefox and same thing again. Did this just now, and log errors same as above. Xwayland also spinning at 100% CPU like my linked bug report.
(In reply to Sinclair Yeh from comment #11) > 1. What is the kernel version in the VM? $ uname -a Linux localhost.localdomain 4.0.7-300.fc22.x86_64 #1 SMP Mon Jun 29 22:15:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > 2. What is the host, e.g. Windows, Mac, or Linux? Windows 7 Ultimate, 64-bit 6.1.7601, Service Pack 1 > 3. What is the Workstation (or Fusion) version? VMware Workstation 11.1.2 build-2780323
Just reboot from crashed VM with the same symptom: ------------------------dmesg-------------------------- [ 16.851764] CPU: 2 PID: 644 Comm: vmtoolsd Not tainted 4.2.0-0.rc1.git3.1.fc23.x86_64 #1 [ 16.851765] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014 [ 16.851766] 0000000000000000 00000000d0527beb ffff8800695dfac8 ffffffff818641f5 [ 16.851768] 0000000000000000 ffff8800695dfb20 ffff8800695dfb08 ffffffff810ab446 [ 16.851770] ffff8800679ebe80 ffffffff81c63bc0 0000000000000061 0000000000000000 [ 16.851772] Call Trace: [ 16.851775] [<ffffffff818641f5>] dump_stack+0x4c/0x65 [ 16.851778] [<ffffffff810ab446>] warn_slowpath_common+0x86/0xc0 [ 16.851779] [<ffffffff810ab4d5>] warn_slowpath_fmt+0x55/0x70 [ 16.851782] [<ffffffff8112551d>] ? debug_lockdep_rcu_enabled+0x1d/0x20 [ 16.851783] [<ffffffff810fa68d>] ? prepare_to_wait+0x2d/0x90 [ 16.851784] [<ffffffff810fa68d>] ? prepare_to_wait+0x2d/0x90 [ 16.851786] [<ffffffff810da2bd>] __might_sleep+0x7d/0x90 [ 16.851788] [<ffffffff812163b3>] __might_fault+0x43/0xa0 [ 16.851791] [<ffffffff81430477>] copy_from_iter+0x87/0x2a0 [ 16.851795] [<ffffffffa03a960a>] __qp_memcpy_to_queue+0x9a/0x1b0 [vmw_vmci] [ 16.851797] [<ffffffffa03a9740>] ? qp_memcpy_to_queue+0x20/0x20 [vmw_vmci] [ 16.851799] [<ffffffffa03a9757>] qp_memcpy_to_queue_iov+0x17/0x20 [vmw_vmci] [ 16.851801] [<ffffffffa03a9d50>] qp_enqueue_locked+0xa0/0x140 [vmw_vmci] [ 16.851803] [<ffffffffa03aa93f>] vmci_qpair_enquev+0x4f/0xd0 [vmw_vmci] [ 16.851805] [<ffffffffa047d7bb>] vmci_transport_stream_enqueue+0x1b/0x20 [vmw_vsock_vmci_transport] [ 16.851807] [<ffffffffa0473e05>] vsock_stream_sendmsg+0x2c5/0x320 [vsock] [ 16.851808] [<ffffffff810fabd0>] ? wake_atomic_t_function+0x70/0x70 [ 16.851812] [<ffffffff81702af8>] sock_sendmsg+0x38/0x50 [ 16.851813] [<ffffffff81702ff4>] SYSC_sendto+0x104/0x190 [ 16.851816] [<ffffffff8126e25a>] ? vfs_read+0x8a/0x140 [ 16.851818] [<ffffffff817042ee>] SyS_sendto+0xe/0x10 [ 16.851820] [<ffffffff8186d9ae>] entry_SYSCALL_64_fastpath+0x12/0x76 [ 16.851821] ---[ end trace 26e121d00ee25d27 ]--- On: Windows 10 10166 + VMWare 11.1.2-2780323 + Fedora 23 Rawhide(This still happen on Fedora 22! It has interrupted upgrading 3 times)
I can reproduce this within 15min of every time I restart fc22 on VMware workstation 11.1.2 build-2780323 VMplayer 7.1.2 build-2780323 Running under Windows 8.1 [root@gt log]# uname -a Linux localhost 4.1.4-200.fc22.x86_64 #1 SMP Tue Aug 4 03:22:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux The machine is fully up-to-date according to 'dnf update' I have also seen Xwayland stuck at 100%; but not sure if this is the direct cause for every crash I have seen. Is there any log file you'd like me to include?
Hi, all. I updated to kernel 4.1.4 yesterday, and the Gnome GUI has been stable since, knock on wood.
Hi, all. False alarm. I am still getting the Gnome issue with VMware Workstation 11 with kernel 4.1.4. It seems to be happening less frequently, though. Sorry.
I get the same behavior on OSX. Host info: OSX 10.10.4 VMWare Fusion 7.1.2 VM Info: Fedora 22, fresh install. uname -a --Linux localhost.localdomain 4.1.4-200.fc22.x86_64 #1 SMP Tue Aug 4 03:22:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Same error here. OSX 10.10.4 VMWare Fusion 7.1.2 Linux 4.1.5-200.fc22.x86_64
What happens is the following, 1) systemd-logind drops drm master on behalf of the gnome-shell --gdm process. 2) gnome-shell --gdm apparently oblivious of this tries to render: #13 0x00007f49ce33b2af in _cogl_journal_flush_modelview_and_entries (batch_start=<optimized out>, batch_len=4, data=0x7ffd21333e00) at ./cogl-journal.c:314 #14 0x00007f49ce33b064 in _cogl_journal_flush_texcoord_vbo_offsets_and_entries (batch_start=0x3c88830, batch_len=4, data=0x7ffd21333e00) at ./cogl-journal.c:565 ---Type <return> to continue, or q <return> to quit--- #15 0x00007f49ce33a9a5 in batch_and_call (entries=<optimized out>, n_entries=<optimized out>, can_batch_callback=0x7f49ce33b4a0 <compare_entry_layer_numbers>, batch_callback=0x7f49ce33afc0 <_cogl_journal_flush_texcoord_vbo_offsets_and_entries>, data=0x7ffd21333e00) at ./cogl-journal.c:266 #16 0x00007f49ce33aef1 in _cogl_journal_flush_vbo_offsets_and_entries (batch_start=0x3c88830, batch_len=54, data=<optimized out>) at ./cogl-journal.c:672 #17 0x00007f49ce33c4e2 in _cogl_journal_flush (journal=0x2739010) at ./cogl-journal.c:1399 #18 0x00007f49ce33d5bc in _cogl_framebuffer_flush_journal (framebuffer=<optimized out>) at ./cogl-framebuffer.c:636 #19 0x00007f49ce311068 in cogl_flush () at ./cogl.c:321 #20 0x00007f49ce34028a in cogl_onscreen_swap_buffers_with_damage (onscreen=0x2718960, rectangles=rectangles@entry=0x7ffd21333ff0, n_rectangles=n_rectangles@entry=1) at ./cogl-onscreen.c:312 #21 0x00007f49cec094df in clutter_stage_cogl_redraw (stage_window=0x2738090) at cogl/clutter-stage-cogl.c:637 #22 0x00007f49cec78317 in clutter_stage_do_redraw (stage=0x2730f70) at clutter-stage.c:1130 #23 _clutter_stage_do_update (stage=0x2730f70) at clutter-stage.c:1186 #24 0x00007f49cec5e7d9 in master_clock_update_stages (master_clock=0x7f49a8004e80, stages=0x3d3a5a0) at clutter-master-clock-default.c:437 #25 clutter_clock_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at clutter-master-clock-default.c:561 #26 0x00007f49cbd32a8a in g_main_dispatch (context=0x2593610) at gmain.c:3122 #27 g_main_context_dispatch (context=context@entry=0x2593610) at gmain.c:3737 #28 0x00007f49cbd32e20 in g_main_context_iterate (context=0x2593610, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3808 #29 0x00007f49cbd33142 in g_main_loop_run (loop=0x2764320) at gmain.c:4002 #30 0x00007f49cf87f766 in meta_run () at core/main.c:437 #31 0x00000000004023fd in main (argc=1, argv=0x7ffd21334398) at main.c:462 Depending on the operations in this render, gnome-shell may or may not segfault. 3) The user X server is intended to take over and grabs master. Now it 2) If we were to allow this, we'd also allow a malicious unprivileged process to become drm master, authenticate itself, drop master and then sit around opening other processes and users exported buffer objects through drm_gem_open(), which is a bad security hole. /Thomas
Problem persists with VMware Workstation Pro 12 (12.0.0 build-2985596) and a fresh install of Fedora 23.
Created attachment 1067691 [details] Rework device initialization. Prerequisite for the next patch
Created attachment 1067692 [details] Allow render node functionality for dropped masters This patch is the patch that actually works around the problem. Will be sent to dri-devel for inclusion in 4.3.
OK, so I've added two patches that together appears to work around the problem on my side. The first one is already queued in drm-next for linux 4.3. It's needed to block render-node buffers from entering VRAM when the master is gone, as buffers in VRAM may accidently get cleared by the device. The second one will be posted on dri-devel shortly, and is the one that enables render-node functionality for dropped masters. Owen, could you help reassigning so that these patches actually make it to the fedora kernel team? Thanks, Thomas
(In reply to Thomas Hellström from comment #24) > OK, so I've added two patches that together appears to work around the > problem on my side. > > The first one is already queued in drm-next for linux 4.3. It's needed to > block render-node buffers from entering VRAM when the master is gone, as > buffers in VRAM may accidently get cleared by the device. > > The second one will be posted on dri-devel shortly, and is the one that > enables render-node functionality for dropped masters. > > Owen, could you help reassigning so that these patches actually make it to > the fedora kernel team? Thanks Thomas! I can probably get these applied later today. I do wonder if/how you plan to fix this in the upstream stable kernels though. The second patch that works around the problem relies on the first, but that first patch seems unsuitable for stable. josh
Hi Josh. First a quick update, there is a forgotten return statement in patch #2, I'll send a v2 later today. For the first patch, as you say I'm not sure we'll get it into stable. Perhaps I'll test it more extensively with 4.1.y and see if I can get it into that tree. Thomas
Created attachment 1067837 [details] New version of the patch to enable render functionality for dropped masters A forgotten return statement was fixed.
OK, both added to all Fedora branches. If something changes based on upstream feedback, please let us know.
Good to see that is progress is being made. Does "added to all Fedora branches" mean that updated packages with the fix(es) will be released soon?
kernel-4.2.0-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-14782
kernel-4.2.0-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14782
kernel-4.2.0-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1260157 has been marked as a duplicate of this bug. ***
kernel-4.1.6-201.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15130
Just tried latest F23 and looks good, no crashes. Thanks Thomas, much appreciated!
kernel-4.1.6-201.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15130
kernel-4.1.6-201.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
kernel-4.1.7-100.fc21 has been submitted as an update to Fedora 21. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15933
kernel-4.1.7-100.fc21 has been pushed to the Fedora 21 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15933
kernel-4.1.7-100.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.