similar to: Firmware required?

For chdir03 investigation result: The fail is caused by the mkdir fail after setreuid. Key code in the test case: if ((pid =3D fork()) < 0) { tst_brkm(TBROK, cleanup, "first fork failed"); } if (pid =3D=3D 0) { /* first child */ /* set the child's ID to ltpuser1 */ if (setreuid(ltpuser1->pw_uid,

Beyond general review, I'm looking for feedback on a few things specifically here: -Is the level of backwards compatibility described here sufficient? Technically I can make the user space drivers support the old modifiers too, but that would mean the layout they specify would morph based on the GPU they're being used on, and sharing buffers between two different NV GPUs, which would

On Mon, Oct 14, 2019 at 03:13:21PM -0700, James Jones wrote: > Builds upon the existing NVIDIA 16Bx2 block linear > format modifiers by adding more "fields" to the > existing parameterized > DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifier > macro that allow fully defining a unique-across- > all-NVIDIA-hardware bit layout using a minimal > set of fields and values.

On Tue, Oct 15, 2019 at 5:14 PM James Jones <jajones at nvidia.com> wrote: > > On 10/15/19 7:19 AM, Daniel Vetter wrote: > > On Mon, Oct 14, 2019 at 03:13:21PM -0700, James Jones wrote: > >> Builds upon the existing NVIDIA 16Bx2 block linear > >> format modifiers by adding more "fields" to the > >> existing parameterized > >>

mainly question for the intel folks, any chance to rerun the ltp testsuites to see how we are doing these days with all the changes ? thanks :) Wim

With this we try to detect if the endianess switch works and assume LE if not. Suggested by Ben. Fixes: 51c05340e407 ("drm/nouveau/device: detect if changing endianness failed") --- .../gpu/drm/nouveau/nvkm/engine/device/base.c | 39 ++++++++++++------- 1 file changed, 26 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c

Hi all, LLVM needs a solution to the long-standing problem that the IR is unable to express certain semantics expected by high-level programming languages that target GPUs. Solving this issue is necessary both for upstream use of LLVM as a compiler backend for GPUs and for correctly supporting LLVM IR <-> SPIR-V roundtrip translation. It may also be useful for compilers targeting

From: Thierry Reding <treding at nvidia.com> Hi Ben, I messed up the ordering of patches in my tree a bit, so these two fixes got separated from the others. I don't consider these particularily urgent because the crash that the first one fixes only happens on gp10b which we don't enable by default yet and the second patch fixes a crash that only happens on module unload (or driver

Hello, all. A while back I posted a question about an issue, but did not get any replies. I understand this might not be something anybody has a definite answer for, and I understand I may not be offering the right information. If that is the case, please let me know what information I can provide, and please don't hesitate to offer any suggestions about what could be causing this problem.

Other gpu drivers have some driver-specific documentation, so it would nice if nouveau did as well. This adds a bare-bones ReStructured Text document with sections for module parameter documentation, an overview of the driver architecture, a section for internal API documentation, and a glossary for nouveau-specific terms. To make the document a little less bare, I've included docblocks for

On Tue, 2015-06-16 at 15:47 -0400, Ilia Mirkin wrote: > On Tue, Jun 16, 2015 at 3:33 PM, Stephen Adler < > adler at stephenadler.com> wrote: > > Guys, > > > > Is there support for display port 1.2 with the nouveau driver and > > GTX > > 970? > > > > I have a dell 4K monitor and to run it in 4K mode at 60Hz I need to > > configure the

On 1/5/20 5:30 PM, Ben Skeggs wrote: > On Tue, 17 Dec 2019 at 10:44, James Jones <jajones at nvidia.com> wrote: >> >> This series modifies the NV5x+ nouveau display backends to advertise >> appropriate format modifiers on their display planes in atomic mode >> setting blobs. >> >> Corresponding modifications to Mesa/userspace are available here:

Hi Kris, lsof (http://freshmeat.net/projects/lsof/) available with most distributions might be your friend: > About: > Lsof is a Unix-specific diagnostic tool. Its name stands for LiSt Open > Files, and it does just that. It lists information about any files that > are open by processes currently running on the system. It can also list > communications open by each process. Using

--- src/nv_driver.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/nv_driver.c b/src/nv_driver.c index e726292..4c40763 100644 --- a/src/nv_driver.c +++ b/src/nv_driver.c @@ -377,6 +377,7 @@ NVHasKMS(struct pci_device *pci_dev, struct xf86_platform_device *platform_dev) case 0xf0: case 0x100: case 0x110: + case 0x120: break; default: xf86DrvMsg(-1, X_ERROR, "Unknown

Hi With Kernel 5.7 I am still getting this, while booting: ~> uname -a Linux zenogentoo 5.7.0 #80 SMP Thu Jun 4 16:10:03 CEST 2020 x86_64 Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz GenuineIntel GNU/Linux ~> dmesg |grep nouveau [ 0.762872] nouveau 0000:05:00.0: NVIDIA GP107 (137000a1) [ 0.875311] nouveau 0000:05:00.0: bios: version 86.07.42.00.4a [ 0.875681] nouveau 0000:05:00.0: acr:

Thanks for the update. Are you updating nouveau for GK208 and GM206? Regards, On Tue, Feb 23, 2016 at 4:11 PM, Kyle McMartin <kyle at infradead.org> wrote: > On Tue, Feb 23, 2016 at 06:55:59PM +0900, Alexandre Courbot wrote: > > Hi linux-firmware maintainers, > > > > The following changes since commit > f66eccaab7d605d433cb82e389441b21ec99b40f: > > > >

Hello, I''ve successfully passed a unmodified GTX 760 to Win7 x64. It involved some driver patching on the client side but I''m close to getting the required steps on the server side, too. Are there any legal issues that might arise from releasing a patch? Bob [image: Inline image 1] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org

On Tue, Dec 10, 2019 at 8:58 PM Dave Airlie <airlied at gmail.com> wrote: > > On Mon, 9 Dec 2019 at 21:39, Rafael J. Wysocki <rafael at kernel.org> wrote: > > > > On Mon, Dec 9, 2019 at 12:17 PM Karol Herbst <kherbst at redhat.com> wrote: > > > > > > anybody any other ideas? > > > > Not yet, but I'm trying to collect some more

Hi linux-firmware maintainers, The following changes since commit f66eccaab7d605d433cb82e389441b21ec99b40f: Update Intel OPA hfi1 firmware (2016-02-15 08:34:16 -0500) are available in the git repository at: https://github.com/Gnurou/linux-firmware.git secboot for you to fetch changes up to 8d1fd61a3723ab8cb6b7bfeb8be38e16282cc1ed: nvidia: Add GM20B signed firmware (2016-02-23

Hello, Various HDMI versions enable higher and higher pixel clocks. However individual GPUs are not required to support the maximum pixel clock supported by the spec in order to be compliant. It appears that some GPUs max out at 225MHz while others at 297MHz (while others still, I assume, are limited to 165MHz, esp among the older ones). We've been unable to find this in the VBIOS (I had a