00:00 karolherbst: wow
00:00 karolherbst: crap
00:00 karolherbst: fun
00:00 karolherbst: when I am on battery my GPU only draws 40W
00:01 karolherbst: and I am sure nouveau doesn't limit it
00:03 Lekensteyn: "only" heh
00:03 karolherbst: Lekensteyn: check /sys/class/power_supply/BAT0/current_now
00:03 karolherbst: I think we messed the EC up a little
00:04 karolherbst: ohh wait
00:04 karolherbst: no, my mistake
00:04 karolherbst: mhh
00:06 karolherbst: Lekensteyn: could it be, that the value doesn't make much sense?
00:07 Lekensteyn: why?
00:08 karolherbst: they are too high
00:08 karolherbst: mhh
00:09 karolherbst: if divided by 0x10 then it starts to make sense
00:10 karolherbst: Lekensteyn: but the problem still remains: it's just a 16bit value, too inacurate and too volatile
00:11 karolherbst: ohhhh wait
00:11 karolherbst: silly me
00:11 Lekensteyn: endianess by any chance?
00:12 karolherbst: yes
00:12 karolherbst: but still
00:12 karolherbst: GPU idling at 0xf: 0xf350 values
00:12 karolherbst: oh no, this is actually fine
00:13 karolherbst: we just need to figure out how to map this to mA values
00:15 Lekensteyn: 3.248A?
00:15 Lekensteyn: two-s complement: (0xf350 ^ 0xffff) + 1
00:16 karolherbst: not quite
00:16 karolherbst: the value seems a bit too high actually
00:16 Lekensteyn: I have values around 1A, but that is with GPU off
00:17 Lekensteyn: with GPU on it doubles (1.9-2A)
00:18 Lekensteyn: karolherbst: you killed your machine? :P
00:18 karolherbst: gk104_fifo_intr strikes again
00:19 karolherbst: GPU off: 0xf98a@15.2V
00:20 Lekensteyn: what is the relative different in power consumption
00:20 karolherbst: GPU on@ 10W: 0xf68d@15.2V
00:21 karolherbst: GPU 0xf/2@19.1W: 0xf320@14.76V
00:22 karolherbst: ohh wait, the second value was at 14.84V
00:27 karolherbst: mhh
00:27 karolherbst: it somehow fits though
00:29 karolherbst: according to this, my keyboard LEDs drain 4W
00:30 Lekensteyn: I think I'll reduce the power consumption of my laptop and lights given the time ;)
00:30 karolherbst: Lekensteyn: :D
00:31 Lekensteyn: any final tests you want to do?
00:31 karolherbst: Lekensteyn: I could add the code to the wmi module I am using
00:31 karolherbst: clevo_xsm_wmi
00:31 Lekensteyn: to read battery status?
00:32 karolherbst: yes
00:32 karolherbst: it already reads out stuff from the EC
00:32 karolherbst: like fan speed
00:32 Lekensteyn: hm, but this info should normally be shown in sysfs (power_supply), let me check the source
00:33 karolherbst: Lekensteyn: I am sure it simply uses the ACPI methods
00:33 karolherbst: and the ACPI method returns 0xffffffff
00:33 karolherbst: so what should it do?
00:34 Lekensteyn: apply a hack like this: https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-B7130/BatteryFix.dsl https://github.com/Lekensteyn/acpi-stuff/tree/master/Clevo-B7130/clevo-battery-fix
00:34 Lekensteyn: assuming that your _BST method has this check for negative values
00:34 Lekensteyn: like this https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-B7130/BatteryFix.dsl#L35
00:35 Lekensteyn: apply it once, and then you can read through sysfs
00:35 Lekensteyn: (don't simply load it, but adapt your own acpi method :))
00:36 karolherbst: I do it through the wmi
00:36 karolherbst: I already added hwmon stuff to it, so I can add this as well
00:37 Lekensteyn: if you patch your BST method, then tools like powertop also report correct vlaues
00:38 karolherbst: mhhh
00:50 karolherbst: Lekensteyn: https://gist.github.com/karolherbst/9ed0a6d52779fa35a759ddfa581ccf9c
00:55 Lekensteyn: neat
00:55 karolherbst: now the voltage
00:56 karolherbst: BPV0
00:57 karolherbst: +0x8 offset to BPR0
00:58 karolherbst: also 16bit value
00:58 karolherbst: but now with a different endianess
00:58 karolherbst: because it makes sense
00:58 Lekensteyn: is 0x32 for me
00:58 Lekensteyn: offset
00:58 Lekensteyn: that is
00:58 karolherbst: uhm
00:58 karolherbst: yeah
00:58 karolherbst: 0x2a+8 ;)
00:59 Lekensteyn: can you pass a copy of your dsdt? (or more specifically, your EC region)
01:01 karolherbst: https://gist.github.com/karolherbst/9987934660c112d9bb09785f912f0443
01:03 Lekensteyn: here with offsets: http://sprunge.us/OeLR (I made mistakes in the past with calculating offsets, so having a lookup table is helpful :))
01:04 karolherbst: Lekensteyn: updated: https://gist.github.com/karolherbst/9ed0a6d52779fa35a759ddfa581ccf9c
01:04 karolherbst: I think I should group those things better
01:07 Lekensteyn: let me know if you made progress with finding the battery usage, I'll enter a different power state now!
01:07 karolherbst: what do you mean?
01:07 karolherbst: uhm wait
01:08 karolherbst: no, should be fine
01:08 karolherbst: hu? I though this is the power usage already?
01:09 Lekensteyn: what I meant is when you figure out why it consumes extra power
01:09 karolherbst: ahh
01:09 karolherbst: first I really need to know
01:09 karolherbst: now I work with precise values
01:09 karolherbst: before that my assumption was based on calculated garbage
01:09 karolherbst: I really like this now :) good think we talked about it :p
01:10 karolherbst: mhh odd
01:10 karolherbst: the value can't be right though
01:11 karolherbst: or not enough sampling
01:12 karolherbst: my laptop draws 5W more than what the GPU reports... :(
17:00 mark4: i think im having problems with nouveau. i cannot see any other possiblity of it being anything else with the problems im seeing.
17:00 mark4: firstly, every time I power on my start up has to be this
17:01 mark4: 1: boot, 2: log in, 3: startx, 4: TAB OUT, 5: killall X, 6, startx. if i do not kill and restart X in that way NOTHING responds in X at all. ever
17:01 mark4: cannot launch anything, dont get menus
17:01 mark4: second issue:
17:02 mark4: if i close the lid and the laptop suspends and i come back later again, the laptop does not "Seem" to respond but theres a difference to the above issue
17:02 mark4: if i try to drag a existing window with the mouse it does not seem to move
17:02 mark4: but if i suspend again and unsuspend it has moved
17:02 mark4: i think things are moving but the frame buffer is no longer being updated. the ONLY fix in this case is a reboot
17:03 mark4: cannot killal X and startx because the frame buffer still doesnt work
17:04 imirkin: are you using plasmashell?
17:04 mark4: no whatas plasmashell?
17:04 mark4: oh
17:05 mark4: kde plasma? fsck no that thing is garbage
17:05 imirkin: some kde thing
17:05 imirkin: what is "tab out" btw?
17:05 mark4: ran plasma for about a year and every 2 weeks of using it plasma totally deletes 100% of its config and you have to totally reconfigure it from scratch
17:05 mark4: control alt f2, log in, killall X
17:05 mark4: exit
17:05 mark4: alt f1
17:05 mark4: startx
17:05 imirkin: ah, switch vt
17:05 imirkin: is the more common nomenclature.
17:06 mark4: tab out is very common gamer speak lol
17:06 mark4: i used to be a wow addict
17:06 imirkin: usually it implies switching between applications in a window manager
17:07 imirkin: switching to a different VT is a very different things.
17:07 mark4: yea i know lol
17:07 mark4: but were nit picking here
17:07 imirkin: when you've switched VT's, X is effectively suspended
17:07 imirkin: no X application can make any progress
17:07 mark4: i know this
17:08 imirkin: ok
17:08 imirkin: so ... i'm not sure what you're complaining about
17:08 mark4: you dont understand, i launch X and nothing responds at all. no launching of anjything UNTIL i switch VT and KILL x and start it a second time
17:08 mark4: so boot, log in, start x, ctrl alt f2, log in, killall x, exit, alt f1, startx. now everything works
17:10 imirkin: i see
17:10 imirkin: and what are you looking for?
17:11 mark4: also, if i suspend my laptop, once i come out of suspend the frame buffer never gets any updates from any output to it. drag a window and it seems to stay where it is. but if i suspend again and come out of suspend the window WAS moved, its just the FB is never updated to show that move.
17:11 mark4: what am i looking for? not having to KILLALL X every time i reboot the laptop?
17:11 imirkin: yeah, that'd be nice
17:11 mark4: i would lilke to do boot, log in, start x and be working
17:12 mark4: is this a common issue with nouvuea?
17:12 imirkin: first time i've heard of such a thing
17:12 mark4: ok because i was going to say, how do the devs think this would be acceptable to anyone lol
17:12 mark4: if its not common its not their fault
17:12 imirkin: i meant more like 'what are you looking for from me'
17:12 imirkin: rather than in the more general sense
17:13 mark4: well any help you can give now that your familiar with the problem lol
17:13 mark4: so far all we did was clarify what my issue was
17:13 imirkin: pastebin dmesg and xorg log from that first "broken" X invocation would be a start
17:14 mark4: there is NOTHING in dmesg or xorg.0.log
17:14 mark4: nothing
17:14 imirkin: they're empty?
17:14 mark4: i mean, nothing unusual
17:14 imirkin: ok
17:14 mark4: no errors
17:15 imirkin: all is well and yet nothing is working
17:15 mark4: correct
17:15 imirkin: without providing additional information, you're on your own
17:15 mark4: until i kill X and start it again, then everyting is working fine
17:15 mark4: not sure what additional info i can supply lol
17:16 mark4: x11-drivers/xf86-video-nouveau
17:16 mark4: Latest version available: 1.0.15
17:16 mark4: 01:00.0 VGA compatible controller: NVIDIA Corporation GT218M [NVS 3100M] (rev a2)
17:16 imirkin: you can supply the dmesg and xorg logs
17:18 mark4: [ 90.917] (EE) Failed to load module "fbdev" (module does not exist, 0)
17:18 mark4: [ 90.917] (II) LoadModule: "vesa"
17:19 mark4: err
21:41 karolherbst: currently thinking about what we shall return if the GPU is powered of though hwmon
21:41 karolherbst: always 0 or something like -EAGAIN?
21:42 imirkin_: EAGAIN is probably better if that's well-handled by hwmon
21:43 imirkin_: or ENODEV
21:45 karolherbst: hwmon isn't the problem here
21:45 karolherbst: it simply returns what the driver wants
21:45 karolherbst: userspace is the issue
21:45 karolherbst: I think there are monitoring application which simply skip sensors returning an error
21:46 karolherbst: but ksysguard seems to be broken for me right now, cause it doesn't give me the sensor list anymore
21:46 imirkin_: ask the hwmon guys?
21:46 imirkin_: and/or read the docs for the APIs?
21:48 imirkin_: https://www.kernel.org/doc/Documentation/hwmon/sysfs-interface
21:48 imirkin_: doesn't say anything useful
21:48 karolherbst: right
21:48 imirkin_: check the libsensors source?
21:48 karolherbst: probably the best idea
21:48 karolherbst: at least "sensors" either returns the value or N/A
21:49 imirkin_: that's a good start
21:49 imirkin_: oh, also check what e.g. amdgpu does
21:49 karolherbst: mhh
21:49 karolherbst: something broke
21:50 karolherbst: power1_input returns -22 as the file content
21:51 karolherbst: uhhh okay meh
21:59 karolherbst: much better
22:00 karolherbst: imirkin_: I guess I shall fix this the right way: https://github.com/karolherbst/nouveau/commit/a4860d3ae6e5deec5998ce62b047fa586be83b75.patch
22:01 imirkin_: errrr
22:01 imirkin_: why is val becoming an err value?
22:01 imirkin_: that sounds like the bug :)
22:01 karolherbst: because we don't seperate value and return code in nvkm
22:01 imirkin_: so the thing consuming it needs to differentiate
22:02 karolherbst: yeah
22:02 imirkin_: (and make the assumption that negative current/temperature are unlikely to happen)
22:02 imirkin_: or separate the two out
22:02 imirkin_: whichever way is fine, but the current thing is nto :)
22:02 karolherbst: well on a GPU it makes no sense to have negative values
22:02 karolherbst: except the temperature sensors could report such
22:02 karolherbst: I think I fix it the right way
22:03 karolherbst: and split ret/value apart
22:03 karolherbst: all the way
22:03 imirkin_: worksforme
22:03 imirkin_: and hopefully for ben too :)
22:03 karolherbst: well
22:03 karolherbst: the current code is worse than what we had before, because the old hwmon didn't had this split as well
22:04 karolherbst: so we simply returned negative values and hwmon detected this as an error
22:04 karolherbst: I think
22:04 karolherbst: or maybe not?
22:04 karolherbst: oh well, doesn't matter anyway
22:17 karolherbst: it seems like the new prefered way for return type is long and not int
22:26 karolherbst: and we may soon have to convert to m°C, but somehow I don't care enough about it to change that as well
22:45 RSpliet: Guess we can't circumvent the negative value problem by converting hwmon to accept temperatures in kelvin? Getting a negative valid temperature then is about as likely as overflowing a 64-bit counter...
23:08 karolherbst: imirkin_: I hope this is more to your liking? https://github.com/karolherbst/nouveau/commit/fbc648c728b091cff5be3ed79b9338182211a415
23:08 karolherbst: RSpliet: it already accepts negative values
23:08 imirkin_: seems fine
23:09 imirkin_: bbl
23:09 karolherbst: RSpliet: which is the entire issue we are talking about already
23:09 karolherbst: if it would interpret negative values as error codes, there wouldn't be any issues
23:26 karolherbst: okay, now why do we return 0.6V if the GPU is powered off
23:27 karolherbst: uhh, okay,that's why
23:27 karolherbst: at least sensors does something reasonable: https://gist.githubusercontent.com/karolherbst/4dd67eeb320606e3205d84c429e5f75d/raw/1e190c32575f4bc31c75c6c5476d1d41e349261b/gistfile1.txt
23:29 karolherbst: and ksysguard seems to be able to handle those sensors as well
23:29 karolherbst: allthough it interprets an error code as 0, which is technically wrong
23:32 tobijk: karolherbst: don't bother too much about ksysguard, with 4.13 it can read out cpu clocks anymore :D
23:32 tobijk: *can't
23:32 karolherbst: ....
23:32 karolherbst: I don't tough legacy software anyway
23:32 karolherbst: and in kde anything <5 is legacy
23:33 tobijk: ksysguard 5.10.5 that would be :>
23:33 tobijk: i meant kernel 4.13 :>
23:33 karolherbst: I see
23:33 karolherbst: well it doesn't list the sensors for me
23:34 tobijk: oh i actually have a nouveau sensor
23:34 tobijk: never noticed
23:34 karolherbst: ;)
23:35 tobijk: well, doesent work
23:35 karolherbst: we report quite a lot of stuff though hwmon