=== mamarley is now known as Guest22518
=== mamarley_ is now known as mamarley
=== yofel_ is now known as yofel
[13:40] <rtg> cyphermox, should be all the UEFI kernels you need in ppa:canonical-kernel-team/unstable
[13:41] <cyphermox> ack
=== adrian is now known as alvesadrian_
=== alvesadrian is now known as adrian
=== alvesadrian_ is now known as alvesadrian
[18:22] <hallyn> hey - apparently during the previous decade quite a few people were doing kernel modules to help find/blacklist bad memory.  Did anything become 'standard' in the ubuntu kernel?
[18:22] <hallyn> (i.e. badmem, badram, memmap, etc)
[18:34] <blue_coon> Q1 - Is there a slack channel for Ubuntu kernel dev?
[18:35] <hallyn> i hope not
[18:35] <blue_coon> Q2. I'm having a hard time on the ubuntu pages pulling out the simple change log between 3.19.0-25-generic #26~14.04.1 & 3.19.0-33-generic #38~14.04.1
[18:36] <blue_coon> We have a kernel feature (tc qdisc) that failed on the 0-25 but work on the -33 and are trying to figure out why
[18:36] <blue_coon> So my first thought was to see if anything was checked in the kernel between those versions
[18:36] <blue_coon> but I'm struggling to find summary/announce page with the changes. 
[18:39] <blue_coon> and patches accepted on here http://patchwork.ozlabs.org/project/ubuntu-kernel/list/? stop at 2011
[18:41] <apw> blue_coon, you probabally want to look at the git repository respresnting the release
[18:47] <blue_coon> apw: haven't tried git yet
[18:47] <apw> blue_coon, otherwise any discussion would be on the kernel-team@ list
[18:48] <apw> and in its archives, though the git repo is more easily understood relative to release tags
[18:49] <blue_coon> any pointers to the git that would refer to the kernel with the naming I see? is 3.19.0-25 a branch somewhere?
[18:50] <blue_coon> Just searched for kernel and came up with a bunch of kernel gits on ubuntu git server
[18:51] <apw> blue_coon, which release are you looking for kernls for
[18:54] <blue_coon> 14.04.1
[18:54] <blue_coon> This is from uname on both of them: 3.19.0-25-generic #26~14.04.1 & 3.19.0-33-generic #38~14.04.1
[18:56] <blue_coon> So i intepret that as linux kernel 3.19 the generic config  on ubuntu 14.04.1. Not entirely sure what the #26 #38 refer to
[18:58] <rtg> blue_coon, you can decode a tag from thoe version numbers, e.g., Ubuntu-3.19.0-25.26 and Ubuntu-3.19.0-33.38
[18:58] <apw> so that then is the lts kernel
[18:58] <rtg> as well as find them in the commit subject
[18:58] <apw> and is in the trusty repository
[18:58] <apw> so ubuntu/ubuntu-trusty.git
[18:59] <blue_coon> Got it. Thx. 
[18:59] <hallyn> apw: do you know whatever happened to the 'badram' kernel patch?
[19:00] <apw> hallyn, i do not recall that patch no
[19:00] <hallyn> drat
[19:00] <rtg> hallyn, I have vague memories of that patch. What is the last kernel in which it appeared ?
[19:01] <hallyn> rtg: sigh it's even older thani was thinking - http://www.linuxjournal.com/article/4489?page=0,1  2001 apparently
[19:01] <hallyn> i'm just looking for something to lock out the bad ram until a new dimm or laptop magically arrives
[19:02] <rtg> wow, that is kind of a hack
[19:02] <hallyn> :)
[19:02] <hallyn> a useful hack
[19:03] <apw> hallyn, some arches let you say what regions of ram you do have, rather than just a size, not sure if that applied to i386
[19:03] <mjg59> hallyn: Nothing ever went mainline, but I believe you can pass a kernel command line that excludes a range
[19:04] <mjg59> hallyn: Ah yeah you can do it with memmap
[19:05] <mjg59> hallyn: memmap=1M$0xdeadbeef will reserve a megabyte at that address
[19:11] <hallyn> mjg59: thanks, yeah, i saw a few mentoins of that, wasn't sure (haven't rebooted yet) whether that was mainline or also old, since all mentions are circa 2008 :)
[19:12] <hallyn> the constant segvs have my mind a bit rattled, so trying to make sense of the memtester reviews :)
[19:12] <hallyn> uh, s/reviews/output/
[19:21] <hallyn> well the values reported by memtester change every time
[19:43] <cyphermox> rtg: the ppa will be missing the linux-meta-lts* packages too I think, since those probably need updating so upgrades work correctly.
[19:43] <blue_coon> There is no frustration greater than bad memory
[19:46] <rtg> cyphermox, you can't just install kernels by hand ? as soon as I upload a meta package they'll be out of date as the SRU cadence rolls forward
[19:55] <cyphermox> of course we can install by hand, but like I said if you want to make sure everything works, you can't just install by hand, you want to pick from the archive + PPA, upgrade, and see that all is well
[19:56] <cyphermox> I'll just do my own in my PPA
[20:11] <rtg> cyphermox, hmm, you'll probably run into linux-signed issues as well. dangit.
[20:12] <apw> rtg, linux-signed issues ?
[20:12] <rtg> apw, missing packages in the PPA 
[20:13] <rtg> guess I'd better do those to
[20:15] <cyphermox> right, kernel ought to be signed by some key; I can enroll the hash afterwards or something
[20:16] <rtg> cyphermox, alright, gimme a bit
[20:17] <apw> cyphermox, when the primary packages publish (linux) a key will be generated for the PPA is there is not yet one
[20:18] <rtg> cyphermox, you'll likely have to sign the kernels by hand (which is what I had to do for testing)
[20:19] <cyphermox> apw: indeed.
[20:19] <cyphermox> yeah, or I can extract the signature and add it in MokManager, I think
[20:23] <cyphermox> hrm, isn't linux-lts-wily supposed to not allow me to load a dkms module?
[20:24] <cyphermox> I just double-checked, shim validation is active here on trusty, and I install bbswitch-dkms, which loads fine (mentions tainting in dmesg, but is otherwise fine)
[20:25] <rtg> cyphermox, 'dmesg|grep Secure'
[20:26] <cyphermox> nothing
[20:26] <rtg> then secure boot is not enabled
[20:26] <cyphermox> I'm running 4.2.0-38-generic
[20:26] <cyphermox> err, it is
[20:26] <cyphermox> I trust the BIOS more than the kernel on this matter.
[20:26] <JanC> hallyn: if the location changes, it can also be a memory controller / motherboard issue... (I hope not!)
[20:27] <rtg> cyphermox, not so far as the kernel is concerned. lemme get my laptop fired up which has those virt instances installed
[20:28] <cyphermox> ok
[20:28] <hallyn> JanC: yeah, that's hwy i haven't bought new ram just yet - i'm thinking it might be that. 
[20:29] <hallyn> for now i juts booted with mem=8G and actually no crashes yet.  will see how that goes through the day
[20:29] <hallyn> (i was working in an incredibly dusty environment last week - it's possible i can just blow some compressed air around and get it stable again, but doubt it)
[20:30] <rtg> cyphermox, in fact, gimme until tomorrow and I'll run through all of these packages again and make sure they are right.
[20:30] <cyphermox> ok
[20:31] <cyphermox> that was for trusty
[20:31] <cyphermox> xenial looked good before, but I'm going to get back to it now to re-check everything
[20:40] <rtg> cyphermox, ok, all of the Trusty linux-meta and linux-signed variants have been upload to ppa:canonical-kernel-team/unstable
[20:41] <cyphermox> ack