01:36RSpliet: skeggsb: I hope you're not at work today, but in case you are: I sent a trace of the blob with NVAC firing up a 1920x1080 monitor to the dumps mail
01:36RSpliet: in response to the NVAC no signal problem reported by poma that I too observed
01:37RSpliet: I can confirm it doesn't work with 4.8, and it does work with 4.9 when I commented away the 0xac case from the workaround codename switch
01:37RSpliet: I didn't get a 4.9 unmodified data point, sorry for that
01:40mwk: yay, first case of weirdo hidden state found on NV4-NV1x
01:40RSpliet: my VBIOS is in the usual repo
01:41RSpliet: mwk: weirdo hidden state?
01:41mwk: RSpliet: PGRAPH state not visible via MMIO regs
01:41mwk: apparently two methods behave differently depending on what the last rendered primitive was
01:42mwk: that's going to be a pain to model
01:43RSpliet: ouch... that sounds unpleasant (yet not completely unsurprising for a fixed-pipeline GPU)
01:43RSpliet: esp since that's from the pre-context switch era presumably?
01:43mwk: so, if the last rendered primitive was a line, the GDI bitmap color 0 format is set by the format method; but if it was a rectangle, the format is set by the bitmap color 0 method
01:44mwk: I mean, what the fuck
01:44mwk: RSpliet: that's the 2D engine FWIW :(
01:44mwk: there's no such thing as a "pre-context switch era" on nvidia, NV1 is already designed for context switching
01:45mwk: and the state... doesn't even make sense
01:48RSpliet: my failure to parse your phrase explaining the different state made me strongly believe it doesn't make sense... is that deliberate or just a hw error on the "MMIO command decoding" side?
01:48mwk: it completely doesn't make sense, so I'd guess a hw bug
01:49mwk: but then, I don't even see why you'd want two different settings of which method sets this piece of state
01:49mwk: so... I'm guessing it's something done on purpose, but gone wrong
01:51mwk: I'll deal with that later, I have to finish the cleanup of existing tests first
05:41gnurou: hakzsam: definitely. not before 01/05 though, as I am far from any board until then
05:41gnurou: hakzsam: I think that's some fantastic work btw, thanks for this
09:25hakzsam: gnurou: untested on gm20x though, but it's the same ISA, so it should work
09:28karolherbst: by the way, it is really hard to get new devs on board here :O
09:28pmoreau: hakzsam: Congratulations on your series and job! Et Joyeux Nowel! :-)
09:30pmoreau: I would assume that the firmware situation is not helping.
09:30karolherbst: pmoreau: there are some especially interested in challenges like that though
10:53hakzsam: pmoreau: thanks, let me know if you can test the series on your gm206 :)
10:56RSpliet: hakzsam: I'll try and dust off my TX1 after the Christmas break
11:11pmoreau: hakzsam: I’ll give it a whirl for sure once I get back home, some time end of next week.
14:23haagch: gnurou is here too, nice
14:23haagch: opengl in X works fine if I revert this patch https://github.com/Gnurou/mesa/commit/a97f868a806ab4f1aaab88c72d4b55bfb18cc3cc
14:24haagch: probably need more permissions to use card1 than to use renderD128
14:25haagch: maybe someone else here knows this? When /dev/dri/card1 is used, nouveau_getparam(dev, NOUVEAU_GETPARAM_FB_SIZE, &v); returns -13, permission denied
14:25haagch: does that only work for drm master?
14:27haagch: this is with the renderonly branch from here on my tegra k1 chromebook: https://github.com/Gnurou/mesa/commits/renderonly
14:27haagch: kmscube in a tty gives no trouble, but the ioctls in X only work as root
20:33nyef``: Hello all. I'm trying to track down a problem with resume-from-suspend on one of my laptops, where the display starts flashing between bright white and black instead of resuming properly. The nvidia blob works fine. I've managed to get a dmesg of the entire sequence here: http://lisphacker.com/temp/m17x-nouveau-suspend-dmesg.txt and I'm wondering what my next step should be. Any hints?
20:42karolherbst: nyef``: does it work with nouveau.runpm=0 ?
20:44karolherbst: nyef``: nvm my comment
20:46nyef``: Okay, I presume that that means that you expect that it won't help?
20:46karolherbst: nyef``: could you test with a drm-next kernel? Because the display code was pretty much rewritten a lot
20:46karolherbst: nyef``: https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next
20:47karolherbst: branch: drm-next
20:47karolherbst: and use --depth 1 for cloning
20:47karolherbst: if that doesn't help, ping skeggsb, he might know more, and create a bug.
20:48nyef``: So, "git clone --depth 1 git://people.freedesktop.org/~airlied/linux"?
20:49nyef``: Hrm. And "-b drm-next"
20:50nyef``: Cloning now.
20:51nyef``: I don't suppose there's any chance that the opengl stuff will do quad buffers with a 3dvision2 emitter, is there?
21:01karolherbst: honestly, I have no clue about opengl, just doing kernel stuff
21:03nyef``: Okay, that's fair.
21:03karolherbst: anyway, with that kernel tree you should get super stable reclocking on your gpu with nouveau
21:04karolherbst: if not, then you are one of the few with a troubling card
21:04nyef``: Which outcome should I hope for? (-:
21:05karolherbst: mhh, depends
21:05karolherbst: if you wanna help out finding out why, then of course a troubling one
21:05karolherbst: I don't have access to such a gpu
21:05karolherbst: all I have access to work fine
21:09nyef``: Trying to build now.
21:09nyef``: If this works, do you have any idea of the timeframe for this hitting mainline?
21:10karolherbst: 2-3 months
21:10karolherbst: but you can use the rc kernels real soon
21:14nyef``: Okay, and given one of the other things wrong with this machine I can expect to be running a patched kernel for a while anyway...
21:25nyef``: Time for a test run, back in a few minutes.
21:33nyef``: And I'm back. Brief garbage on the screen during resume, but then solid black. A definite improvement, but still not useful. http://lisphacker.com/temp/m17x-nouveau-suspend-drm-next-dmesg.txt
21:36nyef``: Is that "failed to read link config" bit significant?
22:30nyef``: Initial digging suggests that the "failed to read link config" bit should probably be expected, and that it kicks off the actual configuration and training sequence.
22:36karolherbst: ask skeggsb
22:36karolherbst: nyef``: can you switch ttys?
22:37karolherbst: it indeed looks better than the output before
22:37karolherbst: but I have not much knowledge about the display code
22:37karolherbst: skeggsb wrote most of it
22:37karolherbst: he should be around soon or maybe not due to holidays
22:38nyef``: Haven't tried switching ttys. Would that even work if the link isn't trained, though?
22:39karolherbst: maybe X is just messed up
22:39karolherbst: allthough that I doubt somehow
22:39karolherbst: I guess something isn't right
22:39nyef``: It's not X, I'm not yet at the point of running X.
22:39karolherbst: I wanted to suggest removing the display for a short period....
22:39karolherbst: ohh I see
22:40nyef``: And sure I can remove the display for a short period... but not while the system is running. Laptop panel and all. (-:
22:40karolherbst: well yeah, create a bug then on bugzilla against nouveau
22:41nyef``: I probably will at some point, but not while I'm still have leads to chase down.
22:45karolherbst: uhh well, your choice, you would just save you the time letting skeggsb handle this, except you want to fix it yourself in the code :)
22:46nyef``: Sure. Right now, I'm learning stuff, which might end up in the bug report.
22:55nyef``: So, it calls dp_set_link_config(), but then doesn't call dp_link_train_cr(), so dp_set_link_config() returned nonzero.
23:03nyef``: Backing up a few steps, during kernel startup I see a message "aux power -> always" before the initial link training. During suspend, I see "aux power -> demand". Early in resume, I see BOTH.
23:05nyef``: ... And the distinct impression I get here is that I should be seeing only the one, and a training sequence at that point.
23:07skeggsb: nyef``: can you get a log with "nouveau.debug=disp=trace,i2c=trace drm.debug=0x14"
23:08nyef``: skeggsb: Sure. Still on the drm-next kernel?
23:09nyef``: Trying now, back in a few minutes.
23:09karolherbst: skeggsb: by the way, it would be nice if you take a look into my stable_reclocking_kepler_v6 and pmu_counters branches
23:10karolherbst: skeggsb: my dynamic reclocking stuff depends on this, and I need to make a big rewrite there
23:10karolherbst: and I actually would like to include your reviewing comments there while doing so
23:11karolherbst: finally figured out how nvidia calculates the memory load
23:11skeggsb: karolherbst: i'll try and get to it in the new year, give me a ping early jan as a reminder though just in case it gets lost in the storm
23:11karolherbst: sure, will do
23:11skeggsb: it's on my list though :)
23:11karolherbst: silly nvidia uses the memory and shader clocks for memory load calculations :/ this basically destroys my current design
23:12skeggsb: hm interesting
23:13karolherbst: nv_mem_load = pmu_mem_load * 100 * (engine_clock / mem_clock)
23:13karolherbst: nv_mem_load = pmu_mem_load * 10 * (engine_clock / mem_clock)
23:13skeggsb: i wonder what that's all about :/
23:13karolherbst: shader waiting on memory
23:14karolherbst: they do busy waits
23:14skeggsb: oh, right
23:16karolherbst: that mem counter is still unreliable, I guess we will have to use pretty pessimistic algorithms, so that the pstate is high enough
23:16karolherbst: or memory clock
23:16nyef```: Looks like it overflowed the kernel log buffer, but I took copies pre- and post-suspend, so I've got all of it. Just need to stitch it together and copy it to my webspace.
23:17karolherbst: it works perfetcly as long as I stay on the highest pstate
23:17karolherbst: still have to check how nvidia decides which mask to set on each index, but maybe this just depends on the chipset feature or model features
23:21nyef```: skeggsb: http://lisphacker.com/temp/m17x-nouveau-suspend-drm-next-i2c-debug.txt
23:23nyef```: Hrm. "sink not detected", huh?
23:25skeggsb: yes, that's slightly problematic
23:27skeggsb: does nouveau work if you: boot with nomodeset to runlevel 3, suspend/resume, connect over ssh (or type blindly, because the screen will be black) and load nouveau ?
23:28nyef```: Hrm. So, rebuild with nouveau as a module, then "echo mem > /sys/power/state; sleep 2; modprobe nouveau" ?