03:45 imirkin: mupuf: did you see the notes that arnd or whoever was complaining about the build fail had about doing it that way?
03:45 imirkin: mupuf: i don't remember all the details tbh
03:45 mupuf: imirkin: I tried looking for it on the ML but could not find it
03:45 mupuf: arnd was his nickname on irc?
03:45 imirkin: ok sec
03:46 imirkin: thread starting with "[PATCH] drm/nouveau: fix LEDS_CLASS=m configuration" on dri-devel
03:46 mupuf: ah, DRI-devel!
03:46 imirkin: "Using 'select' on user-selectable symbols risks introducing circular dependencies" is what he said about doing "select LEDS_CLASS"
03:47 imirkin: his final suggestion was to just use IS_REACHABLE
03:47 imirkin: if you build nouveau=y and leds_class=m, you'll silently not get led support
03:47 imirkin: which imo is fine - leds is a fringe feature
03:50 mupuf: yeah, right. This is plain lovely
03:54 mupuf: imirkin: thanks for having such a good memory
03:54 imirkin: :)
12:54 ouned: is prime known to not work after hibernation?
12:55 ouned: https://gist.github.com/ouned/07e00509a23f8c1b2e705f5bb1287b35
12:56 ouned: it doesnt turn off the dGPU and as soon as it tries to use the dgpu the whole system freezes
12:56 ouned: suspend works fine though
13:05 pmoreau: ouned: It seems that some clevo latpops have issues resuming, see https://bugs.freedesktop.org/show_bug.cgi?id=94725#c22 starting from comment 22
13:55 ouned: nouveau 0000:01:00.0: fifo: read fault at 440f80c000 engine 0c [HOST5] client 06 [HOST] reason 00 [PDE] on channel 0 [017f763000 DRM]
13:56 ouned: i also get this: [ 175.019727] Uhhuh. NMI received for unknown reason 2d on CPU 0.
13:56 ouned: [ 175.019729] Do you have a strange power saving mode enabled?
13:56 ouned: [ 175.019730] Dazed and confused, but trying to continue
13:56 ouned: lol
15:21 orbisvicis: hey, does 4.10 come with reclocking support ?
15:21 orbisvicis: imirkin: anyway I built a debug 4.9-rc8 kernel with drm-next, but the logs are 15mb ...
15:22 imirkin: ... either you built a 4.9-rc8 kernel or your built a drm-next kernel. can't do both.
15:23 orbisvicis: imirkin: drm next
15:23 imirkin: ok
15:24 imirkin: i've completely lost context on why i asked you to do that
15:24 orbisvicis: black screen on resume
15:24 orbisvicis: imirkin: http://superuser.com/questions/1153248/causes-failure-to-reinitialize-video-out-on-resume
15:26 imirkin: and did drm-next help?
15:26 orbisvicis: no
15:27 imirkin: you're gonna need help from skeggsb
15:28 orbisvicis: imirkin: anyway, it seems that drm-next supports dynamic reclocking ?
15:28 orbisvicis: also, how do I upload this dmesg ?
15:28 imirkin: it does not.
15:28 orbisvicis: kernel: nouveau 0000:05:00.0: clk: 1516000 KHz
15:29 orbisvicis: ^^ I have a bunch of lines like this, where clock changes
15:30 orbisvicis: ok, probably just enumerating available frequencie
15:30 imirkin: precisely that :)
15:37 orbisvicis: skeggsb: I'd appreciate your help in debugging a GK208 issue: video-out dead after resume
15:38 orbisvicis: skeggsb: more details @ http://superuser.com/questions/1153248/causes-failure-to-reinitialize-video-out-on-resume
15:38 orbisvicis: skeggsb: anyway, I have the logs for drm-next, they actual seem to contain something useful (unlike last time), but they are 15Mb (too large to upload)
17:15 RSpliet: orbisvicis: expect long round trip times for messages directed at skeggsb, they have to go all the way to Australia
17:15 RSpliet: (where it's currently 3:15)
17:15 NanoSector: http://bash.org/?142934
17:15 NanoSector: comes to mind
17:22 orbisvicis: heh
17:26 orbisvicis: if were doing the long-distance thing, I need to figure out how to upload this log
17:36 RSpliet: orbisvicis: Your best bet is bugzilla; check the "reporting bugs" page on the nouveau wiki
17:38 RSpliet: big logs can be compressed using xz and if they're still too large (...) you can send them to mmio.dumps at gmail and drop a notification of that in the bug report
17:44 orbisvicis: heh, RSpliet: better solution:
17:44 orbisvicis: skeggsb: for the log:
17:44 orbisvicis: curl -s https://paste.fedoraproject.org/501132/81132565/raw/ | base64 -d | bunzip2 > log
18:31 imirkin_: anyone with a GM20x + nvidia blob - can you do some traces with an application that futzes with glSubpixelPrecisionBiasNV to see how that's programmed? [this is a non-trivial task]
18:36 orbisvicis: how non-trivial ?
18:37 orbisvicis: https://www.kernel.org/doc/Documentation/trace/mmiotrace.txt --> looks simple enough ?
18:37 imirkin_: orbisvicis: this would be a mmt trace
18:37 imirkin_: but step 1 would be to write an application which performs the relevant steps
18:38 imirkin_: some GL knowledge necessary
18:38 orbisvicis: heh nevermind, then
19:31 pmoreau: imirkin_: GM20x + NVIDIA blob was tempting, but then I saw I would need to write the application as well… :-D Maybe over the weekend, if I haven’t forgotten and don’t feel lazy
19:32 imirkin_: :)
19:32 imirkin_: i already have some basic traces in https://trello.com/c/Zjm7vs5h/149-gm200-nv-conservative-raster
19:33 imirkin_: but the person who made them didn't do the subpixel stuff
19:33 pmoreau: Ok
19:34 pmoreau: Hum… I probably need to install an old version of the blob, which still works fine with mmt… and downgrade the kernel at the same time.
19:34 pmoreau: I would have to do that anyway, but… it’s becoming even less tempting :-D
19:35 imirkin_: new blob doesn't work with mmt?
19:35 imirkin_: ugh
19:36 pmoreau: I don’t think so. It is preventing hakzsam from playing with my CUDA traces on Pascal
19:37 imirkin_: but that's pascal
19:37 imirkin_: what about with GM20x?
19:38 pmoreau: I think it remains valid for other chipsets as well
19:38 imirkin_: and by "valid" you mean "non-working"?
19:38 pmoreau: Right
19:38 imirkin_: :)
19:38 pmoreau: Though I could be misremembering: it was some time ago :-D
19:39 imirkin_: np
19:42 hakzsam: new blob only doesn't work with mmt for compute (cuda)
19:43 hakzsam: no need to downgrade for tracing 3D like piglit tests
19:47 pmoreau: Ah, good to know! :-)
21:01 Marex: airlied: hey, regarding the MXSFB, PR for single patch or PR for the whole series (4 patches then) ?
21:04 airlied: Marex: since I've already pulled, just the one fix
21:04 Marex: airlied: roger, sorry for the trouble
21:11 Marex: airlied: I am testing the suggestion from Stefan (add missing select DRM_PANEL) now, so expect patch in less than 1 hour
21:11 imirkin_: Marex: you're probably looking for #dri-devel
21:12 Marex: imirkin_: oh, yeah, that's better
21:12 Marex: imirkin_: sorry for the unrelated noise
21:12 imirkin_: no worries
21:13 Marex: imirkin_: thanks though, I wasn't aware of that channel
21:44 pmoreau: skeggsb: Ping on https://bugzilla.kernel.org/show_bug.cgi?id=153911#c3
21:45 pmoreau: NV_* print macros are not affected by the actual log level and max level specified in the kernel config
21:47 imirkin_: pmoreau: they're not supposed to be afaik
21:47 imirkin_: they're wrappers around DRM_DEBUG which is a diff mechanism
21:47 imirkin_: at least ... iirc
21:48 pmoreau: Ah, ok
21:49 pmoreau: What are the pros of using DRM_DEBUG over the regular kernel print interface?
21:49 imirkin_: no clue.
21:49 imirkin_: all the cool drivers do it!
21:49 pmoreau: Eh eh :-D
21:50 karolherbst: prefixing I guess
21:50 karolherbst: printk doesn't print the pci address
21:50 imirkin_: dev_printk does
21:50 imirkin_: or pr_dev or whatever
21:50 karolherbst: drm log levels for another thing
21:50 pmoreau: nvkm_printk which uses dev_* does print the PCI address as well
21:51 karolherbst: k sure
21:51 karolherbst: but nvkm_printk is for nvkm only
21:53 pmoreau: Sure, but it’s a bit counter-intuitive to, let's say, limit Nouveau logs to errors, and still get warning and info ones because NV_* doesn’t care about those limitations.
21:53 imirkin_: yes.
21:54 karolherbst: right
21:54 karolherbst: but then we should change that
21:54 karolherbst: shouldn't be a problem to add log leves there, or are there some already?
21:55 pmoreau: I think there are some levels already, or at least it should be easy to as you have different macros
21:58 karolherbst: so we replace NV_INFO with NV_DEBUG for the annoying stuff
21:59 karolherbst: maybe we could add one NV_INFO for "card putting to sleep" and "waking up card"
22:02 pmoreau: Is that needed as current information?
22:03 pmoreau: If it is only happening when the laptop suspend/resume, then ok
22:03 pmoreau: But for an Optimus setup, this can become quite noisy, even with just two messages per suspend/resume cycle
22:05 karolherbst: pmoreau: might help some users
22:05 karolherbst: pmoreau: 1 message is better then 10
22:06 pmoreau: That’s for sure
22:06 karolherbst: the ACPI warning is annoying though
22:06 karolherbst: this should be debug as well
22:06 karolherbst: well sure, we know that like all mother board uefis implemented that wrongly, but why should every user be annoyed with this
22:08 pmoreau: Yeah… I went back to my PR, that somewhat addressed that, last summer, but… I didn’t really wanted to go back and have a look at the ACPI spec and so on
22:36 pmoreau: Hum… PGRAPH is unhappy when resuming on my G96 now… will have to investigate that at some point (tm)
23:58 pmoreau: skeggsb: Updated&tested version sent. I rebased it on top of your master branch as well, so there shouldn’t be any merge conflicts.