03:49rez_: damn, so much people here :)
03:50rez_: since the proprietary NVidia drivers doesn't work on my computer i'm using nouveau since some months
03:51rez_: but recently I have a lot of problems, like X server crashing randomly when I'm "too much" using 3d acceleration
03:51rez_: also, I have a desastrous framerate with pixelshaders while others drivers give me a solid 60fps :D
03:54pmoreau: rez_: Could you please link the output of dmesg and Xorg.0.log after a crash?
03:55pmoreau: rez_: And also, which card do you have and which kernel version are you running?
03:56rez_: pmoreau: a NVidia 320M (it's a MacBook Air from 2010), and I'm using Debian with kernel 4.1 as only one OS :)
03:56pmoreau: So, it's a MCP89 iirc
03:56rez_: pmoreau: the good side of nouveau is that the framebuffer resolution is my native screen resolution, so I have a beautifull TTY shell :D
03:57pmoreau: No need to run X then! :p
03:58rez_: but since I'm coding some 3d stuff, sometimes I need X :D
03:58rez_: ho also I'm using i3wm, but it's probably not a problem for the video drivers
03:58rez_: ok, so when the next crash will occur i will log error output
03:59pmoreau: iirc, you should be able to do some reclocking for that card
03:59pmoreau: For that you need to boot with nouveau.pstate=1, and then play with /sys/class/drm/card0/device/pstate
04:00pmoreau: echo'ing that file will give you a list of different performance level, with the associated clocks
04:00rez_: ok, so it's probably the reason why the same shader on the very same computer doesn't run at same speed with a different driver
04:00pmoreau: and then you echo which perflvl you want
04:01pmoreau: it can be *one* reason, but most likely not the only one
04:03rez_: pmoreau: thank for your answers, i'm currently at work, I will try that at home tonight :D
04:03pmoreau: Sure! Whenever you have time :)
04:04rez_: pmoreau: are you french? your name sounds like a french family name :)
04:04pmoreau: rez_: Indeed :D
04:04rez_: héhé, ok, me too :)
04:04rez_: (after all, we are using "nouveau")
04:06rez_: https://www.shadertoy.com/view/llBSWh I did that yesterday night, I hope to get more fps by tweaking the driver :D
04:11pmoreau: rez_: The driver for NV30 cards is called nouveau_vieux ;D
04:12pmoreau: Interesting :-)
04:13mupuf: pmoreau: I thought it was for the stuff before the nv30
04:14pmoreau: mupuf: Oh, maybe
04:14pmoreau: But the most interesting point was the name
04:14karolherbst: mupuf: I think the cstates are pstate unrelated. a Pstate has only a cstate it is suppose to run at, but I highly doubt that the blob has somehting like a list of cstates for a pstate :/
04:15pmoreau: mupuf: NV04-NV20, you're right
04:15karolherbst: but the blob respects the bounds of the boost table for min/max values
04:16mupuf: karolherbst: hey, before I forget, please reset reator in the state you found it before leaving ;). You uninstalled xf86-video-nouveau and hakzsam had to reinstall it
04:16rez_: pmoreau: haha, nice name :D
04:17mupuf: and pretty sure cstates are not unrelated to pstates
04:17mupuf: this is easily seen in some of my traces
04:17mupuf: when we keep on needing to increase the core clock
04:17rez_: btw, some people reported a strange framedrop with shaders compared to proprietary drivers? (in general)
04:17karolherbst: mupuf: :O
04:17karolherbst: I didn't do that
04:17rez_: i hope it's just my strange setup
04:17mupuf: hmm, what the heck then :D
04:17karolherbst: I think he bootet into the blob
04:18mupuf: anyway, it does not matter
04:18karolherbst: because he left it with the 4.1.6 kernel :)
04:18karolherbst: I know what you mean, I just ran pacman as you told me
04:18mupuf: oh, possible, he may have been on the wrong partition
04:18karolherbst: I only know it messed up grub a bit, and I had to rebuild grub from chroot :/
04:18karolherbst: pacman on the blob partition
04:19karolherbst: let me unable to boot the nouveau partition, because it rerun its grub stuff
04:19karolherbst: so I had to chroot into the nouveau partition and rebuild the grub boot entries there
04:19mupuf: really? I HATE THIS KIND OF BEHAVIOUR!
04:19karolherbst: but I think the default boot entry is still the blob though
04:20mupuf: grub2 is a fucking disaster when used with the auto generator
04:20mupuf: I do not get why it got run again on its own
04:20mupuf: anyway, back to your issue
04:20karolherbst: maybe kernel update?
04:20mupuf: this is not ubuntu
04:21karolherbst: no clue then, I was a bit bothered, that it won't boot nouveau and this is what I found out, so
04:21mupuf: ack, thanks for investigating
04:21mupuf: drop me a line about this kind of issues though
04:22mupuf: anyway, http://fs.mupuf.org/mupuf/nvidia/graphs/thresholds_graph.svg
04:22mupuf: that will prove you that you are wrong with regards to cstates being unrelated to pstates
04:23karolherbst: I didn't meant they are totally unrelated, I just don't think there is something liek a list of cstates for each pstate
04:23mupuf: well, it is kind of equivalent
04:24karolherbst: you should check nve7/kubus2 vbios
04:24karolherbst: there are only 3 cstates
04:24karolherbst: and in a different order than usual
04:24mupuf: fun, but are we sure the vbios is the right one?
04:24mupuf: and not a corrupt one?
04:24karolherbst: it makes still sense
04:24karolherbst: it is not like there is garbage in it
04:24mupuf: well, that;s for this week end
04:24karolherbst: it is just _different_
04:25mupuf: until then, sorry, busy with my intel work
04:25karolherbst: no problems
04:32karolherbst: imirkin: I need nvapeek 0x88000 0x1000 of your x8 kepler card :)
04:41hakzsam: karolherbst, I'm using reator btw
07:03rez_: pmoreau: sorry to ask a noob question, but that "nouveau.pstate=1" parameters must be entered in GRUB boot options right?
07:03pmoreau: rez_: Right
07:03pmoreau: And do not forget to regenerate the grub.cfg file afterwards
07:04rez_: pmoreau: ok! something like "GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nouveau.pstate=1" ? :)
07:04pmoreau: Exactly :-)
07:04rez_: great! thank you!
07:04karolherbst: rez_: what card do you have again?
07:05rez_: karolherbst: Nvidia 320M
07:05rez_: karolherbst: on a MacBook Air late 2010, th
07:05rez_: the very last one with a NVidia card
07:05karolherbst: this one looks a bit crazy :/
07:06rez_: a bit crazy?
07:06karolherbst: is it the MCP89 one?
07:06karolherbst: this is as odd as your nvidia crads :D
07:07karolherbst: it has 256MB dedicated VRAM + 1.5GB sys ram
07:07rez_: ha yes, fast duckduckgo search: http://applethis.com/tag/nvidia-mcp89/
07:07karolherbst: it seems like it can access system ram, like "integrated" cards
07:07rez_: karolherbst: but it worked really fine, coded a lot on 3d with it, worked fine under wine too :)
07:08pmoreau: karolherbst: Well, it still is a MacBook, so those cards *think different* ;)
07:08karolherbst: pmoreau: do you know anything about htat?
07:08pmoreau: karolherbst: MCPXX cards are all integrated ones iirc
07:08karolherbst: ohh okay
07:08karolherbst: but it has dedicated vram
07:09karolherbst: do you think nouveau can handle such a card the right way?
07:09karolherbst: which means using vram and sys ram for stuff?
07:10pmoreau: No idea
07:10rez_: karolherbst: actually the same shader run at less than 1 fps with nouveau while it run at full 60fps with NVidia proprietary drivers :D
07:10karolherbst: I bet it has something todo with the vram situation :/
07:10rez_: karolherbst: BUT since some weeks, the shaders is WELL displayed while it was a bunch of random black pixels some months ago
07:11rez_: so it's a good point after all :)
07:11karolherbst: yeah, but pstates won't bump perf from 1fps to 30fps or something
07:11karolherbst: so you may get 3 instead of 1
07:11pmoreau: rez_: Do you remember around which kernel version the behaviour changed?
07:11karolherbst: there is something really odd
07:11rez_: pmoreau: sadly no :(
07:12rez_: but perhaps it happened when i moved from 3.16 to 4
07:12pmoreau: Let me check something
07:13rez_: ha also, the computer heat much more with nouveau than with nvidia drivers
07:13karolherbst: rez_: could you give me dmesg | grep -i nouveau
07:13karolherbst: rez_: this is normal
07:13rez_: karolherbst: yes, but tonight! i'm currently at work :3
07:13karolherbst: tesla cards usually boot with higher pstates
07:13karolherbst: I see
07:13karolherbst: not with the lowest one
07:19pmoreau: Can't find back the map storing relations between cards and engine version...
07:20pmoreau: Can't remember if the MCP89 is using ramnvaa or not
07:22karolherbst: pmoreau: is this handled be the fb subdev?
07:23karolherbst: it uses mcp89_fb
07:24karolherbst: what is NVKM_RAM_TYPE_STOLEN?
07:24karolherbst: is this sys ram usage?
07:25karolherbst: ohh yeah
07:25pmoreau: When the card *steals* memory from RAM to use as it's own VRAM.
07:25karolherbst: seems like it only uses vram
07:25karolherbst: I mean sys ram
07:25karolherbst: basically it just allocs a bunch of sys ram, and uses this
07:26karolherbst: I may be wrong, but I don't think nouveau will use dedicated vram for this mcp89
07:26pmoreau: I'll have to change a few things: MCP89 doesn't have 0x100c18 and 0x100c24 iirc
07:26pmoreau: Most likely
07:26karolherbst: such cards are a lot of fun :D
07:28pmoreau: Especially when some decide to not include everything in the VBIOS
07:29karolherbst: well 256MB schould be enough for most stuff
07:29karolherbst: the cpu will be the bigger problem most likely
07:30karolherbst: pmoreau: I think mcp89 is just a "fake" mcp name and the chip is based on another one mainly
07:33karolherbst: ohh wait
07:33karolherbst: what is this
07:33karolherbst: pmoreau: MCP89 is actually a sata and audio chip, too
07:34pmoreau: MCP79 integrates a lot of things as well
07:34karolherbst: I see
07:34pmoreau: USB controller, maybe ethernet as well, ...
07:36karolherbst: you have fun to enable ahci modes on these apple laptops too
07:36karolherbst: ohh wait
07:36karolherbst: I remember, I had hacky enable ahci on mine, too
07:36karolherbst: pmoreau: is your sata controller in IDE or ahci mode?
07:37pmoreau: No idea! How to check?
07:37karolherbst: dmesg | grep -i ahci
07:37karolherbst: dmesg | grep -i scsi
07:37karolherbst: for me it says stuff like "scsi host0: ahci"
07:37karolherbst: I bet yours will show ide
07:38pmoreau: ahci it is
07:38karolherbst: ohh nice
07:39karolherbst: maybe these quirks are upstreamed now
07:39karolherbst: I know I had to deal with stupid issues like this back then :/
07:42rez_: karolherbst: so do you think it's possible to do something? :D
07:43karolherbst: rez_: always, but it may be hacky
07:43karolherbst: if I knew what other chipset the card is based upon, maybe we can just use another ram subdev and use that
07:53mwk: karolherbst: there's nothing fake about MCP*
07:54imirkin: rez_: re performance, the nouveau shader compiler is a lot less sophisticated than the blob's compiler, also you're probably not clocking the chip up to the highest speed when comparing perf. we have reclocking support for mcp79, might Just Work for mcp89
07:54mwk: their GPUs are not just "NVxx" integrated
07:54mwk: they're all rather different beasts than the usual GPUs
07:55karolherbst: mwk: yes, but this mcp has dedicated vram
07:55mwk: karolherbst: no MCP has dedicated VRAM
07:55karolherbst: this one has
07:56mwk: how so?
07:56karolherbst: 256MB dedicated vram
07:56karolherbst: mwk: http://images.anandtech.com/reviews/mac/MacBookPro2010/13-inch/320M.jpg
07:57karolherbst: this one has 256MB dedicated + up to 1.5GB sys vram
07:57mwk: that's, simply put, fake
07:57karolherbst: if you say so
07:59karolherbst: will have to dig a bit deeper then
07:59mkay_: wait, are there graphic cards that steals system rams still around?
07:59mkay_: that was something they did when memory was expensive.
07:59karolherbst: maybe it was meant differently
07:59karolherbst: 256MB fixed for the gpu and + up to 1.5GB dynamically allocated?
08:00mwk: all the MCP* have "stolen memory", which is a piece of system RAM that the OS never even sees
08:00mwk: as in, it's excluded from the BIOS memory map
08:00karolherbst: okay, mhh
08:00mwk: and the GPU uses it whenever you tell it to use VRAM
08:00karolherbst: so 256MB are stolen this way, and the gpu can allocated even more ram as needed
08:01mwk: but it's still system RAM, if you figure out where it is, you can just poke its normal system RAM address
08:01mwk: in addition to that, you can address "normal" system RAM as usual
08:01karolherbst: that makes much more sense
08:01mwk: both go through exactly the same pathway when accessed
08:01mwk: except for aslightly different address translation step
08:02mwk: there's one thing that I think is different for MCP89
08:02karolherbst: and the other part still shows up as "system" ram usage I guess
08:02mwk: it seems to have memory compression capabilities, which is unusual for an integrated GPU, as the compression RAM is usually closely tied to the actual VRAM circuitry
08:03mwk: but that in no way changes the "VRAM is fake" part, I've verified it closely
08:03mwk: if you want proof, just take a look at memory map... there'll be 256MB missing
08:03mwk: maybe "reserved"
08:04rez_: thank for the support boys, i will provide all the infos you need tonight :D
08:05karolherbst: mwk: nah I just wondered why everybody called that dedicated vram
08:05karolherbst: oh well :/
08:08karolherbst: imirkin: can you give me the 0x88000 0x1000 range of your kepler card or can you only do this later? I want to figure out where the card width is stored :D
08:08karolherbst: you are the only one with a x8 width card I know :p
08:09imirkin: karolherbst: not right now
08:14mwk: karolherbst: and FWIW, MCP* are indeed quite integrated beasts
08:15karolherbst: mwk: yeah I saw that they are all integrated cards indeed
08:15karolherbst: and they also have other stuff as well on them
08:16mwk: the list is probably incomplete, btw
08:16mwk: but then, I didn't care all that much
08:16mwk: and I have NFI what all those "alt ID" things are about
08:17mwk: there's basically a PCI reg on each SATA controller that you can poke to change 4 LSBs of its pciid
08:55effractur: hi when will http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=baa3e97147d197dbbb0d6427ae98bd9ec18b578f be merged into the kernel?
09:01RSpliet: effractur: already has been
09:05RSpliet: pmoreau: have you already given my tree a whirl on your G96 recently (since introducing voltage GPIO code)?
09:05imirkin: effractur: should be in 4.3-rc2 i think
09:06effractur: imirkin: cool
09:07imirkin: effractur: commit 15ee00589 upstream
09:07imirkin: actually it made it into rc1
09:08imirkin: effractur: but that was a regression of the rewrite, not a longer-standing problem
09:09effractur: imirkin: i am aware of that
09:09effractur: this maby fixes the issues i had with the newer kernels
09:09imirkin: and only on pre-nv40 boards... i happened to have just gotten a ppc g5 with a nv34 in it, took me a while to realize it was a recent regression =/
09:11effractur: i have a NV18 card where the issue was that on newer kernels it complety broke
09:14imirkin: newer kernels like what?
09:15effractur: whell i got broken output on 3.17 i think
09:15effractur: and with 4.0+ no output at all
09:16imirkin: you should bisect
09:16effractur: theoutput from 3.17 was also not usefull
09:16imirkin: yeah, i meant between 3.16 and 3.17
09:16imirkin: you can restrict the bisect to drivers/gpu/drm/nouveau -- that should most likely catch the issue
09:17effractur: dono if it ever work tho
09:17imirkin: didn't you file a bug ages ago about DVI not working or... something?
09:17imirkin: maybe that was someone else
09:18imirkin: some of those macs had very funny issues
09:18effractur: the main issue was loading the stuff from openfirmware
09:18imirkin: yeah... that got broken
09:18effractur: it can't find a good image
09:18imirkin: i have a local fix for that
09:18effractur: and in 3.17 it loaded a corrupt image
09:18effractur: could you provide me whith the patch ?
09:18imirkin: errrrrr.... i HAD a local fix
09:19imirkin: now i need to see if i blew it away =/
09:19effractur: let me try to find the image of the ouput
09:20imirkin: effractur: https://paste.debian.net/313403/
09:20imirkin: effractur: change the 2403 to whatever the size of your bios is
09:21effractur: and how can i find that size?
09:21imirkin: or maybe /proc/device-tree
09:21imirkin: look for NVDA,BMP
09:22effractur: that was the broken output
09:22imirkin: not *quite* right
09:22effractur: whell it does not hang the kernel
09:23imirkin: ooooh, i bet there's some be/le situation going on in there
09:23imirkin: where we read some stuff from the vbios without doing the proper swap
09:23imirkin: or... we do one swap too many
09:23imirkin: anyways, you should def file a bug about that issue
09:23imirkin: and include debug logs
09:23imirkin: (boot with nouveau.debug=debug drm.debug=0xe)
09:24imirkin: but first you need my patch to make OF work again
09:24imirkin: which you need to fix up to match your bios size
09:24effractur: can i apply that directly to the kernel tree?
09:24imirkin: no, it's against ben's tree
09:24effractur: k i will hack in th in the kernel tree ;p
09:24imirkin: but you should be able to if you go into the drivers/gpu directory
09:27effractur: iw ill try it and report back and if needed with a bugreport
09:28imirkin: also include your NVDA,BMP in such a report
09:39pmoreau: RSpliet: How recent is recent? I only tested it once, around June maybe?
10:51pmoreau: RSpliet: It timeout'ed: https://phabricator.pmoreau.org/P32
10:51pmoreau: RSpliet: I'll retry to reclock while having the G96 driving the screen; not sure if it will change something or not.
10:54pmoreau: RSpliet: Ah ah!! It does work! (Tried switching between 03 and 05, and back)
10:54pmoreau: I'll check by running Portal, and test all perflvls
11:36pmoreau: RSpliet: From 03 to 05: 8 fps to 20fps
11:36pmoreau: RSpliet: At 0e or 0f, I loose the screen
11:39imirkin_: it goes so fast you can't even see anything on the screen? :)
11:39karolherbst: pmoreau: with your gddr3 gpu?
11:40pmoreau: karolherbst: Yep
11:40karolherbst: I am blind I don't see your perf table :D
11:40karolherbst: which is the mem clock on the highest pstates?
11:40karolherbst: I am currently wondering, maybe this gddr5 issue on kepler, is older than that :/
11:41karolherbst: ohh found it
11:41karolherbst: memory 700 and 792
11:42pmoreau: imirkin_: While I was running Portal and switched to level 0e, I got a lot of PAGE_NOT_PRESENT, trapped write
11:42pmoreau: karolherbst: Right
11:43karolherbst: pmoreau: does the blob run on your system?
11:44karolherbst: there is indeed a check for cl_hi and cl_lo in gddr3
11:44pmoreau: karolherbst: What do you mean by that? Currently, not
11:44karolherbst: in theory
11:44pmoreau: In theory, it runs
11:44pmoreau: And in practice, it runs when I modprobe it
11:46karolherbst: you could trace the blob and nouveau while going to the higher pstates and check for a difference
11:46karolherbst: this is what I've done for finding the gddr5 kepler issue
11:50karolherbst: maybe some timings or PLLs are significantly different
11:50pmoreau: I have a reclocking trace somewhere
11:50pmoreau: In the vbios repo I think
11:50karolherbst: on kepler everything was inside a PDAEMON script so, this was easy to find
11:50karolherbst: found the trace
11:50imirkin_: it's even easier pre-gt215
11:50imirkin_: it's directly in HWSQ
11:50karolherbst: and what is hwsq?
11:50imirkin_: instead of commands to some pmu firmware
11:50imirkin_: hwsq is a hardware scripting language
11:50imirkin_: while the "seq" stuff is purely software impl of the nvidia pmu
11:50imirkin_: which could in turn be totally different
11:50karolherbst: ohh okay
11:50imirkin_: while hwsq is what it is
11:50imirkin_: and it's been RE'd
11:54karolherbst: pmoreau: it would be still nice to create two well created traces
11:54karolherbst: just so that all this garbage is stripped off
11:54pmoreau: I'll try to
11:54karolherbst: like start trace, load nvidia, stop catting file, start catting file again, reclock, stop catting, unload nvidia
11:54karolherbst: something like that
11:54karolherbst: I created a 185K trace with that, and it was much easier to handle
11:54pmoreau: 185K! That's small!!
12:16karolherbst: pmoreau: "/* XXX: Get these values from the VBIOS instead */"
12:16karolherbst: but I don'T really know what they do
12:16karolherbst: these values there
12:18karolherbst: also this line: https://github.com/karolherbst/nouveau/blob/master/drm/nouveau/nvkm/subdev/fb/ramnv50.c#L272
12:20karolherbst: pmoreau: do you know if 0f works slightly better than 0e?
12:22karolherbst: pmoreau: 0x004008 is the PLL reg, you could check the value of this for the different pstates in the blob, allthough it may be enough to get the value for the highest one
12:23karolherbst: and then check what nouveau tries to write in it
12:25karolherbst: pmoreau: better check 0x004008 0x14
13:00imirkin_: skeggsb: should nouveau_bo_del do a pushbuf_kick just like nouveau_bo_wait does?
13:01imirkin_: skeggsb: joi noticed a situation where we alloc a bo, use it, and delete it, without a kick in between
13:02imirkin_: skeggsb: hrmmmm.... actually we don't have a client available at that point.
13:12jefferym_: ~/who effractur
13:13effractur: hi jefferym_
13:36imirkin_: joi: can you give this a shot with your witcher2 (?) issues? https://github.com/imirkin/mesa/commit/a5c065185c26ea99e0dcf4b485de31dca12cf5df
13:41rez_: pmoreau: here? :)
13:41rez_: pmoreau: http://people.zoy.org/~rez/nouveau_dmesg1.txt
13:42rez_: pmoreau: http://people.zoy.org/~rez/nouveau_dmesg2.txt
13:42rez_: pmoreau: it looks like a bit messy :D
13:50joi: imirkin_: sure
13:50imirkin_: joi: it was witcher2 with the broken buffer things right?
13:50imirkin_: i haven't done more than compile-test that patch btw
13:51joi: nv50_transfer.c change looks suspicious
13:51joi: (I know it does not affect my card)
13:51imirkin_: how so?
13:52joi: there 2 unrefs
13:52joi: there are 2 unrefs
13:52imirkin_: oh oooops
13:53imirkin_: (top of master)
13:57pmoreau: rez_: What were the conditions for both crashes?
13:58imirkin_: rez_: afaik lots of people have reported issues like that on MCP89
13:58rez_: pmoreau: there was no crash at the moment :)
13:58imirkin_: rez_: investigation never went anywhere
13:58rez_: pmoreau: my computer is running, i'm talking to you from the current X session :D
13:58imirkin_: rez_: search for MCP89 in bugzilla
14:00rez_: imirkin_: I see a lot of bug with SATA or HDMI, things I actually don't use :)
14:00imirkin_: rez_: https://bugs.freedesktop.org/show_bug.cgi?id=83957
14:01rez_: ha thank you!
14:01pmoreau: And https://bugs.freedesktop.org/show_bug.cgi?id=77574
14:02rez_: ho thank you imirkin_ ! you already replyed
14:02rez_: so I have exactly the same problem (and probably the same computer as the op)
14:03rez_: will try the "nouveau.config=PCE0=1"
14:03imirkin_: yeah, only one model of computer ever had a MCP89
14:03imirkin_: nah, that won't help
14:03imirkin_: PCE0 is pre-disabled
14:03imirkin_: for all NVAF (= MCP89)
14:03imirkin_: i didn't realize that at the time i had made the suggestion
14:04imirkin_: anyways, MCP89 is only in that model of mac
14:05rez_: the most strange thing is that post is one year old EXACTLY
14:05pmoreau: Hum... Bug report #77574 has a slightly different version of the card: BOOT0 = 0x0af100a2 vs 0x0af180a2
14:05imirkin_: (might be a couple of models depending how you count)
14:05rez_: and i have this problem just since one month
14:05rez_: (and I update everyday)
14:05pmoreau: Welcome to the bisecting world then :-)
14:05rez_: perhaps the guy was using a very early version
14:06rez_: because I always add performance problem but everything was working fine
14:06rez_: so something "happened" and make X really unstable
14:08rez_: but of course since it's an opensource project, it's impossible for me to blame people for giving their free time to help :D
14:11rez_: just had a "nouveau hicup"
14:11rez_: i got some log dropped on TTY2
14:13pmoreau: Did you had this kind of errors before (the one in the dmesg you linked)?
14:13rez_: pmoreau: before the problem started? never
14:15pmoreau: You could probably try to bisect Nouveau then, to find which changes broke it.
14:16imirkin_: keeping in mind it could be either a kernel or userspace change that precipitated this
14:16imirkin_: and it could even be that some piece of software you use is doing things now that it wasn't before
14:16daemon32: Or both..?
14:17rez_: pmoreau: you mean trying to install previous version?
14:17imirkin_: rez_: find a working setup, then bisect the differences.
14:17joi: imirkin_: 2nd run: http://paste.ubuntu.com/12560100/
14:17imirkin_: joi: ;(
14:18joi: looks like a different issue?
14:18imirkin_: joi: yeah
14:19imirkin_: joi: it's trying to stick 200406c0 into RT_HORIZ... that's not great
14:19imirkin_: that looks like a buffer memory address
14:20imirkin_: 1000f010 looks like the query thing.
14:20imirkin_: i think a push kick is happening at a sad time
14:20imirkin_: can you remove the push kicks i added to rseource destroy?
14:20imirkin_: and only leave the transfer changes?
14:22joi: remove the one from nouveau_buffer.c?
14:22imirkin_: shouldn't matter
14:23imirkin_: actually... probably yeah
14:23imirkin_: basically if one of those happens concurrently with the fence, then sadtimes
14:24imirkin_: if one of those happens concurrently with another submit
14:24imirkin_: coz there's the stupid kick handler
14:24imirkin_: i should probably just defer the actual resource release until later
14:24imirkin_: instead of kicking
14:25joi: that's definitely safer
14:25imirkin_: that requires like 2 more lines of code and i was lazy and didn't think about the possible interaction :)
14:27rez_: ho btw, application using SDL easily crashe nouveau
14:27rez_: while intensive shaders with chromium seems to be ok
14:27imirkin_: i doubt SDL has anything to do with it fyi
14:27rez_: ha :D
14:28rez_: imirkin_: it's SDL used as OpenGL viewport display
14:29joi: 3 tries with updated patch were flawless, 4th one crashed with "Unknown handle 0x0000049f"
14:30imirkin_: did it take a while to repro before too?
14:30imirkin_: i.e. is this identical to before, or better?
14:31imirkin_: joi: also i don't think you uploaded your trace... did you?
14:31joi: well, I think there are multiple errors
14:31imirkin_: multiple bugs in a single application? inconceivable!
14:32joi: if i understand correctly your patch is supposed to help with fifo read faults
14:32joi: and so far I didn't hit it
14:32imirkin_: well, i figured it might also be a source of unknown buffers
14:32imirkin_: coz the buffer was on the pushbuf list
14:32imirkin_: but had already been freed
14:33joi: I cannot reproduce any of the bugs with glretrace
14:34imirkin_: whereas you could before?
14:34imirkin_: ah ok
14:34joi: i think witcher2 is kinda multithreaded
14:34imirkin_: yeah sounds like it
14:34joi: and apitreace is single threaded
14:37pmoreau: karolherbst: How do you define "works slightly better"? The screen turns black in both cases, so hard to say if one works better than the other.
14:37karolherbst: pmoreau: more stable
14:37rez_: my X didn't crashed yet but the dmesg log is growing :D http://people.zoy.org/~rez/nouveau_dmesg3.txt
14:37karolherbst: like try to go from the lower pstate to the highest
14:38imirkin_: joi: well, so *one* problem is that there's a single pushbuf shared by all contexts and there's no sync on it
14:38karolherbst: pmoreau: but maybe it is easier to just peek the regs I told you on the blob for both high pstates
14:38imirkin_: joi: so that's probably not great :)
14:38pmoreau: karolherbst: Most likely :-)
14:38karolherbst: but there can be a lot of different things wrong
14:39karolherbst: there are some comments about that in the gddr3 source
14:39joi: imirkin_: weren't mlankhorst's locking patches for libdrm supposed to fix this?
14:39imirkin_: not a libdrm issue
14:39karolherbst: mhhh, Networkmanager wakes up my laptop, strange
14:39imirkin_: mlankhorst did have some patches for mesa though... but they did things weirdly (imo)
14:39imirkin_: and incompletely
14:40imirkin_: i should do another pass on them that does the bare minimum to not do HORRIBLE things
14:40imirkin_: but still not work
14:41rez_: hello mmu_man!
14:41rez_: mmu_man: i heard of you, but I don't remember where :D
14:43rez_: mmu_man: ha yes, you have some relation with the demoscene :)
14:43mmu_man: yeah I do some ugly things with ORIC Atmos and other stuff :)
14:46rez_: mmu_man: ho nice! so you probably know that good old Jylam and DBug :)
14:47rez_: mmu_man: I never had so much fun coding since I started to do ASM on Commodore 64 :D
14:48joi: imirkin_: I restarted witcher2 ~20 times and other than this "Unknown handle" it seems quite stable
14:48mmu_man: they are still alive on ircnet, on #oric
14:49mmu_man: btw, http://triplea.fr/alchimie/ ;-)
14:49mmu_man: get your C64 back and come make us a nice demo!
14:50karolherbst: joi: ohh which patches?
14:50rez_: mmu_man: haaa ok, dbug is on #demofr and jylam on our #libcaca and #lol channel :)
14:50rez_: mmu_man: ha yes Alchimie :D
14:50joi: karolherbst: imirkin:master: "nouveau: be more careful about freeing buffers"
14:50karolherbst: joi: mesa?
14:51karolherbst: I suspected a kernel module fix as well, but okay
14:51joi: (with 1st chunk reverted)
14:53karolherbst: joi: why is that?
14:53karolherbst: joi: but you said you still get crashes?
14:55karolherbst: joi: I meant why the first chunk reverted
14:55joi: because Ilia told me to do it
14:57pmoreau: karolherbst: 0f 00004008: 80186400
14:57karolherbst: pmoreau: I meant the entire range
14:57karolherbst: 4008 0x14
14:57karolherbst: these should cover 6 regs from 3 plls
14:58pmoreau: Oh! I thought you meant writing 0x14 to 4008 while running Nouveau
14:58karolherbst: nope :D
14:58karolherbst: memory reclocking is never done with nva tools
14:58karolherbst: because this would be insane
14:58pmoreau: Ok, rebooting again
14:58karolherbst: I need those values with nouveau and blob
14:59karolherbst: if they are too different, then this may one issue
14:59pmoreau: I could do those for Nouveau now
14:59karolherbst: yeah, that's why I tried you to stop rebooting :)
14:59pmoreau: Do you need it only for highest perflvl?
14:59karolherbst: should be enough
14:59pmoreau: Well, it doesn't take that much time anyway
14:59karolherbst: but for both would be better
15:00pmoreau: Oh, except I'm not on the correct kernel version, I don't have Roy's patches
15:00pmoreau: So, still have to reboot
15:04joi: imirkin_: heh, just to be sure I reverted your patch and I can't reproduce fifo read faults :(
15:05joi: I'll go back to mesa from week ago and retest without&with your patch
15:09pmoreau: karolherbst: 00004008: 80186400 00001603 00000000 00000000, remaining is 0
15:10karolherbst: there should be another though :/
15:10karolherbst: maybe 0x18 then? :D
15:10karolherbst: or do you mean both reamining?
15:10pmoreau: I'll try 0x18
15:11pmoreau: karolherbst: Still 0 for the rest
15:11karolherbst: which was the nouveau codename again?
15:12karolherbst: ahh okay
15:12karolherbst: these are the values for nouveau?
15:12pmoreau: For the blob
15:12karolherbst: and second highest pstate?
15:13pmoreau: 00004008: 90186400 00001a04 00000000 00000000
15:13pmoreau: (rest is 0)
15:14karolherbst: okay, now nouveau :)
15:14pmoreau: Sure, let's reboot first ;)
15:14karolherbst: both states have stuff in common already, so
15:14karolherbst: nearly the same as kepler gddr5
15:20pmoreau: karolherbst: 00004008: 80186400 00001603 00000000 00000000
15:20karolherbst: okay, so PLLs aren't the reason it fails
15:23karolherbst: then you should trace it, there are many other places where stuff could be wrong :/
15:23karolherbst: 0x100710 0x10 for example
15:23karolherbst: 100da0 and 4008, but I think these are mainly fine
15:24karolherbst: then there are the timings, but they should be right as well...
15:24karolherbst: don't know, trace please :D
15:25pmoreau: 00100710: 0000021f 00033022 00022077 00044077
15:25pmoreau: I'll do the same with the blob and trace it
15:28karolherbst: then please do short traces, because I don't feel like searching for the moment where the blob changes to the highest pstate ;)
15:28pmoreau: 00100710: 00000070 00033122 00022077 00044077
15:28karolherbst: this is different
15:28pmoreau: I usually add marker just before switching the perflvl
15:28karolherbst: ohh okay
15:28karolherbst: let's try something
15:29karolherbst: see this line? https://github.com/karolherbst/nouveau/blob/master/drm/nouveau/nvkm/subdev/fb/ramnv50.c#L353
15:29karolherbst: ram_wr32(hwsq, 0x100710, 0x70); instead
15:29karolherbst: this may or may not work for highest pstate
15:29karolherbst: and may or may not work for other pstates
15:30karolherbst: even lowest could be messy with it
15:30karolherbst: I know the time, where I added constant values
15:30karolherbst: and got like 162MHz me clock at 0a
15:30karolherbst: instead of 1600
15:30daemon32: pmoreau: Which hardware is this?
15:30karolherbst: daemon32: tesla :p
15:30pmoreau: daemon32: a G96 card (9600M GT)
15:31daemon32: pmoreau: Oh, fun, I've got an 8600M GT that won't stay connected to its board :P
15:31daemon32: I have to put that damned thing in the oven every six months, if I want to keep using it
15:32pmoreau: karolherbst: I should have "ram_mask(hwsq, 0x100710, 0x00000070, unk710);", right?
15:33pmoreau: Oh, yeah, sorry
15:33karolherbst: ram_wr32(hwsq, 0x100710, 0x70);
15:33pmoreau: I just parsed the 0x70, and not the rest
15:35pmoreau: Maybe I should port Roy's patches to Ben's tree. I'm not used anymore to have to build a new image each time I make a change...
15:36karolherbst: pmoreau: you should know that, if this works, then we are kind of screwed for now :)
15:37karolherbst: so I really hope it does not
15:37karolherbst: because I don't plan to RE this stupid reg :D
15:38pmoreau: But maybe RSpliet wants to :D
15:43karolherbst: pmoreau: so please just go into highest pstate :D
15:43karolherbst: anyway, in which pstate does your gpu boot?
15:43karolherbst: second lowest I assume?
15:47pmoreau: karolherbst: Exactly
15:47pmoreau: The display did came back
15:47pmoreau: I tried to start Steam, to check if the framerate had increased
15:48pmoreau: And the whole thing just froze when trying to display my Steam library
15:48joi: imirkin_: on 8f6fd57db2275 4 out of 5 times I reproduced fifo read faults, on 8f6fd57db2275 with your patch 5 out 6 times there were no errors and the only one was different (multiple instances of buffer 2 on validation list)
15:48karolherbst: pmoreau: so is it "better" or the same?
15:49pmoreau: karolherbst: Before: black screen, now: no black screen but freeze when launching steam
15:49imirkin_: joi: but on master without my patch you don't get the fifo read faults?
15:49karolherbst: pmoreau: progress! :D
15:49joi: yes :/
15:50pmoreau: karolherbst: I didn't try to launch steam while having the black screen, kinda hard to detect if it froze or not :D
15:50karolherbst: okay, so this reg is indeed important
15:50imirkin_: joi: that's highly surprising
15:50karolherbst: +1 for the one adding this comment there :D
15:50joi: imirkin_: but maybe it's just coincidence
15:51karolherbst: pmoreau: but that means, that reclocking itself worked
15:51imirkin_: joi: in that case my patch "helping" is also easily coincidence
15:51karolherbst: pmoreau: did you read back the pstate file?
15:51pmoreau: karolherbst: One thing I didn't try, is if reclocking would now work, even without switching to the G96
15:51pmoreau: I didn't
15:51karolherbst: you should
15:51karolherbst: to check if the clocks are screwed up
15:51pmoreau: I can do that, I'm on the correct kernel version
15:51joi: imirkin_: yes, that's possible :/
15:52imirkin_: gnurou: sorry, don't have a better place to report this -- the docs at http://docs.nvidia.com/cuda/parallel-thread-execution/#parallel-synchronization-and-communication-instructions-atom are wrong for the inc() description -- should be ? r : r+1
15:52pmoreau: karolherbst: 00100710: 00000070 00033022 00022077 00044077
15:53imirkin_: gnurou: errr... ? s : r+1
15:53karolherbst: pmoreau: I meant the pstate file ;)
15:53pmoreau: Oh, yeah, I had read it
15:53karolherbst: and the clocks were close enough?
15:54pmoreau: Well, they are the same
15:54pmoreau: I guess, they are close enough
15:54pmoreau: On 0e they are a bit off
15:55pmoreau: 1MHz for core and shader, 2MHz for memory
15:55karolherbst: as I said
15:55karolherbst: coding some hard values in is a lot of fun
15:55karolherbst: the other pstate should be messed up as well
15:56karolherbst: ohh you meant diff
15:56pmoreau: They aren't that much messed up
15:56pmoreau: Yeah, diff
15:56karolherbst: I thought ....
15:56pmoreau: :D :D :D
15:56karolherbst: 2MHz is close enough :D
15:56karolherbst: timings can't be different though
15:56karolherbst: which may make sense
15:56karolherbst: try to run glxgears on 0f
15:58pmoreau: Yeah, with 0x70 it seems better: I can reclock while having the MCP79 driving the display
15:58karolherbst: pmoreau: "unk710 = ram_rd32(hwsq, 0x100710) & ~0x00000101; ... ram_mask(hwsq, 0x100710, 0xffffffff, unk710);" << this unk710 value seems to be read the wrong way, but I don't get why this should be right in the first place
15:58pmoreau: Though, I'll have to check if it works before switching to the G96 in the first place
15:58karolherbst: should be the same then
15:59karolherbst: funny pthon, funny
16:00karolherbst: hex(~0x00000101) == -0x102
16:01imirkin_: karolherbst: really annoying :)
16:02joi: imirkin_: oh shit, I think I screwed up testing master
16:02karolherbst: It seems there is a level I didn't reach yet, instead of calculating with decimal values, use hex values instead for daily calculations
16:02imirkin_: karolherbst: something to aspire to
16:03joi: I forgot to actually revert the last patch
16:03joi: in my defence I can say I as distracted by the ending of "300"
16:05karolherbst: pmoreau: okay, we need a trace of this hwsq scripts
16:07karolherbst: blob and nouveau
16:08karolherbst: hwsq looks kind of strange :D
16:08imirkin_: joi: you've been testing with this, right? https://github.com/imirkin/mesa/commit/718d28e4d8d4ab0a3ab19e45b820ba801f520263
16:09pmoreau: karolherbst: Meh... Can't start X anymore, it closes itself automatically
16:10karolherbst: but shouldn't gddr3 work in general?
16:10karolherbst: or is it the same broken as gddr5?
16:11pmoreau: It should work afair
16:11karolherbst: so this is more of a chip specific issue
16:11joi: imirkin_: almost, also with nv50_miptree.c
16:11imirkin_: joi: yeah, but that code doesn't get run for you
16:12joi: that's a relief
16:12imirkin_: [you have a GK10x right?]
16:12imirkin_: some nv50_miptree code gets run, but nvc0 has its own destroy
16:12imirkin_: no it doesn't
16:12imirkin_: interesting. so destroying buffers is what killed it for you? surprising.
16:15joi: I can retest original patch...
16:15imirkin_: no, doing the kicks there is def wrong
16:15imirkin_: resources can be deleted without a context active
16:15imirkin_: or from another thread
16:19karolherbst: pmoreau: okay, I think I found the trace part for 0f reclocking
16:20karolherbst: only need it for nouveau then
16:21imirkin_: karolherbst: search for HWSQ\[
16:21karolherbst: imirkin_: I have the script already :)
16:21karolherbst: but I need to compare to nouveau
16:23pmoreau: karolherbst: Ah, ok. Was going to trace the blob.
16:23pmoreau: Rebooting to the correct kernel version then
16:23karolherbst: yes :)
16:23pmoreau: So, the important part is reclocking from default to 0f, right?
16:25rez_: well so: https://twitter.com/chiptune/status/647550889817964544
16:25joi: imirkin_: 718d28e4d8 also works, 0 errors in 5 runs
16:26imirkin_: joi: great!
16:27imirkin_: hopefully it doesn't also leak oodles of memory
16:27imirkin_: that's a really basic bug though... a bit annoying that it's been around this long =/
16:28karolherbst: pmoreau: yes
16:29RSpliet: pmoreau: ah! that's probably related to the "wait for VBLANK" code
16:29RSpliet: excellent, that's a good lead :-)
16:29RSpliet: or well, the timeout is
16:29RSpliet: the perflvl f not working isn't...
16:29imirkin_: rez_: step 1 of crashing nouveau: go to shadertoy.com
16:29pmoreau: neither is 0e
16:29karolherbst: RSpliet: I heard you want to RE one reg
16:30RSpliet: they're nearly equal
16:30karolherbst: 00100710 to be precise
16:30imirkin_: rez_: also shadertoy shaders tend to rely on long for loops, and there's some undiagnosed issue with long for loops
16:30karolherbst: the value differs on nouvea, and with the blob value, pmoreau doesn't get a black screen
16:30imirkin_: rez_: i.e. after like 100 iterations it just kinda craps out for no apparent reasons
16:34imirkin_: rez_: https://bugs.freedesktop.org/show_bug.cgi?id=78161
16:35RSpliet: karolherbst: oh, is that the only diff to fix things... that's well possible, I'll keep that in mind, tn
16:35RSpliet: I think we touch that on GT21x, so it shouldn't be too hard to figure out
16:36karolherbst: okay :)
16:37RSpliet: pmoreau: the patches should apply cleanly to Ben's tree too
16:37RSpliet: no porting required
16:37pmoreau: Ok, cool :)
16:37RSpliet: previously I had to manually hack paths, but I don't think that's even required nowadays
16:38karolherbst: RSpliet: is PCOUNTER anywhere related to clocking?
16:38RSpliet: not atm
16:39karolherbst: I have to reduce the trace a little, will ask random stupid questions maybe
16:39imirkin_: karolherbst: it should eventually be used to drive reclocking decisions
16:39karolherbst: imirkin_: yeah I figured
16:39karolherbst: what is PMC all about?
16:40imirkin_: memory controller
16:40imirkin_: it controls... memory.
16:40karolherbst: seems related
16:40imirkin_: er wait
16:40skeggsb: master control
16:40imirkin_: master controller
16:40imirkin_: skeggsb: welcome back!
16:40skeggsb: thanks :) i'm alive, barely
16:40skeggsb: jet-lag is fun
16:41karolherbst: *hmpf* on a headless gpu this is much easier to debug :(
16:41imirkin_: karolherbst: on a headless gpu, there's a lot less display logic that tries to read out your memory while you disconnected it
16:41karolherbst: I not saying I don't know why it is easier :D
16:43RSpliet: pmoreau: anyway, I'll dive into it tomorrow
16:43karolherbst: skeggsb: do you need some tested-by for the gddr5 patch?
16:43RSpliet: I think :-P
16:43RSpliet: I want to get these patches out the door before starting my PhD
16:43skeggsb: karolherbst: i don't mind, i've seen enough msyelf on irc to be convinced
16:43imirkin_: skeggsb: oh, i got confirmation that my 16k patch worked on GM107 (from the same guy with 3x 4k screens). there were a bunch of display artifacts, but that could just be usual maxwell shittiness
16:44skeggsb: cool, worse stuff would've happened if it was because of that
16:44skeggsb: so, i'll make a note to merge it
16:44karolherbst: skeggsb: did you noticed that on maxwel there are _a_lot_ more regs returning "bad" on read?
16:47RSpliet: on second thought, fudge it... I'm drunk, I'll do excellent RE'ing now
16:47karolherbst: is PFIFO anywhere reclocking related ?
16:47karolherbst: RSpliet: :)
16:47RSpliet: must be paused before initiating reclock
16:48karolherbst: yeah, but I meant more, do the PFIFO regs matter for stability?
16:48karolherbst: mhh maybe another stupid question
16:48RSpliet: if you don't pause PFIFO, your card will crash during reclock
16:48karolherbst: is PFIFO anywhere related to gddr3? :D
16:48imirkin_: skeggsb: the worst thing that happens is that the earlier fermis don't support it, and we'll get some complaints. i'm not too worried.
16:50skeggsb: imirkin_: hm, looking at cl907d.h, it should be ok
16:50karolherbst: pmoreau: you really should check if glxgears or anything simplier than steam works
16:50imirkin_: skeggsb: ok :)
16:51imirkin_: skeggsb: in practice, i don't think you can go over 8k on fermi
16:51skeggsb: assuming it's not lying, or there's not extra checks beyond the size of the bitfield :P
16:51imirkin_: without doing something unreasonable
16:51skeggsb: well, there's panning
16:51imirkin_: like having a huge void in the middle or something
16:51imirkin_: does anyone do that on purpose?
16:51imirkin_: by accidnet -- yes, happens every now and then :)
17:04rez_: imirkin_: yes i had a hard time with shadertoy, but it works not so badly (except framwoerate) with my problematic setup :D
17:04rez_: imirkin_: i just wanted to show that it's possible to code something with a faulty video driver ;)
17:08imirkin: rez_: quite so, yes.
17:11rez_: btw, except some black pixels sometimes, the shaders are perfectly rendered now
17:11imirkin: rez_: yeah, it's coz of the loops which crap out in the middle after a lot of iterations
17:11imirkin: rez_: no idea why
17:11rez_: while most of them were a total mess some month ago
17:12rez_: imirkin: ho
17:12imirkin: i did push out a few fixes for nv50
17:12rez_: you are doing an awesome work, i can't imagine how much things you have to know/learn to code a video driver :)
17:13imirkin: a lot fewer when you have a working video driver someone else wrote :)
17:26imirkin: skeggsb: btw, what are we going to do about the OF situation?
17:26imirkin: skeggsb: do you not have a preference re how to fix it?
17:30daemon32: karolherbst: Just FYI, I narrowed the voltage issue I mentioned on reddit down to the last two cstates
17:30karolherbst: daemon32: yeah, makes sense
17:30karolherbst: it will be usually the last ones
17:30daemon32: karolherbst: Ah, more hurdles I take it?
17:30karolherbst: nouveau just doesn't parse one of the voltage tables the right way
17:31daemon32: Well, we're nearly there xD
17:31karolherbst: imirkin: excuse me if I bother you with that, but I really want that nvapeek 88000 1000 really bad :)
17:32karolherbst: daemon32: except some other stuff
17:32imirkin: karolherbst: oh crap. i forgot.
17:32imirkin: karolherbst: and now i'm away from the box again
17:32karolherbst: I don't feel like to search for that in the traces, but well
17:33karolherbst: anyway, I don't know what the benefit of this is on kepler anyway
17:34karolherbst: maybe the width can be changed indeed, but I doubt we will ever figure out how
17:34karolherbst: on kepler+ that is
17:40rez_: tonight X didn't crashed but my log is kinda "funny": http://people.zoy.org/~rez/nouveau_dmesg4.txt
17:42karolherbst: rez_: well isn't it obvious? VRAM_LIMIT :p
17:43karolherbst: I have no clue how nouveau will react when there is no vram, but it won't do something usefull I assume
17:44karolherbst: rez_: how much vram does your card have?
17:47rez_: karolherbst: NO IDEA :D
17:47karolherbst: rez_: okay, which gpu do you have?
17:47rez_: it's a MBA 2010, Apple doesn't give much info on their hardware :D
17:47karolherbst: usually they do
17:48rez_: karolherbst: Nvidia 320M
17:48rez_: karolherbst: ha sorry
17:48rez_: everything is at beginning of the first log
17:48karolherbst: 256MB, should be enough usually
17:49karolherbst: what are you trying to run?
17:49rez_: but i'm annoying everybody with my problem since this morning :D
17:49rez_: karolherbst: just an X server :D
17:49karolherbst: X without anything
17:50karolherbst: or login to desktop?
17:50rez_: karolherbst: sometimes X can crash because I changed of virtual screen (I'm using i3wm)
17:50rez_: tonight (the log you have seen) i mostly used chromium
17:50rez_: and a bunch of shell
17:51karolherbst: you could check how much vram is used with the blob though
17:51rez_: the blob?
17:52karolherbst: but, well
17:52karolherbst: if it is with x and i3wm already
17:53karolherbst: but maybe you really run out of ram
17:53karolherbst: because 2GB - 256MB and chromium....
17:53karolherbst: or do you have 4GB ram?
17:54rez_: yes i have
17:54karolherbst: okay, that's not that bad
17:54rez_: and I'm using only 50% of it
17:54rez_: also, as i said before, some months ago nouveau was working fine
17:55rez_: (nrandomo crash)
17:55karolherbst: mhh okay
17:55karolherbst: you could try to bisect it
17:56rez_: yes :)
17:56karolherbst: or try out older kernels
19:14daemon32: Is there a known problem with the fans?
19:15daemon32: Because I keep getting spammed with this: "[41718.669490] nouveau 0000:01:00.0: therm: FAN target request: 0%"
19:15daemon32: And I have to manually raise pwm1_min to get the fan going
19:15daemon32: Or else this happens, and scares me when it screams: "[41716.479995] nouveau 0000:01:00.0: therm: temperature (90 C) hit the 'fanboost' threshold"
19:16imirkin: daemon32: chances are you flipped the fans into manual mode
19:17daemon32: imirkin: Is that pwm1_enable?
19:17imirkin: yeah, if you touch that it goes out of auto mode
19:17imirkin: on boot it should be auto... in thoery
19:17imirkin: there are some fermi's that get misdetected somehow
19:17daemon32: When it boots, it's at 2, and I haven't touched it ever
19:18imirkin: hm, 2 = auto
19:18daemon32: And I'm kepler (GK104)
19:18imirkin: file a bug, include your vbios, logs
19:18daemon32: Alright, will do
19:19daemon32: Well, my dmesg is cut off, since it's been flooded, so it doesn't include anything from boot
19:19daemon32: Should I get a clean boot?
20:29daemon32: imirkin_: I don't mean to be a bother, I'm brand new to being in the open source community
21:22LordShadowWing: daemon32: it's free-software not open-source listen to Richard Stallman
21:23imirkin: actually best thing you can do ignore anything coming from RMS
21:26daemon32: Eh, I'm in the middle, I use like BSD/MITish stuff and GPL stuff
21:26daemon32: I use FreeBSD on my laptop and Linux on my desktop