00:00 RSpliet: right, but I do
00:00 imirkin_: anyways, i'm basically an email processing machine. if it's not over email, it doesn't exist
00:01 imirkin_: if you're really embarrassed, you can send to me directly first
00:01 RSpliet: if only I had the time to process the entire nouveau@ and dri-devel@... anyway, well, no not embarrasment. I guess I'd just send it there then
00:02 imirkin_: i have no problem with nouveau + dri-devel volume...
00:02 RSpliet: it's scope is considerably more limited than dri-devel@ I guess, ratelimiting the feedback too
00:02 imirkin_: lkml defeats me quite handily though
00:02 RSpliet: heh, well, I don't spend my 9 to 5 trying to keep up
00:03 imirkin_: i spend 10s max reading each email, with a few exceptions
00:03 RSpliet: I spend more time on just deleting them :-D
00:03 imirkin_: gmail + keyboard shortcuts ftw
10:09 NunoEOSA: hi :)
10:09 NunoEOSA: what is the best graphical driver for linux mint? My graphic is Nvidia Geforce GTX 860M
10:12 imirkin_: NunoEOSA: which chip is it? GM107 or GK104?
10:13 NunoEOSA: imirkin_, GM107M
10:13 imirkin_: GM107 support is pretty weak in nouveau right now, blob is pretty much your only choice
10:14 imirkin_: if you get a 4.1-rc kernel and use the modesetting ddx with xorg 1.17, it should be mostly ok, i guess
10:14 imirkin_: except a bunch of people have reported vram size misdetection
10:15 imirkin_: or rather, have reported the chip not coming up properly due to bad mmio reads, which in turn causes the vram size to be misdetected, which in turn causes nouveau to do some horrible things
10:21 NunoEOSA: mm maybe is better I just use my intel HD 4600
10:22 NunoEOSA: thanks for the help :)
13:23 manjaro_user2: Hello, EDID seems to report some non-working modes. It is a DP monitor without built-in scaler and is pretty picky on timings, only some modes like 24, 60, 85, 100, 120, 144 Hz works on default with nonfree nvidia, here I have problem that as far I could get to is 85 Hz. Tried creating new mode with cvt, gtf both left me with blank screen and had to restart linux to see video output. Any solution or way to restart video driver
13:23 manjaro_user2: without restarting linux every time?
13:24 imirkin_: manjaro_user2: did you set scaling mode to none?
13:24 manjaro_user2: imirkin_: Yes.
13:25 imirkin_: ok, well you should use some fancy gui application that bring you back to the previous mode if you don't click some button within 15 seconds
13:25 imirkin_: otherwise you can ssh in and change the mode manually
13:25 imirkin_: or you can do like xrandr bla && sleep 30 && xrandr bleh
13:26 manjaro_user2: Seems like a nice way, thanks!
13:26 imirkin_: which will execute the first xrandr, then sleep for 30 s, then execute the last one which would hopefully undo your settings. and if you're happy with what it did, just hit ^C and the sleep will die and cause the last cmd to nto get run
13:32 manjaro_user3: Hmm... xrandr -s 2560x1440 -r 24 && sleep 10 && xrandr -s 2560x1440 -r 85 worked fine, but xrandr -s 2560x1440 -r 100 && sleep 10 && xrandr -s 2560x1440 -r 85 did not.
13:32 manjaro_user3: By that, I mean that it did not bring video output back.
13:37 imirkin_: hmmmm
13:37 imirkin_: after 10s presumably :)
13:37 imirkin_: that means that something bad is going on when you do -r 100
13:37 manjaro_user3: It seems so.
13:37 imirkin_: perhaps we get some calculation wrong? not sure, sorry
13:37 imirkin_: you'd need to get logs
13:37 imirkin_: try ssh'ing in
13:37 manjaro_user3: -r 100 is from EDID
13:38 imirkin_: right, but those values are fed into computations that go to program the hardware
13:39 manjaro_user3: Using custom mode as 100 Hz, 120 Hz, 144 Hz did not work as well. :/ Tested CVT, CVT with reduced blanking and GTF.
13:39 imirkin_: try to ssh in and see what's going on in dmesg when the screen dies
13:39 imirkin_: i'm guessing PDISP hangs
14:50 hakzsam: imirkin_, no idea for the DDX issue?
14:51 imirkin_: hakzsam: you need to read the code
14:51 imirkin_: and figure out how to hit it
14:51 imirkin_: or what hits it
14:51 imirkin_: and then... try to hit it ;)
14:53 hakzsam: imirkin_, okay, no ideas so :)
14:54 tobijk: hakzsam: next time add a _untested_ so a naive me can see that ;-)
14:54 hakzsam: I'll take a quick look at this tomorrow, but this is not my top priority
14:54 imirkin_: it's been that way since 2009
14:54 tobijk: btw whats with the other two series of yours? can you push them?
14:54 imirkin_: it can wait another day
14:55 hakzsam: imirkin_, sure
14:55 hakzsam: tobijk, what series? the query header thing?
14:55 tobijk: yep
14:56 hakzsam: need more work to get an R-b of imirkin_ ;)
14:56 tobijk: imirkin_: go r-b that ;-)
14:57 imirkin_: that was the series which was a no-op? it can wait until it becomes useful.
14:57 tobijk: yep those two no-op series
14:59 hakzsam: yeah, those two series will be re-submitted with a series which implements perf counters, and they will be useful
21:34 imirkin: skeggsb: ouch, that m2mf class id typo ... oops!
21:38 skeggsb: imirkin: yeah :/
21:38 skeggsb: my bad
21:44 imirkin: only in 4.1-rc though, so hasn't been there too long
21:46 skeggsb: yeah, i've got some other trivial fixes pending i'll send along too
21:50 imirkin: thoughts on the one i sent? should help us stay out of trouble when the card's dead
21:50 skeggsb: i just replied to that actually
21:50 imirkin: oh yeah, just saw it
21:51 imirkin: so..... right. clearly we have an issue
21:51 imirkin: and *where* we detect that we have an issue doesn't really matter to me, the vram thing was just an easy dead give-away
21:51 imirkin: but once we know we're screwed, it does seem like bailing is the classy thing to do rather than trying to operate the hw
21:54 skeggsb: either way, we're going to get a bug report, and either way, the hw doesn't work
21:55 skeggsb: what we need is a trace, and to fix it :P
22:00 imirkin: skeggsb: yeah, but then it tries to modeset and fails quite horribly
22:00 imirkin: whereas if it bails, at least you don't have a hung box
22:01 imirkin: anyways, wtvr. it was just a thought.
22:05 skeggsb: yeah, i do understand what your point. i'd have no objection if it were the type of error that could happen under normal circumstances, i just don't like making these kind of bugs less "severe" instead of just finding the fix
22:06 skeggsb: anyways, do we have any traces of one of the boards that do this with nouveau?
22:06 imirkin: skeggsb: ok, well, i know *i* don't have the hw, and with your luck, any hw you get will just work out of the box :)
22:06 imirkin: there was at least one trace for a GM108
22:06 imirkin: but it's also happened with GM107's
22:07 skeggsb: do you remember where the gm108 one is?
22:07 imirkin: skeggsb: https://bugs.freedesktop.org/show_bug.cgi?id=89558
22:08 imirkin: might have landed in the email account, i forget
22:08 imirkin: oh no, it's in there
22:09 imirkin: apparently cycling the module is enough to get it loaded? weird
22:10 imirkin: there was another email to the list recently for a GM107 although no mmiotrace i think
22:11 imirkin: ("Handling GeForce GTX 850M GPU on Arch Linux")
22:11 imirkin: perhaps you could get the owner to run a mmiotrace
22:18 skeggsb: it looks to me like we're not detecting that the board needs devinit run
22:18 imirkin: skeggsb: didn't you say that we never run devinit for >= nv50?
22:18 skeggsb: no?
22:20 imirkin: er
22:20 imirkin: vbios init
22:20 imirkin: close enough :)
22:20 skeggsb: that is devinit :P
22:22 skeggsb: the gm107 case is different though i think
22:24 imirkin: i thought there was a thing that just says "never run vbios init for >= nv50"
22:24 imirkin: i pointed it out to you and you were like "yes, that is correct"
22:25 skeggsb: that's the old-school stuff in drm/ that's only used for pre-nv50 modesetting, it *used* to have devinit stuff there too
22:25 skeggsb: i *am* working on cleaning these rough edges off btw
22:25 imirkin: skeggsb: http://cgit.freedesktop.org/~darktama/nouveau/tree/drm/nouveau/nouveau_bios.c#n2058
22:26 skeggsb: yep, that's left-over old stuff
22:26 imirkin: where does it run vbios init from now?
22:26 skeggsb: nvkm/subdev/devinit
22:26 imirkin: but does that actually exec the tables?
22:26 skeggsb: is where the bios init tables get executed
22:27 skeggsb: the stuff left in nouveau_bios.c is purely for pre-nv50 modesetting stuff
22:27 skeggsb: (yes, i know it's a mess)
22:28 imirkin: not that i don't trust you, but via what code path do the vbios tables get executed?
22:28 imirkin: is it in the vbios subdev init?
22:28 skeggsb: yep, devinit checks if it needs to be posted, and calls the vbios init table parser to do it
22:28 skeggsb: (or, on gm2xx and up, uploads signed bullshit to pmu to do it)
22:29 imirkin: .post = nvbios_init
22:29 imirkin: that?
22:29 skeggsb: yes
22:30 imirkin: looks like that only executes the vbios tables on resume
22:30 imirkin: not on load
22:30 imirkin: (or when NvForcePost=1 is set)
22:31 skeggsb: if (!priv->base.post) {
22:31 skeggsb: if (!nv_rdvgac(priv, 0, 0x00) &&
22:31 skeggsb: !nv_rdvgac(priv, 0, 0x1a)) {
22:31 skeggsb: nv_info(priv, "adaptor not initialised\n");
22:31 skeggsb: priv->base.post = true;
22:31 skeggsb: }
22:31 skeggsb: }
22:31 skeggsb: that's the check we use for "is it posted"
22:31 skeggsb: and sets it for the first load too
22:33 imirkin: ah, some nice grep-evasion there
22:33 imirkin: i was looking for '->post'
22:34 imirkin: although for nvc0+, this is the condition:
22:34 imirkin: if (nv_rd32(priv, 0x022500) & 0x00000001)
22:34 imirkin: priv->base.post = true;
22:35 skeggsb: (in addition to the nv50 one, which is detected at init time)
22:35 skeggsb: that's a "is the display engine missing"
22:35 imirkin: nothing gets by you!
22:36 skeggsb: which, may actually explain the gm108
22:37 skeggsb: those regs moved for at least the engine missing stuff, so the PDISP missing bit might be too
22:39 imirkin: ah yeah, probably
22:39 imirkin: should be apparent from the trace
22:39 skeggsb: yes, nvidia don't ever read it in the gm108 trace
22:39 skeggsb: i'm trying to guestimate where it's gone
22:39 imirkin: you mean 22500?
22:39 skeggsb: yeah
22:40 imirkin: oh, but you know know where the "engine missing" stuff is either?
22:40 skeggsb: oh, i do know where it is
22:40 skeggsb: nvm
22:40 skeggsb: yeah, and it's missing
22:40 skeggsb: ok, patch coming in a few mins
22:40 imirkin: yay :)
22:41 imirkin: have you gotten your hands on a problematic GK106M btw?
22:48 skeggsb: and, completely untested patches pushed
22:48 skeggsb: no... not yet, i tried to follow up some more on that yesterday
22:50 imirkin: oh heh. it *should* have been looking in 22500 but wasn't?
22:51 imirkin: or rather the ->disable thing knows how to compute the right stuff
22:51 skeggsb: yeah, ->disable() computes it to disable engines that aren't there
22:51 imirkin: right. 21c00
22:51 skeggsb: it's 0x21c04 on gm107
22:52 imirkin: cool, that sounds like it could work
22:52 skeggsb: but yeah, the bug on the mailing list isn't the same issue unfortunately
22:52 imirkin: how do you know?
22:52 imirkin: that ram amount is awfully close to 0xbadf
22:52 imirkin: it was 0x3adf
22:52 imirkin: and bit-shifted
22:56 skeggsb: [ 0.345280] nouveau [ DEVINIT][0000:01:00.0] adaptor not initialised
22:56 skeggsb: [ 0.345311] nouveau [ VBIOS][0000:01:00.0] running init tables
22:56 skeggsb: that's why :)
22:58 imirkin: oh. heh. so running them harder is unlikely to help?
22:59 skeggsb: ;)
23:00 imirkin: skeggsb: should probably fix up pramin_init as well
23:01 skeggsb: well, it's correct already, but yes, i should make it use the more obvious interface
23:01 skeggsb: s/interface/test/
23:01 imirkin: right
23:03 skeggsb: anyway, i'm off for a little bit, will be back in a couple of hours
23:05 imirkin: k, see ya