03:00_171_: I'm currently reading the envytools documentation, and I don't understand what PMC.INTR_LINE_* is used for. Can anyone tell me?
03:03imirkin: is that 0x140 or something?
03:03_171_: 0x160, 0x164 and 0x168
03:04imirkin: don't know offhand, but you can check nouveau source
03:04imirkin: to see if we ever set it/read it
03:15_171_: It seems to only come up in gp100.c, which is a later card than mine, so I'll ignore it for now. It doesn't come up in my trace either.
03:18_171_: Thank you for answering me!
03:19imirkin: it's just part of the intr ack'ing procedure i guess
03:19imirkin: potentially to do with MSI
03:20imirkin: either way, i wouldn't worry too much about it
03:33_171_: Oh, is it like a way for the PCI bus to look at interrupt status?
03:53imirkin: more like to tell the GPU that the interrupt has been acked, and ready to process another one
03:55_171_: Oh, that would makes sense!
14:09karolherbst: ehhh... nouveau_screen_get_name isn't thread safe :D
14:10karolherbst: imirkin: nouveau_screen_get_name with multiple GPUs... mhhh
14:10karolherbst: annoying :p
14:13imirkin: karolherbst: yeah, it's definitely not thread-safe. it also doesn't matter for anything, so "don't care"
14:13karolherbst: well.. for CL it does
14:13karolherbst: but yeah
14:14karolherbst: but it's also easy to fix and reduces the noise of tsan
14:14imirkin: karolherbst: ok. feel free to make it cleverer, e.g. allocate something in the screen object
14:14imirkin: or have a fixed char array in the screen
14:14imirkin: since it can never be longer than a few chars
14:15karolherbst: was thinking about a 8 byte char array and just init it in screen_create
14:22imirkin: sounds fine
14:34Ariel_Cabello: Hitting some strange warning related to Nouveau, should I upload logs to pastebin?
14:34imirkin: can't hurt
14:38Ariel_Cabello: starting in line 1029
14:38karolherbst: imirkin: soo... the remaining stuff is inside nouveau_mm.c :/
14:38karolherbst: that will be painful to fix
14:39karolherbst: the mm_slab stuff
14:39karolherbst: threads are racing on the list
14:39imirkin: Ariel_Cabello: i think that lack of firmware is causing nouveau to not be happy. it doesn't get a lot of testing without the firmware, i think
14:40Ariel_Cabello: Is this the problem?
14:40Ariel_Cabello: "nouveau 0000:01:00.0: pmu: firmware unavailable"
14:40karolherbst: imirkin: well, firmware is available
14:40imirkin: that's what i'm guessing
14:40karolherbst: it's just the PMU stuff which is missing
14:40karolherbst: which is expected
14:40imirkin: oh ok
14:40imirkin: nevermind me then
14:40karolherbst: but yeah...
14:40Ariel_Cabello: hmm thats strange
14:40karolherbst: it's a known issue
14:41karolherbst: sometimes stopping the co processors doesn't work
14:41karolherbst: yeah, that's in the runpm path
14:41karolherbst: so we want to turn off the GPU but fail to stop one of the co processors running the firmware
14:42karolherbst: I think I hit it on my machine as well
14:42karolherbst: causes the GPU to go into the runpm error state
14:42karolherbst: so it's always on after this point
14:43karolherbst: skeggsb: could we ignore the falcons being stupid in the suspend paths?
15:14karolherbst: imirkin: mhhh, kind of feels like that each mm_bucket and mm_slab object needs a lock
15:15karolherbst: mhh maybe not mm_slab
15:15imirkin: iirc i just had much less fine-grained locks
15:15imirkin: around anything that could potentially use mm
15:15karolherbst: sounds... slow
15:16imirkin: fewer locks = better usually
15:16imirkin: the critical sections aren't hit that often, so wtvr
15:16karolherbst: well.. in GL maybe
15:16karolherbst: but in CL it's all super MU
15:16karolherbst: you can do like nearly everything multithreaded
15:16karolherbst: hence why I am testing with multithreaded CL tests now :)
15:17karolherbst: but I think a lock per mm_bucket isn't all too bad
15:18karolherbst: and that would be the third lock I add
18:12karolherbst: mhh, nouveau_mm_allocate is a little weird