[12:47] <tseliot> apw: would it be possible to update linux-firmware to include the amdgpu firmware? (Linux 4.2 needs it for the amdgpu driver)
[12:57] <rtg> tseliot, sforshee is the firmware dude these days
[12:57] <tseliot> rtg: ok, thanks, let's see what sforshee says. Thanks
[13:27] <sforshee> tseliot: where is this firmware? I don't see anything in upstream linux-firmware that we don't already have.
[13:31] <tseliot> sforshee: it's all here: http://people.freedesktop.org/~agd5f/radeon_ucode/
[13:35] <tseliot> sforshee: the firmware for amdgpu has to live in /lib/firmware/amdgpu/ (look for carrizo, tonga, and topaz on that page)
[13:37] <sforshee> tseliot: it seems that's all under the same license as the radeon firmware we already have, so I see no problem. Would be nice if they would get the stuff upstream ...
[13:37] <sforshee> tseliot: Why don't you send me a pull requests with the ones we need?
[13:38] <tseliot> sforshee: sure, where do you maintain linux-firmware?
[13:38] <sforshee> tseliot: git://kernel.ubuntu.com/ubuntu/linux-firmware.git
[13:39] <tseliot> sforshee: ok, thanks
[13:41] <sforshee> tseliot: btw you'll want to use the wily branch, master just tracks upstream
[15:00] <rtg> mjeanson, apw tells me that you've been working on lttng. I just uploaded lttng-modules_2.6.2-1ubuntu3 with support for Linux 4.2 by applying patches from git://git.lttng.org/lttng-modules.git stable-2.6
[15:01] <rtg> (for wily, that is)
[15:06] <mjeanson> rtg: great, we will probably release 2.6.3 and push it to debian once the 4.2 kernel is released but that may be too late for wily
[15:06] <rtg> mjeanson, that works for me
[15:13] <mjeanson> rtg: I 'd like to have a micro release exception for the next LTS, so we can properly support the HWE stacks
[15:15] <apw> mjeanson, that doesn't sound unreasonable
[15:15] <rtg> mjeanson, yeah, it would be nice if it at least compiled when a HWE kernel is installed
[15:19] <rtg> tseliot, is there an upstream repo for fglrx-installer ? I'm taking a look at the DKMS build issues
[15:22] <rtg> apw, do you have anything in the pipe for the -rc8 rebase ? I thought I'd get that uploaded to the PPA this morning.
[15:23] <rtg> assuming the test build succeeded
[15:23] <apw> rtg, no i have nothing, i'd test build it if i was you :)
[15:23] <rtg> apw, test build looks like it is OK except for ppc64el
[15:24] <apw> rtg, most likely the ppc64el will fail, the cross compiler is fooked
[15:24] <rtg> apw, any update on the ppc64el compiler problem ?
[15:24] <apw> the current -5.5 did build ok, ignore the ppc64el RED thats just a lie
[15:24] <rtg> cool
[15:24] <apw> there are _two_ one good one bad, so a new build should be fine with the compiler now in -release
[15:24] <rtg> ack
[15:27] <apw> ok
[16:03] <rtg> apw, fglrx-core appears to be working now. that should be the last of the DKMS failures taht we care about
[16:04] <apw> rtg, yeah i recon
[16:04] <rtg> apw, uploaded -6.6, so lets get it into the -proposed tomorrow
[16:12] <apw> rtg, once its built i'll do a final dkms run, then we sghould be good
[16:13] <rtg> apw, wfm
[16:17] <tseliot> rtg: if you mean the packaging scripts, then they are here: https://github.com/tseliot/fglrx
[16:17] <tseliot> rtg: the upstream scripts are here http://www.phorogit.com/index.php?p=fglrx-packaging.git
[16:18] <rtg> tseliot, nah, I was more looking for where the DKMS code bits are stored. However, fglrx-core appears to have started building OK.
[16:25] <tseliot> rtg: the kernel code is extracted from the installer (and made available in the tarball), then the packaging scripts install it, and DKMS applies the patches and build it. BTW what DKMS failures are looking into?
[16:26] <rtg> tseliot, it was failing to build on earlier rc's of 4.2
[16:28] <tseliot> rtg: maybe I was checking version < 4.2 but things changed in 4.2, so that change didn't mean much
[16:28] <tseliot> s/that change/that check/
[16:29] <rtg> tseliot, so this shows a build failure on 4.2-5.5 (http://people.canonical.com/~kernel/info/dkms/int-matrix.html), but I can't reproduce it. we'll see what the results are after -6.6 is done and the tests are rerun
[16:29] <rtg> tseliot, perhaps you could catch up with apw in your morning tomorrow
[16:31] <tseliot> rtg: yes, they must have changed struct fpu. It seems to be failing on i386. I'll have a look tomorrow
[16:32] <rtg> tseliot, ah, well I only tries amd64
[16:32] <rtg> tried*
[16:32] <tseliot> rtg: yes, that must be the problem. It shows a failure only on i386 here: http://d-jenkins.ubuntu-ci:8080/job/dkms-wily-release_canonical_kernel_team_ppa-generic-fglrx_core/30/
[18:08] <bladernr_> So anyone around know why I can't boot in SMP mode (ubuntu-lts-utopic on Trusty) on a Macbook Air (late 2013 Haswell i7)? 
[18:12] <bladernr_> https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1487621
[18:20] <davmor2> bladernr_: Trusty still has an amd64_mac build for that.  That could be why, Stop with the 32bit love and join the 64bit revolution
[18:21] <bladernr_> hrmmm, I'm pretty sure that's what I installed from... hrmmm...
[18:22] <davmor2> bladernr_: I thought SMP was only available on 32bit I could be wrong
[18:23] <bladernr_> Linux Bun-Bun 3.16.0-40-generic #54~14.04.1-Ubuntu SMP Wed Jun 10 17:30:45 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[18:24] <bladernr_> what sucks is that I have a dual core Haswell i7 and can only use a single core/single thread :(
[18:25] <bladernr_> and I think that is causing this thing to run hot as well, since it's not distributing the load across 4 CPU threads (that's a guess for now, but battery life is crap and it's running hot pretty consistently compared to OSX)
[18:27] <apw> bladernr_, have you tried an lts-vivid kernel ?  
[18:29] <bladernr_> apw: hrmm, no, I'm on utopic, let me try that and see what happens.
[18:32] <apw> bladernr_, as you are using an lts backport it seems sensible to take something with the newest h/w support
[18:33] <bladernr_> right, that makes sense to me... for some reason I don't recall, I wasn't able to install vivid when I updated this last time... I really don't recall why, but it is installing now, so I'll reboot when it's done and see what happens.
[19:07] <bladernr_> apw: no dice... vivid does the same.  
[19:13] <apw> bladernr_, bah, update the bug with that, and could you give the latest mainline kernel a test, 4.2-rc8 and lets see if its fix in tip
[19:14] <bladernr_> yeah, I added ubuntu-lts-vivid as a task and updated a bit... I'll try mainline too
[19:37] <bladernr_> apw: bug updated... mainline didn't want to fully install, it died on building bcmwl http://pastebin.ubuntu.com/12186541/ but it may have actually at least provided neough to boot, so I'll check that and come back shortly.
[19:45] <bladernr_> apw: ok, so 4.2.0 rc8 does boot in SMP mode
[19:45] <bladernr_> it choked on bcmwl (noted in the pastebin) but it did boot and saw all four cpu threads properly.  I updated the bug accordingly
[20:30] <apw> bladernr_, there is an ubuntu-ized version of that pending for wily in the canonical-kernel-team PPA which might work better with bcmwl
[21:21] <hallyn_> haven't see nthis before - got some of these:  http://paste.ubuntu.com/12187270/
[21:21] <hallyn_> when my laptop completely hung
[21:21] <hallyn_> had to alt-sysrq-b
[21:26] <t3hSteve> hey everyone, I have a question/observation/(bug?) related to cgroups + cpuacct reporting, I'm noticing that the usage reported by looking at cpuacct.stat is lower (~20%) than the CPU usage reported in by per-process reports (such as looking at top)
[21:26] <t3hSteve> I'm on ubuntu 12.04, and I've seen it on both 3.8 and 3.13 kernels
[21:26] <t3hSteve> cpuacct.usage seems correct however
[22:05] <justicefries> hey! I'm looking for extras for 4.1.6 so I can use aufs for Docker. where are they located?
[22:07] <justicefries> maybe I'll just go overlay
[22:17] <justicefries> unless they're just not up