03:53pmoreau: ... netconsole doesn't want to help me...
03:53pmoreau: For some reason it prefers to stop sending messages before the interesting part.
04:39pmoreau: Adding all PFB writes from the blob didn't have the slightest effect. :(
04:40RSpliet: they probably had, just unmeasurable
04:40pmoreau: You're right; I should have precised "on the issue".
04:41RSpliet: oh right, you're looking at the bug in evo_wait()
04:41pmoreau: Yep, still that one ;)
04:42pmoreau: It's probably the last major issue on my laptop (hopefully)
04:42RSpliet: I'd say stop caring what the blob does, try to figure out who (and which part of the code) is responsible for setting the put and get counters of the fifo and fix that :p
04:43pmoreau: I'm not sure what you mean by that. The part setting and retrieving the put/get pointers seems correct.
04:44RSpliet: I thought the put counter was set to 3fffffff
04:44RSpliet: which sounds wrong
04:45pmoreau: It's just that at some point the PDISP channel will go berserk (with PDISPLAY.CHANNEL.STAT = 0xffffffff) and the put ptr becomes garbage
04:45pmoreau: Or at least this is my interpretation
04:45pmoreau: And if I do a pci reset of the card before loading Nouveau, everything is fine
05:00RSpliet: well, that's too easy for me :p
05:00RSpliet: although stat == 0xffffffff sounds like trouble
05:01RSpliet: what happens exactly with a PCI reset?
05:01RSpliet: some initialisation on the graphics card side?
05:01mlankhorst: pmoreau: is it just the STAT being 0xffffffff or the whole display block?
05:02pmoreau: mlankhorst: Ah, didn't checked the whole block. Could try that
05:02pmoreau: RSpliet: Part of the regs are reset to some value it seems
05:03pmoreau: I dumped the regs for PGRAPH, PFIFO, PDISP, PFB before and after the reset, but nothing interesting came out of the diff
05:04pmoreau: But first, need to eat something else than my laptop or some mmiotraces! :D
05:33RSpliet: what about PCLOCK? if the display clock is wrong it could go tits up as well...
05:34RSpliet: just some ideas
05:41pmoreau: They are always welcome! ;)
05:42pmoreau: I'll check PDISP block first, then PCLOCK and PCONTROL
05:48pmoreau: I forgot I'll first have to find how to get an object I can use nv_rd32 on...
06:34pmoreau: RSpliet: PCLOCK and PCONTROL are the same before and after the reset
08:13imirkin: skeggsb: the ddx has a lot of push_space checking... sometimes. other times, it doesn't check. thoughts?
08:15mlankhorst: imirkin: where doesn't it?
08:16imirkin: mlankhorst: hm, those might just be internal functions...
08:16imirkin: although why does it matter if it runs out of space? i thought that was all handled...
08:17imirkin: and wtf is PUSH_RESET... hm
08:17imirkin: nouveau_bufctx_reset(BUFCTX(push), 0);
08:19mlankhorst: mostly in case bo's are added to the list, i would imagine
08:24pmoreau: Grrr, my custom implementation of nv_rd32 didn't help
09:14pmoreau: mlankhorst: I won't be able to check: my laptop doesn't want to cooperate. :/
09:56pmoreau: Would it make sense to take a look at PNVIO too?
10:45mlankhorst: bleh I'm getting tons of error when starting lightdm :(
10:46imirkin: speaking of lightdm... is there any way to get it to start ssh-agent?
10:46mlankhorst: stuff it in /etc/X11/Xsession?
10:48imirkin: gdm used to just do it, but i can't use gdm anymore
11:04mlankhorst: I wonder what I did to upset Xorg :/
11:04mlankhorst: hm, maybe missing some coherent thing?
11:37pmoreau: It's not PNVIO. Let's continue copy/pasting PDISP writes
12:31mlankhorst: gnurou: will there be any performance issues with making scanout uncached?
14:10mlankhorst: ah nm, if I just nuke a memset coherency is unneeded
14:42mlankhorst: I need to fix up LeaveVT still so mode gets restored on normal X.org exit :P
14:44imirkin: is it working well yet?
14:47mlankhorst: depends on what you mean by working well
14:47mlankhorst: it mostly runs
14:48mlankhorst: it seems to hang if trying to run it a second time, but other than that
15:12joroot: my screen is going to black every 10 second and back to normal
15:13imirkin: joroot: what GPU, and how is the screen connected?
15:13imirkin: joroot: (my bet is VGA, and you're using some DE which polls the connector every 10s)
15:14joroot: i got a adaptor
15:15joroot: msi > vga
15:15imirkin: msi is not a connector type
15:15joroot: im on debian
15:15joroot: how do i remove all installed drivers?
15:15imirkin: ... not what i asked
15:16imirkin: roxlu: it's basically the same people in all these chans... you're not magically going to get different answers to your questions :)
15:16roxlu: imirkin why not?
15:18roxlu: I'm looking into ways to capture the framebuffer of displays (preferably on GPU) and wondering if someone knows what APIs I need to look into on Linux?
15:18imirkin: roxlu: ... because it's the same people. if you want to reach maximum exposure, try #dri-devel. but your question is too vague.
15:19roxlu: imirkin ok thanks. Though because I don't know what to ask for on Linux specifically I need to start somewhere :)
15:20joroot: imirkin its connected to a led screen with a adaptor and a vga cabel
15:23imirkin: roxlu: start with what you're trying to do. accessing the framebuffer is hardly something anyone wants. you have an end-goal in mind, start with that.
15:23roxlu: imirkin if that would be true, why are there apis for this on the other main platforms. It -is- something someone will want
15:24roxlu: imirkin look at me :)
15:24imirkin: roxlu: no. no one ever walks into a store thinking "i would like to capture a framebuffer"
15:24imirkin: roxlu: it's a means, not an end. talk about the end. then you can get help on the means
15:25roxlu: hmm I want to get access to the pixel of my a display <--- is that more clear to you?
15:29imirkin: roxlu: not particularly. i don't think you understand my point. but that's ok, don't worry about it.
15:29roxlu: ok :)
15:31nonroot: im going crazy
15:32nonroot: my screen is blinking every 10 second with black
15:32nonroot: some kind of error going on in the machine?
15:33imirkin: nonroot: perhaps answer my question? what GPU, and how is the screen connected?
15:33nonroot: how do i find out?
15:34nonroot: 2 sec
15:34imirkin: nonroot: lspci -d 10de: -nn
15:35nonroot: pm 2sec
15:37imirkin: ugh, i need to figure out how to tell lspci to look at the device class :) always forget about those boards...
15:38imirkin: you have an nforce motherboard. not that there's anything wrong with that
15:38imirkin: but it generates a much longer lspci -d 10de: list :)
15:38imirkin: anyways... you have a GK104
15:38imirkin: and you mentioned that the screen is hooked up via VGA?
15:38nonroot: GTX 760
15:39imirkin: nonroot: the most likely situation is that *something* in your DE is polling the connector status every 10 seconds
15:40imirkin: which in turn causes the VGA screen to flicker
15:40imirkin: however there's an alternate possibility, that it has something to do with a bad EDID readout
15:40imirkin: nonroot: can you pastebin your dmesg?
15:40nonroot: ofcause, whats the command
15:41imirkin: run that, pastebin the output
15:41nonroot: you don't wanna see that
15:41nonroot: its 1000+ lines long
15:41nonroot: anyway give me 2 sec
15:42imirkin: 1000 lines long is what i was expecting
15:43imirkin: you've got EDID problems
15:43nonroot: sounds bad
15:43imirkin: it hates the EDID that your monitor sends
15:43imirkin: and then tells it to send it again
15:43imirkin: every 10s presumably
15:43imirkin: which in turn causes the flicker
15:44imirkin: what resolution is your monitor?
15:45nonroot: now i should say thta..
15:45nonroot: i tried to install a driver, and when i rebooted it was blackscreen with a blinking "_"
15:46nonroot: so i disconnected the device and used the mother board vga port instead to remove the driver
15:46nonroot: and now im stuck with a flicker screen
15:46imirkin: you can boot with drm_kms_helper.edid_firmware=edid/1024x768.bin
15:46imirkin: which should force the edid to be the 1024x768 one
15:47nonroot: isn'ẗ it easier to just reinstall the whole system
15:47imirkin: not sure how that would help
15:47imirkin: you have a hardware issue... one of the adapters you're using is probably bad... not sure
15:48imirkin: or the monitor really has a bad EDID
15:48nonroot: what is a EDID?
15:48imirkin: stands for something clever... basically a block of data that describes the monitor
15:48imirkin: which the monitor supplies to the video card over DDC
15:51nonroot: imirkin im gonna use another os on another hdd to test the problem
15:51nonroot: be back in 5
15:57NonRoot: its a software problem
15:58NonRoot: im gonna reinstall debian on the new installed hdd
15:58NonRoot: thanks for you time m8
22:36nonroot: hi imirkin
22:42nonroot: was it dmsg that displayed the graphic card interface?