/srv/irclogs.ubuntu.com/2015/08/24/#ubuntu-kernel.txt

=== Laney is now known as Guest65212
=== Guest65212 is now known as Laney
tseliotapw: would it be possible to update linux-firmware to include the amdgpu firmware? (Linux 4.2 needs it for the amdgpu driver)12:47
rtgtseliot, sforshee is the firmware dude these days12:57
tseliotrtg: ok, thanks, let's see what sforshee says. Thanks12:57
sforsheetseliot: where is this firmware? I don't see anything in upstream linux-firmware that we don't already have.13:27
tseliotsforshee: it's all here: http://people.freedesktop.org/~agd5f/radeon_ucode/13:31
tseliotsforshee: the firmware for amdgpu has to live in /lib/firmware/amdgpu/ (look for carrizo, tonga, and topaz on that page)13:35
sforsheetseliot: 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
sforsheetseliot: Why don't you send me a pull requests with the ones we need?13:37
tseliotsforshee: sure, where do you maintain linux-firmware?13:38
sforsheetseliot: git://kernel.ubuntu.com/ubuntu/linux-firmware.git13:38
tseliotsforshee: ok, thanks13:39
sforsheetseliot: btw you'll want to use the wily branch, master just tracks upstream13:41
rtgmjeanson, 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.615:00
rtg(for wily, that is)15:01
mjeansonrtg: 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 wily15:06
rtgmjeanson, that works for me15:06
mjeansonrtg: I 'd like to have a micro release exception for the next LTS, so we can properly support the HWE stacks15:13
apwmjeanson, that doesn't sound unreasonable15:15
rtgmjeanson, yeah, it would be nice if it at least compiled when a HWE kernel is installed15:15
rtgtseliot, is there an upstream repo for fglrx-installer ? I'm taking a look at the DKMS build issues15:19
rtgapw, do you have anything in the pipe for the -rc8 rebase ? I thought I'd get that uploaded to the PPA this morning.15:22
rtgassuming the test build succeeded15:23
apwrtg, no i have nothing, i'd test build it if i was you :)15:23
rtgapw, test build looks like it is OK except for ppc64el15:23
apwrtg, most likely the ppc64el will fail, the cross compiler is fooked15:24
rtgapw, any update on the ppc64el compiler problem ?15:24
apwthe current -5.5 did build ok, ignore the ppc64el RED thats just a lie15:24
rtgcool15:24
apwthere are _two_ one good one bad, so a new build should be fine with the compiler now in -release15:24
rtgack15:24
apwok15:27
rtgapw, fglrx-core appears to be working now. that should be the last of the DKMS failures taht we care about16:03
apwrtg, yeah i recon16:04
rtgapw, uploaded -6.6, so lets get it into the -proposed tomorrow16:04
apwrtg, once its built i'll do a final dkms run, then we sghould be good16:12
rtgapw, wfm16:13
tseliotrtg: if you mean the packaging scripts, then they are here: https://github.com/tseliot/fglrx16:17
tseliotrtg: the upstream scripts are here http://www.phorogit.com/index.php?p=fglrx-packaging.git16:17
rtgtseliot, nah, I was more looking for where the DKMS code bits are stored. However, fglrx-core appears to have started building OK.16:18
tseliotrtg: 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:25
rtgtseliot, it was failing to build on earlier rc's of 4.216:26
tseliotrtg: maybe I was checking version < 4.2 but things changed in 4.2, so that change didn't mean much16:28
tseliots/that change/that check/16:28
rtgtseliot, 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 rerun16:29
rtgtseliot, perhaps you could catch up with apw in your morning tomorrow16:29
tseliotrtg: yes, they must have changed struct fpu. It seems to be failing on i386. I'll have a look tomorrow16:31
rtgtseliot, ah, well I only tries amd6416:32
rtgtried*16:32
tseliotrtg: 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/16:32
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:08
bladernr_https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/148762118:12
ubot5Ubuntu bug 1487621 in linux-lts-utopic (Ubuntu) "Fails to boot on Macbook Air 2013 (Haswell)" [Undecided,New]18:12
davmor2bladernr_: Trusty still has an amd64_mac build for that.  That could be why, Stop with the 32bit love and join the 64bit revolution18:20
bladernr_hrmmm, I'm pretty sure that's what I installed from... hrmmm...18:21
davmor2bladernr_: I thought SMP was only available on 32bit I could be wrong18:22
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/Linux18:23
bladernr_what sucks is that I have a dual core Haswell i7 and can only use a single core/single thread :(18:24
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:25
apwbladernr_, have you tried an lts-vivid kernel ?  18:27
bladernr_apw: hrmm, no, I'm on utopic, let me try that and see what happens.18:29
apwbladernr_, as you are using an lts backport it seems sensible to take something with the newest h/w support18:32
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.18:33
bladernr_apw: no dice... vivid does the same.  19:07
apwbladernr_, 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 tip19:13
bladernr_yeah, I added ubuntu-lts-vivid as a task and updated a bit... I'll try mainline too19:14
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:37
bladernr_apw: ok, so 4.2.0 rc8 does boot in SMP mode19: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 accordingly19:45
apwbladernr_, there is an ubuntu-ized version of that pending for wily in the canonical-kernel-team PPA which might work better with bcmwl20:30
=== JanC_ is now known as JanC
hallyn_haven't see nthis before - got some of these:  http://paste.ubuntu.com/12187270/21:21
hallyn_when my laptop completely hung21:21
hallyn_had to alt-sysrq-b21:21
t3hStevehey 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
t3hSteveI'm on ubuntu 12.04, and I've seen it on both 3.8 and 3.13 kernels21:26
t3hStevecpuacct.usage seems correct however21:26
justicefrieshey! I'm looking for extras for 4.1.6 so I can use aufs for Docker. where are they located?22:05
justicefriesmaybe I'll just go overlay22:07
justicefriesunless they're just not up22:17

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!