01:06 Jayhost: Anything interesting happening in Nouveau world?
07:23 gnurou: karolherbst: I am still having the same issue even with your LED fix
07:23 gnurou: actually the issue occurs during nouveau_led_init()
07:23 gnurou: see http://pastebin.com/wXGjDy9v
07:24 gnurou: led_resume() is called by led_classdev_register() and things go wrong there
07:24 gnurou: I would expect that led_classdev_register() would not be called at all, since this card does not have a LED
07:27 karolherbst: gnurou: check your vbios with nvbios
07:28 karolherbst: this is the divide by 0 error I told mupuf abuot
07:28 gnurou:did not even notice it was a divide issue
07:28 karolherbst: gnurou: this needs to be guarded against 0 : https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nouveau_led.c#L47
07:28 gnurou: whenever I see a trace I assume NULL pointer dereference :)
07:28 mupuf: I have all the fixes, I will send them today or tomorrow
07:28 karolherbst: :D
07:29 karolherbst: mupuf: k, awesome
07:29 mupuf: karolherbst: I kept yours
07:29 mupuf: so it will just be two more fixes
07:29 gnurou: ah, perfect then
07:29 karolherbst: gnurou: I assume your vbios exposes a GPIO for the LED
07:29 karolherbst: mupuf: two more? I thought it is just the divide by 0 and null pointer access
07:29 mupuf: gnurou: I can send you the patches right now to see if they help
07:29 gnurou: mupuf: do you also check that gpio != NULL in nouveau_led_init()? (crashes on Tegra otherwise)
07:29 mupuf: karolherbst: the gpio one too
07:29 mupuf: gnurou: yes
07:29 karolherbst: ahh, k
07:30 gnurou: mupuf: just tell me where your patches are, I will grab them myself
07:32 karolherbst: gnurou: well, output of nvbios of your vbios would be still interesting ;)
07:33 gnurou: karolherbst: will gladly provide it, just need some guidance on how to do it :P
07:33 Hoolootwo: I have a bunch more info on the bug I was seeing. it's not causing a kernel panic, the computer is still up
07:33 Hoolootwo: posting dmesg in a bit
07:33 karolherbst: gnurou: cat /sys/debug/dri/0/vbios.rom > /tmp/vbios.rom ; nvbios /tmp/vbios.rom > output
07:34 karolherbst: uhh or was it /sys/kernel/debug?
07:34 karolherbst: ...
07:35 gnurou: I just symlink /sys/kernel/debug to /d, makes things simpler ;)
07:35 mupuf: gnurou: sent on the ML
07:35 mupuf: I do not guarantee their logic since I wrote them at 2am
07:36 mupuf: and there may be more fixes needed]
07:36 Hoolootwo: https://bpaste.net/show/73f98de2eaa1
07:37 mupuf: brb
07:37 karolherbst: I should auto signoff my commits by git by default :/ always forget this
07:37 mupuf: karolherbst: hehe, yes
07:38 mupuf: I will audit the code again tonight and see if there is anything left to guard against
07:38 gnurou: mupuf: thanks! checking them while I extract the vbios...
07:39 karolherbst: mhh that div thing, perfect place for that silly ?: operator :D
07:39 karolherbst: ohh wait
07:39 karolherbst: meh won't work
07:43 karolherbst: still left a comment about a potential performance optimization! Cause that call is so critical :p
07:44 karolherbst: the other part is more serious though
07:44 karolherbst: well meant seriously
07:46 karolherbst: gnurou: in nvbios you should see a GPIO section somewhere
07:46 karolherbst: I am sure there is some LED stuff going on
07:50 Hoolootwo: is there any debugging I can do to get those errors go away? I'd rather not do a bisect on the kernel but I guess I can if I have to
07:50 karolherbst: Hoolootwo: well errors are reported to get those fixed
07:51 karolherbst: but if it's a regression, git bisect will show you the cause for sure
07:51 Hoolootwo: it's definitely a regression, this is on kernel 4.6, and 4.2 works fine
07:54 Hoolootwo: I would definitely test it on other versions but I'm IRCing from the affected machine currently
07:58 karolherbst: mhh k, you could at least test different kernel releases
07:58 karolherbst: maybe somebody has an idea if you can say which kernel version introduced the issue
08:04 Hoolootwo: yeah, I'll do that in a bit when I get IRC configs copied over and stuff
08:07 Hoolootwo: 4.5 appears to be the same as 4.6
08:09 Hoolootwo: hmm after a while garbage showed up on the screen, but dmesg is essentially the same
08:12 Hoolootwo: I don't have 4.4 in any of my repos right now... I guess I'll test 4.7
08:13 Hoolootwo: ooookay that worked at least a little bit, I have a DM
08:15 Hoolootwo: oops, sorry about the false alarm, appears as if it got fixed
08:17 gnurou: karolherbst: my GM206's vbios: https://drive.google.com/file/d/0B4Wi9SO0F_89MTJ5d3FYVm5FalU/view?usp=sharing
08:17 gnurou: karolherbst: I will let you run nvbios on it, as I saw some errors/warnings when I did
08:19 karolherbst: gnurou: k
08:20 Hoolootwo: okay so some things are still broken in 4.7, such as brightness control causes mate-power manager to segfault, not sure whose fault that is
08:24 karolherbst: mupuf: GPIO 11: line 11 tag 0x84 [LOGO_LED_PWM] OUT DEF 0 param 1 gpio: normal SPEC_OUT 0x84 [SOR1_PANEL_BACKLIGHT_LEVEL]
08:24 karolherbst: is there anything you didn't expect?
08:24 Hoolootwo: http://i.imgur.com/Vjyylzi.png happens when I click-drag on desktop, along with other minor glitches
08:28 karolherbst: gnurou: what errors did you mean?
08:28 mupuf: karolherbst: :)
08:29 karolherbst: man… those crazy CSTEP tables
08:30 karolherbst: https://gist.github.com/karolherbst/780377e5cec016bbdaec8d5176f3c790
08:30 karolherbst: no idea what that's all about
08:30 karolherbst: not that nouveau would care about the entries after 74
08:30 karolherbst: but still
08:32 karolherbst: crazy thing is, the referenced voltage map entries even make sense
08:35 karolherbst: and that is that! -- ID = 9, mode: 3, link: -1, voltage_min = 600000, voltage_max = 1600000, volt = 1100000 [µV]
08:35 karolherbst: good to have confirmation about that somewhat
08:36 karolherbst: I knew it was "(info.min + info.max) / 2;" but didn't got any serious confirmation for this
08:55 karolherbst: gnurou: if you got time, I am sure you can add an LED to your gpu :p
08:56 gnurou: karolherbst: just what we need to make people switch to Nouveau! :D
08:58 karolherbst: sure
08:58 karolherbst: especially those windows gamers, they won't switch without proper LED support anyway!
09:52 Dezponia: karolherbst: But but... mah RGB!
10:58 karolherbst: gnurou: 32bit should just die! :D
11:12 karolherbst: thanks for finding it though
11:12 karolherbst: we seriously need some kind of CI to catch those things much earlier before those slip through into releases
11:14 mupuf: karolherbst: agreed
11:14 mupuf: this can be caught with travisCI AFAIK
11:18 karolherbst: yeah
11:18 karolherbst: I started to do stuff there, but there was something I couldn't do
11:18 karolherbst: ohh right
11:18 karolherbst: no sudo rights or something
11:18 karolherbst: or something else
11:19 karolherbst: the pain with travis is though, that you need a .travis.yml file within your repository :/
11:21 karolherbst: mupuf: we would also need to parse the git log to find the last drm commit the tree is based on and build the kernel drm tree from that :/ it is a bit messy if you want to fetch all possibilites
11:21 karolherbst: and if you want something that works reliable
11:46 mupuf: yeah, right
14:01 gnurou: mupuf: I caught this on Jetson TK1 FWIW ;)
14:01 mupuf: gnurou: caught what?
14:02 mupuf: the led crash?
14:02 gnurou: mupuf: the 32-bit issue
14:02 mupuf: oh, is it 32 bits?
14:02 gnurou: yep
14:02 mupuf: well, then I guess I could be testing linus' tree automatically every month
14:03 gnurou: it's often already too late once it's in Linus tree
14:05 karolherbst: I guess I will set something up for that
14:06 karolherbst: maybe I configure my repository in a way, that if you do PRs against it, it will be automatically built checked or so
14:06 mupuf: gnurou: not as late as seeing the bug in a released kernel ;)
14:06 karolherbst: if it's in linus tree, we will get a email 10 minutes later anyway :D
14:07 mupuf: but there is no point in testing drm-next since ben always is the last to submit his changes
14:07 mupuf: karolherbst: hehe, quite probable, yes
14:07 karolherbst: mupuf: right, that's why: extract drm-next version from git log, clone drm-next from that, link nouveau into that repository -> build
14:08 mupuf: yep... all the fun...
14:08 karolherbst: maybe there is a CI system which can even read PRs from MLs
14:08 karolherbst: and reply on commits which break stuff :D
14:08 mupuf: hehe, yes
14:08 mupuf: there is, with patchwork
14:08 karolherbst: ahh I see
14:08 karolherbst: do we want to use patchwork?
14:09 mupuf: well, there is no other way :D
14:09 karolherbst: :D
14:09 karolherbst: it is no fun if somebody doesn't play be the rules though
14:11 mupuf: ?
14:11 karolherbst: well usually we don't see bens patches before he pushes his stuff ;)
14:12 mupuf: yep :D
14:13 mupuf: well, I am sure we could persuade him to send them for testing before they are ready to be merhed
14:13 karolherbst: yeah, maybe
14:15 mupuf: mwk has quite a lot of machines that we may be able to access
14:15 mupuf: that should help
14:31 pmoreau: Something worth discussing during next week :-)
14:33 karolherbst: yep
18:54 Hoolootwo: with 4.4 I got my DM background but same dmesg and all, that's broken, will start bisection from there
19:07 gwfwe: hello
19:07 gwfwe: i like the irc room of nouveau. its not possible to post into #radeon - also not when registered to freenode when using just the normal webchat
19:08 gwfwe: am i here right for VDPAU bugs?
19:08 imirkin: perhaps
19:08 gwfwe: original autor of vdpau is nvidia and now kind of freedesktop
19:08 gwfwe: my machine seems to crash because of vdpau error
19:08 karolherbst: it actually depends on what driver you use
19:09 gwfwe: karolherbst: radeon r600
19:09 karolherbst: go to #radeon then
19:09 imirkin: then you want #radeon
19:09 gwfwe: dmesg tells: [ 9324.269781] traps: Vdpau Mixer[1083] general protection ip:7fc6d73821f2 sp:7fc72a8dcd30 error:0 in libvdpau_r600.so.1.0.0[7fc6d7203000+baa000]
19:09 gwfwe: other software reports: ERROR: (VDPAU) Error: An invalid/unsupported value was supplied. This is a catch-all error code for values of type other than those with a specific error code.(21) at VDPAU.cpp:1724
19:09 karolherbst: we can't help you, honestly
19:10 gwfwe: i cant write to #radeon because of those tons of blockings of users :/
19:10 karolherbst: you may want to register your nick before and authenticate
19:11 karolherbst: then you might be able to join
19:12 gwfwe: karolherbst: also didnt work. Just register your nick, visit https://webchat.freenode.net/ , login with the irc password, join #radeon -> still not working. You still get the error that you cant write
19:13 gwfwe: karolherbst: you can try that when you didnt beleive
19:13 gwfwe: karolherbst: btw thanks for your great reclocking work and the new boost-state changes :)
19:17 karolherbst: gwfwe: works for me
19:17 gwfwe: karolherbst: when using https://webchat.freenode.net ?
19:17 karolherbst: gwfwe: "[21:17] [Whois] karolherbst1 is a user on channels: #nouveau #radeon [21:17] [Whois] karolherbst1 is online via herbert.freenode.net (Webchat)."
19:17 karolherbst: yes
19:17 gwfwe: you have not wrote to the channel
19:17 gwfwe: try to write to the channel
19:17 karolherbst: ohh I see
19:18 karolherbst: I think webchat might be blocked
19:18 gwfwe: you would see that you get the error
20:02 karolherbst: okay, I think this will be easy with the CI
20:02 karolherbst: mupuf: I will do a test today and I am sure it will work out :) getting the right commit is fairly easy as long the name stays the same
20:13 karolherbst: git can't clone by commit hash :/
20:13 karolherbst: sad
20:21 imirkin: hakzsam: what's the status of your variable local size series?
20:31 pmoreau: karolherbst: Really? You can clone by branch and tag, would be weird not to have commit hash as well…
20:31 karolherbst: pmoreau: try it
20:32 ajax: it would probably be very easy to fix that, then
20:33 karolherbst: guess I will try to get the cache working on travis
20:38 pmoreau: Indeed, commit hash does not seem to be supported… Oo
20:45 karolherbst: yeah
20:48 karolherbst: pmoreau: do you know any other way ?
20:48 karolherbst: I really don't want to clone an entire git tree on travis-ci :D
21:00 karolherbst: :D
21:00 karolherbst: 1.2GB file cachine on travis, sure, why not
21:00 karolherbst: *caching
21:04 pmoreau: No idea…
21:06 karolherbst: https://github.com/git/git/commit/68ee628932c2196742b77d2961c5e16360734a62
21:06 karolherbst: ............