[Nouveau] [Bug 105173] [MCP79][Regression] Unhandled NULL pointer dereference in nvkm_object_unmap since kernel 4.15

2018-03-01 Thread bugzilla-daemon
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

2018-03-01 Thread Ilia Mirkin
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

2018-03-01 Thread bugzilla-daemon
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

2018-03-01 Thread bugzilla-daemon
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

2018-03-01 Thread bugzilla-daemon
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

2018-03-01 Thread bugzilla-daemon
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

2018-03-01 Thread bugzilla-daemon
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

2018-03-01 Thread bugzilla-daemon
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

2018-03-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105319

Sérgio M. Basto  changed:

   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

2018-03-01 Thread bugzilla-daemon
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

2018-03-01 Thread bugzilla-daemon
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

2018-03-01 Thread bugzilla-daemon
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

2018-03-01 Thread bugzilla-daemon
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

2018-03-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103721

Marc Burkhardt  changed:

   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]

2018-03-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100567

Marc Burkhardt  changed:

   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

2018-03-01 Thread bugzilla-daemon
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.

2018-03-01 Thread Ilia Mirkin
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 Kleiner
 wrote:
> 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

2018-03-01 Thread bugzilla-daemon
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

2018-03-01 Thread Meelis Roos
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

2018-03-01 Thread bugzilla-daemon
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