08:58jcapik: imirkin: Hello ... saw your message to skeggsb yesterday
08:58jcapik: imirkin: wanna know whether you're able to reproduce the 406040 issue
08:58jcapik: imirkin: I'm willing to troubleshoot that / debug with you if you want
08:59jcapik: imirkin: as it is well reproducible on my system
08:59imirkin_: jcapik: i've seen it on very rare occasions
08:59imirkin_: but it's usually non-fatal
08:59jcapik: imirkin_: it happens here often
08:59imirkin_: maybe like once ever few months
09:00imirkin_: i haven't had a nv50 plugged in in a while though
09:00jcapik: imirkin_: and usually crashes the whole X ... two times the whole kernel crashed
09:00jcapik: imirkin: I noticed wrong colors in case of openscad
09:01imirkin_: right... i spoke with skeggsb about it a bit, it sounds like it might actually not be the cause of the fail, but the result of i
09:01jcapik: imirkin_: some of the segments are rendered white
09:01imirkin_: wrong colors are totally unrelated... probably some sort of bug
09:01jcapik: imirkin_: looks like too much light
09:01jcapik: imirkin_: but it doesn't happen when I disable 3D
09:02jcapik: imirkin_: maybe something else triggers the bug
09:02imirkin_: probably either a bug or a missing feature in nv50
09:02jcapik: imirkin_: and makes the nvidia controller behave incorrectly
09:02imirkin_: any sort of consistent rendering issue is extremely unlikely to do that
09:02imirkin_: it's just wrong code being generated, or some GL thing not being respected
09:04jcapik: imirkin_: ok .... I'm not nvidia expert .... just thinking whether that could be a HW bug that is triggered by correct manipulations
09:05imirkin_: sure, conceivable
09:05imirkin_: i've never seen anything like that
09:05jcapik: imirkin_: and that doesn't happen eith the proprietary drivers just because they do the things a bit differently
09:06imirkin_: could just be that it's a hw bug that sometimes happens and the proprietary drivers know how to recover from
09:06imirkin_: you have a G96 right?
09:06jcapik: imirkin_: yup .... that's it
09:06jcapik: imirkin_: 0f:00.0 VGA compatible controller : NVIDIA Corporation G96GL [Quadro FX 380] [10de:0658] (rev a1)
09:06imirkin_: never saw it on my G96 fwiw
09:06imirkin_: or rather... very rarely
09:07jcapik: imirkin_: try openscad / blender
09:07imirkin_: haven't had it plugged in in a while now
09:07imirkin_: but it used to be my desktop card
09:41night199uk: anyone know anything much about the bit ‘B’ table?
09:41night199uk: i don’t see it in envytools or nouveau that i can see
09:41night199uk: wondering if anyone knew anything off-hand though
09:41night199uk: seems to be maybe information about the VBIOS
18:06imirkin: skeggsb_: probably want to cc 4195f40685 to stable... 3.19+ iirc?
22:37pmoreau: mwk: ping
23:30mwk: pmoreau: pong
23:31pmoreau: mwk: Did you had time to figure out which naming to use in the EVO doc for BLOCK_LINEAR, PITCH & co.?
23:33pmoreau: And/or look at the latest patches I added to the pull request?
23:34mwk: there's new stuff?
23:34mwk: let's see
23:37mwk: well, looking good
23:37mwk: as for naming
23:38mwk: I'm not entirely certain
23:38mwk: here's the thing: if we get doc flowing from nvidia, that's a good argument for just using block linear / pitch
23:38mwk: but that'd mean you have to fix all the *other* places in envytools
23:39pmoreau: And if it's like getting the signed firmware, we should stick with the old naming? :D
23:39RSpliet: mwk: did you already figure out how to sign firmware yourself? :-P
23:40mwk: RSpliet: only for G98, unfortunately.
23:40pmoreau: I'll try to fix the other places and make a separate pull request
23:46pmoreau: mwk: Btw, would you have any idea why calling nv50_display_flip_stop or nv50_display_flip_next (more precisely, after the corresponding evo_kick took place) would make the EVO / PDISP engine crash (aka. EVO put ptr becomes crap, and iirc the PDISPLAY.CHANNEL[X].STAT also becomes garbage)?
23:47mwk: hmm, not really
23:48pmoreau: No problem :)
23:51pmoreau: skeggsb_: Would you have any idea? -^