=== mamarley is now known as Guest22518 | ||
=== mamarley_ is now known as mamarley | ||
=== yofel_ is now known as yofel | ||
rtg | cyphermox, should be all the UEFI kernels you need in ppa:canonical-kernel-team/unstable | 13:40 |
---|---|---|
cyphermox | ack | 13:41 |
=== adrian is now known as alvesadrian_ | ||
=== alvesadrian is now known as adrian | ||
=== alvesadrian_ is now known as alvesadrian | ||
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:22 |
blue_coon | Q1 - Is there a slack channel for Ubuntu kernel dev? | 18:34 |
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:35 |
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:36 |
blue_coon | and patches accepted on here http://patchwork.ozlabs.org/project/ubuntu-kernel/list/? stop at 2011 | 18:39 |
apw | blue_coon, you probabally want to look at the git repository respresnting the release | 18:41 |
blue_coon | apw: haven't tried git yet | 18:47 |
apw | blue_coon, otherwise any discussion would be on the kernel-team@ list | 18:47 |
apw | and in its archives, though the git repo is more easily understood relative to release tags | 18:48 |
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:49 |
blue_coon | Just searched for kernel and came up with a bunch of kernel gits on ubuntu git server | 18:50 |
apw | blue_coon, which release are you looking for kernls for | 18:51 |
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:54 |
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:56 |
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:58 |
blue_coon | Got it. Thx. | 18:59 |
hallyn | apw: do you know whatever happened to the 'badram' kernel patch? | 18:59 |
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:00 |
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:01 |
rtg | wow, that is kind of a hack | 19:02 |
hallyn | :) | 19:02 |
hallyn | a useful hack | 19:02 |
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:03 |
mjg59 | hallyn: Ah yeah you can do it with memmap | 19:04 |
mjg59 | hallyn: memmap=1M$0xdeadbeef will reserve a megabyte at that address | 19:05 |
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:11 |
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:12 |
hallyn | well the values reported by memtester change every time | 19:21 |
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:43 |
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:46 |
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:55 |
cyphermox | I'll just do my own in my PPA | 19:56 |
rtg | cyphermox, hmm, you'll probably run into linux-signed issues as well. dangit. | 20:11 |
apw | rtg, linux-signed issues ? | 20:12 |
rtg | apw, missing packages in the PPA | 20:12 |
rtg | guess I'd better do those to | 20:13 |
cyphermox | right, kernel ought to be signed by some key; I can enroll the hash afterwards or something | 20:15 |
rtg | cyphermox, alright, gimme a bit | 20:16 |
apw | cyphermox, when the primary packages publish (linux) a key will be generated for the PPA is there is not yet one | 20:17 |
rtg | cyphermox, you'll likely have to sign the kernels by hand (which is what I had to do for testing) | 20:18 |
cyphermox | apw: indeed. | 20:19 |
cyphermox | yeah, or I can extract the signature and add it in MokManager, I think | 20:19 |
cyphermox | hrm, isn't linux-lts-wily supposed to not allow me to load a dkms module? | 20:23 |
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:24 |
rtg | cyphermox, 'dmesg|grep Secure' | 20:25 |
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:26 |
rtg | cyphermox, not so far as the kernel is concerned. lemme get my laptop fired up which has those virt instances installed | 20:27 |
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:28 |
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:29 |
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:30 |
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:31 |
rtg | cyphermox, ok, all of the Trusty linux-meta and linux-signed variants have been upload to ppa:canonical-kernel-team/unstable | 20:40 |
cyphermox | ack | 20:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!