00:02 imirkin: ok, i'm out for real.
00:03 chewitt: night.
00:05 chewitt: I still think there should be something in dmesg to say this is active.. but nothing
02:27 chewitt: almost
03:35 karolherbst: imirkin: I see you are unhappy with the talos situation? But I think you are kind of right, because usually it wasn't looking that bad. One thing though: in third person view, sometimes the arm was getting "cut off" and hovering in a strange angle
04:13 chewitt: dumb question time: does it matter if nouveau is build with =m or =y
04:13 chewitt: because I built with =y
04:13 chewitt: (previously =m)
04:13 chewitt: no hang on boot.. but no module loaded either
04:15 chewitt: netconsole is a bust.. there is something odd about our distro that prevents it from working
04:15 chewitt: using another (different hardware) test box I can get some (a little) but not useable output
04:16 chewitt: but on the box that counts.. nada
04:23 prg: =m might be more convenient, so you can blacklist the module, boot, make sure everything is working (like netconsole), then load the module
04:23 prg: but =y should still work, it's just built in so there is no module
04:23 prg: netconsole is just a kernel thing, so distro shouldn't matter
04:24 prg: (unless the distro patches the kernel to break such things, then just use a vanilla kernel)
04:24 mogorva: Hi! What are the advantages to use a newer version of LLVM? I have 3.5.0 installed on Fedora 22. Out of curiosity I tried llvm-3.6.1 from the rawhide repo but mesa fails to build: http://hastebin.com/vahitibeni.vbs
04:31 chewitt: here's the kernel config.. we are relatively normal http://sprunge.us/UTCX
04:33 prg: that doesn't show patches the distro might have applied. but i'd assume there are no netconsole-breaking patches and it's more like a configuration problem
04:35 chewitt: I wonder.. https://github.com/OpenELEC/OpenELEC.tv/blob/openelec-5.0/packages/linux/patches/3.17.8/linux-003-no_dev_console.patch
04:36 chewitt: although that wouldn't explain why on different hardware I do get some netconsole output
04:36 chewitt: but it starts late and stops (always) after ~10 lines.. at the same point
04:45 prg: by default only important messages are sent, try dmesg -n 8
04:45 prg: after that everything should get sent
04:48 prg: you can test with sysrq+s, by default you only get "SysRq : Emergency Sync" over netconsole, after dmesg -n 8 you also get "Emergency Sync complete"
06:26 gnurou: airlied: may I gently ping you for https://lkml.org/lkml/2015/7/1/145 ? It is required for Nouveau on ARM64, and should be sitting in your mailbox somewhere
10:33 imirkin_: hakzsam: btw if you're looking for a nice and easy nouveau cleanup, s/boolean/bool/ (and BOOLEAN)
11:23 karolherbst: imirkin_: by the way, do you know that the subroutine has some piglit fails?
11:23 karolherbst: seems like compiler stuff only
11:25 imirkin_: airlied: --^
11:25 karolherbst: I think the subroutine keyword isn't parsed well
11:26 karolherbst: spec@arb_shader_subroutine@compiler@subroutine-param-type-mismatch.vert and subroutine-return-type-mismatch.vert
11:26 karolherbst: spec@arb_shader_subroutine@linker@no-overloads.vert fails too
11:26 karolherbst: no-mutual-recursion.vert crashes
11:27 karolherbst: first one get compiled allthough the shouldn't
11:27 karolherbst: same for the third fail
11:27 karolherbst: all of these have "subroutine" involved"
11:36 hakzsam: imirkin_, you don't like boolean keyword? :)
11:37 imirkin_: it's not a keyword
11:37 imirkin_: it's a typedef to char
11:37 hakzsam: yes, bool is a keywork but not boolean
11:38 imirkin_: right.
11:38 imirkin_: actually in C, bool is also not a keyword
11:38 imirkin_: it's a typedef to _Bool
11:38 imirkin_: which in turn is a built-in type in C99
11:39 imirkin_: they did that to avoid the oodles of existing code that already typedef'd bool to something
11:39 hakzsam: maybe, I'll make a patch if I don't make progress on the vertexid stuff :)
11:39 tobijk: heh, maybe i'll do between my crashes :O
11:40 tobijk: btw somebody already using xproto 7.0.28? :>
11:40 hakzsam: nope
11:41 tobijk: i narrowed my crashes down to Mesa-10.6.1 -> 10.6.2 and xproto 7.0.27 -> 7.0.28
11:45 tobijk: mh xproto with its client increase from 256->512 would make sense, as my xserver always dies in the long unchanged FlushAllOutput() function which iterates over all clients
11:45 tobijk: do we have xserver experts here? :D
11:46 mlankhorst: those exist?
11:46 tobijk: ;-)
13:10 karolherbst: tobijk: :O
13:10 karolherbst: mupuf: !
13:10 tobijk: ?
13:10 karolherbst: mupuf: !!!!
13:10 karolherbst: tobijk: found the issue
13:10 tobijk: yours or mine? :D
13:10 karolherbst: both
13:11 karolherbst: mupuf has the same
13:11 karolherbst: tobijk: https://bugs.freedesktop.org/show_bug.cgi?id=91316
13:11 hakzsam: tobijk, do you plan to make the boolean patch?
13:11 karolherbst: so xproto is the culprit?
13:11 tobijk: hakzsam: i got sidetracked, if you want to do them, go ahead
13:11 karolherbst: tobijk: it can't be mesa, because I am using master since always
13:11 tobijk: karolherbst: it could be
13:12 hakzsam: tobijk, I'll do so
13:12 karolherbst: will check that
13:12 karolherbst: tobijk: there is a workaround patch
13:12 tobijk: where? :O
13:13 karolherbst: tobijk: https://gist.github.com/karolherbst/33327ebcb804abea5baf
13:13 karolherbst: its for the X server
13:13 karolherbst: dirty workaround
13:13 karolherbst: but it stops crashing
13:14 tobijk: ah
13:15 tobijk: i'll first test if it _really_ is xproto, but if its really, i guess somebody foreget to make the limit 512 instead of 256 :)
13:15 tobijk: *somewhere :D
13:17 hakzsam: imirkin_, I assume that we also need to s/TRUE/true (for the boolean patch) ?
13:17 hakzsam: btw, BOOLEAN doesn't exist
13:18 mlankhorst: its in wine, but its a bite..
13:18 mlankhorst: byte*
13:18 hakzsam: I mean, I can't find BOOLEAN in src/gallium/drivers/nouveau ;)
13:19 imirkin_: hakzsam: yes
13:19 imirkin_: hakzsam: and also FALSE -> false
13:19 hakzsam: sure :)
13:20 imirkin_: hakzsam: yeah, that might have gotten nuked a while back. or i'm imaginign it
13:24 imirkin_: karolherbst: i wonder if http://cgit.freedesktop.org/xorg/proto/xproto/commit/?id=2c94cdb453bc641246cc8b9a876da9799bee1ce7 is related
13:26 karolherbst: the thing is, I am sure that clients is just 256 big
13:26 imirkin_: yeah, there's a stupid thing going on:
13:26 imirkin_: configure.ac: CFLAGS="$CFLAGS -DFD_SETSIZE=256"
13:27 karolherbst: :D
13:27 karolherbst: in xorg-server?
13:27 imirkin_: oh, but only for cygwin/mingw
13:27 karolherbst: mhhh
13:27 karolherbst: will check something
13:28 karolherbst: mhh
13:28 karolherbst: but the X server doesn't get built against xproto anyway
13:28 imirkin_: include/dix.h:extern _X_EXPORT ClientPtr clients[MAXCLIENTS];
13:28 imirkin_: include/misc.h:#define MAXCLIENTS 256
13:28 karolherbst: yeah
13:28 karolherbst: that's it
13:29 karolherbst: wow
13:29 karolherbst: serious ABI problem is going crazy here
13:29 imirkin_: bleh, ajax's not here
13:29 tobijk: but we found it in the end :)
13:29 karolherbst: yeah
13:30 karolherbst: but unbound array access
13:30 tobijk: we my crash indicates and oob access
13:31 imirkin_: i've mentioned it in #dri-devel
13:32 hakzsam: imirkin_, well, some functions still need to use boolean for the prototype because they depend of the gallium interface...
13:32 imirkin_: hakzsam: such as?
13:32 hakzsam: begin_query()
13:33 hakzsam: nouveau_screen_fence_finish(), etc
13:33 karolherbst: tobijk: in fact there was memory corruption going on
13:33 imirkin_: boolean (*begin_query)(struct pipe_context *pipe, struct pipe_query *q);
13:33 imirkin_: sadness.
13:33 imirkin_: i guess leave those.
13:34 imirkin_: fixing those up can be a project for another day
13:34 hakzsam: sounds good to tme
13:34 hakzsam: *me
13:35 imirkin_: wow, p_compiler.h both includes stdbool.h *and* typedefs boolean to char??
13:35 imirkin_: that's some serious schizophrenia
13:35 glennk: that's... special
13:35 karolherbst: bool for itself is strange
13:36 karolherbst: I am suprised, that mostly false/true aren't set to the most sane values anyway
13:50 hakzsam: imirkin_, marek has introduced a compilation warning with 05a12c53a308965aba1c00f0caf36d8e0f32e035 (writable shader images)
13:50 hakzsam: I'm going to fix it too
13:50 imirkin_: ok
13:50 hakzsam: the prototype of nvc0_set_shader_images() has not been updated
13:50 imirkin_: i thought he #ifdef'd that out
13:55 hakzsam: actually, one parameter is missing
13:58 hakzsam: that's not a big deal since the function does nothing
14:12 hakzsam: the boolean patch is ready, but to make sure everything is okay, I'm going to build mesa with Clang because it detects more stuff than GCC
14:26 tobijk: if you see me crashing, then its not xproto :D
14:27 hakzsam: mupuf, clang is not installed on reator :D
14:28 hakzsam: tobijk, do you still have issues with llvm-3.6.2?
14:29 tobijk: hakzsam: for now my way of solving it: remove the broken package ;-)
14:29 tobijk: one problem at a time
14:29 hakzsam: what was that broken package? llvm?
14:29 tobijk: yep
14:30 tobijk: the function that is missing is a well defined one, i dont think they did remove it
14:30 hakzsam: mmh, we can't build mesa with llvm-3.6.2?
14:30 tobijk: hakzsam: i guess its the distro package
14:30 hakzsam: what distro?
14:30 tobijk: opensuse
14:31 hakzsam: okay, well I won't build with clang then :)
14:31 hakzsam: because I need to install llvm-3.6.2
14:31 tobijk: heh
14:39 hakzsam: imirkin_, patch sent
14:39 hakzsam: really painful to review, btw...
14:40 hakzsam: oh, the patch needs moderator approval
15:12 mupuf: hakzsam: why do you need clang?
15:12 mupuf: You can installl it :)
15:13 hakzsam: mupuf, to make sure everything is okay with the boolean patch (ie. s/boolean.bool)
15:13 mupuf: ack
15:13 hakzsam: yes, but it requires llvm-3.6.2 and tobijk seems to have some issues with that package (with opensuse)
15:14 hakzsam: I don't want to break anything on reator :)
15:58 tobijk: mupuf: the xserver crashes are really related to xproto > 7.0.28, so downgrading helps for now :)
15:58 mupuf: tobijk: what? :o
15:58 tobijk: * >=
15:58 mupuf: I have been using my distro-provided one
15:58 tobijk: karolherbst mentioned you had problems with a crashing xserver
15:59 mupuf: yeah, sounds plausible
15:59 mupuf: updated on the 1st of july
15:59 mupuf: ok, can you tell me more about what is going on?
15:59 tobijk: we narrowed it down to xproto .27 -> 28
16:00 tobijk: the client size increased from 256 to 512, that seems to cause problems
16:00 tobijk: dont ask me where they are exactly :>
16:00 mupuf: http://cgit.freedesktop.org/xorg/proto/xproto/commit/?id=2c94cdb453bc641246cc8b9a876da9799bee1ce7
16:00 tobijk: right
16:00 mupuf: this is the commit that likely breaks everything
16:01 mupuf: so it is not corruption in the end
16:01 tobijk: i guess we end with oob access somewhere
16:01 mupuf: yeah
16:01 airlied: probably the macro
16:01 mupuf: right, should be pretty easy to track down now
16:02 airlied: as we override FD_SETSIZE to 256 in some places I think
16:02 imirkin_: airlied: for cygwin/mingw
16:02 tobijk: yeah imirkin found it
16:02 mupuf: I mean, it is not like the other commits are relevant
16:03 mupuf: tobijk, imirkin_; thanks for tracking it down
16:03 mupuf: I spent some time on it on monday
16:03 mupuf: and friday
16:03 tobijk: :)