01:22 neoraider: Hi, I've just set up reverse PRIME with intel + nouveau. It's working nicely, but I see tearing on the nouveau output, is there anything I can do to fix that?
01:24 neoraider: Ugh, I have to correct myself. 2D output and VAAPI are working fine (apart from the tearing), but GL gives me about 1 FPS with glxgears
01:24 karolherbst: neoraider: seems like your gl setup is a bit borked
01:25 karolherbst: how does glxgears do on your intel screen?
01:25 neoraider: karolherbst, on the Intel screen it's working fine
01:25 karolherbst: and what happens when you move the window to the other screen?
01:26 neoraider: It stops working as soon as it is completely on the nouveau screen
01:26 karolherbst: mhh
01:26 karolherbst: but if it is partly it still works?
01:26 neoraider: Yes
01:26 karolherbst: even if only one pixel line is on the intel display?
01:26 neoraider: Yes
01:26 karolherbst: mhhh
01:27 karolherbst: seems like I found a workaround :p
01:27 karolherbst: but this looks a bit strange
01:27 karolherbst: mhhh
01:27 karolherbst: then dmesg and x log please
01:27 karolherbst: neoraider: does it tear when it is partly on the intel screen?
01:30 karolherbst: maybe airlied has a clue, any idea why gl contexts fully displayed on a reverse primed output are messed up, but if only parts of it are on the main screen, it works?
01:31 karolherbst: neoraider: another question, does the part on the nvidia screen also looks fine? Or only the part on the intel screen?
01:31 karolherbst: maybe something is odd with the communication between both cards
01:33 neoraider: karolherbst, ah, I've fixed it myself. I had DRI3 enabled in xorg.conf, but my mesa doesn't seem to be compiled with DRI3 support
01:34 karolherbst: ohhh
01:34 karolherbst: that makes partly sense
01:35 karolherbst: so does it work with dri3 support in mesa then? :D
01:38 neoraider: I'll try
01:52 neoraider: karolherbst, I was wrong about the DRI3 support, mesa is compiled with DRI3.
01:54 karolherbst: okay, so how does the part on the nvidia screen looks like when it is partly on the intel screen?
01:55 neoraider: With my previous setup, where GL was completely broken on the nouveau output?
01:56 neoraider: As long as a part of the window was on the intel output, everything looked fine (apart from the tearing on the nouveau output)
02:00 qq[IrcCity]: could anybody explain the «struct nvkm_device» object? is there one such thing per video card (hence we expect one nvkm_device_init()) , or ?
02:09 karolherbst: qq[IrcCity]: I think so
02:18 karolherbst: neoraider: could you post your dmesg and x log then? maybe there is just something odd
02:34 neoraider: I'm getting more and more confused. I'm not so sure anymore if my mesa actually has DRI3, so I'm now building it myself to be sure. `LIBGL_DEBUG=verbose glxinfo` should show me something about DRI3 if it is supported, shouldn't it?
02:35 neoraider: karolherbst, I'll paste the logs as soon as I'm finished with my current tests
02:36 karolherbst: neoraider: do you get something like "libGL: Using DRI3 for screen 0"?
02:37 karolherbst: and what distribution do you use? Usually the intel ddx doesn't support DRI3
02:37 neoraider: Arch Linux
02:37 neoraider: No, LIBGL_DEBUG=verbose doesn't show anything about DRI3 at all
02:39 karolherbst: mhhh
02:39 karolherbst: I don't actually know if reverse prime does work with dri3 at all :D
02:41 neoraider: According to https://wiki.archlinux.org/index.php/PRIME , it should work in some setups... maybe?
02:42 neoraider: Well, would DRI3 potentially fix the tearing issues on the reverse prime output? If it doesn't, I don't really need DRI3 anyways...
02:42 neoraider: Can reverse prime even work without tearing at the moment?
02:46 karolherbst: depends, but yes it should work
02:50 neoraider: Meh. My nouveau DDX is ancient as well... I guess I'll have to recompile a lot more packages to get DRI3
02:55 fling: Can't I use this with nouveau? -> https://wiki.ixit.cz/d3d9
02:55 fling: https://wiki.ixit.cz/_media/winecfg.png
02:57 Yoshimo: depending on your cards reclocking status in nouveau it might be a slide show
03:00 karolherbst: fling: you can, but you need wine-staging + recent mesa
03:01 fling: karolherbst: I have wine staging and recent mesa!
03:01 karolherbst: fling: then it should work
03:01 fling: hmmh mmm
03:02 fling: karolherbst: mesa is 11.0.0
03:02 karolherbst: well, usually you need bleeding edge mesa with these state tracker patches
03:02 fling: staging useflag is enabled on wine.
03:02 fling: ohh
03:02 fling: I will then install both bleeding edge mesa and wine.
03:02 karolherbst: maybe 11.0.2 is fine though
03:03 fling: No need for bleeding edge nouveau driver?
03:03 karolherbst: if the games are working then no
03:03 fling: libdrm? kernel?
03:03 fling: ok
03:03 fling: karolherbst: thanks for the info ;>
03:04 fling: Don't I need gles1/gles2 btw? I have them disabled.
03:05 neoraider: karolherbst, okay, it now seems like I've enabled DRI3 successfully. Unfortunately, Xorg now segfaults as soon as I start a GL application when the nouveau output is enabled O_o
03:06 karolherbst: neoraider: reverse prime is a lot of fun as you see, never tested it myself yet, because I am lucky enough to have all ports connected to my intel gpu
03:06 fling: karolherbst: don't I need to rebuild anything after mesa upgrade?
03:06 neoraider: karolherbst, well, here's the Xorg.log: https://paste.debian.net/314341/
03:07 karolherbst: fling: no
03:07 neoraider: I guess I'll have to as the intel devs for that one...
03:07 neoraider: *ask
03:07 karolherbst: neoraider: maybe you shouldn't enable DRI3 on the nouveau ddx
03:09 neoraider: karolherbst, doesn't make a difference, still segfaults
03:10 karolherbst: also you may want to try dri 2 on intel again
03:11 karolherbst: I am not sure if reverse prime works with dri 3 at all
03:11 neoraider: Yes, with DRI2 it works fine
03:12 neoraider: Only the tearing remains...
03:12 karolherbst: but how is the perf on the nouveau screen?
03:13 neoraider: Performance seems fine
03:13 karolherbst: okay
03:13 karolherbst: do you use kwin?
03:13 neoraider: No, just xmonad, no compositing, no reparenting
03:13 karolherbst: ohhh
03:13 karolherbst: you may want to enable compositing
03:13 neoraider: Okay, I'll try
03:13 karolherbst: and full tearing prevention/vsync whatever
03:32 neoraider: karolherbst, well, I couldn't get rid of the tearing, but I found another way to crash Xorg: by setting a VAAPI window to fullscreen on the nouveau output (again the backtrace shows the intel DDX)
03:33 karolherbst: mhh
03:33 karolherbst: you should file a bunch of bug reports :D
03:34 neoraider: Yes, I'll do that
03:44 fling: karolherbst: I'm now rebuilding wine with latest everything
03:44 fling: with all the patches I mean.
04:09 joi: imirkin: it seemed to be a sane idea at the time, I'm not sure how kernel is supposed to guess to which channel gem bo belongs to when channel_hint is always 0...
04:25 fling: Native Direct3D 9 is active.
04:35 fling: karolherbst: blackops crashes with native
04:35 fling: karolherbst: is 3.17.7 too old?
04:35 fling: Or do I need to update libdrm or somethnig…
04:35 karolherbst: depends on where the crash is
04:36 karolherbst: usually it is the fault of the d3d state tracker somewhere
04:36 fling: err:winediag:init_driver_info Could not find GPU info for 10de:0603.
04:37 fling: and a lot of these -> err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
04:42 karolherbst: what gpu do you have?
04:42 karolherbst: ohh wait
04:43 karolherbst: your pci id seems odd
04:44 fling: karolherbst: http://dpaste.com/2ERW8QS
04:44 karolherbst: this looks fine so far
04:45 karolherbst: maybe you may want to boot with nouveau.pstate=1 though
04:45 karolherbst: so you can actually clock to your 0f pstate
04:46 fling: karolherbst: will it reclock automagically after I reboot with nouveau.pstate=1?
04:46 karolherbst: no, you have to do it
04:46 karolherbst: but it's better than not be able to do it
04:46 fling: Will it give me the huge performance boost?
04:47 karolherbst: no
04:47 fling: hmm hmmm
04:47 karolherbst: 20%
04:47 karolherbst: it is still significant
04:48 karolherbst: I thik your gpu is just missing in wine
04:48 karolherbst: have to check something
04:52 karolherbst: fling: and what card do you have (model)?
04:52 karolherbst: not chipset
04:52 fling: karolherbst: 9800 something I think.
04:53 karolherbst: not GeForce GT 230 OEM ?
04:53 karolherbst: what does lspci print?
04:53 karolherbst: either way, your card isn't listed in wine
04:53 karolherbst: you need to add something like that: https://github.com/karolherbst/wine/commit/627aebf77467d594cb986c523f81bb48c6bdea68 just for your gpu
04:54 fling: not
04:54 karolherbst: what does lspci | grep VGA say?
04:54 fling: karolherbst: why is this needed?
04:54 karolherbst: because wine has to know what card is it
04:54 fling: 01:00.0 VGA compatible controller: NVIDIA Corporation G92 [GeForce GT 230 OEM] (rev a2)
04:54 karolherbst: okay, as I said GT 230 :p
04:54 fling: But it is not.
04:54 karolherbst: mhhh
04:54 fling: This one is way much older.
04:54 karolherbst: where did you buy that card?
04:54 karolherbst: and when
04:55 karolherbst: actually the clocks fit to the GT 230
04:55 fling: From an underground store many years ago
04:55 karolherbst: and because it is only DDR2
04:55 karolherbst: yeah
04:55 karolherbst: then it is a GT 230
04:55 fling: hmm hmmm
04:55 karolherbst: you gut scamed
04:56 fling: haha :D
04:56 karolherbst: the card still has the pci id of a GT 230
04:56 fling: is this bad or good? :P
04:56 karolherbst: mhh well, the driver does the right thing
04:56 RSpliet: fling: fyi: nouveau can't change the clocks of DDR2 memory of that generation
04:57 karolherbst: but a 9800 has like 504 GFLOPS and 230 only 360
04:57 karolherbst: so your card is actually slower than a 9800
04:57 karolherbst: not much though
04:58 fling: Should I buy radeon? :D
04:58 karolherbst: it is still the same chipset
04:58 karolherbst: depends on what you want to do
04:58 karolherbst: if you don't mind using the prop driver, then no
04:58 fling: I want to try playing Black Ops.
04:58 karolherbst: if you want to use the open driver, then radeon
04:58 fling: hmm hmmm
04:58 karolherbst: anyway, you could hack together a patch like mine
04:59 karolherbst: isn't too hard
04:59 karolherbst: I am sure somebody in #winehq may help you with that
04:59 karolherbst: they need this anyway
05:00 karolherbst: fling: and your card has 1536 MB vram
05:00 fling: Is this good?
05:00 karolherbst: it is more than a 9800 has :D
05:00 fling: hmm hmmm
05:00 karolherbst: you just need to know this for wine support
05:05 karolherbst: fling: if you are lucky you may get your money back if the store still exists
05:05 karolherbst: and if you have enough evidence
05:18 karolherbst: fling: do you know how to build wine and install it?
05:22 fling: karolherbst: yes, I use emerge.
05:23 karolherbst: ohh nice
05:23 fling: I'm running wine in an lxc container ;P
05:23 karolherbst: would you like to add https://github.com/karolherbst/wine/commit/e640a33ce837520acc48140e8dbf27e1efffe4c9.patch this patch?
05:23 fling: I would
05:23 karolherbst: with that wine should kind of work for you then
05:23 karolherbst: or at least should work better
05:23 fling: kinda work?
05:23 fling: ok, adding
05:25 karolherbst: fling: I don't know if that changes much, but with -staging it helps wine to know how much vram your card has
05:26 karolherbst: anyway, maybe it makes more sense for you to use the propritary driver with bumblebee, when reclocking doesn't work, but maybe it is _fast_ enough with nine
05:26 karolherbst: there is an overlay though
05:26 karolherbst: ixit
05:26 karolherbst: it should provide patches mesa/wine with more recent nine changes
05:28 fling: karolherbst: bumblebee?
05:28 karolherbst: yeah, but you can't use it with nine
05:28 karolherbst: ohh wait
05:28 karolherbst: you have a desktop
05:28 karolherbst: nvm
05:28 karolherbst: then you can just use the prop driver :D
05:28 karolherbst: you don't need bumblebee then
05:29 fling: hm mhmm
07:58 karolherbst: imirkin: found another game with some graphical issues
07:59 karolherbst: will try to create a small trace
08:00 karolherbst: 180MB, this is small
08:03 karolherbst: I like how this trace crashes apitrace
08:07 karolherbst: and I like how I already know about that crash :/
08:15 karolherbst: works with llvmpipe and looks okay there
08:38 karolherbst: any idea where the issue is? https://gist.github.com/karolherbst/249ce119b918bce9819f
08:48 qq[IrcCity]: karolherbst: is __src=0x43697d10 a valid memory address?
08:49 karolherbst: qq[IrcCity]: I've rebuilt mesa with -Og and will rerun gltrace
08:50 karolherbst: qq[IrcCity]: but the issue has to be somwhere in core mesa (or in the game)
08:50 karolherbst: or every driver implemented something wrong :D
08:50 karolherbst: qq[IrcCity]: updated: https://gist.github.com/karolherbst/249ce119b918bce9819f
08:50 karolherbst: at least we have the memcpy length now
08:51 karolherbst: an no, it is not valid memory
08:51 karolherbst: ohh wait
08:51 karolherbst: it i is
08:52 qq[IrcCity]: so, it crashed beause of invalid destination?
08:52 karolherbst: but __src+0x100 is invalid
08:53 qq[IrcCity]: but 200 < 0x100
08:53 karolherbst: ohhh right
08:54 karolherbst: +0xc8 also invalid
08:54 karolherbst: up to 0xb9 it is valid
08:55 karolherbst: invalid since 0xc0
08:55 qq[IrcCity]: an obvious out-of-bounds condition.
08:55 karolherbst: actually 0xbd, but that doesn't matter then :D
08:55 karolherbst: yeah
08:55 karolherbst: the game actually crashes with the prop driver, too
08:56 karolherbst: this could be because of some really rare corner case nobody cared about since, or the game engine is faulty
10:23 imirkin: karolherbst: can you do 'i locals' at the nouveau_scratch_data frame?
10:23 imirkin: karolherbst: and p nv.scratch
10:23 imirkin: er, p nv->scratch
10:24 imirkin: karolherbst: what's the actual valid limit there?
10:24 karolherbst: imirkin: will do
10:24 imirkin: perhaps nouveau is miscounting somehow or doing something else dodgy
10:24 karolherbst: imirkin: it is not nouveau faults
10:25 karolherbst: I am pretty sure it is the fault of the game engine doing something nasty
10:25 karolherbst: because I get also crashes with the blob
10:25 imirkin: oh
10:25 karolherbst: but maybe mesa can fortify against that somehow
10:25 imirkin: ok, then i don't care :)
10:25 imirkin: maybe. i don't know how you can find out if an address is valid or not
10:25 karolherbst: :D
10:27 karolherbst: i locals: bgn = 1721044
10:27 karolherbst: p nv.scratch $1 = {map = 0x7ffff1b9a000 <error: Cannot access memory at address 0x7ffff1b9a000>, id = 3, wrap = 3, offset = 1721436, end = 2097152, bo = {0x0, 0x20e9a60, 0x423b99b0, 0x42f75530}, current = 0x42f75530, runout = 0x0, bo_size = 2097152}
10:29 karolherbst: it is a race condition somewhere though
10:29 karolherbst: because the crash is always at a different frame
10:29 imirkin: weird.
10:29 karolherbst: imirkin: can it be the game engine fauilt, if it alsoc rashes in glretrace?
10:29 karolherbst: obviously wrong order of API calls, but still
10:29 imirkin: no
10:29 karolherbst: okay
10:30 karolherbst: it crashes in the trace :)
10:30 karolherbst: but
10:30 imirkin: or at least... sounds like an apitrace bug in there too
10:30 karolherbst: while tracing the app, it did not :D
10:30 karolherbst: mhh
10:30 karolherbst: maybe the game was tested on radeon, and radeon did something wrong/right I don't know
10:31 imirkin: could also be a situation where nouveau reads buffers it's not supposed to
10:31 karolherbst: it also crashes with intel though
10:31 karolherbst: llvmpipe seems fine though
10:32 karolherbst: I could give you the trace if you want
10:32 karolherbst: it's "only" 100MB compressed
10:36 imirkin: not really
10:37 imirkin: perfectly happy to allow you the privilege of keeping debugging it :)
10:43 karolherbst: thanks a lot
10:45 imirkin: you're most welcome :)
10:45 karolherbst: I have still noe clue what's happening :D
10:46 karolherbst: I just wanted to show you some graphical artifacts in that game and now I am surprised with that segfault
10:48 karolherbst: ohh a pattern
10:48 karolherbst: it seems like the _src area is either 28 too small or count 28 too big
10:49 karolherbst: now it is only 20 :/
10:55 imirkin: could be an off-by-1 situation somewhere
10:55 karolherbst: I try to find it
10:56 karolherbst: ohhh
10:57 imirkin: (including in the game, sadly)
10:57 karolherbst: yeah
10:57 karolherbst: I think there is a race condition somewhere
10:58 karolherbst: but why does it even crash in glretrace at random points
10:58 karolherbst: :/
10:58 imirkin: apitrace might be bad at client-side arrays
10:58 karolherbst: it does work fine with llvmpipe
10:59 karolherbst: what does "Illegal sampler view creation without bind flag" mean?
11:02 karolherbst: yeah, no crash with llvmpipe
11:09 imirkin: karolherbst: could be that nouveau defers the read for longer than apitrace expects? dunno
11:13 karolherbst: could valgrind help?
11:15 imirkin: sure
11:18 karolherbst: seems like it will take an hour though :D
11:24 qq[IrcCity]: I modified nouveau to make «device->devinit->post = true; nvkm_device_init(device);» (commanded via sysfs) to clear a GPU lockup. without post = true is hasn’t any visible effect, …
11:25 qq[IrcCity]: … but loading with config=NvForcePost=1 on Linux startup causes nouveau to fail at all.
11:25 imirkin: yeah, it skips execution of the init scripts unless it wants to post
11:26 karolherbst: imirkin: okay I am getting some invalid reads inside this memcpy
11:26 karolherbst: 4 until now
11:26 karolherbst: same trace all the time
11:48 karolherbst: imirkin: okay, the memory region is somewhere allocated while parsing the trace, I figure that means that some buffer is created an d later used with a bigger size?
12:41 karolherbst: imirkin: okay, I got the calls which cause the invalid read, what should I do next?
12:42 karolherbst: one of them is like this: 238100 @1 glDrawRangeElements(mode = GL_TRIANGLES, start = 0, end = 112, count = 168, type = GL_UNSIGNED_SHORT, indices = blob(336))
12:44 imirkin: ok, so, ... 168 * 2 = 336, so that's all good
12:45 imirkin: check the bound vertex arrays and check their stride against the max range
12:45 imirkin: end = 112, so each one must be at least 112 * stride in size
12:45 karolherbst: how can I do that
12:45 imirkin: if you use qapitrace, it'll show you all the info
12:45 karolherbst: k
12:46 karolherbst: do I have to one the trace for that?
12:47 karolherbst: ohh the vertex data
12:47 karolherbst: k
12:48 karolherbst: what is the stride size?
14:33 Cosumu: what does this mean in kernel logs? BLOCKLINEAR_CB
14:33 Cosumu: -- on hangs i get a lot of those messages.
14:35 imirkin: Cosumu: what's the full log line?
14:35 imirkin: iirc it's a mismatch between various settings to pgraph
14:35 Cosumu: [28000.342102] nouveau [ PLTCG][0000:01:00.0] LTC1_LTS3: BLOCKLINEAR_CB
14:36 Cosumu: and a few of these [28000.341466] nouveau [ PLTCG][0000:01:00.0] LTC1_LTS1: EVICTED_CB BLOCKLINEAR_CB
14:36 imirkin: what kernel are you on?
14:36 Cosumu: [28000.341471] nouveau [ PLTCG][0000:01:00.0] LTC1_LTS2: EVICTED_CB
14:36 Cosumu: 4.3
14:36 imirkin: and what gpu do you have?
14:36 Cosumu: nvidia 650ti
14:36 imirkin: that's a GK10x right?
14:36 Cosumu: i do beleive so
14:36 imirkin: did these issues happen with 4.2?
14:37 Cosumu: yep
14:37 imirkin: ah too bad. i was hoping it was a regression.
14:37 Cosumu: pretty much every kernel back to 3.17 (haven't tried older ones) however on some kernels i would only get a lockup/hang once a month, with others its hourly.
14:38 imirkin: well, LTC = level two cache
14:38 imirkin: so it's *some* sort of mismatch between... something
14:38 imirkin: also, those log lines aren't from 4.3-rc
14:39 Cosumu: hmm, one of my montiors (a korean panel) has an invalid EDID, however the driver is able to display 2560x1440 just fine. the non-free driver cannot.
14:40 imirkin: weird
14:40 imirkin: how's it hooked up?
14:40 Cosumu: DVI-D-2
14:40 Cosumu: does this mean anything?
14:40 Cosumu: [ 204.444640] nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device
14:40 Cosumu: [ 204.444641] nouveau 0000:01:00.0: registered panic notifier
14:40 imirkin: that's just the fbdev registration stuff
14:41 Cosumu: there is an EDID check sum error, however thats way back when xorg starts.
14:41 imirkin: if it's hooked up over dvi (and not some hdmi -> dvi thing), then the only diff is in dual-link vs not
14:42 Cosumu: i also get a strange thing with dpms, where my hdmi display will not sleep.
14:42 Cosumu: Probs something simple.
14:48 Cosumu: oh and another thing; using chromium or google-chrome makes it hang. (within about 10 minutes)
14:50 imirkin: i've heard that from a few people... i pushed some fixes to mesa, you could try git and see if that fixes it
14:52 Cosumu: ty
16:13 imirkin: skeggsb_: see above for the LTC errors... do those ring a bell? i don't think i've seen stuff like that.
18:03 imirkin: i wonder if the translate module knows about BE vs LE... presumably it does
18:04 imirkin: nv30 works when feeding everything through the translate module
18:05 imirkin: but not if i feed it in directly
18:06 imirkin: hmmmmmmmm i think things are getting one time too many
18:06 imirkin: (or too few?)
18:52 Jayhost: Trying to get help on Kernel message Firmware: failed to load nouveau/nv117_fuc409c
18:53 imirkin: Jayhost: 4.1+ should get you acceleration on GM107
18:54 Jayhost: I guess that means I have to compile from source. I'm on Debian 8.2 stable
18:55 imirkin: Jayhost: be aware that people are reporting some pretty nasty issues with GM107, so it's probably not going to help *that* much
18:56 Jayhost: Ouch. Is there an alternative. Right now I had to set Nomodesetting to get small resolution
18:57 imirkin: blob drivers work quite well
18:57 imirkin: as do open-source radeon ones, although that's of limited conslation to you now that you have the nvidia hw :)
18:58 Jayhost: I wanted to avoid proprietary. Hmm. I also couldn't use CVT xrandr to set my "default" res
18:58 imirkin: yeah, nomodeset = no nouveau. you're using vesa
18:58 imirkin: which can only set fixed modes
18:58 imirkin: anyways, that firmware load fail error shouldn't affect modesetting
18:58 imirkin: just acceleration
18:58 imirkin: modesetting should still work fine
18:59 imirkin: although if you're using DP, you might need to switch to 4.3-rcN -- a bunch of issues relating to DP on GM10x were resolved there i think
18:59 Jayhost: Without nomodesetting I get low resolution plus red dots
18:59 imirkin: well, try the latest kernel and see if that still happens
19:00 imirkin: if so, file a bug
19:00 imirkin: (latest kernel == 4.3-rc4 right now, btw)
19:00 Jayhost: Debian Testing gives me more trouble
19:00 Jayhost: What's the easiest way to get 4.3-rc
19:00 imirkin: https://www.kernel.org/
19:01 imirkin: if you're looking for prebuilt stuff, find a distro support channel and ask there
19:03 Jayhost: I suppose I'll read up on how to patch.
19:04 imirkin: no need to patch
19:06 Jayhost: Does using HDMI create more problems?
19:08 imirkin: don't think so
19:24 Jayhost: Working on it, are you a nouveau developer?
21:17 Jayhost: Fingers crossed shutdown -r now
21:22 Jayhost_: Imirk success
21:39 Jayhost_: @imirkin thanks, Nothing seems to be broken at this point.
22:03 karolherbst: after reclocking I got a "bus: MMIO read of 00000000 FAULT at 085048 [ TIMEOUT ]" but nothing else I usually get
22:03 karolherbst: anyway, the card seems to have crashed for some reason
22:04 karolherbst: ohh wait, the card just returns "bad0011f" for every reg
22:05 karolherbst: ohhh no, not for all
23:21 imirkin: Jayhost: glad it worked out
23:24 imirkin: skeggsb_: is this sort of thing expected? http://hastebin.com/vaqomujupo.hs
23:24 imirkin: skeggsb_: i would have imagined that the pushbuf would have gotten rotated...
23:24 imirkin: (this is on nv30)
23:38 karolherbst: imirkin: when I add kernel module parameter, should I do that where I use it or do I have to do some special stuff for non-linux kernels?
23:38 imirkin: if it's in nvkm, you should use the same mechanism as everything else
23:38 imirkin: so that the various helpers work
23:39 karolherbst: okay
23:48 imirkin: skeggsb_: i'm trying to find differences between how nv30 does things and nv50
23:49 imirkin: skeggsb_: it seems like nv50 is a bit more optimized in terms of its pushbuf kick handler usage, but fundamentally they behave the same way
23:49 imirkin: skeggsb_: and yet i'm getting these weird fence issues on nv30 ppc be
23:52 karolherbst: imirkin: mhh somehow I don't find anything non-linux like (or do other kernels port nouveau over themselves?)
23:54 imirkin: karolherbst: nvkm_longopt & co
23:55 karolherbst: yeah I saw them already, I just thought they would deal with more than they do