04:13Scall: Hello everyone, do you remember my freezes with my "C73 [GeForce 7100 / nForce 630i]" on Gentoo? If it isn't so you can search for my nick in the backlog - 2014-11-26 -, that was the first time I wrote in this channel, this is the second one. Anyway, since I always have the same problem, I tried to do a "cat /dev/kmsg" again, with the following software:
04:13Scall: * Linux Kernel 3.18 (I'm using the hardened one of Gentoo, but as you probably recall from the last time I wrote, using the vanilla one caused exactly the same problem with the same messages from kmsg, so this shouldn't be a issue)
04:13Scall: * libdrm 2.4.58
04:13Scall: * Mesa 10.4.3
04:13Scall: I have got two logs, I hope this time you can find something useful in one of them.
04:13Scall:  with debug level 6: https://www.dropbox.com/s/rfbu2on1estrba5/kmsg-debug_level_6?dl=0
04:14Scall:  with debug level 7: https://www.dropbox.com/s/u8n82szcny5vxx9/kmsg-debug_level_7?dl=0
04:14Scall: Note: in both the logs my system froze when trying to resize the "glxgears" window, but it freezes resizing any other window when the program running in that window use the hardware acceleration like glxgears does.
05:54pmoreau: Scall: Both files' end seems to be corrupted. If you have another machine, use netconsole to get the logs (level 6 is good, even 5 could be enough).
09:14imirkin: Scall: one thing we've done is just turned MSI off on all IGP chipsets. not sure if you have the relevant patch though, it's fairly recent... you can boot with nouveau.config=NvMSI=0 to disable it
09:20mlankhorst: mm interesting pull request :P
09:22imirkin: a little behind the times, are we?
09:24imirkin: or is there some new one that i haven't seen yet?
09:24mlankhorst: naw, just the gk20a one
09:24mlankhorst: I've been busy :-)
09:50tizbac: imirkin, if it can be useful for nouveau developement, there's corruption happening with 0a performance level on kepler too
09:51imirkin: tizbac: probably just bad params somewhere which make it _really_ explode at the highest speeds
09:51tizbac: reclocking more times between 07 and 0a and retrying some times can give good results
10:00mlankhorst: active video engines while reclocking will definitely crash too...
10:03tizbac: mlankhorst, here does not seem to be the case, it's memory starting to have random errors after reclock
10:10mlankhorst: ah :P
10:10mlankhorst: fermi has no memory reclocking
10:10mlankhorst: well I can reclock my card by uploading a script for memory reclocking, but nothing official..
10:13imirkin: mlankhorst: and i assume no time to "productionize" something?
10:15tizbac: why the memory training in the fuc file for cards other than gt215 is a noop?
10:16imirkin: tizbac: because the memory training is not done in fuc on kepler
10:16tizbac: it's done by the controller itself?
10:17imirkin: it's done by the cpu
10:17imirkin: [i think. i'm a bit out of my depth here. but skeggsb is asleep.]
10:17mlankhorst: imirkin: I've tried to understand it and look at other cards.. if it was easy it would have been done..
10:18imirkin: mlankhorst: i wasn't suggesting it was easy... i "supervised" rspliet's evoc for doing it on nva3, i know just how much of a pain it is...
10:18mlankhorst: it will depend on the memory configuration, memort type, even different cards use different registers
10:19imirkin: fun, isn't it? :)
10:20imirkin: and all driven off random vbios bits, for your convenience
10:22tizbac: imirkin, for the nvidia blob too it's done without using fuc?
10:23imirkin: tizbac: not sure. i believe that on gt21x it was done in the fuc.
10:37RSpliet: imirkin: did I complain *that* much? :p
10:37imirkin: RSpliet: well, i saw the issues you were running into
10:39mlankhorst: imirkin: oh and top of that kepler changes it all around again and then maxwell probably too :P
10:39RSpliet: yes... it's unfortunate I couldn't solve that with my "Max Power" attitude
10:39imirkin: mlankhorst: well on the bright side, skeggsb has done a lot of the kepler work already. so it's just fermi...
10:40imirkin: RSpliet: blah, you know nothing of the Max Power attitude. you seem like you're pretty careful by nature. very un-Max Power
10:40RSpliet: not when it comes to RE'ing GPUs
10:41imirkin: you were always talking about doing things the right way
10:41imirkin: rather than the wrong way, but faster!
10:42mlankhorst: memory reclocking, doing the wrong way faster :P
16:19Manoa: hi, I have a problem, my Linux box has nouveau kernel and it's statically in the kernel, my monitor is connected to a GT210 video card from which there is a cable going from DVI at the card to a HDMI at the monitor, the problem is that at boot not long after nouveau recognizes the card the screen goes blank
16:19Manoa: I looked in the kernel logs to find what hapen but there is nothing there as if the kernel never really booted
16:20Manoa: the kernel version is 3.19-rc7
16:21Manoa: monitor is Eizo Foris FG2421
16:21skeggsb: Manoa: i'd rebuild as a module, boot with "nomodeset", and manually load the module after the system has fully booted. more change you'll get something in logs
16:21skeggsb: and/or you can ssh into it and see what's happened
16:21Manoa: ok I will do that
17:41koz_: imirkin: Could my reclocking issues on my card (core speed not changing, memory speed is) be to do with my power supply?
17:43imirkin: koz_: no
17:43koz_: imirkin: Good to know.
19:49_root_: hello @/
19:50_root_: do we have this https://bugs.freedesktop.org/show_bug.cgi?id=84721 error on Linux kernel 3.18.3 ???
19:52imirkin: afaik there's no fix
19:53_root_: imirkin: no fix yet. or never going to be fixed?
19:53_root_: may be bad idea to ask this here. but is there a livecd out there with Nvidia binary driver on it by default?
19:55imirkin: not sure. mupuf said he'd look at it, but i don't think he's had time to yet
22:19mupuf: imirkin: yeah, wanted to have a look at it during the week end, but Linux 3.19 is about to be released so it means I am busy writing the article about it on linuxfr
22:19mupuf: I really need to take the time to reproduce the bug though
22:20mupuf: now that the guilty commit has been found
22:33zRecursive: Can i use nouveau driver on OpenBSD ?
22:34imirkin: the license is compatible. however afaik no integration has been done.
22:35zRecursive: Unfortuately !
22:36imirkin: that said, i bet it wouldn't take exhorbitantly long for a motivated and knowledgeable individual
22:36imirkin: could probably get it up and running in under a month assuming familiarity with openbsd internals (and assuming openbsd already supports some other 3d-accel cards)
22:39zRecursive: Now OpenBSD is using an old `nv` driver for nvidia cards
22:39imirkin: yeah, that's 2d only, just a ddx
22:39imirkin: no kms, no accel (afaik)
22:39imirkin: maybe it does have some accel, not sure.
22:39zRecursive: but `nv` doesnot work well.
22:40imirkin: and it doesn't support fermi or newer chips
22:40zRecursive: It even always shit my screen to right 1cm (1440x900)
22:41imirkin: is it hooked up via VGA?
22:41imirkin: or is it LVDS?
22:41zRecursive: i am not sure. I am using the xorg.conf created by `Xorg -confiure` directly
22:42imirkin: i mean... what kind of screen is the 1440x900 display?
22:43zRecursive: NVIDIA GeForce 7300 LE
22:43zRecursive: HP w1907
22:43imirkin: VGA or DVI?
22:44zRecursive: How do i know it ?
22:44imirkin: you hooked up the cable, no?
22:45zRecursive: It is connected to PC directly
22:46zRecursive: i guess it is VGA