similar to: [Bug 111242] New: Device driver tries to sync DMA memory it has not allocated

This doesn't look related. -James On 7/17/20 2:30 PM, Kirill A. Shutemov wrote: > On Fri, Jul 17, 2020 at 11:57:57AM -0700, James Jones wrote: >> Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() >> family of modifiers to handle broken userspace >> Xorg modesetting and Mesa drivers. >> >> Tested with Xorg 1.20 modesetting driver, >> weston at

Greetings, Box is an aging generic i4790 + GTX-980 desktop. [ 1143.133663] ============================= [ 1143.133666] [ BUG: Invalid wait context ] [ 1143.133671] 5.9.0.g34d4ddd-preempt #2 Tainted: G S E [ 1143.133675] ----------------------------- [ 1143.133678] X/2015 is trying to lock: [ 1143.133682] ffff8d3e9efd63d8 (&zone->lock){..-.}-{3:3}, at:

On Fri, Jul 17, 2020 at 11:57:57AM -0700, James Jones wrote: > Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() > family of modifiers to handle broken userspace > Xorg modesetting and Mesa drivers. > > Tested with Xorg 1.20 modesetting driver, > weston at c46c70dac84a4b3030cd05b380f9f410536690fc, > gnome & KDE wayland desktops from Ubuntu 18.04, > and sway 1.5 > >

https://bugs.freedesktop.org/show_bug.cgi?id=92032 Bug ID: 92032 Summary: WARNING: CPU: 0 PID: 290 at lib/dma-debug.c:1205 check_sync+0x169/0x6e0() Product: xorg Version: git Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: normal Priority: medium

https://bugs.freedesktop.org/show_bug.cgi?id=111843 Bug ID: 111843 Summary: Resume fails after suspend with nouveau and Gtx 1050 ti Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: not set Priority: not set Component: Driver/nouveau

(Apologies for any duplication, yesterday's e-mail doesn't seem to have made it through moderation) I've had several recent crashes of the nouveau kernel driver over the past month or so. My suspicion is that Firefox is causing it. The screen goes black and then the computer reboots. Nothing much in the syslogs, however I've managed to get netconsole output. I've also run

On 10.11.2015 17:25, Mario Kleiner wrote: > On 11/10/2015 05:00 PM, Thierry Reding wrote: >> On Tue, Nov 10, 2015 at 03:54:52PM +0100, Mario Kleiner wrote: >>> From: Daniel Vetter <daniel.vetter at ffwll.ch> >>> >>> Apparently pre-nv50 pageflip events happen before the actual vblank >>> period. Therefore that functionality got semi-disabled in

I've had several recent crashes of the nouveau kernel driver over the past month or so. My suspicion is that Firefox is causing it. The screen goes black and then the computer reboots. Nothing much in the syslogs, however I've managed to get netconsole output. It happens very infrequently and I'm afraid I don't know how to reproduce it, however I'll be more than happy to

On Wed, Nov 11, 2015 at 09:12:33PM +0100, poma wrote: > On 10.11.2015 17:25, Mario Kleiner wrote: > > On 11/10/2015 05:00 PM, Thierry Reding wrote: > >> On Tue, Nov 10, 2015 at 03:54:52PM +0100, Mario Kleiner wrote: > >>> From: Daniel Vetter <daniel.vetter at ffwll.ch> > >>> > >>> Apparently pre-nv50 pageflip events happen before the

On Wed, Nov 11, 2015 at 9:19 AM, Ben Skeggs <skeggsb at gmail.com> wrote: > On 11/09/2015 05:37 PM, Alexandre Courbot wrote: >> The LRU list used for recycling CPU mappings was handling concurrency >> very poorly. For instance, if an instobj was acquired twice before being >> released once, it would end up into the LRU list even though there is >> still a client

I applied the changes manually. This time, Xorg is actually starting... [ 16.862744] WARNING: CPU: 3 PID: 381 at drivers/gpu/drm/nouveau/nouveau_bo.c:280 nouveau_bo_new+0x450/0x4d0 [nouveau] [ 16.873333] Modules linked in: nouveau i2c_algo_bit ttm tegra_drm gpio_keys drm_kms_helper drm drm_panel_orientation_quirks(P) host1x dwmac_dwc_qos_eth stmmac_platform stmmac ptp pps_core syscopyarea

From: Emil Velikov <emil.velikov at collabora.com> The authentication can be circumvented, by design, by using the render node. >From the driver POV there is no distinction between primary and render nodes, thus we can drop the token. Note: the outstanding DRM_AUTH instance is: - legacy DRI1 ioctl, which is already neutered Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at

When I attach an external monitor to my new Dell Precision I always get this and the monitor refuses to recognize video input. If I persist it reaches a point where the machine will boot but won't bring up a login prompt. I have to ssh to get in. And worst of all, it persisted after I remove the external monitor and am forced to re-install CentOS (7.6.1810). Aug 02 14:19:42

On Mon, 27 May 2019 at 09:19, Emil Velikov <emil.l.velikov at gmail.com> wrote: > > From: Emil Velikov <emil.velikov at collabora.com> > > The authentication can be circumvented, by design, by using the render > node. > > From the driver POV there is no distinction between primary and render > nodes, thus we can drop the token. > > Note: the outstanding

Hello, I've noticed firefox got randomly stuck, and as sometimes that leads to a complete system lock-up, I've checked dmesg and got this: [Jan29 10:49] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes) [ +0.000033] swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152 [ +0.000004] CPU: 6 PID: 1023 Comm: Xorg Not tainted 4.15.0-rc8 #1 [ +0.000003]

On Wed, Jan 31, 2018 at 9:20 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > Yeah, a lot of people were getting that, as a result of some drm/ttm > hugepage usage. > > Christian, did a fix ever end up going out? If so, what kernel was it > included in? https://lkml.org/lkml/2018/1/16/106 Alex > > -ilia > > On Wed, Jan 31, 2018 at 11:05 AM, Ricardo Nabinger

Yeah, a lot of people were getting that, as a result of some drm/ttm hugepage usage. Christian, did a fix ever end up going out? If so, what kernel was it included in? -ilia On Wed, Jan 31, 2018 at 11:05 AM, Ricardo Nabinger Sanchez <rnsanchez at gmail.com> wrote: > Hello, > > I've noticed firefox got randomly stuck, and as sometimes that leads to a > complete system

https://bugs.freedesktop.org/show_bug.cgi?id=105173 --- Comment #8 from Nick Lee <nvlbox at gmail.com> --- Also tried: Vanilla kernel 4.15.4-300.vanilla.knurd.1.fc27.x86_64 mesa-17.3.5 wayland session reproducible Fedora-Workstation-Live-x86_64-Rawhide-20180220.n.0.iso wayland session mesa-18.0.0-0.1.rc4.fc28.x86_64 Got artefacts with dmesg output: [ 1035.437016] nouveau 0000:03:00.0:

https://bugs.freedesktop.org/show_bug.cgi?id=105173 --- Comment #10 from Pierre Moreau <pierre.morrow at free.fr> --- (In reply to Nick Lee from comment #8) > Also tried: > > Vanilla kernel 4.15.4-300.vanilla.knurd.1.fc27.x86_64 > mesa-17.3.5 > wayland session > reproducible What exactly is reproducible? The artefacts I would assume, but which error exactly? The NULL

Hi Guys, i have a problem with PXE/UEFI Boot. Legacy PXE Boot is working fine. I use Dnsmasq with integrated tftp. As Mentioned above, legacy pxe boot is working fine, tcpdump shows: --- start tcpdump legacy pxe boot --- 13:44:16.589197 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from f8:ca:b8:06:7d:ed (oui Unknown), length 548 13:44:20.543910 IP 0.0.0.0.bootpc >