00:23 sooda_: yo, does anybody else than skeggsb know how the post-refactor nvif should be used? or has that been even decided yet? :P in particular, i'd like to write to a specific memory location in a gr context (per channel) but i'm not sure if this would be more suitable in gf100_fermi_mthd() (where i can't find how to get the associated chid) or in the fifo side that creates the ctx via engine_ctor...
00:30 hakzsam: imirkin, those drv-queries need a debug build
00:31 hakzsam: imirkin, for metric-issued_ipc, I bet you issued less than 1 isnt / cycles and as the hud doesn't still display floats, you see 0 ;)
00:31 hakzsam: try with heave, valley or something
01:00 pmoreau: gnurou, imirkin: +1 for renaming to NVIDIA conventions. I did it to some extent for LINEAR, TILED to PITCH, BLOCKLINEAR when integrating the EVO stuff
01:37 skeggsb: sooda_: https://github.com/skeggsb/nouveau/commit/8abd3f9a2c52c34e5268c58ee11a06496b363524
01:37 skeggsb: like that
02:25 sooda_: skeggsb: well that's nice, thanks :D
02:28 sooda_: still trying to wrap my head around this whole thing, it's nice but complex
03:54 pmoreau: karolherbst: Could you please tell me again which regs you were after on my laptop?
03:55 karolherbst: 0x02010c and 0x020074
03:56 pmoreau: K, I'll run that right now
03:56 karolherbst: maybe 20480 too
03:56 pmoreau: Hum three of them… I might lack time for that then. :-
03:56 karolherbst: or just all listed here: https://gist.github.com/karolherbst/1854da8068b510d4cc14 :D
03:56 pmoreau: :-p
03:57 karolherbst: well
03:57 karolherbst: I am not interested in all of them directly though
03:57 karolherbst: if 20480 is set, then the value
03:57 karolherbst: the thresholds I only want to know if they are set
03:57 karolherbst: status doesn't matter
03:58 karolherbst: I want to understand what the blob does when these regs aren't set through the vbios script
03:58 pmoreau: Would you like me to add the results as a comment to your gist or paste them here?
03:59 karolherbst: it actually depends
03:59 karolherbst: I am pretty sure the blob won't set most of the regs anyway
04:00 karolherbst: and 20074 seems to be set to something stupif through the vbios
04:01 karolherbst: pmoreau: well even your trace seems to indicate the values may be all empty on your nva0 card :/
04:01 pmoreau: On Nouveau, G96: ..., ..., 6e, 67, ...,..., 7d, ...
04:02 karolherbst: mhhh
04:02 pmoreau: Nouveau still, MCP79: ..., ..., 87, 5d, ..., ..., ..., ...
04:02 karolherbst: 87 :O
04:03 karolherbst: that's 135°C
04:03 karolherbst: I bet nouveau sets this value though
04:03 pmoreau: That's the value reported by sensors as well (for emerg)
04:04 karolherbst: yeah I know
04:04 karolherbst: but usually nouveau doesn't touch the value when it's set I guess
04:04 pmoreau: I can reboot on the blob to compare
04:04 karolherbst: yep, would be nice
04:07 pmoreau: NVIDIA, G96: 40000104, 6e, 60, ..., ..., 7d, ...
04:08 pmoreau: NVIDIA, MCP79: 40000304, ..., 7d, 5e, ..., ..., ..., ...
04:08 karolherbst: oaky
04:08 karolherbst: so the blob does set some values
04:08 pmoreau: Oh BTW, I did run Nouveau with config=NvForcePost=1
04:08 karolherbst: and it doesn't use the THRESHOLD_2 anymore, but 4
04:08 karolherbst: doesn't matter actually
04:09 karolherbst: I think ptherm just executes the script itself from the vbios
04:09 pmoreau: Ok
04:09 pmoreau: Some more testing needed?
04:09 karolherbst: don't think so
04:09 karolherbst: mhh well maybe to activate the fsrm
04:10 karolherbst: but not now anyway
04:10 pmoreau: I don't want to burn my laptop! :-D
04:10 karolherbst: forcetemp :p
04:10 pmoreau: :-)
04:10 karolherbst: well
04:10 karolherbst: you could do one thing
04:10 karolherbst: nvaforcetemp below the CRIT value, but above the THRESHOLDS
04:10 karolherbst: check the status
04:10 karolherbst: and check freq used in nvidia-settings
04:11 karolherbst: with normal temp and forcedtemp
04:11 pmoreau: Of all those regs? Or whcih which status do you mean?
04:11 karolherbst: status is 201e0
04:11 pmoreau: K
04:11 karolherbst: well first check the freq with nvidia-settings
04:11 karolherbst: I only need this for one gpu anyway
04:12 pmoreau: How does nvaforcetemp work?
04:12 karolherbst: just specify the temperature you want to use in decimal
04:12 karolherbst: 0 to restore
04:12 karolherbst: you don't want to go above the CRIT value :D
04:13 pmoreau: :-D
04:13 pmoreau: So something below 7d
04:13 karolherbst: yeah
04:13 karolherbst: but above 5e
04:14 karolherbst: this should cut the freq a bit :D
04:15 pmoreau: graphics and processor were halved, memory stayed the same
04:15 pmoreau: 201e0: ...
04:15 karolherbst: okay, I figured
04:15 karolherbst: tesla seems to use a different status reg
04:16 karolherbst: but only halfed?
04:16 karolherbst: mhhh
04:16 karolherbst: which temp did you set?
04:16 pmoreau: Ouch, on the MCP79: 125 -> 15, 250 -> 31!!!
04:16 karolherbst: yeah
04:16 karolherbst: that's more like it
04:16 pmoreau: still 201e0: ...
04:16 karolherbst: yeah, I check the reg
04:16 karolherbst: 0x20048 maybe
04:17 pmoreau: Weird that it only halved on the G96
04:17 karolherbst: mhh no
04:17 karolherbst: it isn't
04:17 karolherbst: the fsrm works with teo thresholds
04:17 karolherbst: the first one halfs (also on my kepler
04:17 karolherbst: )
04:17 karolherbst: the second one does more
04:17 karolherbst: the formular on my kepler is: real_freq = set_freq / ((fsrm_div / 2) + 1)
04:18 karolherbst: the first thresholds sets div to something between 0 and 7
04:18 karolherbst: 2 currently
04:18 karolherbst: the seond one sets it to something 8-f
04:18 karolherbst: e currently
04:18 pmoreau: On the MCP79, 20048: before ff, after 13800 (talking about the temp rise)
04:18 karolherbst: e/2 + 1= 8
04:18 karolherbst: so clock cut by 8
04:18 karolherbst: k
04:19 karolherbst: cur_div = 8
04:19 pmoreau: ff -> 11800 on my G96
04:19 karolherbst: 250/8 = 31.25 so this seems to be right
04:20 karolherbst: 11800: div=2
04:20 karolherbst: so clock is halfed
04:20 karolherbst: okay
04:20 pmoreau: Nice! :-)
04:20 karolherbst: so this seems to be right
04:20 karolherbst: see the 1 and 3 from the CFG reg?
04:21 karolherbst: this is the thing the fsrm is set to when the thresholds hit
04:21 karolherbst: seems like on your cards there is only one threshold though then
04:21 pmoreau: Oh ok
04:21 karolherbst: so on tesla the formular is more like real_freq = set_freq/ fsrm_div
04:21 karolherbst: :D
04:22 karolherbst: 2 ^ fsrm_div actually
04:23 pmoreau: Well, it still does the job pretty well
04:23 karolherbst: mhhh
04:23 karolherbst: one could argue about that
04:23 karolherbst: half clock means 16% less power consumption on my gpu
04:23 karolherbst: that's not _that_ much
04:23 karolherbst: if you think about the situation the gpu is in
04:24 pmoreau: So it only halfs the current frequency? Doesn't it also downclock to the lowest perlvl as well?
04:25 karolherbst: mhhh
04:25 pmoreau: Hum, maybe it doesn't make sense to half the frequency then if you downclock.
04:25 karolherbst: no
04:25 karolherbst: setting the perlvl is the task of the driver
04:26 karolherbst: there is a lower threshold which tells the driver to downclock (I bet ptherm sends an interrupt)
04:26 karolherbst: but the driver does that
04:26 pmoreau: Understood
04:26 karolherbst: the fsrm is a stupid thing, which just lowers the clock
04:26 karolherbst: you can also have the fsrm active on highet clocks
04:27 pmoreau: I guess NVIDIA computed that halving the clocks was enough to keep it under a certain temp no matter what (well, maybe not if mupuf is around with a hairdryer)
04:28 RSpliet: fsrm is a safety mechanism to instantly protect cards that run hot, without relying on the driver to intervene
04:29 RSpliet: so under high CPU load or more nasty cases, the hardware is still protected
04:29 karolherbst: RSpliet: yeah, but then you don't just half the clock
04:29 karolherbst: another thing is, the gpu will be kept at the threshold
04:29 karolherbst: so the fsrm just prevents the gpu from getting hotter actually
04:30 RSpliet: with the old cards (pstate, no cstate) it makes sense to have this as your throttling mechanism
04:30 karolherbst: RSpliet: yeah, but a higher divider means less heat, a divider of 8 "just" means half power consumption on my gpu
04:30 RSpliet: karolherbst: it's a last resort, the card shouldn't run this hot in the first place, and it might help prevent shutdown
04:30 karolherbst: yeah I know
04:31 karolherbst: but I wouldn't trust a divider of 2
04:31 karolherbst: but there is the CRIT thresholds too
04:31 RSpliet: I'd trust whatever NVIDIA is doing, they likely had some engineers doing the measurements
04:31 karolherbst: and then the gpu just disables some stuff
04:32 karolherbst: yeah as long as the crit thing is set to some reasonable value
04:32 karolherbst: at least I know now that 125°C is the default value when we don't know anything else
04:32 karolherbst: which is a good thing to know
04:33 karolherbst: nouveau currently uses 135°C
05:01 karolherbst: RSpliet: what fermi cards do you have?
05:17 RSpliet: karolherbst: hahahahahahahahahahaha
05:17 RSpliet: cardS
05:17 RSpliet: :-P
05:17 RSpliet: I have an NVC4, full stop
05:17 RSpliet: and I 'll probably have to hand it in when I get home today
05:18 karolherbst: :D
05:18 karolherbst: k
05:19 karolherbst: I think I have a nvc1 here
05:23 pmoreau: RSpliet: Come to think of it: I could plug my NVC0 on my work computer and get some stuff out of it if you need.
05:24 pmoreau: imirkin: Same goes for you, I think there should be enough place in my work computer to plug the 960.
05:36 RSpliet: pmoreau: thanks for the offer, we'll look into your NVC0 later
11:06 hakzsam: imirkin, I should wait for the first coffee before answering :). Actually, metric-issued_ipc is a ratio (ie. inst_issued / active_cycles), so if inst_issued < active_cycles, you get 0...
11:06 hakzsam: I should definitely send a patch to allow the HUD to display floats
11:06 imirkin_: hakzsam: either way, it seemed less-than-interesting :)
11:07 imirkin_: i would have expected a float
11:07 imirkin_: but you can scale it up by 100 or something and make it a percent
11:08 hakzsam: yeah, that's possible :)
11:08 hakzsam: imirkin_, why did you test that metric btw?
11:08 hakzsam: out of curiosity
11:08 imirkin_: i forget... glxgears maybe?
11:09 hakzsam: did you try the other ones?
11:09 hakzsam: feel free to report me any weird results like that ;)
11:09 imirkin_: it just said 0, i assumed it was broken and moved on
11:09 imirkin_: i didn't *actually* care, i was just a bit curious
11:10 hakzsam: okay, cool
11:10 imirkin_: i know nouveau's not perfect, but 0 seemed a bit low :)
11:10 hakzsam: I'll fix it then
11:10 hakzsam: sure
11:13 tflink: I apologize if this is a repeated question but I couldn't find anything after much searching - is basic 2d expected to work w/ 4.4rc5 and GM107 chips?
11:13 tflink:isn't sure whether to file a bug or not
11:14 imirkin_: tflink: can you define what "basic 2d" is?
11:15 tflink: imirkin_: allows computer to boot and have native resolution
11:15 imirkin_: tflink: yes, that is expected to work starting... 3.18 or so? i forget exactly
11:15 imirkin_: tflink: but take a look at this bug, on the off chance you're misdiagnosing your issue: https://bugs.freedesktop.org/show_bug.cgi?id=93373
11:16 tflink: that's easily possible - I haven't spent much time triaging nouveau stuff
11:17 imirkin_: tflink: pastebin dmesg + xorg log
11:17 tflink: that's going to be difficult, if I don't disable nouveau this machine doesn't boot
11:18 imirkin_: perhaps we have different definitions of 'boot'
11:18 imirkin_: a machine with non-working display still boots, you just can't see it on the monitor :)
11:18 imirkin_: and logs still get generated
11:18 tflink: it pivots from dracut to systemd but the cpu stalls with error messages and the machine is unresponsive
11:19 tflink: can't switch VTs etc. but I'll look through the logs to see what all was recorded
11:19 imirkin_: i want to see everything up to and including those error messages
11:19 imirkin_: i believe systemd has a logging system which allows you to retrieve logs
11:19 imirkin_: but i haven't the faintest idea how to operate it
11:20 imirkin_: i just do 'less /var/log/messages' and everything i care about is right there
11:50 RSpliet: karolherbst: I now have zero fermi cards
11:50 karolherbst: :D
11:51 RSpliet: that's nothing to smile about
11:51 RSpliet: although it does force me to take a break, which is good
11:51 karolherbst: see
11:51 karolherbst: how far are you by the way with the fermi stuff?
11:52 imirkin_: RSpliet: wait, are you out of nv50 cards too?
11:52 RSpliet: I think about 80%, but it looks like a tornado went past
11:52 RSpliet: imirkin_: oh I have a mountain of those
11:52 karolherbst: more core or more memory?
11:52 RSpliet: just none that I can't reclock
11:52 imirkin_: right, that's what i meant by "out of"
11:52 RSpliet: I only focussed on mem
11:52 karolherbst: k
11:53 karolherbst: RSpliet: well if you want you could take a look at the FSRM stuff on tesla cards
11:53 tflink: imirkin_: syslog: http://paste.fedoraproject.org/301289/02088711/ xorg: http://paste.fedoraproject.org/301293/20916314
11:53 RSpliet: karolherbst: no
11:53 RSpliet: :-P
11:53 karolherbst: :D
11:53 RSpliet: sorry, I'm going to take that break quite serious
11:53 karolherbst: k
11:53 RSpliet: I'll probably get bored next week, when I have my NVA8 and NVAC
11:54 RSpliet: (you've got trace + VBIOS, so don't know what else you need tbh)
11:54 tflink: it looks like this'll be an interesting issue to track down - I was able to reboot without nomodeset 3 times before it failed again
11:54 karolherbst: ohh I thought you meant a break like a month or more
11:54 imirkin_: tflink: ok, so this is an optimus system?
11:55 karolherbst: RSpliet: yeah well, finding the right temperature threshold is the bigger issue
11:55 mupuf: karolherbst: what other issues are there?
11:55 karolherbst: mupuf: well, I don't know actually :D
11:56 mupuf:doesn't get why you are stuck on this :s
11:56 karolherbst: mupuf: here is my first version for gf119 cards anyway: http://paste.fedoraproject.org/301289/02088711/
11:56 tflink: imirkin_: I didn't think it was
11:56 karolherbst: gf119+
11:56 mupuf: but I don't want to hear until thursday, when I am in France
11:56 karolherbst: :D
11:56 karolherbst: :p
11:56 karolherbst: too late
11:56 karolherbst: no, on fermi and later I got it already
11:57 karolherbst: ohh I have to check against too low temperatures too, meh
11:57 imirkin_: tflink: try booting with nouveau.modeset=0
11:57 tflink: imirkin_: but it is a laptop. i assumed not optimus because it's skylake and the graphics worked with 4.2
11:57 imirkin_: that should disable just nouveau
11:57 mupuf: what is this crash?
11:58 imirkin_: looks like "nouveau 0000:01:00.0: Refused to change power state, currently in D3"
11:58 imirkin_: which is then in turn not handled particularly well
11:58 imirkin_: also, when tflink says "reboot" he really means "suspend/resume"
11:58 karolherbst: imirkin_: I think the card is accessed while it is off anyway
11:59 karolherbst: mhh
11:59 tflink: imirkin_: I do?
11:59 karolherbst: there are quite a few issues in the trace :O
11:59 karolherbst: *log
11:59 imirkin_: tflink: those logs have suspend/resume cycles in them
11:59 karolherbst: " x86/mm: Found insecure W+X mapping at address ffff880001c00000/0xffff880001c00000"
11:59 karolherbst: "Info: mapping multiple BARs. Your kernel is fine."
11:59 karolherbst: but I have no idea what they do anyway
12:00 tflink: i was doing a reboot - it went from UEFI to grub to boot
12:00 mupuf: karolherbst: right, so it is not related to your code
12:00 mupuf: anyway, one more evening of studying!
12:00 karolherbst: no :O
12:00 imirkin_: tflink: are you doing hibernate perhaps?
12:00 mupuf: but, before I forget, what cards would you need for 10 days?
12:00 tflink: imirkin_: 'reboot' as root from the terminal
12:00 mupuf: I want to solve the nvafakebios issue
12:01 karolherbst: mupuf: mhh I have to remeber, ohh that was because of the unk50 and unk5c tables... so keplers
12:01 imirkin_: tflink: well, your system logs indicate multiple suspend/resume cycles
12:01 karolherbst: no sure anymore though
12:01 mupuf: and have a look at the tk1 one again
12:01 mupuf: hakzsam: what do you need?
12:02 tflink: setting nouveau.modeset=0 gets me to the lightdm
12:02 karolherbst: imirkin_: ohhh I think I know what is going on :/
12:03 karolherbst: tflink: does this happen like after login?
12:03 tflink: after login? i can't get to the point where i can login, the boot process hangs before the dm is started
12:03 karolherbst: did you try nouveau.runpm=0 ?
12:03 tflink: nope, will try
12:04 karolherbst: imirkin_: libpcieaccess has an issue, where the nvidia card is woken up, when you init the library in your application
12:04 karolherbst: like when you call glxinfo
12:04 karolherbst: and there are some application which just call glxinfo and with bad timing, stuff just goes a bit crazy
12:06 tflink: setting nouveau.runpm=0 also got me to the dm
12:06 karolherbst: in fact in his log the card goes off and then later it is woken up
12:06 karolherbst: and I am sure this is because of pcieaccess
12:07 karolherbst: or Xorg enumarates over all gpus or whatever
12:08 karolherbst: tflink: yeah well, now your nvidia gpu is always on, which is a problem :D
12:09 tflink: it's better than not booting to the dm or 800x600 graphics :)
12:09 tflink: karolherbst: do you know if there's a bug filed for the issue?
12:09 karolherbst: not quite sure
12:09 karolherbst: tflink: do you have a xorg.conf?
12:10 karolherbst: if not create one under /etc/xorg.conf with this content: http://pastebin.com/RPm8FUmk
12:10 karolherbst: and remove the runpm thing
12:10 karolherbst: and see if that helps
12:10 karolherbst: if that helps, you want to enable DRI3 for the intel ddx and tehn you can use prime offloading through dri3
12:13 tflink: it's back to stalling before starting the dm
12:13 karolherbst: mhh
12:13 karolherbst: it shouldn't really :/
12:14 karolherbst: ohh
12:14 karolherbst: wrong path
12:14 karolherbst: tflink: /etx/X11/xorg.conf
12:14 tflink: ok
12:14 karolherbst: ...
12:14 karolherbst: wrong again
12:14 karolherbst: /etc/X11/xorg.conf
12:14 karolherbst: now it is good
12:14 tflink:used /etc/xorg.conf
12:15 karolherbst: yeah I know, it was wrong
12:15 karolherbst: you can move the xorg.conf file into /etx/X11 though
12:15 karolherbst: but
12:15 karolherbst: check if there is one already
12:18 tflink: no dice, looks to be the same hang
12:19 karolherbst: then your xlog please
12:19 karolherbst: ohh wait
12:19 karolherbst: it won't help
12:19 karolherbst: I think this is some automatic behaviour of X then
12:19 karolherbst: mhhh
12:21 karolherbst: something while waking up the gpu just fails then :/
12:21 karolherbst: ohhhhh
12:21 tflink: in case it's useful: http://paste.fedoraproject.org/301312/14502108/
12:22 karolherbst: ohh wait
12:22 karolherbst: this is another issue
12:22 karolherbst: huh wait
12:22 karolherbst: tflink: what gpus do you have?
12:23 RSpliet: tflink: why the <insert profanity here> do you have nomodeset in your kernel args?
12:24 karolherbst: RSpliet: imirkin_ told him I think :p
12:24 karolherbst: but yeah
12:24 karolherbst: that should be go too :D
12:24 karolherbst: tflink: remove nomodeset :D
12:24 karolherbst: the intel ddx is very unhappy otherwise
12:25 RSpliet: if you just want to disable the NVIDIA GPU, go for nouveau.modeset=0 instead
12:25 karolherbst: tflink: and install the dummy Xorg module please :)
12:25 tflink: RSpliet: because that was the only way I found could get booted to the point where i could login
12:25 karolherbst: RSpliet: we are debugging some nouveau wakes up gpu => hang issue
12:26 karolherbst: ay....
12:26 karolherbst: yeah
12:26 karolherbst: RSpliet: his kernel is stuck herE: https://github.com/karolherbst/nouveau/blob/master/drm/nouveau/nvkm/subdev/pmu/base.c#L202
12:27 karolherbst: like when the card doesn't wake up the right way or something is messed up, nvkm_timer_read returns the same value
12:27 karolherbst: always
12:27 karolherbst: and you can guess what that means ;)
12:27 tflink: is there a better way to force basic video than nomodeset?
12:27 karolherbst: tflink: remove nomodeset and reboot
12:27 karolherbst: :D
12:27 karolherbst: it should work
12:27 tflink: I did
12:27 karolherbst: mhh
12:27 karolherbst: then x log
12:27 Dezponia: And I'm also here, for no reason right now, just saying hai
12:27 RSpliet: tflink: if it's an optimus set-up, nouveau.modeset=0 is the way to go
12:27 Dezponia: Soooo... hai
12:28 Dezponia: RSpliet: Where were you from anyway?
12:28 hakzsam: mupuf, a fermi please
12:29 karolherbst: meh
12:29 karolherbst: we _have_ to fix all those runpm issue at some point, they seem to pile up quite nice now :/
12:30 tflink: RSpliet: in general, i use 'nomodeset' as a semi-generic way to force the most basic graphics when something's not working - is there a better general way?
12:30 tflink: http://paste.fedoraproject.org/301322/45021139/
12:31 tflink: ^ xorg.log from last hung boot
12:31 karolherbst: skeggsb: is there a reason why nvkm_msec is using the timer on the gpu? because this causes a lot of issues when the gpu is in a faulty state
12:31 karolherbst: tflink: did you remove the xorg.conf?
12:31 tflink: no
12:31 karolherbst: meh :/
12:31 karolherbst: stupid xorg server
12:32 karolherbst: tflink: you could try to add this to the xorg.conf file: http://pastebin.com/SZUvLNBA
12:32 RSpliet: tflink: no there's no better general way, nouveau.modeset=0 is more specific rather, keeps the intel GPU running at full steam while still disabling nouveau. nomodeset effectively just disables the entire driver. Don't ask me about it's mechanics
12:33 karolherbst: I don't understand why somebiody would want to use nvkm_timer_read when he just wants to wait 4 seconds for something
12:33 karolherbst: why bother doing iommu request all over again just for a wait?
12:34 tflink: karolherbst: that worked, i got to the dm
12:34 karolherbst: tflink: can you also login?
12:35 tflink: yes but the fans seem to be at 100% now
12:35 karolherbst: yeah well :/
12:35 tflink: there are worse things, just figured I would add it in case it was relevant
12:35 karolherbst: maybe because the gpu is off and the EC doesn't like it
12:35 karolherbst: who knows
12:36 pmoreau: hakzsam: The offset for kernel inputs on Fermi+ is 0x20, right? And you put them in c0?
12:36 karolherbst: tflink: does sensors show any high temperatures?
12:38 hakzsam: pmoreau, yeah, c0 but I don't remember what is the offset
12:38 pmoreau: Ok, then the offset is probably correct as well
12:39 pmoreau: Need to figure out first why RA is crashing on Tesla, while it used to work and still works on Fermi.
12:40 hakzsam: offset seems to be 0 actually
12:42 pmoreau: Really? Hum… Where are the gridDim, offset & co supposed to go then? Other CB maybe?
12:42 pmoreau: Not there yet, but I'll hopefully soon need those. :-)
12:47 tflink: karolherbst: i ended up needing to reboot again and for some reason, that xorg.conf is no longer working - it always hangs before getting to the dm unless I turn off nouveau
12:48 tflink: xorg log : http://paste.fedoraproject.org/301334/50212493
12:48 karolherbst: yeah okay, I somehow now what the issue is, but not what is causing this
12:48 hakzsam: pmoreau, those are accessible with $nctaidX, $gridid, $tidX special registers
12:49 karolherbst: tflink: well then do like RSpliet said and add nouveau.nomodeset=1 and remove this xorg.conf file
12:49 tflink: nouveau.modeset=0?
12:50 pmoreau: hakzsam: Oh true! Maybe not the workground offset thingy, but otherwise most of them should.
12:50 hakzsam: pmoreau, yeah and we don't need to upload them with input parameters
12:50 pmoreau: tflink: Yes, nouveau.modeset=0
12:50 karolherbst: ohh right, my mistake :D
12:51 hakzsam: pmoreau, on tesla some of those bits are uploaded to s[]
12:51 hakzsam: 0x00:0x10 IIRC
12:51 pmoreau: hakzsam: That I know ;-) I did got to run get_local_id() & co. on my laptop
12:52 hakzsam: for tesla only right?
12:52 pmoreau: Yes
12:52 hakzsam: that's a good start anyways :-)
12:52 tflink: karolherbst: that gets me booted to the dm, is there a bug i can file/add to or more triage info needed?
12:52 karolherbst: no idea to be honest
12:53 pmoreau: hakzsam: The hello_world should work, I think, on Fermi+ now
12:53 hakzsam: pmoreau, nice
12:53 hakzsam: unfortunately I can't test since mesa/llvm seems to be a bit borken :)
12:53 pmoreau: hakzsam: Just waiting for someone test O:-)
12:54 pmoreau: Well, I might know how to solve it
12:54 pmoreau: I have mine back up and running
12:54 pmoreau: Thanks to karolherbst! :-)
12:54 hakzsam: cool
12:55 karolherbst: :D
12:56 karolherbst: well
12:56 karolherbst: now it is broken for me, because I have to rebuild my entire system
12:56 pmoreau: :-D
12:56 karolherbst: stupid gcc upgrade
12:56 karolherbst: but 1000 package of 1400 already done
12:56 karolherbst: *packages
12:56 pmoreau: It's not like you didn't know about it before upgrading! ;-)
12:56 karolherbst: :D
12:56 karolherbst: I wasn't aware of the consequences
12:56 pmoreau: :-D
12:56 karolherbst: like chromium also doesn't work anmymore
12:57 karolherbst: and I had to reboot
12:57 karolherbst: ....
12:57 pmoreau: Seems like fun!
12:57 karolherbst: well "had"
12:57 karolherbst: was trying to get by subwoofer working on my laptop
13:00 pmoreau: imirkin_: I might need your help: RA now bails out on Tesla, on the hello_world example while the same code used to work a week or two ago. https://phabricator.pmoreau.org/P69
13:00 pmoreau: (I did fix the constant thing by the way :-) )
13:01 pmoreau: The generated code seems reasonnable to me
13:01 imirkin_: don't you think a backtrace of when the segfault happens could be useful?
13:01 pmoreau: Maybe O:-)
13:02 pmoreau: Added as a comment to the paste
13:03 imirkin_: ooh, code i just added
13:03 imirkin_: something it hates in isShortRegOp()
13:04 pmoreau: Well, insn is a null pointer…
13:05 imirkin_: right....
13:06 imirkin_: can you figure out what lval this is?
13:06 imirkin_: and how it's getting an instruction-less use
13:06 pmoreau: seems to be r0, of size 4, but TYPE_NONE
13:07 imirkin_: what's it's defining op?
13:07 pmoreau: No value set, so it doesn't look like it's the constant
13:07 imirkin_: lval->getInsn()->op
13:08 pmoreau: lval->getInsn() is null pointer
13:08 imirkin_: that's unfortunate.
13:08 imirkin_: but lval->defs.size() != 0?
13:08 imirkin_: p lval->defs
13:09 pmoreau: Yep, == 1
13:09 imirkin_: i bet it's that stupid nop?
13:09 imirkin_: anyways
13:09 imirkin_: you can add lval->getInsn() == null to the if (lval->defs.size() == 0)
13:10 imirkin_: i don't even know why these values are still around
13:10 imirkin_: but... wtvr
13:13 pmoreau: imirkin_: Got a new exception further down (bt added to the paste), insn is NULL once again, same lval
13:14 imirkin_: hehe
13:14 imirkin_: more code i added ;)
13:14 imirkin_: add lval->getInsn() != null to the if above it
13:14 pmoreau: Yep, did that, and it works now :-)
13:15 pmoreau: And the produce code looks correct to envydis
13:15 imirkin_: ah-mazing
13:15 pmoreau: :-D
13:15 pmoreau: I don't know where that nop came from
13:16 pmoreau: But it's probably not the cause for this troublesome reg, could it?
13:18 pmoreau: imirkin_: The INFO_DBG macro is for feeding the glDebugCallback?
13:18 imirkin_: no
13:19 imirkin_: there's no way to feed it from within the compiler, i never hooked it up
13:19 imirkin_: in the rest of nouveau, you can use pipe_debug_message
13:19 pmoreau: Ok
21:22 chillfan: what is the fsrm_kepler branch?
21:29 chillfan: ah nvm will wait for karol to come back heh