01:23 night199uk: hey
01:24 night199uk: anyone comment on the diff between the ‘d’ BIT table and ‘U’ bit table?
01:25 night199uk: ‘d’ == displayport as far as i can see
01:25 night199uk: but ‘U’ seems very similar
01:25 night199uk: seems to be some kind of output config table?
01:50 pmoreau: skeggsb_: Do you think we should revert your patch or look for some already existing bug that was unearth by it? https://bugs.freedesktop.org/show_bug.cgi?id=87244
04:46 _root_: plz look at https://www.libreoffice.org/bugzilla/show_bug.cgi?id=84721 if you get a chance
04:51 joi: mupuf_: ^
05:27 RSpliet: night199uk: did you check out the kernels BIOS parsing routines?
05:28 RSpliet: I don't have the answer for you, but I assume it's in there
06:03 rah: would there have been any critical changes in the kernel config between 3.13 and latest git?
06:04 rah: I'm doing a git bisect and I'm wondering whether I can reuse the same config
07:58 mupuf_: _root_, joi: Hey, I'm going to have a look at those fan issues tonight
07:58 mupuf_: that's very weird
08:05 night199uk: RSpliet: yeah, I did
08:05 night199uk: RSpliet: I understand the code but not the general structure, if that makes sense
08:06 night199uk: In both DP & ‘U’ (display?) tables there seem to be ‘Output’ entries and ‘Config’ entries?
08:06 night199uk: something like that
08:06 RSpliet: night199uk: it's not the most straight-forward code in the world
08:06 night199uk: trying to understand the general structure a bit more
08:06 night199uk: heh
08:06 night199uk: it’s much cleaner than what i’m looking at :-)
08:16 RSpliet: U is the display table
08:16 RSpliet: http://lxr.free-electrons.com/source/drivers/gpu/drm/nouveau/core/subdev/bios/disp.c#L33
08:20 RSpliet: can't tell you the exact distinction, but I reckon dcb connector table has some entries that define the connector type, and if it's DP, you should consult the "d" table for additional parameters, and the U table is for... idk, VGA, perhaps DVI or LVDS?
08:20 RSpliet: something like that
08:21 RSpliet: night199uk: ^
09:03 _root_: plz look at https://www.libreoffice.org/bugzilla/show_bug.cgi?id=84721 if you get a chance
11:26 tobijk: is reclocking available for nvcX?
12:07 RSpliet: tobijk: no
12:07 RSpliet: (that's the short answer)
12:09 tobijk: ke thats enough :)
12:10 tobijk: RSpliet: maybe you can post a status update here: https://bugs.freedesktop.org/show_bug.cgi?id=58784
12:14 RSpliet: I've hardly worked on NVCx reclocking... there's little I can say that's not covered by the status matrix
12:14 RSpliet: memory reclocking needs work, if someone shoved me a couple grand I'd do it :p
12:15 tobijk: :D
12:16 RSpliet: unfortunately, the reality right now is that I'm forced to waste 40 hours a week on administrative work just to cover the rent and keep myself fed, despite having a masters degree in the pocket
12:16 RSpliet: and there's little time left to focus on anything else, let alone money to actually buy a Fermi
12:17 tobijk: sorry to hear that :/
12:17 tobijk: haven't you written the master thesis already?
12:17 RSpliet: all done
12:17 RSpliet: graduated a year and a half ago
12:18 RSpliet: hopefully starting a PhD next academic year
12:18 RSpliet: (which is why some find it difficult to hire me...)
12:18 tobijk: heh
12:19 RSpliet: I could be doing something more interesting than I do now... but I kept them on a string as I tried to find funding for nouveau
12:20 tobijk: so they wouldnt let you work on nouveau while working for them? :-(
12:20 tobijk: or seperate funding for nouveau?
12:21 RSpliet: not during office hours, and tbh, after 40 office hours a week I'm exhausted and hardly feel like working on nouveau
12:21 RSpliet: there's only so many energy and focus in me ;-)
12:21 tobijk: i hoped more for 2hrs in the 40hrs for nouveau :D
12:21 RSpliet: not in their interest
12:23 RSpliet: so there's a point where I need to make some hard choices... and my health, wealth and sanity then has to be prioritised over nouveau
12:23 RSpliet: sad reality
12:24 tobijk: that comes first, sure, after all we are a opensource project
12:25 tobijk: wasting peoples health on it is not the way i want this driver :)
12:25 tobijk: *driven
12:25 RSpliet: heh, no absolutely not, but it's a sad story because I have the experience that would take others months to gain... and I'd love to use it for the good
12:25 RSpliet: bloody capitalism...
12:26 tobijk: yeah, it has its major downfalls but its the only system humanity can work with, it seems...
12:27 RSpliet: none of the other systems has been given a fair chance
12:27 RSpliet: but even the capitalistic west is starting to look more and more like communism
12:28 RSpliet: (... or, that's an interesting theory I read recently, on how we seem to be inventing jobs just to keep everybody working; that has a very communistic mindset behind it)
12:29 tobijk: but they tend to kill people anyway
12:29 tobijk: communistic jobs were more like eh, part time i guess :)
12:30 RSpliet: well, I wasn't there
12:30 RSpliet: but half of the office jobs in government administration are redundant
12:30 tobijk: me neither, but thats waht i have read and heared
12:31 RSpliet: you can sack them... but that would increase the unemployment rate dramatically
12:31 tobijk: let alone burecracy ;-)
12:32 RSpliet: more and more people are actually working part-time...
12:32 RSpliet: anyway, totally different discussion :D
12:32 tobijk: yeah an the wrong channel :)
12:33 tobijk: other thing: is imirkin on vacation? :D
12:34 RSpliet: I have no idea
12:34 RSpliet: he does still send out e-mails
12:34 tobijk: yeah i observed that, but he is missing here...
12:35 RSpliet: might be busy
12:35 tobijk: i go with the first option (positive minded me)
12:38 tobijk: RSpliet: if you are bored, you can review my last iteration on the OP_CVT patch ;-)
12:38 RSpliet: I'm hardly bored
12:39 RSpliet: I could do that, but I also have some compiler patches of my own to polish up further
12:39 tobijk: guessed that, but trying is free :)
12:39 tobijk: oh interesting, more folding work?
12:40 RSpliet: plus there's an NVA0 in my cabinet
12:40 RSpliet: well, the "short form MAD" implementation + a post-RA folding pass for immediates
12:41 tobijk: looking forward to it, even if i am not able to review it/them :)
12:48 RSpliet: there's been several versions on the ML already
12:48 RSpliet: and it's not super-exciting until we can trick RA to prefer SDST == SSRC2
12:52 tobijk: dont ask me about the RA, i failed doing even easy things with it (one might think)
12:52 RSpliet: well, RA is the most complex step in compilers...
12:53 RSpliet: the problem itself is allegiadely NP complete
13:32 vnd: hi again
13:33 vnd: I have a question about the entry: “The fan is really LOUD all the time”. when did it apeared?
13:34 vnd: I mean the problem with the fan - the first reported bug or sth?
13:35 mupuf: vnd: I doubt this is a regression
13:35 vnd: hi mupuf
13:35 mupuf: it must boot with the fan to 100% and nouveau fails to slow it down :s
13:35 vnd: I have a similar problem with my fan
13:35 mupuf: great
13:35 mupuf: well, great for me :D
13:35 mupuf: not for you
13:36 mupuf: so, tell me more
13:36 mupuf: does the computer start with the fan to 100%?
13:36 vnd: and I’ve checked that it appeard between kernel 3.14.29 and 3.15.10
13:36 mupuf: so, that would be a regression!
13:36 vnd: mupuf: when the nouveau is compiled into the kernel - yes, but in general the fan gets mad when nouveau is loaded
13:37 mupuf: ok ok
13:37 vnd: but I’m not exactly sure if it’s exactly this problem that is mentioned in faq
13:37 mupuf: you know what, screw sleep
13:37 mupuf: let's unbox my REing machine
13:37 mupuf: I have no case for it, so it is not going to be pretty
13:37 vnd: in my case I can control the fan (I can for example turn it off) but the 1% is still 101% in normal case
13:38 vnd: I mean manging by pwm1 files
13:38 vnd: I’ll post you something
13:38 vnd: https://forums.gentoo.org/viewtopic-t-1009318.html
13:38 vnd: here’s exactly explained what happens to me
13:39 vnd: firstly I thought that it’s a problem with my .config
13:39 vnd: but latelly I’ve realized that the fan is working ok on previous kernels
13:39 vnd: and doing some kind of binary search I’ve found the range (3.14.29; 3.15.10]
13:40 mupuf: are you aware of the existance of git bisect?
13:40 mupuf: but let me check, the commit should be trivial to find
13:40 mupuf: not many commit on fan management
13:41 vnd: I’m not 100% sure that it’s nouveau problem (maybe some termal monitoring or other thinks) but the change in nouceau seems to be the simplest reason
13:42 vnd: things*
13:43 mupuf: look no further than nouveau
13:43 mupuf: and I'm probably the one to blame
13:43 mupuf: well, at least partially
13:43 vnd: hah ;)
13:44 mupuf: I may have accidentally regressed fermi/kepler fan management by adding fan management support for the maxwell
13:44 mupuf: but I guess this is more subtle
13:45 mupuf: give me some time, I literrally need to unbox my computers
13:45 vnd: mupuf: in my case it’s kelper I think - it is discovered by nouveau as NVc0
13:45 mupuf: and set them up in a cardboard box
13:45 mupuf: c0 == fermi
13:45 vnd: ok :) may be that way
13:47 vnd: sorry, I’m not an everyday kernel developer ;) just when I encounter some problems I trying to go as far as I could to diagnose it
13:51 mupuf: vnd: thanks for doing so
14:01 vnd: mupuf: maybe it would help you a bit, I’ve mentioned it on gentoo forums but I’ll point it once again in here:
14:02 vnd: the kernel 3.14.29 works normally - the fan speed is ok
14:03 vnd: but when I change the mode to manual (echo 1 > pwm1_enable) the fan speeds up to 100% as in branch 3.15.10 (where the fan works with that speed since the beggining when the nouveau is loaded)
14:03 vnd: after changing to manual mode there’s no other way than reboot to slow down the fan
14:04 vnd: switching back to auto mode doesn’t work
14:05 vnd: maybe there was some change that bease on this scenario? maybe you set internally the mode to manual and then back to automatic - just a guess
14:06 tobijk: i'd more guess that auto fan managment was not avail on 3.14.x, only manual managment...but mupuf will find out eventually :)
14:06 tobijk: vnd: anyway bisecting would really help him, as he mentioned
14:09 vnd: np guys, it would help me too when you found the solution :)
14:11 vnd: if you need some support with testing the patches or other things I open to help
14:15 vnd: / vnd+nouveau@vndh.net just in case
14:16 vnd: it’s a little bit late in here :) going to sleep in a hour
14:23 mupuf: it's alive!
14:23 mupuf: it's aaaaaliiiiivvvveeeee!!!
14:23 mupuf: so, it would seem like all my packages arrived in a perfect condition
14:23 mupuf: kuddos to the Finns for handling them nicely
14:23 hakzsam: reator is ready ? :)
14:23 mupuf: yeah
14:23 mupuf: it has no case
14:24 mupuf: but it is there
14:24 mupuf: no internet access yet though
14:24 hakzsam: excellent
14:24 mupuf: so no wtrpm
14:24 mupuf: I'll possibly get it this week or next week
14:24 mupuf: let's cross fingers!
14:24 hakzsam: okay :)
14:24 mupuf: anyway
14:24 mupuf: that was the good news
14:25 mupuf: the bad news is ... I cannot reproduce the problem with my nvcf
14:25 mupuf: I can try again with the nvc4 but this one, for some reason, seem incompatible with my machine...
14:25 mupuf: oh, but I also received the c8 and ce
14:25 mupuf: I'll try them first
14:25 mupuf: let's hope that I can reproduce the problem
14:26 mupuf: vnd: have you tried with a more-recent kernel?
14:26 tobijk: mupuf: can one run tests on the blob there (reator)?
14:26 mupuf: or are you stuck with the 3.15
14:26 vnd: mupuf: the latest one I’ve tried was 3.17.something
14:26 mupuf: tobijk: that would require wtrpm
14:26 vnd: the problem existed
14:26 mupuf: ok
14:26 tobijk: wtrpm?
14:26 mupuf: on 3.18, it runs
14:26 mupuf: tobijk: let me find you the article I wrote about it
14:27 mupuf: http://mupuf.org/blog/2013/05/11/wtrpm-a-web-based-wt-suite-to-power-up-slash-down-your-computers/
14:27 mupuf: it changed quite a lot since
14:27 tobijk: ah thanks a lot
14:27 mupuf: but the concept remains
14:27 mupuf: https://lh3.googleusercontent.com/-X4ERIO-UPuA/U9eMeNmMVJI/AAAAAAAAAS0/pRtYwG7-99Y/w1545-h870-no/14070021.jpg a more up to date hw
14:28 mupuf: althought this one is still a prototype
14:28 mupuf: anyway, if you want to request access to reator, that will be possible, indeed
14:28 mupuf: I'll have two reators soon
14:28 mupuf: as in, probably in march
14:28 mupuf: when I buy myself a new computer
14:28 hakzsam: mupuf, I'll try to get mine wtrpm card the next friday, btw
14:29 mupuf: you'll need to finish to assemble it ;)
14:29 mupuf: and solder
14:29 hakzsam: and buy a new computer very soon, too
14:29 mupuf: anyway, let's not waste some sleep time on chit chat
14:29 hakzsam: np
14:29 Wonka: mupuf: that a RasPi below the Wt-RPM board?
14:29 mupuf: yep
14:30 Wonka: mh... a bit much :)
14:30 Wonka: got something not done yet... attiny2313, vusb, 8 opto couplers...
14:31 Wonka: makes 4x RSTSW 4x PWRSW.
14:31 Wonka: add a USB hub and 4 USBTTYs...
14:31 Wonka: and hook that up to an OpenWrt router.
14:32 Wonka: but well, bed time for me now
14:33 mupuf: openwrt router?
14:33 mupuf: that would be overkill ;)
14:33 Wonka: openwrt.org
14:33 Wonka: but the raspi isn't?
14:33 mupuf: price-wise, nope :D
14:33 mupuf: at the time, it was the cheapest ethernet board you could get
14:33 Wonka: addition: I'm building that for use at a place where we already have the openwrt router
14:33 mupuf: and I seriously don't want to deal with openwrt
14:34 mupuf: arch is fine :D
14:34 mupuf: ah, right
14:34 mupuf: then it makes a lot of sense then!
14:39 tobijk: mupuf: if grub looks garbled with RS232, its grubs fault :D (i did experience that few times with a Galileo Board as well)
14:42 mupuf: I can't remember the issue
14:42 mupuf: anyway, the c8 works well too
14:42 mupuf: and the c0 does not use the same fan management technique
14:43 mupuf: wait, it is only related to the manual fan management?
14:43 mupuf: that would be weird
14:44 tobijk: mupuf which technique does c0 use? the weird non step non linear one?
14:45 vnd: mupuf: as far as I’ve checked - yes, after switich to manual the fan gets mad (on 3.14)
14:46 vnd: and on 3.15 the fan gets mad since the beginning
14:49 mupuf: tobijk: an i2c chip
14:49 mupuf: adt7473
14:49 mupuf: vnd: ok, I really cannot reproduce the bug on the 3.18
14:49 mupuf: I'll have to go to sleep
14:50 mupuf: I have to arrive early at work tomorrow
14:50 vnd: ok, np
14:50 vnd: I’ll try to figure out something on my own too :)
14:51 mupuf: vnd: nah, I'll have a closer look tomorrow
14:51 mupuf: you updated your bug report right?
14:51 mupuf: the only thing I would like you to try, is the 3.18
14:51 vnd: hm, I haven’t filled any
14:51 vnd: ok
14:51 vnd: I’ll try it
14:52 vnd: I gonna sleep too
14:52 tobijk: vnd: there was a bugentry for the same case
14:53 tobijk: dont know if it was with nvc0
14:53 tobijk: s/know/remember/
14:53 vnd: tobijk: ok :) I wasn’t aware of it
14:53 vnd: do you have some link?
14:54 tobijk: just digging into bugzilla, give me some minutes
14:54 vnd: ok
14:56 tobijk: vnd: likely the same cause: https://bugs.freedesktop.org/show_bug.cgi?id=84721
14:57 vnd: yup, and nvc0 too
14:57 vnd: seems like the same issue
14:57 vnd: and even gentoo matches :)
14:58 vnd: anyway it’s not gentoo related problem - newest fedora has the same problem
14:59 tobijk: nah its nouveau handling something wrong
14:59 vnd: ok, i’ll post some comment about there kenel versions affected etc.
15:03 mupuf: yes, there are multiple bug reports
15:03 mupuf: so, I really need to understand this problem
15:04 mupuf: bisecting would really help though
15:04 mupuf: since all my cards seem to work fine
15:04 tobijk: so better keep it seperate?
15:04 mupuf: I won't be able to have a look at it tomorrow
15:04 tobijk: its nv0/nvc1
15:04 mupuf: so that will be for tuesday or later
15:04 mupuf: tobijk: keep what separate? the bug reports?
15:04 mupuf: yes, please
15:04 tobijk: vnd: -^
15:04 mupuf: and I'll need the vbios + kernel logs
15:05 vnd: mupuf: but I haven’t filled any yet
15:05 vnd: anyway I think it’s exactly the same issue
15:05 tobijk: vnd: file a new one
15:05 vnd: just the gfx card model differs
15:05 mupuf: yeah, but I would rather have separate ones
15:05 mupuf: because your vbios will be different
15:06 vnd: ok, I can :) anyway, I just posted the comment to this previous one
15:06 mupuf: nouveau.freedesktop.org tells you how to report one
15:07 vnd: ok ok, give me 5 minutes
15:07 mupuf: oh, you have time ;)
15:07 mupuf: see you! I should already be asleep
15:07 mupuf: cheers
15:07 tobijk: bye!
15:07 vnd: bye mupuf
15:07 tobijk: to bed with you :P
15:08 vnd: tobijk: anyway, why this bug is marked as nvc1 if in dmesg there’s info that the card was detected as nvc0? :)
15:09 tobijk: it is an nvc1
15:09 tobijk: look closer
15:09 tobijk: the family is nvc0
15:09 vnd: ah, sorry
15:09 vnd: you’re right
15:09 tobijk: np :)
15:10 pmoreau: tobijk: imho we should close https://bugs.freedesktop.org/show_bug.cgi?id=47965 as invalid rather than fixed as we aren't sure if it works now.
15:10 tobijk: pmoreau: sure, i played a bit of roulette there anyway!
15:11 pmoreau: :D
15:11 vnd: I’ve mislooked in my case too - my card is also detected as nvc1
15:11 vnd: the same chipset
15:11 vnd: GF108
15:11 pmoreau: tobijk: At least you're working on cleaning the bugzilla :) , I can't say the same for me
15:12 tobijk: vnd: really?
15:13 vnd: tobijk: yup, here’s the dmesg I’ve posted on gentoo forums: http://pastebin.com/tGHKV8pc
15:13 vnd: Chipset: GF108 (NVC1)
15:13 tobijk: yep right
15:14 vnd: ok, I’ll create this bug report tomorrow if still needed - another monday tomorrow… gonna sleep
15:15 vnd: bye, ttyl!
15:15 tobijk: vnd: no as it is nvc1, use the other report
15:15 tobijk: bye!
16:28 _root_: take a look at https://www.libreoffice.org/bugzilla/show_bug.cgi?id=84721 seems I am not alone in this
16:28 _root_: It needs attention ;)
16:32 pmoreau: _root_: There are quite a few bugs that need attention unfortunately. :/
16:33 tobijk: _root_: that was vnd here in the channel
16:34 pmoreau: But you're right to ping about it ;)
16:34 tobijk: mupuf will have a look at it this week
16:34 tobijk: (he said)
16:41 pmoreau: Which misconfigured engine(s) could cause a nouveau_bo_vma_add to generate a BARCTL timeout and a FIFO interrupt? PFB I guess?
16:43 _root_: oh; I am a little bussy this week and I lost the focus to check in here time to time
16:43 _root_: sorry
16:43 _root_: but
16:43 _root_: this is really needed. i want to switch to hardened kernel and it is stoping me to do so
16:44 pmoreau: Apart from the noise, isn't your card working?
16:44 tobijk: _root_: there are other people suffering from major problems, like not working cards, which problems to deal with first?
16:45 _root_: anyhow; I thind i need to add sensors and dmesg with nouveau.debug enabled
16:45 _root_: tobijk: devs' call.
16:46 _root_: It always assumed it is my and only my problem.
16:46 tobijk: _root_: well the problem is there are not that many devs :/
16:46 _root_: now It seems a whole bunch of cards sufering from the same issue
16:47 _root_: where is martin
16:47 tobijk: i havent said nobody is going to fix it, it just may take some time
16:47 tobijk: he is asleep
16:47 tobijk: let him rest
16:47 _root_: I got that. and I do respect
16:47 _root_: ;)
16:47 tobijk: :)
16:47 _root_: I just said martin said he could help
16:48 _root_: It was my part in being late to produce the materials
16:48 tobijk: yeah his nick is mupuf and he said he'll look at it this week
16:48 tobijk: give him that time please
16:49 _root_: tobijk: of course of course I am not pushing really scouts honor
16:49 _root_: ;9~)
16:49 _root_: ;)
16:50 _root_: oh look at that I coined new emoji
16:50 tobijk: whats that for? serious face damage? :O
16:50 tobijk: ;-)
16:51 _root_: tobijk: I guess something between sleep deprived and smile.
16:52 tobijk: heh, take a nap as well :)