01:02baumy: is there any way to get 6 monitors to work with 2 nvidia 970 gpus under nouveau? i'm having no luck
02:39karolherbst: imirkin: aha!
02:39karolherbst: now I get some better information
02:39karolherbst: nouveau: kernel rejected pushbuf: Cannot allocate memory; nouveau: ch0: krec 0 pushes 1 bufs 276 relocs 0
02:40karolherbst: imirkin_: here if you can make anything out of it: https://gist.github.com/karolherbst/5c71043b241164ca0b45
02:41karolherbst: just added 32GB zram swap on my system and metro just peaker ad 14GB real memory usage + 10GB zram usage
05:53karolherbst: seriously? unchecked array index access in Xorg?
05:54karolherbst: got a nice backtrace for my X crashes now
07:18imirkin: karolherbst: "cannot allocate memory" -- pretty self-explanatory :p
07:18karolherbst: yeah , but I had still a lot of memory left
07:19karolherbst: metro was only at 32GB vm ... :D
07:19imirkin: did you see something in dmesg?
07:19karolherbst: a lot of oom stuff again
07:20karolherbst: I tried to check if there is an upper bound somewhere so that I get at leaste one run without an oom
07:20karolherbst: but I guess I really need more real RAM for that, 16GB real RAM + 32GB zram swap didn't really do the trick
07:22karolherbst: but I noticed something
07:22karolherbst: while ooming the process metro got stuck because of nouveau errors
07:22karolherbst: so it was already listed as "dead" in top without any memory usages anymore
07:22karolherbst: like a zombie process, but it waited for nouveau to respond
07:22karolherbst: and while nouveau through sched errors, the memory usage slowly dropped while doing it
07:23karolherbst: and by slowly I mean like 3-4 GB per "cycle" nouveau could respond something
07:25karolherbst: imirkin: this is whats in the logs before the fun starts: https://gist.github.com/karolherbst/eb45f0da564d980b5f09
07:27karolherbst: this is before oom, after I only get these SCHED_ERROR [ CTXSW_TIMEOUT ], BIND_ERROR [ UNBIND_WHILE_RUNNING ] and failed to idle channel
07:28karolherbst: maybe if I find my screwdriver I try with 32GB ram (allthough I think 1 dimm of them is a little bit broken or my laptop doesn't like it) and 64GB zram swap
07:44imirkin: baumy: i think patches were commit to Xorg git to be able to support offsets on reverse prime screens. however the system will likely feel very slow, since there is no 3d or 2d acceleration available on the GM20x series.
07:45baumy: imirkin: thanks for the answer, didn't fully understand that though. what is a reverse prime screen?
07:46imirkin: baumy: http://nouveau.freedesktop.org/wiki/Optimus/
07:46baumy: also i would only be using this for web browsing and text editing, i don't think slowness will bother me
07:46imirkin: ignore the fact that it's talking about intel, the same applies to any multi-gpu combination
07:46baumy: oh, that I didn't know
07:46imirkin: [and obviously ignore all the switcheroo and mux bs]
07:46baumy: I thought it was exclusively for switching between discrete GPUs and integrated graphics
07:46baumy: ok thank you, I'll read up on this
07:46imirkin: you're looking for "Using outputs on discrete GPU" in that page
07:47baumy: ok I will give that a try
07:47imirkin: basically you just run xrandr --setprovideroutputsource 1 0
07:47imirkin: and presto-changeo, you have the other gpu's outputs available in xrandr
07:47baumy: if that actually works you're my hero, I haven't seen mention of that in any documentation anywhere
07:48baumy: actually, nouveau crashes on startx for me but that's probably because I botched getting rid of nvidia, I can figure that out
07:48imirkin: (a) get rid of xorg.conf
07:48imirkin: this won't work if you have an xorg.conf
07:48imirkin: (b) once you've done that, pastebin your xorg log
07:49baumy: I'll do that now, thanks. this is on arch by the way, so it should be a fairly recent version of nouveau
07:49imirkin: you actually shouldn't be using the nouveau ddx here in the first place... hm. i don't think it recognizes the GM20x gpu's
07:49imirkin: you should be using 'modesetting'
07:49imirkin: which might only recently have gained reverse-prime functionality
07:49imirkin: (and by recently, i mean xorg git)
07:51baumy: modesetting is a substitute for nouveau? I must be confused about what does what
07:51baumy: I thought modesetting was just for the boot process and nouveau was the video driver
07:52imirkin: there is a DDX called 'modesetting' which just drives the KMS interfaces
07:53imirkin: [and has integration with glamor, should you have a working 3D driver]
07:53imirkin: but i think you underestimate how slow this will all be...
07:54imirkin: i'm guessing that these aren't 800x600 screens you're hooking up
07:54baumy: 1200p but they'll pretty much be running vim and firefox
07:54karolherbst: imirkin: does reverse prime actually works with DRI3?
07:54imirkin: it's a lot of pixels :)
07:54imirkin: karolherbst: no clue
07:54karolherbst: because with dri3 xrandr doesn't list the nouveau card
07:55karolherbst: xrandr --listproviders just gives the intel one
07:55karolherbst: maybe I try it out on the fermi card here, because there is a hdmi port plugged on the nvidia card :/
07:56karolherbst: but first I need an HDMI cable for that
07:56imirkin: karolherbst: you should be able to see the thing in xrandr whether you have an HDMI cable or not :p
07:57karolherbst: ohh right
07:58baumy: trying to start an xserver is actually freezing now
07:58karolherbst: mhh, and my screwdriver is too big for the screws of my keyboard, where my other dimm slots are under :( so no test with more RAM apperantly
08:01imirkin: baumy: if you can ssh in, perhaps you can figure out what happened
08:01baumy: did get a log http://jbaumy.com/files/xlog.txt
08:02baumy: had to hard restart the machine though since it was frozen
08:03baumy: from skimming that all I can see is that it did correctly recognize all my hardware
08:03imirkin: baumy: yeah, seems all happy
08:03baumy: and yet frozen =/
08:03imirkin: glamor thankfully fails
08:04baumy: what is glamor?
08:04imirkin: right... well what are you running?
08:04imirkin: gnome or kde or something?
08:04imirkin: coz those are right out.
08:04baumy: no DE
08:04imirkin: not really familiar with i3, but does it use a compositor? if so, turn that off.
08:04baumy: it doesn't
08:05baumy: I've used one in the past with it but it doesn't start automatically
08:05imirkin: do you see anything in dmesg?
08:05baumy: a whole lot of stuff from nouveau, none of which looks at all informative
08:05karolherbst: i3 is a tilling window manager ;)
08:06imirkin: baumy: any errors before/during the freeze?
08:06baumy: nope, just freezes on the tty after i type `startx'
08:06baumy: only thing in my xinitrc is `exec i3'
08:06karolherbst: baumy: are you running compton?
08:07imirkin: baumy: and you can't ssh in anymore once it's "frozen"?
08:08imirkin: note that "freeze" can be a very relative concept... could just be that the screens stop updating and everything else keeps working fine
08:08baumy: i probably can, since i can get to another tty
08:08baumy: just moved to a new place + new router, haven't set up nice sshing yet
08:08baumy: gimme a minute
08:08imirkin: ah. and nothing in dmesg, just frozen?
08:08imirkin: weird :(
08:09baumy: i agree
08:10karolherbst: maybe .xsession-errors tells something
08:11karolherbst: maybe i3 complains about something
08:11imirkin: baumy: what if you just start X, without i3?
08:11imirkin: i.e. literally run 'X'
08:11baumy: i'll try that
08:11imirkin: you should see a black screen with the X mouse cursor and that's it
08:11baumy: i also need to do a fresh install on a new hard drive, i'm gonna do that too and see if everything Just Works
08:12imirkin: (it used to draw the mask, for background, but that got nuked somewhere along the way)
08:15baumy: running just `X' gets a nice juicy error!
08:16imirkin: care to share?
08:16baumy: working on it
08:17baumy: slightly convoluted process with lack of ssh
08:17imirkin: ah yeah. might want to get that going at some point ;)
08:26imirkin: systemd strikes again
08:27imirkin: good luck with that, sorry, can't help much with crazy system setup issues
08:27imirkin: it's some sort of permission fail i assume
08:27imirkin: or... who knows with systemd
08:27baumy: i was vaguely afraid of this
08:27baumy: well I can dig into it
08:27karolherbst: baumy: don't you have tty* files in /dev ?
08:28imirkin: nah don't worry about that
08:28imirkin: this is not the error you're looking for ;)
08:28baumy: if that --setprovidervideooutputsource flag actually works that's all i really need to know, i can get it working
08:28imirkin: instead of 'exec i3', what about 'exec xterm'
08:29baumy: same freeze, don't think the problem is the program i'm trying to launch
08:29karolherbst: no of course
08:29karolherbst: baumy: try running X as root
08:30baumy: that gives me the willies but i'll try
08:30karolherbst: yeah well, X is usually run with root rights
08:30baumy: i thought that was changed a year or so ago
08:30imirkin: yeah, systemd insanity
08:30karolherbst: there are scripts for that
08:31karolherbst: basically systemd opens the socket and fds and everything and X can't use them
08:35hakzsam: imirkin, does your Rb is for all the series or only for the patch #1?
08:36imirkin: just patch #1
08:36imirkin: not enough context in patch #2, need to look at the code
08:36imirkin: also need to test on nvc0
08:36hakzsam: yes, sure
08:37baumy: well once i figure out this systemd business and get nouveau running at least, i'll see if that flag works
08:37baumy: thanks for all the help
08:37hakzsam: imirkin, we could ask mupuf to plug a fermi, but I remember that you have a c0, right?
08:39imirkin: and a kepler
08:39imirkin: baumy: my guess is there's some deeper issue
08:39karolherbst: baumy: did X start as root?
08:39imirkin: but unfortunately i have no clue what it might be
08:39karolherbst: or same issue?
08:39imirkin: baumy: i'd start by unplugging all but one screen
08:40imirkin: (make sure to actually unplug the cable, not just power the screen off)
08:40imirkin: and then going from there
08:40baumy: x didn't start as root, had the exact same issue
08:41baumy: since i'm doing a fresh install anyway i'll try that with one screen and see how it goes
09:16martm: hi, does anyone know if there is in hw level some drastical differences between hw context and vbo, they way gpu executes them?
09:18martm: for instance to map a huge allocation to the cpu to certain physical address blocks with ioremap, and write a minor program to make one context, youd roughly know where the context will end up in physical vram
09:19martm: now when you copy the contents from that bo to vbo, i wonder what would happen, will the gpu execute those instructions that were in context buffer that are now in vbo?
09:25martm: imirkin: mupuf: don't be shy
10:27phillipsjk: I pulled an AMD Athlon X2 system from the trash, which according to my benchmarking (monero mining) is faster and more efficient than my Pentuim D.
10:29phillipsjk: I am curious if nouveau can take advantage of 3DNow! instructions. The existence of the "MESA_NO_3DNOW" knob in this page: http://www.mesa3d.org/envvars.html suggests yes.
10:30phillipsjk: My video card is on the PCI bus though, which is a bottle-neck by modern standards.
10:31imirkin_: phillipsjk: nnnnot really. nouveau doesn't really do anything cpu-heavy in the first place.
10:32imirkin_: every so often it has to convert texture formats, and vertex formats, but that's done by mesa core
10:32imirkin_: which might in fact be able to make use of 3dnow instructions... not sure
10:32imirkin_: you can check the gallium translate module
10:32imirkin_: there's a translate_sse impl
10:32phillipsjk: ooh, key word!
10:32imirkin_: which uses rtasm to put together dynamic programs to convert things
10:33imirkin_: sort of a very simplistic jit
10:33RSpliet: 3dnow? :-D
10:33imirkin_: i forget what core mesa uses for this stuff... iirc something similarish
10:33imirkin_: but nothing that gets too much attention... most modern programs never hit these paths
10:35phillipsjk: Yes, software rendering on the CPU never was too popular. (other than quake doing insane things with the Pentium FPU)
10:37imirkin_: i dunno which gpu you have... the nv30 driver has a fallback path to do vertex shading on the cpu, which would in turn cause more cpu usage
10:37imirkin_: it uses gallivm (which in turn uses llvmpipe) for this... i don't think llvm jit has 3dnow support though
10:38imirkin_: but the fallback paths are almost never hit, unless you force them
10:38imirkin_: [and in fact were *quite* broken until recently when i fixed them up]
10:38phillipsjk: Machine had a GeForce 7600 GT in it (nv50 series?), but most the capacitors are vented.
10:40phillipsjk: I noticed that GPGPU is listed as stalled on the feature matrix.
10:41imirkin_: no, those are both nv4x's
10:41imirkin_: which use the nv30 driver
10:41imirkin_: nv4x isn't capable of GPGPU in the first place
10:41imirkin_: at least... not really
10:41imirkin_: you can do vertex shaders + TF i suppose
10:41imirkin_: or very carefully written fragment shaders
10:41imirkin_: but there's no gmem access
10:41phillipsjk: So no rush to replace the caps then :)
10:43phillipsjk: thanks for the chat. I am supposed ot be making food now.
10:45progman32: Hiya folks, I'm running into some odd PIBUS errors on my GTX 780 (GK110), and I've had no luck googling solutions. Figured I'd check here to see if the errors ring any bells. I'm seeing this repeated in dmesg over and over forever:
10:45progman32: nouveau E[ PIBUS][0000:01:00.0] GPC4: 0x5233e4 0xbadf1301 (0x01024215)
10:46progman32: Running Arch with kernel 4.0.7-2-ARCH
10:52imirkin_: progman32: some patches went into linux 4.1 which do PGOB powerup on there, perhaps it'll help. no idea.
10:52imirkin_: progman32: specifically http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=6986212516f9f079fe426d3c96fc4e7d11218bf6
10:54progman32: Interesting. I'll try a kernel with that patch and report back. Thank you!
10:57imirkin_: not a *ton* of people use GK110's with nouveau, so it's not the best-tested combination. however another user with a GTX 780 Ti (GK110B) got it to work just fine afaik [after some fixes landed in 4.0]
11:38progman32: imirkin: Still experience the issue running latest mainline 4.2.0-rc2. I will go ahead and file a proper bug report in a bit.
11:38imirkin_: progman32: sounds good
11:38imirkin_: perhaps ben will break out his GK110 and give it a go
11:39imirkin_: his is a titan though iirc
11:41progman32: Cool. I'll mess with this a bit more later in the week. Cheers!
12:43Kiranos: just tried nouveau with my three monitors and ubuntu 15.04, the mouse pointer disapers and stutters
12:44Kiranos: goes away with nvidia propitiary drivers
12:44imirkin_: what's your gpu/configuration?
12:57Kiranos: Imirkin_ Its two GT 240
12:57Kiranos: Three monitors
12:58imirkin_: not the GDDR5 GT 240's, i hope?
12:59Kiranos: Dont Know just now, dont have them herre, is there issues with them?
12:59imirkin_: the GDDR5 ones have issues yeah, although nothing like what you describe
12:59imirkin_: they have memory-looking issues because... dunno
13:00imirkin_: when you're back on the setup, we can do some debugging to see what's going wrong
13:00Kiranos: I tried fedora, ubuntu all the same
13:00Kiranos: Yes Will be tomorrow
13:07glennk: imirkin_, presumably gt240 would need higher than lowest memory clocks to drive two displays?
13:09imirkin_: glennk: i've never seen that to be an issue
13:10glennk: i've seen that on nvidia even with the binary drivers on older chips
13:10imirkin_: they push the clocks up coz reclocking with multiple displays is impossible
13:10imirkin_: coz they're not frame-locked
13:11glennk: not only, you need a certain bandwidth to drive the crtcs
13:11glennk: underrun that and all sorts of display randomness happens
13:13rpirea: imirkin how can i help you with informations about my graphic card?
13:16imirkin_: rpirea: i don't really remember your issue, but i doubt i can really help
13:17rpirea: imirkin_ i don't have any issue
13:19rpirea: but i thought i can be helpful by running some mmio test
13:19rpirea: with binary driver
13:21RSpliet: imirkin_: that's not quite true
13:22RSpliet: you can reclock with multiple monitors, all you need is a functional linebuffer
14:05chewitt: hello.. could anyone suggest ideas for a nouveau driver build problem: http://pastebin.com/NNkavRrP
14:05chewitt: (building from source)
14:06imirkin_: are you building against an ancient X server?
14:06chewitt: no, quite current
14:06imirkin_: too recent then ;)
14:07imirkin_: let me pull and see what happened
14:07imirkin_: oh. not at all new.
14:07imirkin_: but hardly ancient
14:08chewitt: I am new-ish to the world of xserver.. I get the impression there is a hideous dependency chain :)
14:08imirkin_: aha, you appear to be building with COMPOSITE defined (somehow)
14:09chewitt: bad idea?
14:09imirkin_: and nouveau does not account for that contingency
14:09chewitt: it's easy to kill
14:09imirkin_: easy enough to fix...
14:10chewitt: lets see :)
14:10imirkin_: the other uses of screen_x/y are guarded in nouveau_xv.c
14:10imirkin_: but this is a new use that didn't account for it i guess
14:11imirkin_: added by airlied it seems
14:12imirkin_: chewitt: http://hastebin.com/xewixekuga.coffee
14:15chewitt: patch added and rebuilding..
14:17imirkin_: mailed a slightly diff patch
14:27chewitt: first one wouldn't apply.. second one does though
14:27chewitt: many thanks!
14:27chewitt: now to see if the resulting graphics stack works..
14:33chewitt: not quite.. http://sprunge.us/dDFO
14:33chewitt: drm errors at the tail end
14:34imirkin_: you probably did 'insmod nouveau'?
14:34imirkin_: instead of 'modprobe nouveau' which will also load any module deps
14:34imirkin_: like, say, drm, or ttm
14:34chewitt: no such file or directory.. which probably explains the error :)
14:35imirkin_: in response to what command?
14:35imirkin_: yeah, that means "module load failed"
14:35imirkin_: coz you didn't have that module's dependencies already loaded
14:35imirkin_: modprobe looks at that info and pre-loads the deps first
14:35imirkin_: insmod just does what you tell it.
14:36imirkin_: or perhaps you had something built-in and then switched to module? that won't work without a full rebuild either :)
14:37chewitt: this is an appliance like OS
14:37chewitt: so i'm working in the build system to create an image which is transferred over to the test box
14:38chewitt: complicated.. but also quite rigid and logical
14:38chewitt: it's been using the nvidia blob.. so a few bits have changed
14:38chewitt: it's probably something dumb like file locations
14:41chewitt: AppleTV:~ # ls -l /lib//modules/3.17.8/kernel/drivers/gpu/drm/nouveau/nouveau.ko
14:41chewitt: -rw-rw-r-- 1 root root 1317528 Jul 15 01:27 /lib//modules/3.17.8/kernel/drivers/gpu/drm/nouveau/nouveau.ko
14:41chewitt: that exists..
14:41chewitt: what other dependencies are there? ..sorry for the dumb question
14:42imirkin_: did you run 'modprobe nouveau'?
14:42imirkin_: to find out all the deps, run 'modinfo nouveau'
14:42imirkin_: there are like 50 of them
14:45chewitt: depends: drm_kms_helper,ttm,wmi
14:45chewitt: and i'm not sure any of those are installed..
14:45imirkin_: well, they're certainly built
14:45imirkin_: kernel wouldn't build without them. but if they're not part of the things you copy over, then that won't work
14:46imirkin_: note that you obviously also need drm_kms_helper's deps, ttm's deps, etc
14:46chewitt: these are kernel things? .. or nouveau things?
14:46imirkin_: there's no such thing as 'nouveau' as a single entity
14:46imirkin_: it's made up of various bits of software
14:47imirkin_: there's the kernel module, the libdrm_nouveau library, the Xorg DDX (xf86-video-nouveau), and the mesa driver
14:53chewitt: looks like they are copied over to the right place
14:54chewitt: so.. time for a full clean build
14:54chewitt: which means an hour or so of compiling
14:54chewitt: and for me.. Zzz
14:54chewitt: thanks for the guidance
16:03imirkin_: airlied: does this look right to you? http://lists.freedesktop.org/archives/nouveau/2015-July/021626.html
16:03imirkin_: [i should have cc'd you, but forgot]
16:05airlied: people build without composite?
16:06imirkin_: scroll up :)
16:07airlied: the right answer it enable composite in the X server :-)
16:07airlied: I should probably make all the DDX refuse to build without composite support :-P
16:08airlied: but yeah patch should be fine, thoguh not sure why yoy removed fpix and moved pPix
16:09airlied: the only necessary bits should be moving the scren_x/y bits
16:09airlied: oh I suppose it reduces warnings maybe
16:09airlied: though since off_x/y are signed, you could just -= then += pDraw->x :-P
16:11imirkin_: airlied: yeah, didn't want to declare the var in the middle
16:11imirkin_: also i saw various code in the xserver which does -= i think
16:11imirkin_: i didn't come up with that all by myself ;)
16:12imirkin_: the main question was about whether pDraw->x/y was even necessary, or if that all's just 0
16:12imirkin_: i have no idea what any of these things are, so... :)
16:13airlied: yeah though really the problem is someone not having composite enabled
16:15imirkin_: is composite good for anything?
16:15imirkin_: other than sucking up system resources for no reason
16:16airlied: it's good for making your X server be consistent with what apps expect
16:16imirkin_: is composite related to compositing in any way?
16:16airlied: yes you can't run any sort of compositing WM without composite
16:16imirkin_: but can (do) you use composite without a compositor?
16:17airlied: some things get automatically composited
16:17imirkin_: it's def telling that it took 3 years for someone to notice the build fail ;)
16:18airlied: yes because he messed up configureing his X server more than likely
16:18imirkin_: sure, but the rest of nouveau supports it, so... may as well
16:18imirkin_: there are checks in nouveau_xv.c
16:20airlied: that code probably comes from nv :-)
16:20imirkin_: just lookign at how convoluted it is, seems likely
16:21imirkin_: i'll do your += trick though, i like it.
16:23imirkin_: airlied: http://hastebin.com/piyacuwici.coffee -- seem ok?
16:25airlied: imirkin_: looks good, r-b
16:31smoking-peanuts: I am getting a GPU lockup when using compiz .. I have been searching for lots of issues
16:34smoking-peanuts: is there a good place to start?
16:37smoking-peanuts: i tried LIBGL_DEBUG=verbose but didn't find out anything
16:46imirkin: smoking-peanuts: what gpu?
19:50smoking-peanuts: imirkin well the error message said E[drm] gpu lockup .. switching to fbcon o the # have a meaning that you can
19:52smoking-peanuts: what I mean is .. if numbers have a meaning that anyone might understand I can add them to my message
19:55imirkin: smoking-peanuts: well, that message is telling you that the gpu is hung
19:55imirkin: however it might be helpful to know what gpu you're using
19:59smoking-peanuts: imirkin.. what command will let me that?
19:59imirkin: lspci -nn -d 10de:
19:59smoking-peanuts: ok i sec
19:59smoking-peanuts: thanks for responding
20:03smoking-peanuts: imirkin that is something that I did know.. nvidia G72 [GeForce 7300 LE]
20:04smoking-peanuts: also has [10de:01d1]
20:04imirkin: ok cool. that's a pretty old GPU, and unfortunately, the nouveau 3d driver for those is quite ... lacking
20:04imirkin: so i am, unfortunately, not surprised that compiz destroys it
20:05smoking-peanuts: imirkin ok I can accept that
20:05imirkin: i pushed a few fixes for that driver of late, they should be in mesa 10.6.2 i believe
20:05imirkin: you can try updating mesa and see if that helps
20:05imirkin: but... i won't be too surprised if it doesn't
20:05Karlton: I have a 7200m that works fine
20:05imirkin: Karlton: with compiz?
20:05Karlton: yeah, i think so
20:06Karlton: its an piece of crap HP laptop from like 2006 or something
20:07Karlton: so I hardly use it
20:08smoking-peanuts: imirkin do you know if mesa 10.6.2 is packaged in a deb package?
20:09imirkin: smoking-peanuts: sorry, not sure
20:11smoking-peanuts: that is understandable.. I really appreciate the work of this project
20:11smoking-peanuts: hopefully I will start doing some driver dev.. I just wish I could do it in Rust
20:12smoking-peanuts: anyway thanks for your time imirkin
20:13imirkin: smoking-peanuts: if you're interested in improving the state of the nv30 driver, let me know ... there's lots wrong ;)
20:48chewitt: imirkin: the build I ran overnight boots to a torn screen and locks up .. or at least, boot didn't reach the point where I can SSH in
20:48chewitt: for coincidence.. i'm also doing this for nv30 on a 7300 chip :)
20:50chewitt: any suggestions on where to look for the problem? .. the only hint I can give is that it's early in the boot sequence
21:01imirkin: chewitt: netconsole
21:02imirkin: in general it should work fine, just... don't try heavy 3d applications. compiz is a particularly crazy app
21:07chewitt: I need to video the boot.. I removed "quiet" and saw stuff fly by..
21:08chewitt: netconsole is not something I know about
21:08imirkin: lets you stream kernel messages over udp
21:08imirkin: this is how i boot an arm board: firstname.lastname@example.org/eth0,@192.168.3.1/ console=ether
21:09imirkin: that tells it to set the ip address to 192.168.3.101 on eth0, and send the udp packets to 192.168.3.1
21:09imirkin: you can specify ports too, but by default it uses 6666 i think. so you can just do 'nc -l -u -p 6666' on the target computer
21:20chewitt: I added nomodeset to kernel params and that gets me to a booted system
21:20chewitt: is it possible to start things from there.. or that completely disables nouveau?
21:20chewitt: I can see the modules are all loaded
21:21imirkin: that completely disables nouveau, but you can unload and then reload nouveau
21:28chewitt: sh: /usr/lib/kodi/kodi.bin: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory
21:28chewitt: in the systemd journal.. I guess that's an important one :)
21:29chewitt: now to find where it should be located
21:29imirkin: don't bother, it won't work
21:30imirkin: xbmc probably wants GL_NV_vdpau
21:30imirkin: and vdpau won't work on your chip
21:30Karlton: I use kodi without vdpau
21:31Karlton: it uses mplayer
21:31chewitt: the OS here has been running without vdpau support for aeons .. via the nvidia blob driver
21:31imirkin: perhaps i'm misinformed
21:31chewitt: and if you go back to 2011/12 days.. the OS was using nouveau
21:31imirkin: or mixing up diff projects
21:32imirkin: either way, neither vdpau nor any sort of GL-ified media player is likely to work
21:32imirkin: mplayer should work just fine
21:32imirkin: and xvmc should work, should mpeg2 be of interest to you
21:34chewitt: libGL_mesa.so.1 is libGL.so .. right?
21:34chewitt: if so this is just setting the right symlinks in the mesa package
21:35imirkin: i suspect it's the osmesa version
21:35imirkin: which is not at all what you want
21:36imirkin: normally mesa just creates a libGL.so.1
21:36Karlton: it does
21:38chewitt: this is a quirk in our build system I think
21:38imirkin: ah perhaps
22:21chewitt: one pace forwards.. one backwards
22:21chewitt: files are named properly and in the right place now
22:22chewitt: Jul 15 05:16:22 box sh: ERROR: Unable to create GUI. Exiting
22:22chewitt: Jul 15 05:16:22 box kernel: kodi.bin: segfault at 38 ip 00000038 sp bfea14ec error 4 in kodi.bin[8048000+15a0000]
22:23chewitt: that's with nomodeset and a manual rmmod and modprobe after boot
22:23chewitt: if I remove the nomodeset.. the box locks when it tries to launch the xserver
22:24imirkin: anything odd in dmesg after the modprobe?
22:30chewitt: nothing obvious .. i'm looking at the systemd journal not dmesg though
22:34imirkin: chewitt: which gpu is this? NV46 by any chance?
22:35imirkin: if so, try setting GLXVBlank to 0 in your xorg.conf
22:35imirkin: chewitt: see https://bugs.freedesktop.org/show_bug.cgi?id=90435
22:37chewitt: it was already commented out
22:38chewitt: I believe this is nv46
22:47chewitt: nvidia G72M / GeForce Go 7300
22:58chewitt: kodi is crashing due to:
22:58chewitt: 05:57:30 T:3046049536 ERROR: GLX Error: No Display found
22:58chewitt: 05:57:30 T:3046049536 FATAL: CApplication::Create: Unable to init windowing system
22:58chewitt: fluxbox is the window manager
22:59chewitt: fluxbox says: fluxbox: Error: Couldn't connect to XServer:0
23:00chewitt: no Xorg log :(
23:00chewitt: which is probably due to .service config
23:00chewitt: or something there
23:00chewitt: sigh.. time for real work
23:18pq: chewitt, http://who-t.blogspot.fi/2014/03/viewing-xorglog-with-journalctl.html perhaps?
23:19chewitt: could be another package renaming files issue
23:20chewitt: libglx.so is not linked properly in the filesystem