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