similar to: [REGRESSION] GM20B probe fails after commit 2541626cfb79

On Thu, Dec 29, 2022 at 12:58 AM Diogo Ivo <diogo.ivo at tecnico.ulisboa.pt> wrote: > > Hello, > > Commit 2541626cfb79 breaks GM20B probe with > the following kernel log: > > [ 2.153892] ------------[ cut here ]------------ > [ 2.153897] WARNING: CPU: 1 PID: 36 at drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c:273 gf100_vmm_valid+0x2c4/0x390 > [

Hello, 5.1.0-next-20190517 I'm looking at quite a lot of kmemleak reports coming from drm/nouveau/core/memory, all of which are: unreferenced object 0xffff8deec27c4ac0 (size 16): comm "Web Content", pid 5309, jiffies 4309675011 (age 68.076s) hex dump (first 16 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace:

On Fri, 20 Jan 2023 at 21:37, Diogo Ivo <diogo.ivo at tecnico.ulisboa.pt> wrote: > > On Wed, Jan 18, 2023 at 11:28:49AM +1000, Ben Skeggs wrote: > > On Mon, 16 Jan 2023 at 22:27, Diogo Ivo <diogo.ivo at tecnico.ulisboa.pt> wrote: > > > On Mon, Jan 16, 2023 at 07:45:05AM +1000, David Airlie wrote: > > > > As a quick check can you try changing > >

From: Thierry Reding <treding at nvidia.com> Hi Ben, these are a couple of patches that are in preparation for adding GV11B support. The fundamental issue that these are trying to solve is that the GV11B is the first Tegra incarnation of the GPU where the aperture really matters. All prior generations would accept any of them. For dGPUs we usually allocate memory in VRAM, so the default

Turing introduced a new simplified page kind scheme, reducing the number of possible page kinds from 256 to 16. It also is the first NVIDIA GPU in which the highest possible page kind value is not reserved as an "invalid" page kind. To address this, the invalid page kind is made an explicit property of the MMU HAL, and a new table of page kinds is added to the tu102 MMU HAL. One

On Fri, 27 Jan 2023 at 20:42, Diogo Ivo <diogo.ivo at tecnico.ulisboa.pt> wrote: > > On Fri, Jan 27, 2023 at 04:00:59PM +1000, Ben Skeggs wrote: > > On Fri, 20 Jan 2023 at 21:37, Diogo Ivo <diogo.ivo at tecnico.ulisboa.pt> wrote: > > > > > > On Wed, Jan 18, 2023 at 11:28:49AM +1000, Ben Skeggs wrote: > > > > On Mon, 16 Jan 2023 at 22:27, Diogo

On Tue, May 05, 2020 at 03:00:04PM +0530, Bharat Bhushan wrote: > Different endpoint can support different page size, probe > endpoint if it supports specific page size otherwise use > global page sizes. > > Signed-off-by: Bharat Bhushan <bbhushan2 at marvell.com> > --- > v4->v5: > - Rebase to Linux v5.7-rc4 > > v3->v4: > - Fix whitespace error >

On (05/17/19 15:13), Sergey Senozhatsky wrote: > 5.1.0-next-20190517 > > I'm looking at quite a lot of kmemleak reports coming from > drm/nouveau/core/memory, all of which are: > > unreferenced object 0xffff8deec27c4ac0 (size 16): > comm "Web Content", pid 5309, jiffies 4309675011 (age 68.076s) > hex dump (first 16 bytes): > 00 00

From: Thierry Reding <treding at nvidia.com> Hi, the GPU on Jetson TX2 (GP10B) does not work properly on all devices. Why exactly is not clear, but there are slight differences between the SKUs that were tested. It turns out that the biggest issue is that on some devices (e.g. the one that I have), pulsing the GPU reset twice as is done in the current code (once as part of the power-ungate

On Thu, Nov 29, 2018 at 03:23:59AM -0800, kernelci.org bot wrote: Today's -next crashes on Jetson TK1 when the Nouveau module is loaded if it can't find firmware: [ 7.617291] nouveau 57000000.gpu: Linked as a consumer to regulator.33 [ 7.624037] nouveau 57000000.gpu: NVIDIA GK20A (0ea000a1) [ 7.629880] nouveau 57000000.gpu: imem: using IOMMU [ 7.635013] nouveau 57000000.gpu:

I see the following on a Jetson TK1: [ 9.495425] [TTM] Initializing DMA pool allocator [ 9.495513] nouveau 57000000.gpu: DRM: VRAM: 0 MiB [ 9.495520] nouveau 57000000.gpu: DRM: GART: 1048576 MiB [ 9.508076] nouveau 57000000.gpu: DRM: failed to create ce channel, -22 A Google search suggests that I'm not the only one with this, but I don't see it being discussed anywhere. Is

Hi Thierry et al. I noticed that since commit 3dde5a2342cd ("ARM: tegra: Add VIC on Tegra124") graphics on Apalis TK1 is broken. During boot it fails loading the vic firmware: [ 1.595824] tegra-vic 54340000.vic: Direct firmware load for nvidia/tegra124/vic03_ucode.bin failed with error -2 [ 1.606140] tegra-vic: probe of 54340000.vic failed with error -2 Subsequently Tegra HDMI

On Mon, Dec 10, 2018 at 11:21:47AM +0100, Thierry Reding wrote: > On Sat, Dec 08, 2018 at 02:54:45PM +0000, Marcel Ziswiler wrote: > > Hi Thierry et al. > > > > I noticed that since commit 3dde5a2342cd ("ARM: tegra: Add VIC on > > Tegra124") graphics on Apalis TK1 is broken. During boot it fails > > loading the vic firmware: > > > > [

Hi, Can anybody advise me how to debug this crash? it happens when I try to start a 32 bit kernel on my 64 bit Xen system, the kernel is my own using opensuse 11.1 rc1 2.6.27.7 xen patches, the kernel works as 32 and 64 bit dom0, and as 64 bit domU PV, is there a technique to find out where in the kernel source the crash happens? i.e what line in the source code? (XEN) mm.c:707:d49 Error getting

Hi, Trying to get pv_ops working with 2.6.28.4, this is what I get on an Intel Xeon CPU. Works fine on AMD Opteron... (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: Errors and warnings (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times to switch input

Hi Arnd, Sorry for sending this email directly to you, but maybe you can help me, or guide me where to look for. I am having big trouble getting the nouveau driver to work with either Geforce GT 710 or Geforce 9800 GT on an ARM armv7l Cortex-A9 with PCIe x1/x4 with linux kernel 4.15-rc. The Geforce GT 710 hangs the kernel boot process for a while and then a kernel oops occurs, due to nvidiafb,

Xen: 3.2.1-rc5 64bit Dom0: 2.6.18.8 (at cs 524) 32-pae DomU: 2.6.26-rc8 32-pae root at newark13:~# xm create -f /linodes/xencaker/xen.conf -c Using config file "/linodes/xencaker/xen.conf". Started domain xencaker root at newark13:~# root at newark13:~# xm dmesg ... (XEN) traps.c:413:d332 Unhandled invalid opcode fault/trap [#6] on VCPU 0 [ec=0000] (XEN)

Hi, we''re using Xen 3.3.0 on Debian Etch with 2.6.18.8 kernel from xen.org on dom0. We have problems starting Intrepid domU (using Intrepid''s kernel 2.6.27-7-server) if we give more than 4GB of memory to this domain. Using memory = ''4096'' works perfectly, but changing it to ''4097'' already gives an error. Can anyone put some light on this?

Can''t seem to fully boot a domU on either EM64T or Opteron with x86_64 xen-unstable. Both systems'' report this from xen: (XEN) (file=traps.c, line=872) Non-priv domain attempted WRMSR(00000000c0000100. (XEN) (file=traps.c, line=872) Non-priv domain attempted WRMSR(00000000c0000102. (XEN) (file=traps.c, line=880) Non-priv domain attempted RDMSR(00000000c0000080. They boot

Hi, With 3.13-rc1 and 3.13-rc2 kernel crashes/BUGs while loading nouveau: [ 657.654915] ACPI Warning: \_SB_.PCI0.IXVE.IGPU._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20131115/nsarguments-95) [ 657.655099] ACPI Warning: \_SB_.PCI0.IXVE.IGPU._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20131115/nsarguments-95) [ 657.655270] checking