similar to: problems with NVS310

The warning you included happens when we're trying to execute a VBIOS script as part of DP training. Can you include your vbios? It should be available at /sys/kernel/debug/dri/0/vbios.rom Also, can you confirm how your monitors are connected to the card (and e.g. what resolution they are, anything else "funny" about them)? Finally, this warning might not have anything to do with

I have two monitors connected to the PC. One is an AOC 23" (1920 x 1080) and the other is a BenQ 27" (2560 x 1440). Nothing special about them. BenQ has a display port and the AOC uses some sort of DVI adapter. I have this event many times and I captured dmesg twice. At least at one time I captured dmesg my computer was under high load: it had about 15 to 20 windows opened

Fixes broken dp on GF119: Call Trace: ? nvkm_dp_train_drive+0x183/0x2c0 [nouveau] nvkm_dp_acquire+0x4f3/0xcd0 [nouveau] nv50_disp_super_2_2+0x5d/0x470 [nouveau] ? nvkm_devinit_pll_set+0xf/0x20 [nouveau] gf119_disp_super+0x19c/0x2f0 [nouveau] process_one_work+0x193/0x3c0 worker_thread+0x35/0x3b0 kthread+0x125/0x140 ? process_one_work+0x3c0/0x3c0 ?

https://bugs.freedesktop.org/show_bug.cgi?id=103421 Bug ID: 103421 Summary: Kernel 4.13+ nouveau breaks screen output Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

https://bugs.freedesktop.org/show_bug.cgi?id=107069 Bug ID: 107069 Summary: trace in kernel.log on boot Product: xorg Version: 7.7 (2012.06) Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

On 5/16/19 10:35 PM, Pankaj Gupta wrote: > Can I take it your reviewed/acked-by? or tested-by tag? for the virtio patch :)I don't feel that I have enough expertise to give the reviewed-by tag, but you can take my acked-by + tested-by. Acked-by: Jakub Staron <jstaron at google.com> Tested-by: Jakub Staron <jstaron at google.com> No kernel panics/stalls encountered during

On 5/16/19 10:35 PM, Pankaj Gupta wrote: > Can I take it your reviewed/acked-by? or tested-by tag? for the virtio patch :)I don't feel that I have enough expertise to give the reviewed-by tag, but you can take my acked-by + tested-by. Acked-by: Jakub Staron <jstaron at google.com> Tested-by: Jakub Staron <jstaron at google.com> No kernel panics/stalls encountered during

On 21.03.19 18:12, Jerome Glisse wrote: > On Thu, Mar 21, 2019 at 04:59:14PM +0100, Tobias Klausmann wrote: >> Hi, >> >> just for your information and maybe for some help: with 5.1rc1 and SVM >> enabled i see the following backtrace [1] when the nouveau card (reverse >> prime) goes to sleep, for now i have papered over with [2] which leaves me >> with

On Tue, 6 Aug 2019 21:00:10 +0300 From: Jaak Ristioja <jaak at ristioja.ee> > Hello! > > I'm writing to report a crash in the QXL / DRM code in the Linux kernel. > I originally filed the issue on LaunchPad and more details can be found > there, although I doubt whether these details are useful. > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1813620

On Tue, 6 Aug 2019 21:00:10 +0300 From: Jaak Ristioja <jaak at ristioja.ee> > Hello! > > I'm writing to report a crash in the QXL / DRM code in the Linux kernel. > I originally filed the issue on LaunchPad and more details can be found > there, although I doubt whether these details are useful. > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1813620

https://bugs.freedesktop.org/show_bug.cgi?id=103351 Bug ID: 103351 Summary: Nouveau fails when booting with a screen connected to displayport since 13a86519202c5d119d83640d6f781f3181205d2c Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

On Tue, May 5, 2020 at 11:02 AM Alberto Sentieri <22t at tripolho.com> wrote: > > I have two monitors connected to the PC. One is an AOC 23" (1920 x 1080) > and the other is a BenQ 27" (2560 x 1440). Nothing special about them. > BenQ has a display port and the AOC uses some sort of DVI adapter. Do you know if the DVI adapter is active or passive? (If you include the

I guess the DVI adapter is passive. $ xrandr --props Screen 0: minimum 320 x 200, current 4480 x 1440, maximum 8192 x 8192 XWAYLAND1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 510mm x 290mm ??? non-desktop: 0 ??? ??? supported: 0, 1 ?? 1920x1080???? 59.96*+ XWAYLAND4 connected 2560x1440+1920+0 (normal left inverted right x axis y axis) 600mm x 340mm ??? non-desktop:

Hi, just for your information and maybe for some help: with 5.1rc1 and SVM enabled i see the following backtrace [1] when the nouveau card (reverse prime) goes to sleep, for now i have papered over with [2] which leaves me with userspace hangs. Any pointers where to look for the actual culprit? PS: Card is: nouveau 0000:01:00.0: NVIDIA GP106 (136000a1) Greetings, Tobias [1]: BUG: unable

This fixes the extra issues I discovered upstream after the introduction of my rework of the atomic VCPI helpers that occur during suspend/resume. This time around, we use a slightly different but much less complicated approach for fixing said issues. Cc: Daniel Vetter <daniel at ffwll.ch> Lyude Paul (4): drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()

This fixes the extra issues I discovered upstream after the introduction of my rework of the atomic VCPI helpers that occur during suspend/resume. This time around, we use a slightly different but much less complicated approach for fixing said issues. Cc: Daniel Vetter <daniel at ffwll.ch> Lyude Paul (4): drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()

On 5/14/19 7:54 AM, Pankaj Gupta wrote: > + if (!list_empty(&vpmem->req_list)) { > + req_buf = list_first_entry(&vpmem->req_list, > + struct virtio_pmem_request, list); > + req_buf->wq_buf_avail = true; > + wake_up(&req_buf->wq_buf); > + list_del(&req_buf->list); Yes, this change is the right one, thank you! > + /* > + * If

On 5/14/19 7:54 AM, Pankaj Gupta wrote: > + if (!list_empty(&vpmem->req_list)) { > + req_buf = list_first_entry(&vpmem->req_list, > + struct virtio_pmem_request, list); > + req_buf->wq_buf_avail = true; > + wake_up(&req_buf->wq_buf); > + list_del(&req_buf->list); Yes, this change is the right one, thank you! > + /* > + * If

Hi all, I am trying to compare the performance of gcc , llvm-gcc , clang and lli(with JIT) on x86. i have attached the performance comparision spreadsheet as well as the source which i used for performing these test. i ran this code for 10000 iterations and the time of execution is as follows for -O3 results refer attachment. *clang (-O0) * real 0m10.247s user 0m2.644s sys 0m5.949s

Previous to commit 22b5c0b63f32 ("vsock/virtio: fix kernel panic after device hot-unplug"), vsock_core_init() was called from virtio_vsock_probe(). Now, virtio_transport_reset_no_sock() can be called before vsock_core_init() has the chance to run. [Wed Feb 27 14:17:09 2019] BUG: unable to handle kernel NULL pointer dereference at 0000000000000110 [Wed Feb 27 14:17:09 2019] #PF error: