00:00 RSpliet: sorry
00:00 RSpliet: it's the labri one
00:00 karolherbst: ufff
00:00 karolherbst: stupid file name
00:00 karolherbst: dump-downclock.xz
00:01 karolherbst: okay.. then my script is broken
00:03 karolherbst: will rescan fermi-maxwell then
00:10 karolherbst: RSpliet: okay.. seems like it's never done on fermi+ then
00:11 RSpliet: Ok. I recall having seen it somewhere. But, I don't think it harms leaving the test on either. Just make sure that the test is left on by unsetting the bit... otherwise you can wait for a lock signal 'till the cows come home
00:12 karolherbst: ahh, yeah.. now the script reached a nve7
00:13 karolherbst: okay.. interesting
00:13 karolherbst: at least that helps now
00:13 RSpliet: A lot of traces are downclock only. For the lowest two performance levels no PLL was required.
00:13 karolherbst: ohh wait
00:13 karolherbst: now
00:13 karolherbst: *no
00:13 karolherbst: it's a faulty one
00:13 karolherbst: "R 0x137000 0xbad0011f PCLOCK.CLK0_CTRL => { ENABLE | PWROFF | UNK2 | BYPASS_PLL_CHECK | UNK12 = 0 | 0xbad00108 }" :D
00:13 karolherbst: find the error
00:13 karolherbst: RSpliet: mhh, right...
00:14 RSpliet: traces in my nva8 are even worse. I was definitely in a "pff, who needs demmio" phase where I stripped them down to bare minimum, getting rid of vital headers...
00:19 karolherbst: RSpliet: okay.. but at least according to the commit message you only added that change with the assumption it works on fermi/kepler as well, because it's done on tesla... would you agree it might be safe to just remove the bypass_pll_lock bit for fermi/kepler then?
00:20 RSpliet: It's safe removing the "set" bit. I would be caeful removing the "unset" bit before the lock test, boot state might be "bypass lock test"
00:21 karolherbst: right..
00:21 karolherbst: it's only about setting the bit
00:22 karolherbst: RSpliet: ilia suggested to restore the bit if it's set, otherwise keep it unset
00:22 RSpliet: Could get on board with that.
00:22 RSpliet: I'd have to dig through traces some other time. I'm sure I had more evidence for this code...
00:24 RSpliet: Now is not that time though, I should be snoring by now
00:24 karolherbst: yeah.. me as well
00:24 karolherbst: would be cool if you find some time finding the traces. Would be helpful
00:25 RSpliet: I'd have to peek on my external hdd, if I can find it under it's mountain of dust
00:27 RSpliet: easiest way to reproduce is enabling coolbitch and tracing like a 50MHz overclock, that's usually pll-to-pll
00:27 RSpliet: *coolbits
00:29 RSpliet: Also, might be worth checking nvgpu code. I think it does core clocking
00:29 RSpliet: For Kepler, but meh, I don't think PLLs changed that much. </famous last words>
00:30 RSpliet: Could be an interesting data point nonetheless
00:30 RSpliet: Wait, no. Pixel C was a Maxwell...
04:20 imirkin: skeggsb: finally got a minute to test -- resent the 256+1024 lut patch, hopefully got it right this time
04:22 skeggsb: imirkin: ack, i'll see if i get time this arvo to re-review, i've added it to my monday todo list just in case though
04:23 imirkin: what's an "arvo"?
04:23 skeggsb: sorry, aussie leaking out... arvo == afternoon
04:23 imirkin: hah
04:24 imirkin: never heard that before
04:24 imirkin: i _did_ have an interviewer greet me with the most australian accent imaginable saying "g'day mate!"
04:24 skeggsb: :)
04:24 imirkin: i don't think i'd ever heard it spoken before, so took me a while to process
04:27 imirkin: skeggsb: working on anything fun these days?
04:27 skeggsb: imirkin: depends how you define "fun"...
04:28 imirkin: trudging through bug reports = not fun
04:28 imirkin: working on new features = fun
04:28 skeggsb: reworking acr (secure boot) code?
04:28 imirkin: not fun.
08:20 karolherbst: RSpliet: nvgpu is for "modern" nvidia tegras
08:20 karolherbst: so kepler as well
11:46 RSpliet: https://twitter.com/core2quad_NIGO/status/1169525142457708544?s=20
11:59 karolherbst: can only be a tesla one :p
12:00 RSpliet: GeForce FX
12:57 meeku_: imirkin: are you familiar with the intel stuff at all ? (trying to get the vsync setup on there)
13:05 imirkin: meeku_: not in the least
13:06 meeku_: lol.. no worries
13:06 meeku_: from the docs it seems like this should be a piece of cake
13:06 meeku_: but now the cake is seeming a bit moudly
13:06 meeku_: mouldy even
13:18 imirkin: mmenzyns: doesn't nvkm_mask return the old value?
13:19 imirkin: could avoid an extra read for the bypass state thing
13:20 mmenzyns: oh, I didn't know this
13:21 imirkin: it might also return the new value. double check :)
13:29 karolherbst: imirkin: maybe you have an opinion on that: for pushbufs, right now we actually map GPU memory into the applications address space. Do you think it makes more sense to keep a client side buffer for filling up the pushbuffer and then copy it into a bo right before submitting the buffer in order to reduce the amount of "small" data transfers?
13:30 karolherbst: airlied: ^^ any ideas on that as well?
13:36 imirkin: karolherbst: pushbuf is client-side
13:37 imirkin: unless you boot with vram_pushbuf=1
13:37 karolherbst: hum...
13:37 karolherbst: but libdrm still allocates a bo inside vram
13:37 karolherbst: and maps it
13:37 imirkin: erm
13:37 imirkin: that's not my recollection :)
13:38 imirkin: i thought it made a GART buffer
13:38 karolherbst: ohh wait, it checks fifo->pushbuf
13:38 karolherbst: and chooses from there
13:39 karolherbst: imirkin: is there actually a benefit of using vram_pushbuf=1?
13:39 imirkin: yeah. makes things work in some cases.
13:39 karolherbst: mhhh
13:39 karolherbst: that sounds like trouble
13:39 imirkin: esp with AGP things
13:40 imirkin: it's to mask bugs
13:41 karolherbst: mhhhhhh
13:42 karolherbst: oh well
13:47 karolherbst: imirkin: do you know what kind of bugs that is?
13:47 imirkin: search bugzilla
13:47 imirkin: iirc one instance was too high an AGP level being used
13:47 imirkin: ended up adding that setup to the blacklist
13:48 imirkin: in another case, the mmu setup was messed up (NV4A)
13:48 imirkin: stuff like that.
13:48 imirkin: basically when gpu's reading of gart = fail
13:49 karolherbst: uff
13:49 karolherbst: okay, but if I would track the pushbuffer client side inside mesa, and then do a copy into a bo (even though it's gart) that should be still be okay, right?
13:49 karolherbst: it's really just about how it got submitted to the kernel
13:49 imirkin: wtvr. no one enables that for long periods of time. don't worry about it.
13:49 imirkin: no way you can run mesa with broken GART anyways
13:50 karolherbst: ahhh
13:50 karolherbst: okay
13:50 karolherbst: so it's just a ddx issue
13:50 karolherbst: fine
13:50 karolherbst: makes it easier then
13:50 imirkin: right, you can limp along with fbcon and probably the ddx
14:30 imirkin_: danvet: let me know if the info i included in the email is enough for you to work out what went wrong
14:30 imirkin_: [or if you even received it... hopefully i sent it to the right place]
14:30 danvet: hm
14:32 danvet: imirkin_, not finding anythig?
14:35 danvet: ah foundit
14:35 danvet: imirkin_, you just applied the three patches?
14:35 imirkin_: i sent the mbox of precisely what i applied
14:35 imirkin_: could be i got the wrong thing
14:36 imirkin_: i also had the "enable 1024 gamma" patch, but i somehow doubt that's what caused the gem errors :)
14:36 imirkin_: there was a trailing whitespace in the first one, so perhaps i got an early version...
14:36 imirkin_: (git am refused to take it, so i had to hand-edit)
14:37 danvet: if I'm reading your BUG correctly you go boom on a non-PAGE_SIZE aligned bo created by the nouveau gem_new ioctl
14:38 danvet: I didn't touch anything in there at all
14:38 danvet: (or I'm blind, it happens)
14:38 imirkin_: tbh i'm entirely unfamiliar with this code
14:38 imirkin_: but i backed out your patches (to test my gamma thing), and that worked without problems
14:38 danvet: does the base kernel boot fine without the 3 patches?
14:38 danvet: huh
14:38 imirkin_: and this wasn't a one-off ... at least a two-off
14:39 imirkin_: i booted the first time, expecting to get problems with the nv34
14:39 imirkin_: but it loads on the gk208, so it's gonna be fine, right? :)
14:39 imirkin_: second time i was ssh'd in and started X separately, to get the log
14:40 imirkin_: on the off chance it matters, this is a pretty standard desktop system. core i7-920, so no funny business.
14:42 danvet: so if userspace hands in an unaligned size for the gem bo you're going to go boom, that's clear
14:42 danvet: there's no check for that
14:42 imirkin_: did you do anything to jostle that logic?
14:43 danvet: I should be very far away from that stuff
15:03 imirkin_: yeah, reading over what you actually changed, doesn't seem trivially obvious...
15:03 imirkin_: could it be some behavior change, like a fault used to fail and now it succeeds or something?
15:06 imirkin_: in a hypothetical case this could backfire with 64k pages on cpu and 4k pages on gpu...
15:06 imirkin_: but that's not my situation
15:08 imirkin_: danvet: yeah, that BUG_ON really can't happen :)
15:08 imirkin_: glad that's settled... :)
15:10 imirkin_: can BUG_ON take a printf thingie?
15:13 danvet: sry had a meeting interrupt me here
15:14 danvet: imirkin_, I'd put a PAGE_ALIGN(req->size) or so in nouveau_gem_new_ioctl plus normal printk to see what's going on
15:14 danvet: so that you see what's happening plus paper over the issue
15:14 danvet: but yeah I'm really surprised why my patches brought that up
15:14 danvet: BUG(condition, printf_str, ...) is the one you're looking for
15:15 danvet: for your q
15:21 imirkin_: what's the diff between that and BUG_ON?
15:21 imirkin_: (i'd look it up, but those macros are not the definition of readable...)
15:56 danvet: imirkin_, BUG_ON only has the condition, but otherwise the same
15:59 imirkin_: aha, makes sense
15:59 imirkin_: i'll try to debug a bit over the weekend
16:00 imirkin_: i have 3 GPUs in the system, so it could be coming from somewhere unexpected.
16:00 imirkin_: (GK208, G84, and NV34)
16:00 danvet: awesome, thx a lot
16:01 danvet: I'll be at plumbers next week, so will be a bit slow with tossing around ideas
16:01 imirkin_: ok. i generally can't do much during the week anyways
16:01 imirkin_: except provide wise-ass remarks on irc...