[qubes-users] nVidia binary in dom0 (ThinkPad P1 gen4)
Hey all,
I am trying to get the nVidia binary driver to work in dom0. Using the latest
version of it (510.60.02) always ends up with this line in `Xorg.0.log`,
followed by X crashing:
> Failed to allocate push buffer
Running `nvidia-smi` shows the card is available, kernel modules loaded; I can
get temperature readouts, for example.
Tried changing UEFI settings ("discrete" vs "hybrid" mode), tried fiddling with
kernel parameters (modesetting, iommu), to no avail.
Not sure what I could try next. Any ideas welcome!
--
Best,
rysiek
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/2097878.irdbgypaU6%40mail-personal.
Re: [qubes-users] Qubes 4.1 & ThinkPad P15 Gen 2 (type 20YQ): Help in Remedying Reduced Functionality?
Hey, On Thursday, 24 March 2022 12:39:27 GMT 'Johannes Graumann' via qubes-users wrote: > > On 24.03.2022 12:16 'Johannes Graumann' via qubes-users > > wrote: ... > > As the laptop's HDMI port also does not work (likely due to being > > hardwired to the NVDIA card), I currently have no means of setting up > > multiple screens. > > > > I want to use Qubes and this machine as my daily driver and non > > functioning dock as well as the lack of a multiple screen options are > > show stoppers for this. The latter is possibly fixable through NVIDIA > > support in `dom0` and that's what I'm working on next, but I would highly > > appreciate any hint on how to get the dock working. > Installing `kernel-latest` in `dom0` (which currently brings in 5.16) and > setting graphics to `discrete` in the BIOS renders the on board HDMI port > active. `Hybrid` graphics settings results in a black screen when the > display manager comes up. Interesting. I am on a P1 gen4 with a nVidia card (so, a similar hardware config), and I simply cannot get any X when using the "discrete" UEFI setting. In "hybrid" mode, initially `kernel-latest` here also meant no X. Only after creating an `xorg.conf` file and *explicitly* setting "modesetting" driver for the integrated card I got X to work with `kernel-latest`. X was working out of the box with the original kernel though in "hybrid" mode (I am guessing some timing changes leading to card initialization happening in different order or some such). HDMI ports refuse to work in X regardless of what I do. Tried the binary driver, tried nVidia modesetting, tried nouveau. Tried "hybrid", tried "discrete". To no avail. Best I got was the Qubes loading screen and FDE password prompt on the external monitor -- both in "hybrid" and "discrete", only with binary driver and nVidia modesetting. Enabling nVidia binary driver and configuring it in `xorg.conf` always ends in this line in `Xorg.0.conf`: > Failed to allocate push buffer What a mess! -- Best, rysiek -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2234076.ElGaqSPkdT%40mail-personal.
[qubes-users] Q: sys-firewall using "100% CPU" while updates are being installed
Hi! I have (by today's standards) just a slow DSL line to download updates. Still I see spikes where sys-firewall is at "100% CPU" (according to xentop),so I wonder what CPU-intensive task sys-firewall might perform. IMHO it cannot be packet filtering (the purpose of a firewall), because my line is so slow. Am I right? Regards, Ulrich -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7782b816-a27d-ec8d-6c5c-f7492d19bc60%40rz.uni-regensburg.de.
[qubes-users] 4.1: Still requiring "systemd.mask=lvm2-monitor"
Hi! I just wanted to point out that booting Qubes OS 4.1 still hangs with today's updates being applied to Dom0. I have to add "systemd.mask=lvm2-monitor". Regards, Ulrich -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e3c840a0-a90d-0247-e552-e0b1a1e3ca49%40rz.uni-regensburg.de.
[qubes-users] 4.1 qubes manager dumped core
Hi! I have saved the journal message about qubes manager dumping core in 4.1. As Thunderbird will ruin the formatting if I paste it here, I attached the message. The coredump happened when some software was updated in VMs. Regards, Ulrich -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e05b907f-c96f-3fd9-5c46-0b4581c300dc%40rz.uni-regensburg.de. --- Begin Message --- Apr 17 21:28:04 dom0 systemd-coredump[23831]: Process 18835 (qubes-qube-mana) of user 1000 dumped core. Stack trace of thread 22156: #0 0x76dd699b67d5 raise (libc.so.6 + 0x3c7d5) #1 0x76dd6999f895 abort (libc.so.6 + 0x25895) #2 0x76dd680b0a7f _ZNK14QMessageLogger5fatalEPKcz (libQt5Core.so.5 + 0x91a7f) #3 0x76dd685f7bf2 _Z15pyqt5_err_printv.cold (QtCore.so + 0xbdbf2) #4 0x76dd65ca5e47 sip_api_call_procedure_method (sip.so + 0xfe47) #5 0x76dd686fe416 _ZN10sipQThread3runEv (QtCore.so + 0x1c4416) #6 0x76dd680e5680 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xc6680) #7 0x76dd69626432 start_thread (libpthread.so.0 + 0x9432) #8 0x76dd69a7b6d3 __clone (libc.so.6 + 0x1016d3) Stack trace of thread 18840: #0 0x76dd6962ce92 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xfe92) #1 0x76dd607be20b util_queue_thread_func (radeonsi_dri.so + 0x49d20b) #2 0x76dd607bdccb impl_thrd_routine (radeonsi_dri.so + 0x49cccb) #3 0x76dd69626432 start_thread (libpthread.so.0 + 0x9432) #4 0x76dd69a7b6d3 __clone (libc.so.6 + 0x1016d3) Stack trace of thread 18842: #0 0x76dd6962ce92 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xfe92) #1 0x76dd607be20b util_queue_thread_func (radeonsi_dri.so + 0x49d20b) #2 0x76dd607bdccb impl_thrd_routine (radeonsi_dri.so + 0x49cccb) #3 0x76dd69626432 start_thread (libpthread.so.0 + 0x9432) #4 0x76dd69a7b6d3 __clone (libc.so.6 + 0x1016d3) Stack trace of thread 18845: #0 0x76dd6962ce92 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xfe92) #1 0x76dd607be20b util_queue_thread_func (radeonsi_dri.so + 0x49d20b) #2 0x76dd607bdccb impl_thrd_routine (radeonsi_dri.so + 0x49cccb) #3 0x76dd69626432 start_thread (libpthread.so.0 + 0x9432) #4 0x76dd69a7b6d3 __clone (libc.so.6 + 0x1016d3) Stack trace of thread 18847: #0 0x76dd6962ce92 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xfe92) #1 0x76dd607be20b util_queue_thread_func (radeonsi_dri.so + 0x49d20b) #2 0x76dd607bdccb impl_thrd_routine (radeonsi_dri.so + 0x49cccb) #3 0x76dd69626432 start_thread (libpthread.so.0 + 0x9432) #4 0x76dd69a7b6d3 __clone (libc.so.6 + 0x1016d3) Stack trace of thread 18836: #0 0x76dd69a7086f __poll (libc.so.6 + 0xf686f) #1 0x76dd6459c38a _xcb_conn_wait (libxcb.s
