02:02 karolherbst: mupuf: I think I have to rethink the iccsense design, because configuring the sensors in init is a bit troublesome for various reasons (if we want to do it perfectly that is)
02:03 mupuf: karolherbst: can you list some of the reasons?
02:03 karolherbst: 1. the ina3221 has 3 config bits for each rail => we have to proble for existing rails before we can configure the sensors fully (or we enable all channels => not perfect)
02:04 karolherbst: 2. rails might point to the same sensors (ina3221) which means have to keep a list of all sensors (no interface currently provides us with the ability to do so)
02:04 karolherbst: the second point is more an issue if we don't want to reconfigure the same sensor more than once
02:05 karolherbst: so what we need in the end is as list of all sensors we have (maybe even all configurable extdevs?) and we need a way to register subdevices or users of that device
02:06 karolherbst: if we want to deal with that in a perfect way that is
02:08 karolherbst: mupuf: maybe we should have a list of all sensors in iccsense too and just reference from the rails to the sensors
02:09 karolherbst: keep the current iccsense interface, but idx 4 would point to sensors[1].rail[3] if sensor[0] has only one rail
02:09 karolherbst: or we simply forget about the rails in the iccsense interface and just read out all rails at once
02:10 karolherbst: for one sensor
02:11 karolherbst: if there is no use in reading out the rails seperatly, I would go for the last idea
02:14 karolherbst: mupuf: as a side note, each rail points to a budget + the is a pointer to one budget in the budget table header
02:14 karolherbst: https://github.com/karolherbst/envytools/commit/709fa85f2c8e036269f81e702248e248cfaa5e3d
02:16 karolherbst: but there is a third reference somewhere and never figured out where it is, and the power_budget unk12 field is a messup too :/
03:14 mupuf: 1. is meh, configure them all the same
03:16 karolherbst: mupuf: there is only one config for the sensor, not the rails, but each channel has a bit in the config to be disabled/enabled
03:17 karolherbst: so yeah, we could just enable them all
03:17 karolherbst: I could try to find out if there is any downside to this
03:27 karolherbst: mupuf: by any chance you have no idea what else could reference to a power_budeget besides a rail and the power_budget header?
03:29 karolherbst: *any
04:01 RSpliet: gnurou: thanks!
04:03 karolherbst: oho, he answered :)
04:04 karolherbst: RSpliet: do you know what is bothering me most currently? your gpu has high clocks, but a rather low voltage compared to other gpus
04:04 karolherbst: usually most keplers are at 1.2V already with clocks above 2GHz
04:05 karolherbst: and it would also make sense somewhat to raise the voltage even more
04:05 RSpliet: karolherbst: okay... did you peek in my trace what GPIO values are set by the blob?
04:05 karolherbst: RSpliet: we checked with my volt compare tool already
04:05 karolherbst: but we could try to set the same gpio value
04:05 karolherbst: there could be someting odd with it indeed
04:06 karolherbst: but
04:06 RSpliet: fetching the GPIO values from trace is just a double-check :-)
04:06 karolherbst: I never really figured out how to use those GPIOs
04:06 RSpliet: well quite simple, every line has it's own reg on kepler, VBIOS tells you which line corresponds with which VID bit
04:07 karolherbst: the max voltage of your gpu seems to be 1.1625V by the way
04:07 RSpliet: which is also quite low, isn't it?
04:07 karolherbst: a bit
04:07 karolherbst: usually 1.2V is the maximum
04:07 karolherbst: some high end cads even got 1.215V
04:08 karolherbst: RSpliet: you could try the think with returning info.max in nvkm_volt_map and in the meanwhile I try to see which VID nvidia sets
04:10 karolherbst: I don't think that a difference of 0.0125V matters that much though, but maybe it does and if nouveau is of by 2 or 3 VIDs it could have a immense effect on "low-production-quality" chips
04:10 RSpliet: did you fix the logic w/ clock adjustments when NvBoost=2 isn't set?
04:11 karolherbst: yeah
04:11 karolherbst: I've updated my branch too
04:11 karolherbst: still based on 4.4
04:11 karolherbst: but I will move to 4.5 soon
04:11 RSpliet: yeah that's fine
04:12 karolherbst: also the last commit tries to fix P to 1 now leaving N/M to be variable.
04:13 karolherbst: it shouldn't change the PLL configs at all because the clocks are already so, that there is aways a good M,N,P=1 combination choosen by nouveau
04:13 karolherbst: or most of the time
04:14 karolherbst: ohhh wait
04:14 karolherbst: I think that commit can be thrown away
04:14 karolherbst: maybe not
04:14 karolherbst: "P = info->vco1.max_freq / freq;"
04:14 karolherbst: in the old version
04:15 karolherbst: well I will remove that commit for now and investigate it further
04:19 karolherbst: k, at least nouveau chooses 1.0971678 => 1.1V for you, let see what nvidia does
04:23 mupuf: karolherbst: I cannot think of anything else that would reference the power budget
04:23 mupuf: 2. Is also meh
04:24 karolherbst: mupuf: yeah, the thing I did was, I had two power_budgets: 1. down to 10W, 2. unlimited. After I pointed with all known references to 2, I still got downclocks in nvidia
04:24 mupuf: if there is no use in reading out the rails seperatly, I would go for the last idea => yeah, that sounds like a good plan actually
04:24 karolherbst: mupuf: well with the only thing that each rail points to a power_budget
04:24 mupuf: karolherbst: really? Each lane has a budget?
04:24 karolherbst: yes
04:25 mupuf: ok, I see, the sw is making sure that the hw is doing the right thing
04:25 mupuf: sounds good
04:25 mupuf: ok, then we need to be able to read the budgets by lanes then
04:25 karolherbst: but I didn't figure out the relation in detail though
04:25 karolherbst: yeah well
04:26 karolherbst: but yes, at least we need to be able to check which lane does have a higher power reading
04:26 karolherbst: I could imagine that they are connected to different parts of the gpu
04:27 karolherbst: maybe even with overlaps?
04:29 mupuf: ah ah, no
04:29 mupuf: you misunderstand how it works
04:30 mupuf: the VR has n inputs and 1 output
04:30 mupuf: inputs are called lanes
04:31 RSpliet: karolherbst: which branch? github doesn't just branches that have been updated more recent than 2 weeks ago
04:32 RSpliet: oh github might be broken
04:32 karolherbst: RSpliet: stable_reclocking_kepler_v2, I just updated it today
04:32 RSpliet: yeah
04:34 karolherbst: do the GPIO have to be set to OUT or IN to adjust the voltage?
04:34 mupuf: karolherbst: OUT
04:34 karolherbst: k
04:35 karolherbst: odd....
04:35 karolherbst: GPIO 0: line 0 tag 0x73 [VID_4] OUT DEF 1 gpio: normal
04:35 karolherbst: this VID isn't touched by nvidia
04:36 karolherbst: ohhh no
04:36 karolherbst: my grep was wrong
04:36 karolherbst: PGPIO.GPIO[0] ...
04:36 karolherbst: maybe that should also be 0x0 like all the others
04:40 RSpliet: karolherbst: btw I'm currently rebasing my most scary tree, about to test a small patch
04:40 karolherbst: mhhh
04:40 RSpliet: ( https://github.com/RSpliet/kernel-nouveau-nv50-pm/commit/8ce553a53d6e222dd534735dac6a09133953a931 )
04:40 karolherbst: that's odd
04:40 karolherbst: it doesn't make much sense
04:40 karolherbst: nvidia volts to 0.9125V and 1.0375V
04:41 RSpliet: are you sure there's no magic negations on some of the GPIO lines?
04:41 karolherbst: mhhh wait
04:42 RSpliet: also: I'm quite sure NVIDIA has spent a lot of engineering effort into reducing the voltage as far as they can (with silly formulas like those you are currently discovering as result)
04:42 karolherbst: ohhhh
04:43 RSpliet: as that's effective to reduce the ever-proportionally-increasing static power consumption :-)
04:43 karolherbst: a negated one wouldn't be in the table
04:43 karolherbst: well there are two combinations anyway
04:44 karolherbst: I've put all in here: https://gist.github.com/karolherbst/7e30c57fba66b84ec3a6
04:44 karolherbst: I am sure I did something wrong
04:45 mupuf: RSpliet: indeed, this is why I said to karolherbst that I would never accept nouveau setting a voltage lower than the blob
04:45 mupuf: above is OK
04:45 mupuf: but not under
04:46 karolherbst: yeah, that's why I want to try to set the voltage to the max according to the map table just to rule that one out
04:46 mupuf: karolherbst: repeat after me, MAX IS A LIE!
04:46 karolherbst: I am sure we figured out that nvidia sets the voltage a bit higher on his gpu
04:46 mupuf: it is not, at least in my testing
04:46 karolherbst: mupuf: it's a clamping max
04:46 mupuf: not true in my case
04:47 karolherbst: the min/max entries specifiy the min/max of the result of the voltage calculation of that row
04:47 karolherbst: if the result is in the middle, good, if not, clamp it
04:47 mupuf: which mode?
04:47 karolherbst: all
04:47 mupuf: because it did not work like that for my GM107
04:47 karolherbst: mode 3 is strange
04:47 karolherbst: so is mode 2
04:47 karolherbst: 2 selects min
04:48 karolherbst: 3 selects (min+max)/2
04:48 karolherbst: mupuf: yeah, because there is much more
04:48 karolherbst: pstate voltage increases effective min
04:48 karolherbst: max voltage entries throws out high cstates
04:48 karolherbst: *throw
04:49 karolherbst: and then you also have the linked entries
04:49 karolherbst: and then the min/max are per entry
04:50 karolherbst: mupuf: if you really want to look into that right, you have to unlimit the pstate voltage, unlink the entries, and have a single entry mapping, not limited by anything else
04:50 karolherbst: then you can play with the coefficients and nvidia is clamping the result with min/max
04:57 karolherbst: RSpliet: what is the 0x10 bit?
04:57 RSpliet: https://github.com/kfractal/nouveau/blob/hwref/drm/nouveau/include/nvkm/hwref/gk107/trim.h#L32 that one?
04:57 karolherbst: ahh
04:57 karolherbst: is it for locking, so that changing the coef doesn't do anything?
04:58 RSpliet: no
04:58 karolherbst: ohh wait
04:58 karolherbst: nope, no idea then
05:01 RSpliet: it enables the PLL lock detection logic?
05:01 karolherbst: ohh
05:01 RSpliet: (inverted: when 1, it powers down logic)
05:01 RSpliet: so when that value is 1, bit 17 would never become 2 - hence you'll see timeouts
05:02 karolherbst: ahh
05:02 karolherbst: nice
05:03 mupuf: karolherbst: thanks for the info
05:04 RSpliet: karolherbst: I re'd that for GT215 two years ago, surprised the Kepler logic has never been revised
05:04 RSpliet: in other news, from the looks of it nouveau actually really really sets 1.1V as it's voltage
05:05 RSpliet: which appears to be well above what the blob sets
05:05 karolherbst: I am sure nvidia sets seomthing higher though
05:05 karolherbst: and
05:05 RSpliet: what makes you think so?
05:05 karolherbst: the difference should be rather small
05:06 RSpliet: a voltage that is set too low could lead to arbitrary unexplainable behaviour
05:06 karolherbst: if the differens is more than 0.05V something is fishy
05:06 karolherbst: not that I say my code is good or right, but I didn't encounter a difference bigger than 10mV
05:07 karolherbst: and if I parsed those gpios right and nvidia volts to 1.0375V then either nouveaus reading is wrong or I did a terrible mistake somewhere
05:07 karolherbst: here is what we could try though: we just set the VID combintion nvidia sets and check if that's better
05:08 karolherbst: also
05:08 karolherbst: the parsing of the voltage table might be actually wrong
05:09 karolherbst: in any case there is nothing I really can rely on regarding volting on your card
05:10 karolherbst: the thing which bothers me most is, that a slightly lower clock works, which could mean, that the voltage is indeed too low
05:11 mupuf: tried setting the voltage to max all the time?
05:11 karolherbst: mupuf: the thing is, I can't be sure that the voltage nouveau thinks it sets is the one nouveau actually sets
05:11 karolherbst: mupuf: he needs this little patch and I can't be sure it is right: https://github.com/karolherbst/nouveau/commit/3d1410ae56842e2dd87a313f8d117cd6467a4e96
05:14 RSpliet: with NVIDIAs voltage settings everything runs fine
05:14 karolherbst: \o/
05:14 karolherbst: on highest clocks with nouveau?
05:14 RSpliet: although that was quite some manual labour
05:14 RSpliet: yep
05:14 karolherbst: k
05:15 karolherbst: then the issue is the voltage indeed
05:15 karolherbst: good
05:15 RSpliet: there's two issues though
05:15 RSpliet: 1: the voltage that we set, is that really the voltage we expect to set?
05:15 RSpliet: (we thought it was higher, but that shouldn't break execution)
05:15 RSpliet: 2: which voltage should be set?
05:15 karolherbst: yeah I already said this^^
05:16 karolherbst: regarding 2. I am sure that my calculation is at least -+0.01V right
05:16 karolherbst: but
05:16 karolherbst: my biggest concern is the headerless voltage table
05:16 karolherbst: wait, I show you something
05:17 karolherbst: I tried to figure out the unk bit in the entries
05:17 karolherbst: https://gist.github.com/karolherbst/ecd9b02c607410293fa0
05:17 karolherbst: the unk_idx might be the actual VID we have to set
05:17 karolherbst: so
05:17 karolherbst: the question is, how does nvidia configure the GPIOs
05:18 RSpliet: well, I just did it manually
05:18 karolherbst: VID 4 set would be 0x10: -- Vid 11, voltage 0 µV/975000 µV (unk0 = 0, unk_idx = 16, unk1 = 1) --
05:18 karolherbst: nouveau wouild think 0.975V
05:19 karolherbst: VID 1, 2: -- Vid 23, voltage 0 µV/1125000 µV (unk0 = 0, unk_idx = 3, unk1 = 1) --
05:19 RSpliet: for the high perflvl I set it to 0x06
05:19 karolherbst: and this would actually make sense!
05:19 karolherbst: 0x06?
05:20 karolherbst: so VID 2 and VID 3 set?
05:20 karolherbst: nouveau would read it as 0.9125V
05:20 RSpliet: no, VID1 and VID2 set
05:20 karolherbst: ahh okay
05:20 karolherbst: this is then 0.875V
05:20 karolherbst: but
05:20 karolherbst: with my parsing of the unk part it would be 1.125V
05:21 karolherbst: RSpliet: I hope you see what I mean from the last paste?
05:21 RSpliet: no, with the original parsing that would be 0.9125V
05:21 karolherbst: unk_idx is the field I am refering to
05:21 RSpliet: i saw that yes
05:21 karolherbst: ohh right
05:21 karolherbst: 0.9125V
05:22 karolherbst: I did a little bit setting mistake in my head
05:22 karolherbst: 0.9125 is obviously wrong
05:22 karolherbst: okay
05:22 karolherbst: nouveau sets 0x15
05:23 karolherbst: which would be 0.9875 with the corrected parsing
05:23 karolherbst: vs 1.0875V from nvidia
05:23 karolherbst: so 0.1V below
05:23 karolherbst: k...
05:23 karolherbst: I try to hack up a patch for this
05:23 RSpliet: the simple test would be to alter one of those unk bits in the VBIOS and see if that changes NVIDIAs behaviour
05:23 RSpliet: no
05:23 RSpliet: verify
05:23 karolherbst: ohh right
05:23 karolherbst: but I have no GPIO based gpu
05:24 karolherbst: ohh well I have the fermi one
05:24 karolherbst: but not with such a voltage table
05:24 karolherbst: that's the biggest issue
05:24 RSpliet: maybe I'll have some time over the weekend for you
05:24 karolherbst: I would have to rewrite the entire table
05:24 karolherbst: and mupuf also doesn't have such a card
05:24 RSpliet: (but time is a rather limited good at the moment , as you may have noticed :-P)
05:25 karolherbst: RSpliet: yeah, but I am quite possitive that my theory is quite right, because if the header is 0, all the information is in the row
05:25 karolherbst: but the VID combinations are currently calculated
05:25 karolherbst: and not taken from the rows
05:25 karolherbst: you get what I imply?
05:25 RSpliet: but how is that correct in all the other VBIOS tables, that don't have this unk values? how does it work for older cards
05:25 karolherbst: because they are header controlled
05:26 karolherbst: there are also voltages in the rows which are ignored, when the header contains usefull data
05:26 RSpliet: mupuf: you don't happen to have this GPU (a GTX650) , do you?
05:27 karolherbst: RSpliet: it doesn't matter, it is nothing chip specific, it is a vbios only issue
05:27 mupuf: RSpliet: I may have actually
05:27 karolherbst: I saw one or two other cards with the same header
05:27 RSpliet: got it off amazon for 50 quid :-P
05:27 mupuf: it would be my nve7
05:28 karolherbst: mupuf: your nve7 has a valid voltage table header ;)
05:28 RSpliet: karolherbst: perhaps mupuf can stick that one in the REator for you to play with the VBIOS and see what NVIDIA does ;-)
05:28 RSpliet: oh
05:28 mupuf: no fun then
05:28 karolherbst: RSpliet: yes, that kind of vbios is quite rare
05:28 RSpliet: I'm quite sure my card has a valid voltage table header too
05:28 karolherbst: RSpliet: I would guess, <5% of all cards have such
05:28 RSpliet: just different :-P
05:28 karolherbst: RSpliet: nope
05:28 karolherbst: 0
05:28 karolherbst: -- Mode GPIO, Base voltage 0 µV, voltage step 0 µV, acceptable range [0, 0] µV --
05:28 RSpliet: it's a valid value, as NVIDIA defined it to be
05:28 karolherbst: this is your header
05:29 karolherbst: ahhh okay
05:29 RSpliet: it's just being parsed invalidly by our tools
05:29 RSpliet: (version mismatch? you did just quickly hack that version stuff up didn't you? :-))
05:29 karolherbst: I am sure I get a patch done which works on your gpu :p
05:30 RSpliet: good
05:31 karolherbst: my biggest issues is, that the unk field has holes
05:32 karolherbst: like there is no 28
05:32 karolherbst: or 23
05:34 karolherbst: RSpliet: nouveau/nvkm/subdev/bios/volt.c:148 : info->vid = (nvbios_rd32(bios, volt) >> 23) 0xff;
05:34 karolherbst: ohh
05:35 karolherbst: info->vid = (nvbios_rd32(bios, volt) >> 23) & 0xff;
05:35 karolherbst: currently there is info->vid = idx
05:38 karolherbst: RSpliet: that would be the corrected table: https://gist.github.com/karolherbst/448a2687488211ccb987
05:38 karolherbst: and then the set VIDs make sense :)
05:40 karolherbst: I just hope that the holes don't break nouveau
05:43 karolherbst: RSpliet: so it would be awesome if this works: https://github.com/karolherbst/nouveau/commit/199a50cfefe3b4a48722d3cedae75b2cfabdb0e7
06:21 RSpliet: karolherbst: I'll give that a try later
06:21 karolherbst: thanks a lot
06:23 RSpliet: and thank you for being so available ;-)
06:23 karolherbst: no problem :D
06:23 karolherbst: I kind of decided I want to focus on nouveau performance from the very start anyway :p
06:23 RSpliet: yeah I know
06:24 RSpliet: are you sure 0xff is the right mask?
06:24 karolherbst: mhh no
06:24 karolherbst: it could be smaller
06:24 karolherbst: but not much
06:24 karolherbst: maybe it is 0x7f
06:25 karolherbst: I know that at 0x100 there is a bit set
06:26 RSpliet: how many VID GPIO lines are there max?
06:26 karolherbst: 8
06:26 RSpliet: then 0xff sounds very plausible :-)
06:26 karolherbst: yep :)
06:27 karolherbst: but I didn't looked it up
06:27 karolherbst: I just looked at the value at the vbios and this was what makes most sense
06:27 karolherbst: I am sure the voltage mask is also a bit bigger
06:27 karolherbst: but never verified it yet
06:28 karolherbst: there is also something at >> 21 0x3 which could be part of the voltage or not
06:29 karolherbst: making the mask 0x007fffff
06:29 karolherbst: 0x1f800000 would be the vid
06:29 karolherbst: and 0xe is something I don't know
06:30 karolherbst: the entries are only 4 bytes big anyway
06:30 karolherbst: that's why they are stored that messed up
06:30 karolherbst: they could use bigger lines though...
06:30 karolherbst: * 0xe0000000
06:34 RSpliet: did you fix this up for nvbios as well?
06:34 RSpliet: (and if not: would you mind? :-P )
06:34 karolherbst: I already have a patch yes
06:34 RSpliet: good stuff
06:34 karolherbst: but I want a bit of confirmation before pushing it
06:35 RSpliet: sure
06:37 karolherbst: ohh a in-kernel debugger gets pulled for 4.6
06:39 RSpliet: karolherbst: sorry to bother you with this question (at work), but what kind of voltage table does my GT640 have?
06:39 RSpliet: is it similar to the GTX650?
06:39 karolherbst: it is the ddr3 nve7?
06:39 RSpliet: yep
06:39 karolherbst: a header based one
06:39 karolherbst: a non header based is really really rare
06:39 RSpliet: version?
06:40 karolherbst: 0x50
06:40 RSpliet: (what does header-based mean anyway? like: not using GPIOs to change voltage but another mechanism?)
06:40 karolherbst: you know what is funny?
06:40 karolherbst: ahh wait
06:41 RSpliet: mupuf... or well, I find him funny
06:41 karolherbst: RSpliet: header-based means there are not only 0 set for each field in the header :p
06:41 karolherbst: like this:-- Mode GPIO, Base voltage 950000 µV, voltage step 12500 µV, acceptable range [950000, 1137500] µV --
06:42 RSpliet: oh ok, so there still is the off chance that we have been using the wrong VID values on other cards as well
06:43 karolherbst: yes
06:43 karolherbst: usually the numbers are going up
06:43 karolherbst: but for your gddr5 card it is in reverse
06:44 karolherbst: so it might be similiar to the index
06:44 RSpliet: are they going up for my DDR3 card?
06:44 karolherbst: yeah, but the voltage values doesn't make much sense in the entries
06:44 RSpliet: simple monotonous rise I mean :-P
06:44 karolherbst: yeah
06:44 karolherbst: ohh wait
06:44 karolherbst: no
06:44 karolherbst: more like 0, 1, 3, 5 ;)
06:44 karolherbst: well
06:44 karolherbst: and 0 at the end again
06:45 RSpliet: hmm
06:45 karolherbst: in the end, it doesn't make much sense
06:45 karolherbst: https://gist.github.com/karolherbst/bd6549cd759519c284ff
06:45 RSpliet: I'm curious whether we've been incorrectly setting the voltage wrongly for those cards too... leading to very infrequent crashes
06:45 karolherbst: yeah might be
06:46 RSpliet: could you re-print unk_idx as %02x please?
06:46 karolherbst: yes
06:47 karolherbst: updated
06:47 RSpliet: thanks, very helpful
06:48 RSpliet: yes, quite likely that your branch would set a voltage that is too low on other cards
06:48 karolherbst: with the vid fix?
06:49 RSpliet: after the patch you just wrote it should then be better
06:49 karolherbst: well this only accounts for voltage tables with 0 values
06:49 karolherbst: nouveau uses the index in other cases
06:50 RSpliet: 0 values?
06:50 karolherbst: this part: https://github.com/karolherbst/nouveau/blob/199a50cfefe3b4a48722d3cedae75b2cfabdb0e7/drm/nouveau/nvkm/subdev/volt/base.c#L211-L243
06:50 karolherbst: info is the header
06:50 karolherbst: "} else if (data && info.vidmask) {" applies for your gddr5 card
06:51 karolherbst: "if (data && info.vidmask && info.base && info.step) {" for your ddr3 card
06:53 RSpliet: is info.base supposed to be the same for every entry>
06:53 karolherbst: info.base is in the header
06:53 karolherbst: but
06:53 karolherbst: "info.base += info.step;"
06:53 karolherbst: ;)
06:54 RSpliet: hmm right
06:55 RSpliet: what you generate there is different from the entries defined in the table that follow
06:55 RSpliet: s
06:56 karolherbst: yeah, nvbios sets the VID according to the index
06:56 karolherbst: and it seems when the voltages are parsed from the entries, we might have to set the VID according to the unk_idx field
06:56 karolherbst: and not the index of the entry
06:56 karolherbst: the Vid
07:00 RSpliet: sounds very plausible
07:01 RSpliet: also the mismatch between the derived µv and the value in the entries makes me a bit nervous...
07:01 karolherbst: yeah
07:02 karolherbst: but the entries make less sense in other vbios'
07:02 RSpliet: do they still make no sense if you take the vid value from unk_idx?
07:02 karolherbst: I would say then even less
07:03 RSpliet: hmm... it would be nice if you could spend some more time on RE'ing that and seeing what NVIDIA does with changes in the VID in those cases
07:03 karolherbst: RSpliet: look at this: https://gist.github.com/karolherbst/d9186bb7a763a2749078
07:04 RSpliet: hmm, yes
07:04 karolherbst: maybe there is a flag somewhere with which we can decide
07:06 RSpliet: either way, you're on the right track I believe
07:06 karolherbst: yeah, it makes actually sense somewhat
07:06 RSpliet: I'd love to find out whether line 219 in volt/base.c should be the vid rather than the idx
07:07 karolherbst: I think index is right there
07:07 karolherbst: because the voltage is also based on the voltage
07:07 karolherbst: ohh wit
07:08 karolherbst: vid is equal to the index
07:08 karolherbst: there is no index field in the entries
07:10 karolherbst: I think in the end there are two modes how to parse the entries: header/index based or entry/value based
07:11 RSpliet: for this last card there's other stuff wrong
07:12 RSpliet: if your base is 825000µv, and every step you go down, then every step further you drop below the "acceptable" range. That'd be silly
07:12 karolherbst: nouveau handles it a bit differently
07:12 karolherbst: I think nvbios isn't updated
07:14 karolherbst: info->base = nvbios_rd32(bios, volt + 0x12) & 0x00ffffff; and info->step = nvbios_rd16(bios, volt + 0x16);
07:14 RSpliet: try and keep nvbios updated as well as you can please, I know it's not always the fun thing to do (and when you're re'ing it's annoying having to change both constantly), but it's useful when others test and verify
07:15 RSpliet: I'm being a bit of a hypocrite saying it, since the timing parsing code is likely stale... so kick me in the butt for that ;-)
07:15 karolherbst: yeah I know
07:16 karolherbst: usually I want to push stuff to envytools first
07:16 karolherbst: mhh how odd
07:16 karolherbst: nvbios reads the step out differently...
07:17 karolherbst: ohhh
07:19 karolherbst: RSpliet: better? "-- Mode GPIO, Base voltage 1212500 µV, voltage step -12500 µV, acceptable range [825000, 1212500] µV --"
07:19 karolherbst: https://gist.github.com/karolherbst/d9186bb7a763a2749078
07:19 karolherbst: this looks nice now
07:19 karolherbst: :)
07:21 RSpliet: excellent
07:21 RSpliet: have you ever observed values below 1.175V on this card?
07:21 karolherbst: nvbios: volt_uv = le32(start+10) & 0x00ffffff, nouveau: info->base = nvbios_rd32(bios, volt + 0x12) & 0x00ffffff;
07:22 karolherbst: ahh
07:22 karolherbst: 10 is min: info->min = nvbios_rd32(bios, volt + 0x0a);
07:22 karolherbst: k, then I know where the error comes from
07:23 karolherbst: this could also have been a typo actually :D
07:25 RSpliet: karolherbst: my question still stands :-P
07:26 karolherbst: which card?
07:26 karolherbst: any why below?
07:26 RSpliet: https://gist.github.com/karolherbst/d9186bb7a763a2749078
07:26 karolherbst: ohh you mean because of the unknown bit
07:27 karolherbst: well
07:27 karolherbst: yes
07:27 karolherbst: because the max voltage of that card is 1.15V
07:27 RSpliet: I wonder why the header is 2 bytes longer, and contains 0xc0 in the end... and every voltage entry has something like 0xcX
07:27 RSpliet: in the entry
07:27 karolherbst: nvidia won't volt above 1.15V
07:27 karolherbst: because of this: https://gist.github.com/karolherbst/6140f4ee55ebcd4dfb3e
07:27 karolherbst: nvidia sets the max clock to the lower value of the both max entries for the current temperature
07:28 karolherbst: becuase both entries are stable (no temperature based parameter)
07:28 karolherbst: the total max volt is 1.15V
07:29 RSpliet: there's meaning in the low 16 bits of these entries
07:30 karolherbst: the unk1 field?
07:30 RSpliet: the low 21 bits are no longer the µv
07:30 RSpliet: but rather contain an index and an informative value
07:32 karolherbst: I don't know who REed this table before :/
07:32 karolherbst: but yeah, it seems like something else is in there
07:32 karolherbst: but
07:32 karolherbst: it could be that it is garbage, which is rather unlikely, but
07:32 RSpliet: who RE'd it hasn't seen this format before :-)
07:32 karolherbst: most likely right
07:32 RSpliet: doesn't matter, just intrigued and interesting to get to the bottom of
07:33 karolherbst: what bothers me
07:33 karolherbst: why are only 4 entries filled
07:33 RSpliet: exactly!
07:33 karolherbst: we have the same with pwm based ones
07:33 RSpliet: that *could* be a further bound for the voltage values used
07:33 karolherbst: my gpu: https://gist.github.com/karolherbst/17f56b17725fe8775153
07:33 RSpliet: or values that help configure the pwm
07:33 karolherbst: same values
07:34 karolherbst: yeah maybe
07:34 karolherbst: anyway, I think/hope that with the new fix, the code might be actually stable enough for now
07:34 RSpliet: oh god why'd I sign up for a PhD rather than just work for someone who wants to pay me to RE this :-P
07:34 karolherbst: :D
07:34 RSpliet: yeah, it's good enough to run my experiments atm
07:35 RSpliet: (actually, manually setting the voltage is good enough)
07:35 karolherbst: yeah well
07:35 karolherbst: :D
07:35 RSpliet: I'll give some stuff test runs when I get to it
07:35 karolherbst: still if my patch works, it would be awesome :)
07:35 karolherbst: thanks a lot
07:35 RSpliet: yeah, I'll test it
07:35 karolherbst: it was kind of hard to do a proper debuging on such cards actually
07:35 karolherbst: because you don't find many of them
07:36 RSpliet: but it'd be good if you could keep digging for the significance of the VBIOS values
07:36 karolherbst: well
07:36 karolherbst: I don't have gpios
07:36 karolherbst: only on my fermi gpu though
07:36 RSpliet: check out mupufs range of GPUs
07:36 karolherbst: huh
07:36 RSpliet: (a new file system)
07:36 karolherbst: wait a second
07:36 karolherbst: the voltage table is empty on may fermi
07:37 karolherbst: this is no fun
07:37 RSpliet: is it really empty? what's the version?
07:37 karolherbst: 0x50
07:37 karolherbst: headeR: 0x70fa: 50 1a 04 00 02 03 1f 00 00 ff 7c c7 0c 00 0c 98 10 00 8c b2 16 00 58 9e ff 00 mask = 0x1f
07:37 karolherbst: -- Mode GPIO, Base voltage 1487500 µV, voltage step -25000 µV, acceptable range [837500, 1087500] µV --
07:37 RSpliet: 0 entries of 4 bytes
07:38 RSpliet: haha, fun!
07:38 RSpliet: what do the 02 03 signify? could the table be larger than we know?
07:39 RSpliet: (check whether it's immediately followed by a new table header or rather something that could be 6 bytes of data)
07:39 RSpliet: and why is that 03 03 in your gpu?
07:40 RSpliet: okay, I'm getting too excited
07:40 karolherbst: the first one is a flag
07:40 RSpliet: time to do other stuff
07:40 karolherbst: if (nvbios_rd32(bios, volt + 0x4) & 1) { PWM } else { GPIO }
07:40 RSpliet: oh good!
07:41 karolherbst: yeah mupuf found this one :p
07:41 karolherbst: maybe we can find out what the other bits mean
07:41 RSpliet: (and numbers etc... it's very likely that bit 31 in an entry just means "entry valid"
07:43 karolherbst: could be yes
07:43 karolherbst: would fit somewhat
07:44 karolherbst: yep
07:44 karolherbst: I found the base of 1487500 weird
07:44 karolherbst: but nouveau really use this
07:44 karolherbst: it just drops the first 9 entries
07:45 karolherbst: "nouveau D[ VOLT][0000:01:00.0] VID 10: 1087500uv" being the first one saved
07:45 karolherbst: ohh
07:45 karolherbst: actually the first 0xf ones are droped
07:45 karolherbst: sometimes I think if the bios designers are some kind of sadistic....
07:46 karolherbst: because, why, why would you do something like that...
07:47 RSpliet: they're hints and clues for us to RE
07:47 RSpliet: NVIDIA and OEMs spend milliards of dollars to design really cool puzzles for us
07:47 karolherbst: yeah
07:48 RSpliet: (yes, I somewhat stoical refuse to adopt the American billion, it's just silly and wrong :-P)
07:48 karolherbst: and if we finally solve it, we will find the golden chip of nvidiados the holy god of light :p
07:51 karolherbst: RSpliet: you know what is odd: 00 03
07:51 karolherbst: for your vbios
07:52 RSpliet: which one? I have quite a few vbii
07:52 karolherbst: gddr5
07:52 karolherbst: bit0: pwm/gpio, bit1: entry/index based
07:54 karolherbst: uhhh
07:54 karolherbst: I think that is it
07:57 karolherbst: RSpliet: grepped all nve* cards: https://gist.github.com/karolherbst/4d310a7edd5bb0b7dfbb
07:57 karolherbst: "-- Mode GPIO, Base voltage 306250 µV, voltage step 6250 µV, acceptable range [750000, 1100000] µV --" this looks like garbage somewhat :D
07:58 karolherbst: also has 00 03
07:58 karolherbst: three with 00 03 have -- Mode GPIO, Base voltage 0 µV, voltage step 0 µV, acceptable range [0, 0] µV --
07:58 karolherbst: and the last one has a valid header
07:58 karolherbst: -- Mode GPIO, Base voltage 1212500 µV, voltage step -12500 µV, acceptable range [825000, 1212500] µV --
07:59 karolherbst: that one is interessting
07:59 karolherbst: https://gist.github.com/karolherbst/9484e66630a5d15023eb
07:59 karolherbst: ohh wrong nvbios
08:00 karolherbst: updated: https://gist.github.com/karolherbst/9484e66630a5d15023eb
08:00 karolherbst: mupuf: there?
08:01 karolherbst: I think bit 1 in byte 4 in the voltage table might indicate if we parse with header or entry values
08:07 RSpliet: karolherbst: know a method to verify this hypothesis?
08:08 karolherbst: flip it and see if the VID changes?
08:08 karolherbst: nvbios shows the header based parsing
08:08 karolherbst: and the unk_idx the entry based one
08:09 karolherbst: 0x6 is with 00 on f pstate
08:09 karolherbst: and mhhh
08:10 karolherbst: with 02 it shouldn't volt at all
08:10 karolherbst: RSpliet: orr
08:10 karolherbst: just push stupid values in the header for the base and step
08:10 karolherbst: and if that's true with 02 it should reacto to those
08:10 karolherbst: with 00 it shouldn't
08:14 RSpliet: happy to experiment a little later on if none of your GPUs let you
08:14 RSpliet: (or none of mupufs actually, I'm a tad busy so if you want quick data, better do it yourself :-P)
08:16 karolherbst: yeah, I will go through all that in detail later at some point
10:59 karolherbst: RSpliet: https://github.com/karolherbst/envytools/commit/4411f57f4082f77a8050b4472b09fc4a9569d665
11:00 karolherbst: this produces something like this now: https://gist.github.com/karolherbst/cfee3501d4f6ff383876
11:03 karolherbst: and this on your gddr5 one: https://gist.github.com/karolherbst/3024b2c8cd452221ca1a
11:26 karolherbst: RSpliet: k, I've updated my branch with all the needed stuff, it should work now out of the box :)
11:31 karolherbst: hakzsam: did you had problems with reator today?
11:40 dcomp: I have an 840M 3D Accelerator
11:40 karolherbst: dcomp: I guess you have no gl acceleration?
11:41 dcomp: I've compile nouveau and added case 0x118: above 0x117
11:41 dcomp: nouveau 0000:07:00.0: unknown chipset (118010a2)
11:41 karolherbst: ohh
11:41 karolherbst: right
11:41 dcomp: now:
11:41 dcomp: nouveau 0000:07:00.0: NVIDIA GM107 (118010a2)
11:41 dcomp: [ 792.549919] nouveau 0000:07:00.0: bios: version 82.08.14.00.0e
11:41 dcomp: [ 792.637311] nouveau 0000:07:00.0: fb: 2048 MiB DDR3
11:41 dcomp: [ 792.637315] nouveau 0000:07:00.0: priv: HUB0: 6013d4 ffff573f (1a408200)
11:41 dcomp: [ 792.637378] nouveau 0000:07:00.0: priv: HUB0: 10ecc0 ffffffff (1b40822c)
11:41 karolherbst: dcomp: yeah, but does something not work?
11:42 dcomp: well right now ... lspci has hung
11:42 karolherbst: that's normal
11:42 karolherbst: this is lspci being stupid
11:42 karolherbst: lspci wakes up the gpu
11:42 karolherbst: or does it hang forever?
11:43 dcomp: http://pastebin.com/6RKJCskb
11:43 karolherbst: ahhh okay
11:43 dcomp: Thats the log as of insmod
11:43 karolherbst: so waking up the gpu fails
11:43 karolherbst: dcomp: insmod nouveau.ko runpm=0
11:44 karolherbst: runpm=0 disables putting the nvidia gpu to sleep
11:44 karolherbst: that should at least give you a stable gpu
11:45 karolherbst: I am really sure makeing wakeup/suspend is on the todo list of 2 or 3 devs here already but somehow everybody found more important things to do :/
11:46 dcomp: just rebooted trying now ...
11:48 dcomp: well lspci no longer hangs
11:50 dcomp: http://pastebin.com/d5xgbiNh
11:50 hakzsam: karolherbst, no, why?
11:51 dcomp: Pointer to TMDS table invalid and pointer to flat planel invalid
11:51 dcomp: Im guessing thats because its only a 3d Accelerator
11:52 Yoshimo: karolherbst: might be because there is so much stuff that hasn't been done yet
11:58 dcomp: DRI_PRIME=1 glxinfo return Gallium 0.4 on NV118 :)
11:58 dcomp: no output on glxgears though :(
12:19 karolherbst: hakzsam: I was just wondering
12:20 karolherbst: had a random crash for whatever reason
12:20 karolherbst: dcomp: so just black window?
12:20 karolherbst: dcomp: do you do DRI2 or DRI3 offloading?
12:21 karolherbst: dcomp: and does someting appear in dmesg after starting glxgears?
12:21 karolherbst: DRI2 offloading requires a running compositor
12:23 dcomp: karolherbst: is gnome-shell wayland suitable
12:23 karolherbst: dcomp: no clue, I don't use gnome
12:23 karolherbst: and why do you ask about wayland?
12:24 dcomp: im running a wayland compositor
12:25 karolherbst: ohhh
12:26 karolherbst: never done offloading in wayland
12:28 karolherbst: but
12:28 karolherbst: I somehow doubt it works with X clients though
12:28 karolherbst: maybe it does
12:29 dcomp: just getting the dmesg log for glxgears
12:30 dcomp: it does pin the cpu but just a black window
12:33 karolherbst: k, so the gpu is most likely running, but no image data gets transfered or something else
12:33 karolherbst: dcomp: can you try eglgears?
12:33 karolherbst: ohh wiat, there is only a x version as well...
12:33 karolherbst: dcomp: you should test some wayland applications
12:34 dcomp: well not sure who to blame but glxgears segfaulted and now my wifi is borked
12:34 karolherbst: uhh
12:34 dcomp: i suspect memory corruption somewhere
12:34 karolherbst: that sounds bad
12:34 karolherbst: well let my start my wayland session
12:38 karolherbst: dcomp: mhh it works for me
12:39 karolherbst: dcomp: I hope there is a Xwayland process started somewhere?
12:41 dcomp: http://pastebin.com/cLHAphpC
12:41 dcomp: Xwayland is running
12:42 karolherbst: uhh
12:42 karolherbst: I think your gpu crashed
12:42 karolherbst: but it shouldn't affect your wifi driver
12:44 dcomp: theres a first for everything
12:44 dcomp: probably some dust on the pci connector
12:45 karolherbst: your gpu usually runs on the cpu pcie controller
12:45 karolherbst: not the motherboard one
12:46 dcomp: its a laptop ... its probably all on the cpu
12:46 karolherbst: nope
12:46 karolherbst: you wouldn't have enough lanes
12:47 karolherbst: this is an issue somewhere in the kernel
12:47 karolherbst: nouveau blocks a kworker forever
12:47 karolherbst: and iwlwifi isn't able to run theirs
12:47 karolherbst: for whatever reasons
12:48 dcomp: were assuming GM108 is the same as GM107 right?
12:48 karolherbst: right
12:48 karolherbst: the differense are minimal though, but there should be some
12:49 dcomp: would an mmiotrace help?
12:49 dcomp: I could try and get the binary driver runningthe
12:49 karolherbst: yeah I think so
12:49 karolherbst: I don't see any gm108 traces
12:49 karolherbst: so yeah, would be usefull
12:50 karolherbst: dcomp: well I trace nvidia through bumblebee usually
12:50 dcomp: does the binary driver support dri offloade
12:50 karolherbst: no
12:50 karolherbst: readup on bumblebee
13:00 dcomp: karolherbst: should I use primus or virtualgl as the bridge?
13:01 karolherbst: doesn't matter
13:01 karolherbst: a simply optirun glxinfo is enough
13:01 karolherbst: you only need to fire up the X server which is done by either command
13:22 karolherbst: reclocking stresstesting :)
13:22 karolherbst: RSpliet: it seems like reclocking itsels seems pretty stable though
13:24 jayhost`: gm107 has been stable here. Computers been on high clocks a few days
13:25 karolherbst: jayhost`: nice
13:25 karolherbst: but I am talking about _reclocking_ itself not the gpu being stable at clocks
13:25 karolherbst: I reclock in a loop now
13:25 karolherbst: done 100.000 reclocks in the past 8 minutes
13:25 karolherbst: actually 200.000
13:26 karolherbst: the only errors I get are "fifo: LB_ERROR" and "fifo: FB_FLUSH_TIMEOUT"
13:44 karolherbst: wow
13:44 karolherbst: somebody got a fermi 730GT ...
13:44 karolherbst: pure guy
13:45 sarnex: :)
13:49 karolherbst: what happened
13:50 karolherbst: this error is new
13:50 karolherbst: https://gist.github.com/karolherbst/48d91d915e8544560be8
13:57 AlexAltea: > https://github.com/envytools/envytools/blob/master/rnndb/fifo/nv1_pfifo.xml#L53
13:57 AlexAltea: could this be: <bitfield high="9" low="2" name="ADDRESS" shr="9"/> instead?
13:57 AlexAltea: same goes to the other registers above
13:58 AlexAltea: writing 0xFFFFFFFF to NV03_PFIFO_RAMRO results in an effective value of 0x101FE
13:59 AlexAltea: so the MSB:LSB range appears to be 9:2 beunless something has changed since NV3 (I'm on NV4D) (or unless I failed at understanding what "high"/"low" means)
13:59 AlexAltea: or probably 8:1 (indexing from 0)
14:00 karolherbst: mupuf: okay, I did like 700.000 reclocks and my gpu fell of the bus... any idea how to debug this?
14:01 dcomp: i think Im getting somewhere
14:02 karolherbst: dcomp: nice
14:02 dcomp: couldnt get an output for glxinfo
14:02 dcomp: but Ive got a 138MiB mmiotrace ... so thats something
14:03 karolherbst: dcomp: somethign in dmesg? or does glxinfo just fails or does it hang?
14:03 dcomp: I cancelled it ... after my dispay hung
14:04 karolherbst: dcomp: in such a case, dmesg is important
14:04 dcomp: and just a lot of mmiotrace mapping in dmesg
14:04 dcomp: and 1 acpi message
14:05 dcomp: ill try running it again after a reboot
14:05 karolherbst: mhh your display shouldn't hang though
14:06 karolherbst: but a 140MB trace might be fine actually
14:13 dcomp: hmmm ... did a reboot amd got a response from glxgears
14:13 dcomp: anyway how should I upload this
14:14 karolherbst: dcomp: compress it with xz first
14:17 dcomp: okay 6.3M
14:17 karolherbst: nice
14:17 karolherbst: you can upload it anywhere
14:17 karolherbst: dcomp: it would be awesome if you could install envytools and get the vbios too and nvapeek 101000
14:18 dcomp: fedora doesnt have any of these
14:19 dcomp: ive been compiling as Im going along :(
14:19 karolherbst: well you don't need to install envytools anyway
14:19 dcomp: actually envytools is here
14:19 dcomp: ;)
14:19 karolherbst: nice :)
14:20 dcomp: for nvapeek:
14:20 dcomp: 00101000: 8040008a
14:21 karolherbst: vbios you can get with nvagetbios
14:25 dcomp: extracted but boh methoda say invalid signature
14:25 karolherbst: uhhh right
14:25 karolherbst: laptop was it?
14:25 karolherbst: uhhh yeah, it's inside your ACPI stuff
14:25 karolherbst: somewhere
14:26 karolherbst: dcomp: did you upload the trace somewhere?
14:26 dcomp: ill do an acpi dump as well
14:26 dcomp: doing it now
14:26 karolherbst: dcomp: well
14:26 karolherbst: dcomp: maybe we can get the vbios with nouveau in a simple way
14:26 karolherbst: in debugfs there is a vbios.rom file with nouveau
14:26 karolherbst: but I have no idea if that works, sorry for that
14:27 karolherbst: but having the trace is actually more important I would say
14:29 dcomp: https://goo.gl/wACrud
14:30 dcomp: thats the trace
14:31 karolherbst: k that looks good
14:32 karolherbst: regarding vbios mhh well
14:32 karolherbst: dcomp: you could try to open both files with nvbios
14:32 karolherbst: vbios prom may contain something though
14:33 karolherbst: or you could just send me the prom one and I check myself
14:33 jayhost`: imirkin I rewrote the perl command in python so I could nvdisasm the whole code
14:35 dcomp: nouveau doesnt like nvagetbios ... got a load of MMIO faults
14:37 karolherbst: dcomp: ohh if you have nouveau loaded
14:38 karolherbst: dcomp: /sys/kernel/debug/dri/1/
14:38 karolherbst: there should be a file named vbios.rom
14:50 arizo: karolherbst: vmix is like alsamixer
14:51 arizo: u can switch it off to switch any resapling off and use hw resampler of the card
14:51 dcomp: vbios prom
14:51 dcomp: https://goo.gl/K6sZHd
14:52 dcomp: vbios via kernel fs
14:52 dcomp: https://goo.gl/hTud2M
15:20 karolherbst: dcomp: the one from debugfs is good
15:21 karolherbst: dcomp: thanks for the files
15:25 RSpliet: karolherbst: good stuff, I'll see if I can give it a spin tomorrow
15:26 karolherbst: RSpliet: nice :)
15:26 karolherbst: by the way, I was able to reclock my gpu 700.000 in a while true loop without sleep :)
15:26 karolherbst: and running glxspheres in the background without vsync
15:26 karolherbst: I think we are slowly getting there
15:26 RSpliet: good stuff, seems like everything is materialising
15:27 RSpliet: did it crash on attempt 700.001?
15:27 karolherbst: it fall of the bus
15:27 karolherbst: complete disconnect
15:29 karolherbst: well
15:29 karolherbst: it will be interessting with a display connect
15:29 karolherbst: but I can't test it
15:35 karolherbst: skeggsb: it would be nice to have those two pmu fixes as well: https://gist.github.com/karolherbst/48d91d915e8544560be8
15:37 karolherbst: RSpliet: by the way, my branch is rebased on 4.5 now, but I have a master_4.4 branch if you need it for 4.4
20:10 ciupicri: am I too cheap if I buy a Geforce 210 video card? I'm not planning to run any games, only play videos and office stuff, perhaps under Wayland in the future.
21:48 airlied: skeggsb: ack for nouveau: fix nv40_perfctr_next() cleanup regression