02:04pmoreau: imirkin: I guess there's still a lot of work to do before reaching that point, but what would be needed to test your debug messages patches for clover?
02:05imirkin: pmoreau: just create a cl context with that pfn_notify thing set
02:05imirkin: pmoreau: it should get called whenever a debug message is emitted by the gallium driver
02:05pmoreau: Oh, ok
02:06pmoreau: And how can I trigger the debug message emission?
02:10imirkin: it's called by nv50_program_translate among others
02:10pmoreau: I'll give it a try then :-)
03:03pmoreau: imirkin: \o/ It worked! :-)
08:45pmoreau: imirkin: $r0l and $r0h refers to the 16 LSB (and resp. 16 MSB) of $r0, or are they special regs?
09:08mwk: pmoreau: yes, they do (assuming Tesla)
09:16pmoreau: mwk: Ok, thanks (you did assume correctly ;))
10:01imirkin: pmoreau: usually used for multiplication... there's only 16- and 24-bit integer mul on nv50, so a 32-bit mul is decomposed into 16-bit muls
10:01pmoreau: Ah, that explains things like "mul $r2 u16 u16 s[0x4] u16 $r0l"
10:02pmoreau: I'm looking at how the blob gets the thread ids, and apparently all the local ones are packed in $r0
10:03pmoreau: With local_id_x in $r0l, local_id_y = $r0h & c1[0x0], and local_id_z = $r0h >> 0xa
10:05pmoreau: And the sizes (I guess) are stored in s[0x0-0xf], which explains why data in shared starts at 0x10.
10:05imirkin: it's all coming together eh
10:53mwk: pmoreau: could've just asked, you know...
10:55mwk: sizes, GRIDID, and CTA id are indeed in first 16 bytes of s
10:55mwk: if it's enabled in... whatever method it wa
11:40Wolf480pl: imirkin, it works! 4.3-rc7 with War00C800_0=1 works on my GPU!
11:40Wolf480pl: lspci: https://gist.github.com/Wolf480pl/258c9863368d099c160a
11:40imirkin: did you have a bug open?
11:41imirkin: remind me which one?
11:42imirkin: mind updating it with the lspci info?
11:42Wolf480pl: as soon as I figure out what my bugzilla password was
11:43imirkin: on worries, i can paste it myself
11:44imirkin: Wolf480pl: btw, what laptop model is this?
11:44Wolf480pl: Medion Erazer X7827
11:45imirkin: btw if you boot with nouveau.pstate=1 you should get reclocking on it too
11:45imirkin: should be a pretty beefy gpu
11:46Wolf480pl: will try
11:47imirkin: although without some additional patches, you're likely not to get it working above the medium perf level
11:49Wolf480pl: how do I check if reclocking works?
11:52imirkin: cat /sys/class/drm/card1/device/pstate
11:52imirkin: that should list the levels as well as the current setting denoted by AC or DC
11:53imirkin: you can then echo a level (e.g. "0a") into that file which should initiate a perf level switch
11:53imirkin: check dmesg and the contents of that file to see if it succeeded
11:57Wolf480pl: at the beginning there was no current setting
11:57Wolf480pl: the file reacts to writes by showing the "AC DC *" marker, but every time I change the power level, dmesg says:
11:58Wolf480pl: fb: ramcfg data for 0MHz not found
11:58Wolf480pl: clk: failed to raise voltage: -22
11:58Wolf480pl: clk: error setting pstate 0: -22
11:58imirkin: you could try with karol's patches
11:59imirkin: btw, i meant that the AC: line indicates the current setting... that * marker is often a lie
12:00imirkin: (or rather, it doesn't reflect what you think it might reflect)
12:00Wolf480pl: oh, the AC line always shows 0, 0
12:01Wolf480pl: btw. can nouveau turn off the GPU when unused, without working pstates?
12:02imirkin: wait wtf? can you pastebin the contents of that file?
12:03imirkin: no wonder it has issues
12:03Wolf480pl: oh, wait
12:03Wolf480pl: when I actually use the GPU
12:03Wolf480pl: it shows non-zero
12:03imirkin: ohhh right :)
12:03Wolf480pl: like if I have DRI_PRIME=1 glxgears running
12:03imirkin: try reclocking while using it
12:03imirkin: not to 0e/0f though -- those almost definitely won't work
12:04imirkin: you need karol's patch for that
12:05Wolf480pl: looks like it's reclocking memory correctly
12:05Wolf480pl: "ramcfg data for 0MHz not found" is not appearing anymore
12:05Wolf480pl: but the other two still do appear with every switch
12:06Wolf480pl: the core clock is at 324 MHz all the time, but maybe it needs more load?
12:07imirkin: you might have a pwm voltage situation too
12:07imirkin: karolherbst: a guinea pig for you --^
12:08sarnex: strange question is there a kernel parameter to set vram size?
12:08Wolf480pl: ok, so running 2 instances of glxspheres64 makes the spheres slow down (190 fps each instead of 300 on a single one), but the GPU core clock doesn't go up
12:08imirkin: sarnex: don't think so... what are you trying to achieve?
12:08Wolf480pl: even though it's on 0a
12:09imirkin: Wolf480pl: is it *actually* on 0a?
12:09sarnex: some user is running out of vram on his 512M card with nine but works with wine
12:09imirkin: Wolf480pl: the last line indicates the actual settings. it probably fails to increase core clock due to the voltage situation.
12:09imirkin: sarnex: define 'running out'
12:10sarnex: game eats more than he has
12:10Wolf480pl: imirkin, yeah, I mean, it's supposed to be on 0a, and it succeeded setting RAM clock to 0a, but looks like it failed setting the core clock
12:10imirkin: which you observe how?
12:10imirkin: Wolf480pl: https://github.com/karolherbst/nouveau/commits/master_karol -- he's got a ton of patches on there, some might even help you :)
12:13Wolf480pl: I'll try to test these patches if I have time... O
12:13sarnex: hm no it seems the bug report is wrong, the game is eating all virtual memory not vram. but it doesnt happen for someone on amd. so im not sure
12:14sarnex: anyway sorry for the noise ill test myself when my card gets here
12:15imirkin: sarnex: the claim is that Metro:LL crashes on nouveau with VA exhaustion as well
12:15sarnex: yeah this is for guild wars 2
12:15imirkin: sarnex: i don't have the game, and the person who does wasn't able to make progress debugging it
12:16imirkin: i'm sure it's some dumb thing, like we're forgetting to unmap something somewhere (potentially in the kernel module), which shows up a lot faster on 32-bit than 64-bit
12:16imirkin: but without a repro, it's hard for me to debug
12:16sarnex: yeah ill test the games with my card to see
12:16sarnex: free shipping though
12:17imirkin: ... once you pay for it
12:18Yoshimo: imirkin: when will we see his stuff merged?
12:19imirkin: Yoshimo: no clue
12:20imirkin: he's not very good at sending it out, and ben's not very good at merging stuff
12:20imirkin: given that combination, maybe in 6 years? :)
12:21Yoshimo: mmhmm, could still beat maxwell firmware release though
12:23karolherbst: I wasn't phisically vailable up until now :d
12:23karolherbst: imirkin: huh
12:23karolherbst: core and memory being set to 0 MHz isn't pwm related
12:23imirkin: karolherbst: no, but the voltage fail set is
12:23imirkin: karolherbst: the 0mhz is coz the card is powered down
12:23karolherbst: imirkin: and don't tell others to use my master_karol branch :D
12:23imirkin: karolherbst: but he tried doing it while the card was powered up too
12:24karolherbst: ahh I see
12:24imirkin: karolherbst: oh? what branch?
12:24imirkin: i thought that was the same patches against older kernels
12:24karolherbst: master_karol is for personal usage :D
12:24karolherbst: maybe I should change the name
12:24imirkin: yeah, like "no_touch"
12:25Wolf480pl: imirkin, and all the nouveau team: thanks a lot for fixing this HUB_INIT bug, and for helping me with testing. I wish I could help you more, but I probably won't have time.
12:25karolherbst: better? :D
12:26karolherbst: imirkin: the setting voltage issue isn't only pwms fault
12:26karolherbst: ohh I could add stuff to my stable branch
12:26karolherbst: wait a sec
12:26karolherbst: no, it is okay
12:26karolherbst: Wolf480pl: please use my master_karol_stable nouveau brnach and retest again
12:27karolherbst: there are also some patches to show the current voltage in sensors
12:27imirkin: Wolf480pl: thank skeggsb for figuring out the c800 thing :)
12:27karolherbst: Wolf480pl: did you post your dmesg somewhere?
12:28Wolf480pl: karolherbst, dmesg of reclock?
12:28karolherbst: not really required though
12:28karolherbst: just do dmesg | grep -i voltage
12:28karolherbst: nouveau prints the current voltage on load
12:28karolherbst: if its 600000uv then you can't set your voltage at all and need the pwm patches
12:29Wolf480pl: I didn't find any printing of voltage on load in the dmesg
12:29karolherbst: if it's something higher, then it just nouveau fault for handling the voltage tables wrongly
12:29Wolf480pl: only clk: failed to raise voltage: -22
12:29Wolf480pl: I might be running w/o debug output or something
12:30imirkin: karolherbst: he's on v4.3-rc7
12:30karolherbst: then just rebase on current nouveau master
12:30karolherbst: the patches should be compatible
12:30karolherbst: ohh wait
12:30karolherbst: I can do that
12:33karolherbst: can anybody compile check that against 4.3?
12:33karolherbst: there might be a compile error inside the debugfs code :/
12:33imirkin: Wolf480pl: you should be able to build the stand-alone nouveau module now, so no need to do full kernel rebuilds
12:34Wolf480pl: btw. I found a new way to crash Xorg: `xrandr --setprovideroffloadsink nouveau Intel` and then `xrandr --setprovideroffloadsink nouveau`
12:35imirkin: what does the second command do?
12:35imirkin: (or what is it supposed to do?)
12:35Wolf480pl: no idea
12:35Wolf480pl: I tried it because I thought it might unset the offload sink
12:36karolherbst: ohh mhhh
12:36karolherbst: when you wnt to be able to unload the nouveau module at runtime (because your card crashes or stuff) you need to remove the nouveau xorg module and use DRI3 with intel
12:36karolherbst: Wolf480pl: isn't the 0f pstate somehow _unstable_ for you?
12:37karolherbst: 0e too
12:37karolherbst: this is the first card I see whree 0e and 0f are different
12:38Wolf480pl: regarding offloadsink - if the second arg is "0x0" it should unset the sink, according to manpage. This too causes Xorg crash
12:38Wolf480pl: karolherbst, I haven't used these pstates long enough to be able to tell if they're stable or not
12:41Wolf480pl: also, I'm not trying to unload nouveau at runtime
12:42karolherbst: Wolf480pl: yeah, but this just means you need to reboot then only because your gpu crashes ;)
12:42karolherbst: I hope DRI3 gets stable enough soon though :/
12:43Wolf480pl: karolherbst, it hasn't crashed yet, since I set the War00C800_0=1
12:43karolherbst: yeah, but gddr5 memory reclocking isn't stable with the nouveau stock module yet
12:43karolherbst: at least it shouldn't
12:43karolherbst: except you are lucky
12:45Wolf480pl: so my options are: 1. disable pstates, 2. risk a GPU crash forcing me to reboot, 3. rebuild mesa with DRI3 support and figure out the right xorg.conf options, still risking a GPU crash?
12:46karolherbst: well mesa should be already be rebuild with dri3 normally
12:46karolherbst: it is just a ddx thing now
12:47karolherbst: ohh wait, turning off the gpu is stilla problem :/
12:47karolherbst: imirkin: maybe there should be a way to turn off/on a gpu without a driver being loaded, or a way to somehow reset the gpu
12:51karolherbst: imirkin: so my _4_3 branch is now compile compatible with 4.3
12:57karolherbst: imirkin: also did you saw some texture flickering in heaven? the floor being red for a brief moment or something?
12:58imirkin: is this recent?
12:59imirkin: i was running it just yesterday on GK208 and it looked fine
13:00karolherbst: mhh maybe I wasn't clear enough, it happens like 1 in 10 runs and only for one or two frames in total
13:00karolherbst: and no it isn't recent
13:00imirkin: never seen it =/
13:01karolherbst: it is just something which happens really rarely
13:05imirkin: ok, well i've never seen it
13:29Wolf480pl: karolherbst, could you confirm that commit sha1 of master_karol_stable_4_3 is b8f76b9e141633c2990e57e8baa54a493edc032f ?
13:33Wolf480pl: also, what was the way to build it? cd drm and make ?
13:39karolherbst: Wolf480pl: seems about right
13:39Wolf480pl: ok, thanks, building
13:40Wolf480pl: soc/tegra/fuse.h: No file or directory
13:41imirkin: comment out that line
13:41imirkin: that's weird though, i thought it was there in 4.3
13:44Wolf480pl: ok, commented out those 2 tegra includes, and looks like it's building
13:45karolherbst: imirkin: Arch is weird
13:46karolherbst: the arm header files doesn't seem to be there
13:46imirkin: it should be picking up the headers from the kernel
13:47Wolf480pl: it's looking for the headers in /usr/lib/modules/4.3-rx7-mainline/build
13:47imirkin: which sounds right
13:48Wolf480pl: which is part of linux-mainline-headers package, which is one of the products of building linux-mainline from AUR
14:11Wolf480pl: when using insmod, should I separate module options with spaces, or with something else?
14:11Wolf480pl: cause there's no pstate file even though I passed pstate=1 right after config=War00...
14:13imirkin: Wolf480pl: full insmod line?
14:13Wolf480pl: sudo insmod nouveau.ko config=War00C800_0=1 pstate=1
14:14imirkin: where are you checking?
14:15imirkin: karolherbst: did you move it in your tree?
14:15imirkin: to like debugfs
14:17Wolf480pl: I found it in debugfs
14:17Wolf480pl: in /sys/kernel/debug/dri/1
14:17Wolf480pl: there's also cstate, I think it's related
14:18karolherbst: I have a bunch of stuff in there to help debugging and stuff :D
14:18karolherbst: try sensors first
14:18karolherbst: when the card is on
14:18Wolf480pl: are the sensors somewhere in sysfs or debugs?
14:19Wolf480pl: nouceau-pci-0100, GPU core: +0.88 V
14:19Wolf480pl: temp1: +58 *C
14:20Wolf480pl: power1: 10 uW
14:20Wolf480pl: should I now try to transition to 07 and see what happens?
14:22Wolf480pl: karolherbst ^
14:32karolherbst: no it is fine
14:32karolherbst: the issue is somewhere else
14:32karolherbst: you could do this
14:32karolherbst: change to 0f
14:32karolherbst: then you get the voltage issue
14:32karolherbst: then find the cstate where it doesn't error
14:32karolherbst: the cstate file is somehow like the pstate file, you'll see after cating it
14:32imirkin: karolherbst: most people don't implicitly know what a cstate is, how to find the list :)
14:33karolherbst: well the cstate interface works the same the pstate interface does
14:34karolherbst: cating it will tell you the other part :p
14:35Wolf480pl: karolherbst, why 0f and not something safer like 0a ?
14:39Wolf480pl: ok, I tried setting it to 0a, bad stuff happened
14:39Wolf480pl: a freeze that I could defeat with sysrq
14:39Wolf480pl: but there's [nouveau] gr: TRAP spam in the console
14:40Wolf480pl: looks like it stopped
14:41karolherbst: you shouldn't run stuff while doing it for now
14:41Wolf480pl: also, did I tell you that starting xorg takes a long time?
14:41karolherbst: because low voltage might cause troubles
14:41karolherbst: ohh wait
14:41karolherbst: I thought you have a hybrid gpu setup?
14:42karolherbst: just by going into 0a nothing should happen if you have that
14:42Wolf480pl: well I do have a hybrid setup
14:42Wolf480pl: and I enabled offload sink and ran DRI_PRIME=1 glxspheres64
14:42Wolf480pl: so that the GPU is in use
14:43karolherbst: ahh I see
14:43karolherbst: but that shouldn't kill your system either
14:43Wolf480pl: well, I think it just slowed it down to an unreasonably slow speed
14:44Wolf480pl: also, after starting xorg, windows are black until I switch to a different VT and back
14:44imirkin: you can also try minimizing
14:45imirkin: known issue with DRI2 i believe
14:45imirkin: esp in conjunction with kwin
14:45Wolf480pl: compiz here
14:46Wolf480pl: so, should I try setting pstate of unused GPU?
14:47Wolf480pl: (it has 0.60 V when unused)
14:47imirkin: when not being used, it should be getting suspended
14:48imirkin: you can see the vgaswitcheroo status
14:48imirkin: see http://nouveau.freedesktop.org/wiki/Optimus/
14:48Wolf480pl: btw. is the vgaswitcheroo related in any way to snd_hda_intel ? cause I've seen dmesg messages from snd_hda_intel mentioning VGA Switcheroo
14:48imirkin: Wolf480pl: cat /sys/kernel/debug/vgaswitcheroo/switch
14:49imirkin: it should say DynOff when not being used
14:49Wolf480pl: 0:DIS-Audio: :Off:0000:01:00.1
14:49Wolf480pl: 2:DIS: :DynOff:0000:01:00.0
14:49Wolf480pl: yeah, DynOff
14:50imirkin: that means it should be powered off (via acpi)
14:50Wildefyr: does anyone know if the binary blob needs anything specific to initilize the display? the module gets loaded fine, but still the display is stuck on the last screen
14:50Wolf480pl: btw. echoing a0 to pstate when GPU is not used caused the call to block indefinitely and some errors in dmesg
14:50karolherbst: sensors will tell you 0.6V when the card is pwoered off
14:50imirkin: Wildefyr: #nvidia :p
14:50karolherbst: that is a known issue
14:51Wildefyr: imirkin, it's pretty dead in there :p
14:51Wolf480pl: so it's a perfectly reasonable for a pstate write to block indefinitely, when the card is powered off?
14:51imirkin: Wildefyr: doesn't make this the right place to ask.
14:52Wolf480pl: that `tee` which is writing to pstate won't even die from kill -9
14:53Wolf480pl: it's blocked somewhere in kernelspace, printing stacktraces to dmesg
14:54Wolf480pl: wanna see dmesg?
14:54Wolf480pl: or should I reboot and do a test that's more likely to work?
15:01Wolf480pl: karolherbst ?
15:10karolherbst: I have also sometimes lockups in that file
15:10karolherbst: but never tried to write something into that while the card is off
15:10karolherbst: might be debugfs related though
15:10karolherbst: the card should be go on
15:10karolherbst: the pstate is reset after the card going off anyway
15:13Wolf480pl: I rebooted, what should I try now?
15:15karolherbst: Wolf480pl: you can load nouveau with runpm=0
15:15karolherbst: but then the card won't go off anymore
15:15karolherbst: enough for testing though
15:15karolherbst: I will investigate this hang on card off issue
15:15Wolf480pl: ok, so you want the card on but no rendering done on it?
15:16karolherbst: for now
15:16karolherbst: and check if switching pstates just works
15:16karolherbst: imirkin: my card doesn't get off anymore through vgaswitcheroo :/
15:18Wolf480pl: ok, the card is on
15:19Wolf480pl: pstate 324 MGz core, 648 MHz ram
15:19Wolf480pl: voltage 0.88 V
15:19Wolf480pl: should I try 0a or 0f ?
15:20Wolf480pl: I'll go for 0f
15:20Wolf480pl: looks like it switched
15:20Wolf480pl: pstate 966 MHz core, 5 GHz memory
15:20karolherbst: what about the voltage?
15:21Wolf480pl: voltage 0.95
15:21Wolf480pl: there are some cstates available for current pstate
15:21karolherbst: yeah, but well
15:21karolherbst: the voltage seems kind of low
15:22Wolf480pl: should it be like 1.2 or 1.4 ?
15:22karolherbst: no, that's too much
15:23karolherbst: what gpu is it?
15:23Wolf480pl: depending on where you look, either gtx 770m, 780m, or 870m
15:23karolherbst: what does lspci say?
15:24Wolf480pl: GK104M (gtx 870m)
15:25karolherbst: the nvidia driver dirves my card at around 1V with 860MHz
15:25karolherbst: no issue though
15:25karolherbst: what gives you dmesg?
15:26Wolf480pl: NVIDIA GK104 (0e4190a2)
15:26Wolf480pl: if you're still asking about the gpu model
15:26Wolf480pl: otherwise, a normal nouveau init output
15:27karolherbst: could you install envytools?
15:29karolherbst: ohh wait
15:29karolherbst: you could also just give me your vbios
15:29karolherbst: there is the vbios.rom file in debug
15:29karolherbst: that would help a lot too
15:31Wolf480pl: ok, I found it, how do I send it to you?
15:31karolherbst: just upload it somewhere
15:32Wolf480pl: should it stay for a long time for others to see, or is it just for you to download it?
15:32karolherbst: I will download it
15:33karolherbst: Wolf480pl: and after you installed envytools I would need the output of nvapeek 101000
15:35karolherbst: indeed you have pwm based voltage
15:36karolherbst: mupuf_: you will enjoy this one even more than all the others together
15:36karolherbst: like a lot
15:37Wolf480pl: cd nva; cmake; make ?
15:38karolherbst: isn't there a package already?
15:38imirkin: cmake first
15:38imirkin: cmake .
15:38imirkin: in the envytools top-level dir
15:41Wolf480pl: make also in toplevel?
15:44Wolf480pl: karolherbst, 00101000: 9f58a49a
15:44karolherbst: thank you
15:45Wolf480pl: is there anything else you want me to do, or am I free to play around with pstates and possibly crash my GPU ?
15:45karolherbst: Wolf480pl: did you try out running anyhting on 0f before=?
15:45karolherbst: you can do it now
15:45karolherbst: it should work somehow
15:45karolherbst: don't know how stable though
15:46karolherbst: due to a little low voltage
15:46imirkin: karolherbst: fyi, most of the time your usage of 'somehow' makes a lot more sense as 'somewhat'
15:47imirkin: 'somehow' = 'in some way', 'somewhat' = 'a little bit'
15:47Wolf480pl: or 'kinda'
15:47karolherbst: but I meant the former
15:47Wolf480pl: glxgears worked, glxspheres froze everything
15:47karolherbst: it should never ever impact the intel gpu
15:48Wolf480pl: I'd rather suspect it to impact the CPU
15:48karolherbst: then it still should work
15:48karolherbst: when I crash my gpu the X server still does stuff normally
15:48karolherbst: just the one process freezes
15:48Wolf480pl: SHED_ERROR 0a [CTXSW_TIMEOUT]
15:49Wolf480pl: TRAP ch -1
15:49Wolf480pl: and they keep appearing on the console
15:49karolherbst: there is something with ROP too
15:49karolherbst: or should be
15:49Wolf480pl: there is
15:49Wolf480pl: ROP0, ROP1, ROP2
15:49karolherbst: and some numbers
15:49Wolf480pl: all ROPs are 000000000 00000001
15:49karolherbst: mhhh okay
15:50karolherbst: I've suspected different values but okay
15:50Wolf480pl: TRAP has a number too
15:50karolherbst: let me think
15:50karolherbst: do you have nvidia installed?
15:50karolherbst: or did you ever used the card with nvidia installed?
15:50imirkin: there's a mmiotrace in the bug
15:50karolherbst: which bug?
15:51Wolf480pl: the HUB_INIT one
15:51Wolf480pl: the one that War008C00_0=1 solves
15:51karolherbst: yeah, but I would need the pwm values nvidia uses at full load
15:51karolherbst: I highly doubt that I can extract this from the trace :/
15:52Wolf480pl: well, the trace was mostly about making nvidia initalize the gpu
15:52karolherbst: I expected as much
15:52Wolf480pl: so I should use the blob and optirun 10 instances of glxspheres
15:52Wolf480pl: and mmiotrace that?
15:53karolherbst: vblank_mode=1 primusrun glxspheres
15:53karolherbst: and no trace
15:53karolherbst: just run it
15:53karolherbst: and we will nvapeek some values
15:54Wolf480pl: it's late here, would tomorrow morning be ok?
15:54karolherbst: imirkin: who is responsible for the runpm code?
15:55imirkin: define 'responsible'
15:55imirkin: airlied wrote it
15:55karolherbst: airlied: :p I have a little issue
15:55karolherbst: maybe you have an idea
15:56Wolf480pl: good night!
16:13beaver6675: hi all, fedora 23, GK110, log spam, [66991.613644] nouveau E[ PIBUS][0000:01:00.0] GPC4: 0x5233e4 0xbadf1301 (0x01024215)
16:14beaver6675: any idea how to quiet the log?
16:18imirkin: can you pastebin the start of the spam?
16:32beaver6675: yes: will need to restart as dmesg is full with PIBUS spam now...
16:33imirkin: beaver6675: what kernel does f23 come with?
16:33beaver6675: kernel: [TTM] Zone kernel: Available graphics memory: 16443734 kiB
16:34beaver6675: kernel: [TTM] Zone dma32: Available graphics memory: 2097152 kiB
16:34imirkin: please use pastebin
16:34imirkin: start with the first nouveau messages, and include a bunch of the pibus errors too
16:34beaver6675: ..to come...
16:35imirkin: or just stick your whole dmesg in there
16:39imirkin: beaver6675: please file a bug with this info at bugs.freedesktop.org, use component xorg -> Driver/nouveau
16:39imirkin: beaver6675: unfortunately i have no idea why this happens =/ but skeggsb might, but he's unlikely to see this in his scrollback
16:40beaver6675: will do: thanks
16:49beaver6675: submitted: https://bugs.freedesktop.org/attachment.cgi?id=119321
16:49beaver6675: I meant: https://bugs.freedesktop.org/show_bug.cgi?id=92761
16:49beaver6675: thanks imirkin
17:34airlied: karolherbst: what's the issue?
17:45karolherbst: airlied: my card sometimes doesn't want to power off through nouveau and switcheroo
17:51karolherbst: airlied: what should I do to check whats happening?