=== zyga-afk is now known as zyga
[10:20] <jsalisbury> bdmurray, Upstream replied with a recently found work around for bug 1436940 .  However, it's not the most elegant solution.  It requires booting with unofficial windows-extracted firmware images.  More info in comment #20 of bug. 
[10:20] <ubot5> bug 1436940 in linux (Ubuntu Wily) "Atheros wifi 168c:0041(QCA6164) is not supported" [Medium,Confirmed] https://launchpad.net/bugs/1436940
[10:35] <jsalisbury> bdmurray, well that was fast.  There is now real firmware here: https://github.com/kvalo/ath10k-firmware/commit/7f7e7dda33676ced293de477b03711199ffe5256  I'll update the bug report.
[11:07] <tseliot> apw: how do I find out what (upstream) kernel release linux 3.19.0-26 is based on? (I need to add a check in my kernel code for fglrx)
[11:09] <apw> tseliot, http://people.canonical.com/~kernel/info/kernel-version-map.html
[11:21] <tseliot> apw: thansk
[11:21] <tseliot> *thanks
[11:31] <tseliot> apw: so 3.19.0-26 = 3.19.8-ckt2, but how do I use that with the KERNEL_VERSION macro?
[11:31] <apw> oh you can't
[11:31] <apw> don't be sillly converting to a number broke you
[11:32] <tseliot> apw: apparently 3.19.0-25 -> 3.19.0-26 made a symbol gpl-only
[11:32] <apw> to a ckt-N name, well and that it is in 4th
[11:32] <apw> welll you can tell -25 and -26 apart
[11:32] <tseliot> how?
[11:32] <apw> UTS_UBUNTU_RELEASE_ABI
[11:33] <apw> which is defined in the same place as you get other versions from
[11:33] <apw> you want something like
[11:33] <apw> #ifdef UTS_UBUNTU_RELEASE_ABI
[11:33] <apw> #define UBUNTU_VERSION KERNEL_VERSION * 100 + UTS_UBUNTU_RELEASE_ABI
[11:33] <apw> #else
[11:33] <apw> #define UBUNTU_VERSION KERNEL_VERSION * 100
[11:33] <apw> #endif
[11:33] <apw> or something
[11:34] <apw> 100 isn't enough i expect
[11:36] <tseliot> I think checking the Ubuntu ABI would be enough. So, if none is available I can define the ABI as 0
[11:36] <tseliot> and check the kernel version
[11:37] <tseliot> ok, that helps
[11:37] <tseliot> thanks
[11:39] <apw> yeah
[11:39] <apw> tseliot, yeah thats why we don't provide accessors, as you have to check they exist and provide your own if no
[11:39] <apw> as you can't assume we are ubuntu, ugg
[11:39]  * tseliot nods
[16:00] <tseliot> apw: are you sure that UTS_UBUNTU_RELEASE_ABI is available in the lts-vivid kernel?
[16:00] <tseliot> I'm doing this:
[16:00] <tseliot> #ifndef UTS_UBUNTU_RELEASE_ABI
[16:00] <tseliot> #define UTS_UBUNTU_RELEASE_ABI -1
[16:00] <tseliot> #endif
[16:00] <tseliot> #if UTS_UBUNTU_RELEASE_ABI < 0
[16:01] <tseliot> and that always seems to be true
[16:02]  * tseliot clones the git repository...
[16:03] <apw> debian/rules.d/2-binary-arch.mk:        echo "#define UTS_UBUNTU_RELEASE_ABI $(abinum)" >> $(hdrdir)/include/generated/utsrelease.h
[16:03] <tseliot> hmm...
[16:04] <apw> /usr/src/linux-headers-3.19.0-14-generic/include/generated/utsrelease.h:#define UTS_UBUNTU_RELEASE_ABI 14
[16:05] <apw> and there it is in a 3.19 i have installed
[16:05] <tseliot> ok
[16:05] <apw> so unless it is getting lost in the lts-backport, which is pretty unlikely
[16:06] <tseliot> I can see it here. Do I have to include that header or is that already exported?
[16:07] <apw> i thouoght if you included the one with KERNEL_VERSION it was incldued
[16:07] <apw> but perhaps not
[16:08] <tseliot> that would be a  bit of a problem
[16:09] <tseliot> as custom kernels won't have utsrelease.h
[16:10] <apw> why not ?
[16:10] <apw> its a standard include
[16:11] <apw> #define UTS_RELEASE "3.19.0-14-generic"
[16:11] <apw> #define UTS_UBUNTU_RELEASE_ABI 14
[16:11] <apw> it has the UTS_RELEASE string in it
[16:11] <apw> which would be 3.19.8-ckt3 normally
[16:12] <tseliot> my fix has to go into fglrx, and I need it to build against custom kernels that may not have that header
[16:13] <tseliot> if I add an #include in the fglrx code, it won't find the header in /usr/src/linux-headers-$(uname -r)/include/generated/
[16:15] <tseliot> apw: oh, wait, fglrx already does that
[16:16] <tseliot> except they get it wrong
[16:16] <tseliot> as they include it only #ifndef UTS_RELEASE
[16:17] <tseliot> no they don't
[16:17] <tseliot> ok
[16:18] <tseliot> it's included in the wrong file
[16:23] <tseliot> apw: problem solved :)
[16:54] <dkessel> i want to run the trusty kernel version (3.13) on my vivid and wily installations. is there an easy way of doing that?
[16:58] <dkessel> i have the problem that power saving is properly working with the trusty kernel, but with vivid and wily's kernels, only one "performance" and "powersave" governors seem to be available. and "powersave" uses more power than in trusty, which i notice because the fan is working all the time, instead only when doing cpu-intensive tasks
[17:06] <ohsix> that could just be a matter of the fan never going off, and those governors are going to be separate from thermal policy stuff thaty may have also changed
[17:07] <ohsix> are you looking at powertop to see if more power is actually being used? (disregarding just fan being on uses more)
[17:17] <apw> dkessel, no easy way of doing that no, we do not assume compatibility in that direction
[17:19] <dkessel> okay. ok, so i did some more searching and found that disabling intel_pstate works for me, as i found in bug 1188647
[17:19] <ubot5> bug 1188647 in linux (Ubuntu) "Please change intel_pstate default to disable" [High,Fix released] https://launchpad.net/bugs/1188647
[17:20] <dkessel> kernel 4.1.0-3 does not work good without disabling it
[17:22] <dkessel> do you think i should collect some more information and file a bug? (yes, i have read the channel topic....)
[17:28] <apw> dkessel, yes you should file a bug indeed if pstate_idle is breaking you on 4.1, it should be "purfect" by now
[17:28] <apw> dkessel, ubuntu-bug linux so we get appropriate h/w info
[17:34] <dkessel> ok, here's bug 1484616 . if i can provide any more info, try anything else, just tell me :)
[17:34] <ubot5> bug 1484616 in linux (Ubuntu) "pstate_idle is broken on 4.1, high fan speed when idle" [Undecided,New] https://launchpad.net/bugs/1484616
=== zyga is now known as zyga-afk