[Nouveau] [Bug 105173] [MCP79][Regression] Unhandled NULL pointer dereference in nvkm_object_unmap since kernel 4.15
https://bugs.freedesktop.org/show_bug.cgi?id=105173 --- Comment #15 from Nick Lee--- today I got that (without OOM Error): [ 1868.631494] nouveau :03:00.0: gr: magic set 0: [ 1868.631502] nouveau :03:00.0: gr:00408604: 98084805 [ 1868.631507] nouveau :03:00.0: gr:00408608: 00383d66 [ 1868.631511] nouveau :03:00.0: gr:0040860c: 4430 [ 1868.631515] nouveau :03:00.0: gr:00408610: 3bd2 [ 1868.631520] nouveau :03:00.0: gr: TRAP_TEXTURE - TP0: 0009 [ LINEAR_MISMATCH] [ 1868.631527] nouveau :03:00.0: gr: 0020 [] ch 24 [000db13000 Xwayland[2070]] subc 3 class 8397 mthd 0f04 data I don't know when moment it happened and how to reproduce. Graphics system works without issues (without artefacts etc) The same I got earlier on kernels < 4.15. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] TLD instruction usage in non-linked sampler mode
Hello, This question is in the context of Tesla / Fermi generations, which have explicit bindings for textures / samplers. It might also apply to Kepler+, not quite as sure due to the bindless nature. I've been trying to understand how the TLD operation works (which is used to implement texelFetch in GLSL). It does not appear to the op takes an explicit sampler id at all (unlike all the other texturing operations). In unlinked TSC mode (i.e. method 0x1234 == 0), my observation is that it desperately wants for a valid sampler to be bound to sampler slot 0. Of course I don't think TLD actually needs anything from the sampler, which makes this all the more odd. Is that a correct assessment of the operation of the TLD instruction? Is there any way to make it just not care about the sampler binding? Does the DirectX driver just always keep something bound to sampler slot 0? (And what happens on Kepler+? Does it always look at TSC ID == 0?) (I kind of assume that all these problems go away in linked TSC mode, since it'd naturally just look up the TSC entry associated with the bound TIC.) Thanks, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 105319] DRM: EVO timeout with kernel 4.15.x
https://bugs.freedesktop.org/show_bug.cgi?id=105319 --- Comment #7 from Sérgio M. Basto--- Sorry for my English , you may anything if you don't understand what I wrote: I just tried jump over and boot with kernel 4.16-rc3, which also don't boot One new : kernel 4.16-rc3 and 4.15.6 boots well if I add nouveau.modeset=0 kernel-4.15-git3 and kernel-4.15-git6 doesn't boot or hang even with nouveau.modeset=0 but maybe it is unrelated -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 105319] DRM: EVO timeout with kernel 4.15.x
https://bugs.freedesktop.org/show_bug.cgi?id=105319 --- Comment #6 from Sérgio M. Basto--- I tried just over and boot with kernel 4.16-rc3 [1], which also don't boot -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 105319] DRM: EVO timeout with kernel 4.15.x
https://bugs.freedesktop.org/show_bug.cgi?id=105319 --- Comment #5 from Sérgio M. Basto--- (In reply to Ilia Mirkin from comment #4) > (In reply to Sérgio M. Basto from comment #3) > > 01:00.0 VGA compatible controller: NVIDIA Corporation G98M [GeForce 9300M > > GS] (rev a1) > > I meant more like what's connected to the card... screens and how they're > hooked up. sorry my previous comment was not a reply . I have one laptop from 2007 , 2009 or so, (dual core dual with a good nvidia at the time ) it boots, it write boot log in vesa mode as usual , when switch root and should load drm , it hangs ( when loading drm kernel module). About bisect kernel , before that I tried just over and boot with kernel 4.1-rc3 [1], which also don't boot . I may try boot with kernel-4.15.0-0.rc0.git3 [2] It is not impossible I try bisect the kernel , but I don't build a kernel for a long time . The thing is I'm not the only one with problems with nvidia /nouveau and kernel 4.15 . yeah also with nvidia drives it hangs . [1] https://fedoraproject.org/wiki/RawhideKernelNodebug [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=999713 -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 105319] DRM: EVO timeout with kernel 4.15.x
https://bugs.freedesktop.org/show_bug.cgi?id=105319 --- Comment #4 from Ilia Mirkin--- (In reply to Sérgio M. Basto from comment #3) > 01:00.0 VGA compatible controller: NVIDIA Corporation G98M [GeForce 9300M > GS] (rev a1) I meant more like what's connected to the card... screens and how they're hooked up. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 105319] DRM: EVO timeout with kernel 4.15.x
https://bugs.freedesktop.org/show_bug.cgi?id=105319 --- Comment #3 from Sérgio M. Basto--- 01:00.0 VGA compatible controller: NVIDIA Corporation G98M [GeForce 9300M GS] (rev a1) -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 105319] DRM: EVO timeout with kernel 4.15.x
https://bugs.freedesktop.org/show_bug.cgi?id=105319 --- Comment #2 from Ilia Mirkin--- Can you say a few words about what's connected? Also, any chance you could bisect to the specific commit? -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 105319] DRM: EVO timeout with kernel 4.15.x
https://bugs.freedesktop.org/show_bug.cgi?id=105319 Sérgio M. Bastochanged: What|Removed |Added CC||ser...@serjux.com --- Comment #1 from Sérgio M. Basto --- boots fine with kernel 4.14.x -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 105319] New: DRM: EVO timeout with kernel 4.15.x
https://bugs.freedesktop.org/show_bug.cgi?id=105319 Bug ID: 105319 Summary: DRM: EVO timeout with kernel 4.15.x Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: ser...@serjux.com QA Contact: xorg-t...@lists.x.org booting with kernel 4.15.6 , Linux Fedora 27 mar 01 21:05:06 darkstart kernel: nouveau :01:00.0: NVIDIA G98 (298480a2) mar 01 21:05:06 darkstart kernel: nouveau :01:00.0: bios: version 62.98.2e.00.08 mar 01 21:05:06 darkstart kernel: nouveau :01:00.0: bios: M0203T not found mar 01 21:05:06 darkstart kernel: nouveau :01:00.0: bios: M0203E not matched! mar 01 21:05:06 darkstart kernel: nouveau :01:00.0: fb: 256 MiB DDR2 mar 01 21:05:06 darkstart kernel: nouveau :01:00.0: DRM: VRAM: 256 MiB mar 01 21:05:06 darkstart kernel: nouveau :01:00.0: DRM: GART: 1048576 MiB mar 01 21:05:06 darkstart kernel: nouveau :01:00.0: DRM: TMDS table version 2.0 mar 01 21:05:06 darkstart kernel: nouveau :01:00.0: DRM: DCB version 4.0 mar 01 21:05:06 darkstart kernel: nouveau :01:00.0: DRM: DCB outp 00: 01000323 00010034 mar 01 21:05:06 darkstart kernel: nouveau :01:00.0: DRM: DCB outp 01: 02011300 0028 mar 01 21:05:06 darkstart kernel: nouveau :01:00.0: DRM: DCB outp 02: 04032312 00020010 mar 01 21:05:06 darkstart kernel: nouveau :01:00.0: DRM: DCB conn 00: 0040 mar 01 21:05:06 darkstart kernel: nouveau :01:00.0: DRM: DCB conn 01: 0100 mar 01 21:05:06 darkstart kernel: nouveau :01:00.0: DRM: DCB conn 02: 1261 mar 01 21:05:06 darkstart kernel: nouveau :01:00.0: DRM: MM: using M2MF for buffer copies mar 01 21:05:06 darkstart kernel: nouveau :01:00.0: DRM: allocated 1280x800 fb: 0x5, bo 8139a319 mar 01 21:05:06 darkstart kernel: fbcon: nouveaufb (fb0) is primary device mar 01 21:05:19 darkstart kernel: nouveau :01:00.0: DRM: EVO timeout mar 01 21:05:19 darkstart kernel: nouveau :01:00.0: DRM: base-0: timeoutmar 01 21:05:19 darkstart kernel: nouveau :01:00.0: DRM: EVO timeout mar 01 21:05:19 darkstart kernel: nouveau :01:00.0: DRM: base-0: timeout mar 01 21:05:19 darkstart kernel: nouveau :01:00.0: DRM: base-0: timeout mar 01 21:05:19 darkstart kernel: nouveau :01:00.0: DRM: base-0: timeout mar 01 21:05:19 darkstart kernel: nouveau :01:00.0: DRM: base-0: timeout mar 01 21:05:19 darkstart kernel: nouveau :01:00.0: DRM: GPU lockup - switching to software fbcon mar 01 21:05:19 darkstart kernel: nouveau :01:00.0: DRM: base-0: timeout mar 01 21:05:19 darkstart kernel: nouveau :01:00.0: fb0: nouveaufb frame buffer device mar 01 21:05:19 darkstart kernel: [drm] Initialized nouveau 1.3.1 20120801 for :01:00.0 on minor 0 mar 01 21:05:21 darkstart kernel: nouveau :01:00.0: DRM: base-0: timeout mar 01 21:05:30 darkstart kernel: nouveau :01:00.0: DRM: EVO timeout -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 105173] [MCP79][Regression] Unhandled NULL pointer dereference in nvkm_object_unmap since kernel 4.15
https://bugs.freedesktop.org/show_bug.cgi?id=105173 --- Comment #14 from Nick Lee--- (In reply to Pierre Moreau from comment #13) > Created attachment 137730 [details] [review] > Proposed patch > Could you please try the attached patch (from > https://github.com/skeggsb/nouveau/pull/1)? It fixes the errors on my end at > least. Yes, it works! I applied the patch to kernel-4.16.0-0.rc3.git2.1. After launching supertuxkart i see only: [ 22.471837] fuse init (API version 7.26) [ 52.346467] nouveau :03:00.0: imem: OOM: 0010 1000 -28 [ 52.346516] nouveau :03:00.0: imem: OOM: 0010 1000 -28 [ 108.372556] perf: interrupt took too long (2530 > 2500), lowering kernel.perf_event_max_sample_rate to 79000 No artefacts. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 105174] [GF108][Regression] Unable to handle NULL pointer dereference in nouveau_mem_host since kernel 4.15.3
https://bugs.freedesktop.org/show_bug.cgi?id=105174 --- Comment #9 from Pierre Moreau--- Created attachment 137731 --> https://bugs.freedesktop.org/attachment.cgi?id=137731=edit Proposed patch Could anyone please try the attached patch (from https://github.com/skeggsb/nouveau/pull/1)? (In reply to D. Hugh Redelmeier from comment #7) > PS: why is the status NEEDSINFO? I don't see where there is an outstanding > request for info. I will try to change the status to NEW. Simply because no one changed the status since the information was provided. :-) -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 105173] [MCP79][Regression] Unhandled NULL pointer dereference in nvkm_object_unmap since kernel 4.15
https://bugs.freedesktop.org/show_bug.cgi?id=105173 --- Comment #13 from Pierre Moreau--- Created attachment 137730 --> https://bugs.freedesktop.org/attachment.cgi?id=137730=edit Proposed patch Okay, thank you for the confirmation. So, I am still failing to reproduce the NULL pointer dereference, but I can reproduce the other errors, so that’s a start. Could you please try the attached patch (from https://github.com/skeggsb/nouveau/pull/1)? It fixes the errors on my end at least. @Sergio You might want to give that patch a try as well. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 103721] [GM107] Frequent freezes with nouveau on Thinkpad P50
https://bugs.freedesktop.org/show_bug.cgi?id=103721 Marc Burkhardtchanged: What|Removed |Added Blocks||100567 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=100567 [Bug 100567] Nouveau system freeze fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 100567] Nouveau system freeze fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
https://bugs.freedesktop.org/show_bug.cgi?id=100567 Marc Burkhardtchanged: What|Removed |Added Depends on||103721 --- Comment #14 from Marc Burkhardt --- Hello there?!?! Just because of pure curiosity: is any developer interested in this or are the users left alone watching their machines freeze for almost 10 months now? Is there anything I (or any other user) could do to provide more info? Maybe apply a patch, send debug log, try this or that? It's really so sad to see absolutely no progress but more complaints for that long... Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=103721 [Bug 103721] [GM107] Frequent freezes with nouveau on Thinkpad P50 -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 105173] [MCP79][Regression] Unhandled NULL pointer dereference in nvkm_object_unmap since kernel 4.15
https://bugs.freedesktop.org/show_bug.cgi?id=105173 --- Comment #12 from Nick Lee--- > The NULL pointer dereference, or the “trapped read at 008000 on channel 1 > [0fbb DRM] engine 00 [PGRAPH] client 03 [DISPATCH] subclient 04 [M2M_IN] > reason 0006 [NULL_DMAOBJ]” one? "NULL pointer dereference" AND "trapped read" after launtching supertuxkart kernel-4.16.0-0.rc3.git2.1.vanilla.knurd.1.fc27.x86_64 mesa-17.3.6 wayland session [ 63.992917] nouveau :03:00.0: imem: OOM: 0004b000 -28 [ 63.992930] BUG: unable to handle kernel NULL pointer dereference at [ 63.993014] IP: nvkm_object_unmap+0x5/0x20 [nouveau] [ 63.993020] PGD 0 P4D 0 [ 63.993027] Oops: [#1] SMP PTI [ 63.993034] Modules linked in: fuse xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables snd_hda_codec_hdmi sunrpc xfs libcrc32c snd_hda_codec_realtek snd_hda_codec_generic coretemp snd_hda_intel snd_hda_codec wmi_bmof pcspkr snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer shpchp snd nv_tco soundcore i2c_nforce2 acpi_cpufreq binfmt_misc nouveau [ 63.993122] mxm_wmi i2c_algo_bit drm_kms_helper ttm drm serio_raw forcedeth video wmi [ 63.993144] CPU: 0 PID: 2867 Comm: supertuxkart Not tainted 4.16.0-0.rc3.git2.1.vanilla.knurd.1.fc27.x86_64 #1 [ 63.993153] Hardware name: NVIDIA MCP7A/MCP7A, BIOS 6.00 PG 04/22/2009 [ 63.993182] RIP: 0010:nvkm_object_unmap+0x5/0x20 [nouveau] [ 63.993188] RSP: 0018:ad338456fc98 EFLAGS: 00010282 [ 63.993194] RAX: c036d400 RBX: 94b4cdf513d8 RCX: 0018 [ 63.993201] RDX: c028a9e0 RSI: 94b4cdf513f8 RDI: [ 63.993207] RBP: 94b4cdf513c8 R08: 000250c0 R09: c0287ca3 [ 63.993213] R10: f9754294c340 R11: aa9440cd R12: 94b4cdf513f8 [ 63.993219] R13: 000ecba0cfdc R14: 94b55c8e7020 R15: 0020 [ 63.993226] FS: 7f77ac70d840() GS:94b56fc0() knlGS: [ 63.993233] CS: 0010 DS: ES: CR0: 80050033 [ 63.993238] CR2: CR3: 6d418000 CR4: 000406f0 [ 63.993244] Call Trace: [ 63.993276] nvkm_object_dtor+0x9a/0x160 [nouveau] [ 63.993304] nvkm_object_del+0x24/0xa0 [nouveau] [ 63.993331] nvkm_ioctl_new+0x260/0x2b0 [nouveau] [ 63.993371] ? nvkm_fifo_chan_dtor+0x100/0x100 [nouveau] [ 63.993398] ? nvkm_object_new_+0x60/0x60 [nouveau] [ 63.993425] nvkm_ioctl+0x10a/0x240 [nouveau] [ 63.993464] usif_ioctl+0x62e/0x740 [nouveau] [ 63.993504] nouveau_drm_ioctl+0xad/0xc0 [nouveau] [ 63.993514] do_vfs_ioctl+0xa4/0x620 [ 63.993521] SyS_ioctl+0x74/0x80 [ 63.993529] do_syscall_64+0x74/0x180 [ 63.993536] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 63.993543] RIP: 0033:0x7f77a89bf8e7 [ 63.993547] RSP: 002b:7ffc62fbfd28 EFLAGS: 0246 ORIG_RAX: 0010 [ 63.993554] RAX: ffda RBX: 0038 RCX: 7f77a89bf8e7 [ 63.993561] RDX: 55a3912a7d70 RSI: c0386447 RDI: 0007 [ 63.993566] RBP: 55a3912a7d70 R08: 55a39129f910 R09: 7f77a8a14708 [ 63.993572] R10: ff90 R11: 0246 R12: c0386447 [ 63.993579] R13: 0007 R14: 55a3912a7da8 R15: [ 63.993585] Code: ff c3 0f 1f 40 00 66 66 66 66 90 48 8b 07 48 8b 40 28 48 85 c0 74 05 e9 6a 8f 97 e9 b8 ed ff ff ff c3 0f 1f 40 00 66 66 66 66 90 <48> 8b 07 48 8b 40 30 48 85 c0 74 05 e9 4a 8f 97 e9 b8 ed ff ff [ 63.993651] RIP: nvkm_object_unmap+0x5/0x20 [nouveau] RSP: ad338456fc98 [ 63.993657] CR2: [ 63.997842] ---[ end trace a49568284ce09eb6 ]--- [ 79.659127] nouveau :03:00.0: imem: OOM: 0010 1000 -28 [ 79.659723] nouveau :03:00.0: gr: TRAP_M2MF 0002 [IN] [ 79.659729] nouveau :03:00.0: gr: TRAP_M2MF 00320951 206f1fc0 04000430 [ 79.659733] nouveau :03:00.0: gr: 0020 [] ch 1 [000fbb DRM] subc 4 class 5039 mthd 0100 data [ 79.659746] nouveau :03:00.0: fb: trapped read at 00206f on channel 1 [0fbb DRM] engine 00 [PGRAPH] client 03 [DISPATCH] subclient 04 [M2M_IN] reason 0002 [PAGE_NOT_PRESENT] -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] Fix colormap handling at screen depth 30.
NVLoadPalette is pretty hard-coded to 256. I haven't looked at what all xf86HandleColormaps does, but it seems pretty suspicious. Also note that the kernel currently only exposes a 256-sized LUT to userspace, even for 10bpc modes. On Thu, Mar 1, 2018 at 1:31 AM, Mario Kleinerwrote: > The various clut handling functions like a setup > consistent with the x-screen color depth. Otherwise > we observe improper sampling in the gamma tables > at depth 30. > > Tested at depths 16, 24 and 30 and tested at depths > 24 and 30 that xgamma and gamma table animations work, > and with measurement equipment to make sure identity > gamma ramps actually are identity mappings at the output. > > Signed-off-by: Mario Kleiner > --- > src/nv_driver.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/nv_driver.c b/src/nv_driver.c > index 32062eb..4fcd4c1 100644 > --- a/src/nv_driver.c > +++ b/src/nv_driver.c > @@ -1568,8 +1568,8 @@ NVScreenInit(SCREEN_INIT_ARGS_DECL) > * Must follow initialization of the default colormap > */ > if (xf86_config->num_crtc && > - !xf86HandleColormaps(pScreen, 256, 8, NVLoadPalette, > -NULL, CMAP_PALETTED_TRUECOLOR)) > + !xf86HandleColormaps(pScreen, 1 << pScrn->rgbBits, pScrn->rgbBits, > +NVLoadPalette, NULL, > CMAP_PALETTED_TRUECOLOR)) > return FALSE; > > /* Report any unused options (only for the first generation) */ > -- > 2.7.4 > > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 75985] [NVC1] HDMI audio device only visible after rescan
https://bugs.freedesktop.org/show_bug.cgi?id=75985 --- Comment #36 from Maik Freudenberg--- I don't know about the current state of this, I would put some effort into it if nobody else is working on it. Daniel Drake's patch is a good starting point for that. Currently, it looks like the problem lies in that the audio dev is only ever looked after on nouveau drm module load. Instead, the state of it should be checked/toggled on - connector connected/disconected - poweron/off the corresponding gpu e.g remove the audio dev on suspend if it has been previously enabled, on resume check if any connector is connected that needs it and enabled it again in that case. This would also work around the quirks of some laptop's acpi toggling the bit either on boot [1] or on suspend [2]. Desktop cards should not be affected by that because they start with audio dev enabled, so it will not be touched. Quirks will have to be added for nForce chipsets with IGP since those have a separate audio dev. BTW, the kernel module has moved to: https://github.com/hhfeuer/nvhda [1] https://devtalk.nvidia.com/default/topic/1024022/linux/gtx-1060-no-audio-over-hdmi-only-hda-intel-detected-azalia/post/5228002/#5228002 [2] https://devtalk.nvidia.com/default/topic/1024022/linux/gtx-1060-no-audio-over-hdmi-only-hda-intel-detected-azalia/post/5234127/#5234127 -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] UBSAN warning in nouveau_bios.c:1528:8
This is the first time I have tried UBSAN on this specific machine (onboard nforce 420 with HP BIOS on Nance mainboard). nouveau seems to be working fine but gives this UBSAN warning: [7.953957] nouveau :00:0d.0: NVIDIA C61 (04c000a2) [7.965101] nouveau :00:0d.0: bios: version 05.61.32.25.02 [7.966141] nouveau :00:0d.0: fb: 128 MiB of unknown memory type [8.015336] [TTM] Zone kernel: Available graphics memory: 952564 kiB [8.015339] [TTM] Initializing pool allocator [8.015344] [TTM] Initializing DMA pool allocator [8.015370] nouveau :00:0d.0: DRM: VRAM: 125 MiB [8.015372] nouveau :00:0d.0: DRM: GART: 512 MiB [8.015377] nouveau :00:0d.0: DRM: TMDS table version 1.1 [8.015379] nouveau :00:0d.0: DRM: DCB version 3.0 [8.015382] nouveau :00:0d.0: DRM: DCB outp 00: 01000310 0023 [8.015385] nouveau :00:0d.0: DRM: DCB outp 01: 00110204 98830003 [8.015386] [8.015423] UBSAN: Undefined behaviour in drivers/gpu/drm/nouveau/nouveau_bios.c:1528:8 [8.015455] shift exponent -1 is negative [8.015482] CPU: 1 PID: 148 Comm: systemd-udevd Not tainted 4.16.0-rc3-00167-g97ace515f014 #1 [8.015483] Hardware name: HP-Pavilion RT589AA-ABU t3709.uk/Nance, BIOS 5.02 11/26/2006 [8.015485] Call Trace: [8.015496] dump_stack+0x5a/0x99 [8.015500] ubsan_epilogue+0x9/0x40 [8.015503] __ubsan_handle_shift_out_of_bounds+0x124/0x160 [8.015506] ? _dev_info+0x67/0x90 [8.015509] ? dev_printk_emit+0x49/0x70 [8.015632] parse_dcb_entry+0x91e/0xd90 [nouveau] [8.015712] ? parse_bit_M_tbl_entry+0x150/0x150 [nouveau] [8.015791] olddcb_outp_foreach+0x66/0xa0 [nouveau] [8.015870] nouveau_bios_init+0x23a/0x2250 [nouveau] [8.015950] ? nouveau_ttm_init+0x3a4/0x710 [nouveau] [8.016029] nouveau_drm_load+0x229/0xf10 [nouveau] [8.016033] ? sysfs_do_create_link_sd+0xa6/0x170 [8.016067] drm_dev_register+0x1b7/0x330 [drm] [8.016070] ? pci_enable_device_flags+0x160/0x1f0 [8.016091] drm_get_pci_dev+0xee/0x2e0 [drm] [8.016172] nouveau_drm_probe+0x1dd/0x270 [nouveau] [8.016175] pci_device_probe+0x113/0x1d0 [8.016178] driver_probe_device+0x375/0x720 [8.016180] __driver_attach+0xeb/0x150 [8.016181] ? driver_probe_device+0x720/0x720 [8.016183] bus_for_each_dev+0x84/0xe0 [8.016186] bus_add_driver+0x19f/0x340 [8.016188] driver_register+0x67/0x110 [8.016190] ? 0xc0cfb000 [8.016193] do_one_initcall+0x66/0x210 [8.016197] do_init_module+0xa7/0x2a9 [8.016199] load_module+0x2548/0x3d30 [8.016202] ? __symbol_put+0x60/0x60 [8.016205] ? kernel_read_file+0x21b/0x390 [8.016208] ? kernel_read_file_from_fd+0x52/0x90 [8.016210] SYSC_finit_module+0x124/0x150 [8.016212] do_syscall_64+0x7a/0x1f0 [8.016214] ? page_fault+0x2f/0x50 [8.016217] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [8.016219] RIP: 0033:0x7f2e47b82e19 [8.016220] RSP: 002b:7ffdcdc157b8 EFLAGS: 0246 ORIG_RAX: 0139 [8.016223] RAX: ffda RBX: 5638b23c7250 RCX: 7f2e47b82e19 [8.016224] RDX: RSI: 7f2e4788d0ed RDI: 0019 [8.016225] RBP: 7f2e4788d0ed R08: R09: [8.016226] R10: 0019 R11: 0246 R12: [8.016227] R13: 5638b23c2ce0 R14: 0002 R15: 5638b23c7250 [8.016228] [8.016299] nouveau :00:0d.0: DRM: DCB conn 00: [8.016301] nouveau :00:0d.0: DRM: DCB conn 01: 1131 [8.016302] nouveau :00:0d.0: DRM: DCB conn 02: 0110 [8.016304] nouveau :00:0d.0: DRM: DCB conn 03: 0111 [8.016305] nouveau :00:0d.0: DRM: DCB conn 04: 0113 [8.016626] nouveau :00:0d.0: DRM: Saving VGA fonts [8.052781] nouveau :00:0d.0: DRM: DCB type 4 not known [8.052784] nouveau :00:0d.0: DRM: Unknown-1 has no encoders, removing [8.053728] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [8.053729] [drm] Driver supports precise vblank timestamp query. [8.055836] nouveau :00:0d.0: DRM: MM: using M2MF for buffer copies [8.084488] nouveau :00:0d.0: DRM: allocated 1280x1024 fb: 0x9000, bo 50f4b5d0 [8.084678] fbcon: nouveaufb (fb0) is primary device [8.193959] Console: switching to colour frame buffer device 160x64 [8.195378] nouveau :00:0d.0: fb0: nouveaufb frame buffer device [8.212083] [drm] Initialized nouveau 1.3.1 20120801 for :00:0d.0 on minor 0 -- Meelis Roos (mr...@linux.ee) ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 105173] [MCP79][Regression] Unhandled NULL pointer dereference in nvkm_object_unmap since kernel 4.15
https://bugs.freedesktop.org/show_bug.cgi?id=105173 --- Comment #11 from Nick Lee--- (In reply to Pierre Moreau from comment #10) > What exactly is reproducible? The artefacts I would assume, but which error > exactly? The NULL pointer dereference, or the “trapped read at 008000 on > channel 1 [0fbb DRM] engine 00 [PGRAPH] client 03 [DISPATCH] subclient > 04 [M2M_IN] reason 0006 [NULL_DMAOBJ]” one? > I did manage to reproduce the second one with Wayland, but still no luck > with the first one. This error: [ 372.954548] nouveau :03:00.0: imem: OOM: 0010 1000 -28 [ 372.954702] nouveau :03:00.0: gr: TRAP_M2MF 0002 [IN] [ 372.954712] nouveau :03:00.0: gr: TRAP_M2MF 00320951 c0001fc0 04000430 [ 372.954722] nouveau :03:00.0: gr: 0020 [] ch 1 [000fbb DRM] subc 4 class 5039 mthd 0100 data [ 372.954752] nouveau :03:00.0: fb: trapped read at 00c000 on channel 1 [0fbb DRM] engine 00 [PGRAPH] client 03 [DISPATCH] subclient 04 [M2M_IN] reason [PT_NOT_PRESENT] kernel-4.15.6-300.vanilla.knurd.1.fc27.x86_64 mesa-17.3.6 Screenshot: https://s9.postimg.org/hajle1skf/Screenshot_from_2018-03-01_10-12-28.png > (In reply to Nick Lee from comment #8) > > Fedora-Workstation-Live-x86_64-Rawhide-20180220.n.0.iso > > wayland session > > > > [ 1035.437016] nouveau :03:00.0: swiotlb buffer is full (sz: 2097152 > > I’ll try the iso. Did you get this error with supertuxkart as well, or > simply by launching the session? > by launching the session -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau