00:10 joi: imirkin: you need to enable it at tracing time
02:48 mlankhorst: anyone feels like reviewing the libdrm patches I've posted to the nouveau ml?
05:14 xexaxo: mlankhorst: I don't mind if I do :-)
05:17 mlankhorst: oke
05:33 robclark: hmm, does oops in nouveau_i2c_acquire_pad() sound familiar.. it is slightly older 3.18 based kernel, I can't seem to find that fxn upstream so not sure whether to bother caring..
05:33 robclark: http://hastebin.com/raw/hixivunemu
05:37 hakzsam: robclark, Hi, seems to be related to https://bugs.freedesktop.org/show_bug.cgi?id=84101
05:37 hakzsam: what card do you have?
05:39 robclark: hmm... random older workstation gfx card, I think... http://hastebin.com/raw/giyinagoli
05:40 hakzsam: nvd9
05:40 hakzsam: fermi
05:40 robclark: since I'm too lazy to checkout 3.18, anyone know offhand if that fxn was renamed to something else in current upstream (or if the issue is expected to still exist in upstream)?
05:41 robclark: doesn't seem to do this very often, but very occasionally it can't come back from dpms-off..
05:43 hakzsam: nouveau_i2c_acquire_pad has been renamed to nvkm_i2c_acquire_pad a few weeks ago
05:44 robclark: thx
05:49 robclark: based on trying to deref 0x8, I kinda suspect it might want something like: http://hastebin.com/raw/esavoqukaz .. or at least owner==NULL would give owner->parent 0x8.. no idea if that is a symptom of some missing locking or something like that..
05:50 robclark: I'll build a kernel w/ a bit of extra debug in a bit..
05:54 xexaxo: mlankhorst: duuude, why didn't you mention it was about race conditions in libdrm :P
05:55 xexaxo: that thing is interesting but a bit above my expertise atm.
05:55 hakzsam: robclark, if it fixes the issue for you, could you please submit the fix to the bug I mentioned a bit earlier?
05:55 xexaxo: mlankhorst: mind if I cover all the other parts of the series ?
05:56 xexaxo: there isn't much in "all the other" but I'll try to make the most of it :)
05:58 mlankhorst: xexaxo: well part 2 doesn't involve race conditions!
05:58 mlankhorst: :D
05:58 mlankhorst: and part 1 has a dumb testcase that 1. shows the problem, 2. ensures the solution works, even tested in valgrind with --free-fill! :D
06:02 robclark: hakzsam, sure, will do..
06:02 hakzsam: thanks
07:34 mlankhorst: who is this patrick baggett..
07:35 imirkin: name sounds familiar
07:35 imirkin: and the if; lock; if pattern _is_ considered dangerous by many
07:36 imirkin: although frankly i can never remember the exact reasons
07:36 mlankhorst: your compiler is fucking broken if it reorders it
07:36 imirkin: right, the mutex implies a compiler barrier
07:36 imirkin: so that really oughtn't happen unless you are explicitly the idiot in the equation
07:36 mlankhorst: if it's about races probably..
07:37 mlankhorst: but in my case once ->next is true, it can never be false again
07:37 mlankhorst: until bo is deleted
07:37 mlankhorst: so it's harmless..
08:20 imirkin: mwk: any idea what the difference between suld.b and suld.p is on nvc0? it appears that the suld.p variant can take both a register and a constant for the image arg... which i thought is what the .b variant was for
08:20 imirkin: (or calim ---^)
08:44 mwk: umm.
08:44 mwk: wasn't that about pixel coordinates or byte coordinates?
08:44 mwk: and, more importantly processed/not
08:47 imirkin: mwk: hm, well i was going by the tex instruction. but you could be right, that would make a *ton* more sense
08:48 imirkin: mwk: fwiw both suld.p and .b have 1d/2d/etc modes
08:48 imirkin: (i am, btw, relying entirely on nvdisasm for this info)
08:53 mwk: yeah, I'm quite sure it's about byte/pixel access
08:53 mwk: I also recall it was *very* ugly
08:53 imirkin: ok, coz on tex, tex.b == indirect
08:53 imirkin: hence my confusion :)
09:24 mlankhorst: imirkin: i think entering a function counts as compiler barrier for non-pure/const functions, but of course mutex_lock would have the memory barriers..
09:26 imirkin: mlankhorst: yeah, but the compilation unit doesn't see the barriers
09:26 imirkin: mlankhorst: makes sense that entering a function acts as a compiler barrier... but it seems really pessimistic
09:26 mlankhorst: shrug
09:26 imirkin: i guess it'd just create too many annoyances to not assume that
09:27 mlankhorst: plus in case of dynamic linking, what if I swap out that function for something that modifies head->next
09:27 mlankhorst: it would fail to run in some mysterious way
09:27 imirkin: :)
09:27 mlankhorst: in short, don't trust people who don't trust their locking primitives..
09:37 mlankhorst: I was going to commit the libdrm stuff without the if check but with all this stupid nonsense I'm going to commit it with the if check..
09:39 imirkin: mlankhorst: oh, i'm sure your original mechanism is fine -- i was just trying to match up my understanding of how things worked with reality
09:55 mlankhorst: yeah
09:55 mlankhorst: fine this is the last mail I'll spend on it
09:56 mlankhorst: I'm going to commit it with the extra check just for patrick
11:27 mlankhorst: I don't really think "memory barrier"
11:27 mlankhorst: is the right word though, not that it matters. It's more like "all writes
11:27 mlankhorst: need to finish and all *previous reads are* *invalid*". Anyways, you've
11:27 mlankhorst: definitely proven to me that the solution is fine.
11:27 mlankhorst: ... how is that NOT a memory barrier?
11:27 imirkin: you seem overly aggravated by this...
11:28 imirkin: it's more of a compiler barrier, in fairness, than a mb() style memory barrier
11:28 imirkin: which is more about cache coherency or whatever
11:35 mlankhorst: :P
11:36 mlankhorst: It's just frustrating to me that people spout such things that can be easily disproven by just compiling the simplest c program you can think of
11:40 imirkin: meh. _i_ learned something!
12:03 huehner: imirkin: hi, after how much time should i ping on the list on the gm206 patches i send?
12:03 huehner: as didn't see any reply so far
12:03 imirkin: huehner: well, ben's on vacation afaik
12:03 imirkin: i assume he's back next week
12:04 imirkin: if you think there's particular urgency around your patches (which i don't think there is), you can always ping dave
12:27 huehner: imirkin: no nothing urgent, just wondering, lets just wait
12:27 huehner: imirkin: thanks for the info
12:29 imirkin: in the meanwhile you can enjoy your unaccelerated fb :)
13:39 mlankhorst: oh well not a complete waste then :)
14:04 mupuf: hey, if anyone is using a fermi (especially an nvc1/gf108), please send me the result of nvapeek e114 8
14:04 mupuf: seems like there is a new funky pwm on this one!
14:05 RSpliet: play that funky pwm, white boy
14:05 imirkin: 0000e114: 0000021c 00000169
14:05 mupuf: that may explain some complaints about noisy fans
14:05 imirkin: [on my GF108]
14:05 mupuf: 108 is nvc1, right?
14:05 imirkin: yes
14:05 mupuf: imirkin: ^^
14:05 mupuf: hmm
14:05 imirkin: no fan complaints here
14:06 mupuf: so... I wonder how I can detect this funky pwm controler
14:06 mupuf: didn't see anything in the vbios
14:06 mupuf: i'll check again
14:06 imirkin: i can send you mine if you like
14:07 mupuf: yeah, please
14:08 imirkin: in my homedir on reator nvc1-vbios.rom
14:09 mupuf: got it, thanks
14:09 mupuf: so far, no change in the GPIO table
14:11 aarwine: hrm, trying to figure out which drivers support kepler nvea :\
14:13 imirkin: aarwine: GK20A should mostly work...
14:13 aarwine: thanks, I'll look into it
14:13 imirkin: i think you have to have blob firmware for them though
14:13 imirkin: i think nvidia semi-distributes it (not sure what the latest status is)
14:14 aarwine: the latest status is verified to be confusing
14:14 aarwine: :)
14:14 imirkin: i keep meaning to look at using nouveau fw for it, but... time... effort... heh
14:15 imirkin: i had no end of trouble getting that board to boot. i've finally gotten sufficient instructions to get it working, but haven't acted on those yet
14:17 mupuf: imirkin: wow! thanks, our vbios are almost identical
14:17 mupuf: I diffed them and there is not much of a difference
14:17 aarwine: it looks like gk20a was merged ina while abck
14:17 mupuf: I did see one that may hold the key to the change in behaviour
14:17 imirkin: aarwine: yeah, but you still need ctxsw fw for it to work
14:17 mupuf: one bit in the GPIO table (NEG)
14:18 imirkin: mupuf: fwiw it claims to be a "GeForce GT 620" as well
14:18 mupuf: well, it certainly is almost the same!
14:19 imirkin: aarwine: you're looking for nvea_fuc409[cd] and nvea_fuc41a[cd] (or something like that)
14:19 RSpliet: mupuf: could that mean the logic is inverted? :D as in: the hotter it gets, the slower the fan goes?
14:19 imirkin: hehehe
14:19 mupuf: RSpliet: it is normally to say that 0 or 1 = full powe
14:19 mupuf: r
14:20 mupuf: thus, in the inverted mode, you need to set 100 - wanted_power
14:20 RSpliet: mupuf: yeah, but I assume you hook it up to a PWM... would the PWM signal be inverted too?
14:20 mupuf: however, ilia's board indeed is reverse (unless the temperature is quite high)
14:20 imirkin: mupuf: but... my fan control works fine (i think)
14:21 mupuf: imirkin: sure, it does not surprise me
14:21 mupuf: RSpliet: don't invert the signal, just invert the duty cycle
14:21 imirkin: oh ok. the way you said it made it sound like i had one of the problem boards
14:21 mupuf: it does the same job
14:21 mupuf: nope
14:24 RSpliet: mupuf: my definition of a signal is a "stream" of highs and lows. The duty cycle is the fraction of high / low for given period. If you invert the signal, you obviously invert the duty cycle as well ;-)
14:25 mupuf: the duty cycle is tOn / (tOn + tOff)
14:25 imirkin: it's all about defining "on" and "off"
14:25 mupuf: you cannot change that
14:25 imirkin: good thing we have things like "active-high" and "active-low" which allow us to get even more confused!
14:25 mupuf: yep!
14:26 mupuf: in any case, DEF 0 and DEF 1 tell you which way to set the fan speed to 100
14:26 mupuf: ok, have to sleep
14:27 mupuf: see you
14:27 imirkin: wait, did you try flipping it on your board?
14:27 mupuf: I will solve this mystery later
14:27 mupuf: ?
14:27 imirkin: just echo a 100 into pwm
14:27 imirkin: and see if the fan slows down
14:27 imirkin: (right?)
14:28 mupuf: oh, it won't work
14:28 imirkin: oh
14:28 mupuf: on the other kind of PWM, you set the divider exactly the same
14:28 mupuf: 21c usually
14:29 mupuf: and then, instead of having duty=0 to duty=21c, you vary it from 0 to .... d
14:29 mupuf: and 0 in the first case == 0% pwr
14:30 mupuf: whereas 0 in the other case == 30% pwr
14:30 imirkin: ok
14:31 mupuf: no idea where this 30% comes from
14:31 mupuf: nor how are we supposed to use one or the other
15:26 imirkin: aarwine: you might try #tegra btw
16:54 aarwine: imirkin: thanks! ( I'm still struggling )
16:55 imirkin: aarwine: what issue are you having?
16:56 aarwine: everything is strange with this box; nothing even shows up with lspci
16:57 aarwine: nouveau isn't showing up in loaded modules yet, but I'm not really sure where to even start
16:57 imirkin: pastebin dmesg
16:58 aarwine: I'm guessing i missed a compiletime option, but it would be nasty if that's true because i used a kernel profile from the chromebook trees
16:59 imirkin: why would you expect it to show up in lspci btw?
17:00 aarwine: I guess it makes sense, as it's integrated but I'm going crazy trying to verify anything supports this thing, which is componded by the fact that I can't verify what version I really do have
17:00 aarwine: ( getting the dmesg )
17:02 aarwine: http://sprunge.us/ZUDR
17:03 imirkin: Linux version 3.10.18
17:03 imirkin: yeah, that won't have nouveau.
17:03 imirkin: you want linux 3.19 or something
17:03 aarwine: ack
17:03 aarwine: Ok
17:03 aarwine: I wonder if that'll even work
17:03 aarwine: :X
17:03 aarwine: was planning on trying anyway, so thank you
17:04 imirkin: with 3.10 you'd have to use blob drivers... or some sort of backport
17:07 aarwine: bah, latest chromeos branch is 3.14; i'm not entirely sure mainline will work, but I'm not opposed to trying it
17:08 imirkin: ah yeah, i highly doubt nouveau would work on chromeos
17:08 aarwine: oh I'm on arch, just using their kernel sources
17:08 aarwine: arch arm
17:09 imirkin: what's wrong with upstream?
17:10 aarwine: I dunno yet, just didn't want to tackle too many things at once, the arch wiki says it won't install on this model
17:11 aarwine: I've got the cross-compile toolchain setup on this machine so I'll know in an hour or so
17:14 aarwine: hrm, i was also using a wireless blob; but it looks like mainline has a wireless driver for me
17:14 imirkin: yeah, check with #tegra for the various details.
23:21 mlankhorst: morning
23:38 gnurou: aarwine: see the repos in https://github.com/NVIDIA/tegra-nouveau-rootfs if you want to get GK20A working
23:39 gnurou: aarwine: right now *almost* all the required stuff is upstream, but not enough for it to work perfectly out-of-the-box, so we still have to maintain these repos
23:39 gnurou: hopefully not for too long