[00:59] <srp> howdy. Is there any way to compare kernel config params (i.e. the CONFIG_ bits in config-<kernel-version>) between two different versions?
[01:00] <srp> other than writing a program to do so or comparing by hand, I meant
[06:19] <gerald_> q
[07:58] <apw> srp (N,BFTL), not really, mostly by writing comparitors
[10:02] <leighman> hey, trying to load a backported drm module on 14.04 using dkms but it says it is tainted
[10:02] <leighman> is this to do with signing? can I enable signing somehow?
[10:02] <leighman> taint code is 4098
[10:02] <leighman> drm and i915 module
[10:17] <apw> leighman, i think  it tells you why when  it taints, in dmesg
[10:17] <apw> though it is very likley them not being signed is what it says
[10:18] <apw> you cannot sign external modules as the key used to sign internal modules has been destroyed deliberatly
[10:18] <apw> why do you care that it is tainted
[10:18] <leighman> apw: it disables trace events
[10:19] <leighman> due to http://lwn.net/Articles/588799/ I think?
[10:20] <leighman> /proc/.../tainted gives 4098
[10:20] <leighman> which seems to be TAINT_OOT_MODULE and TAINT_FORCED_MODULE
[10:20] <leighman> TAINT_FORCED_MODULE causing trace events to be disabled as in the lwn article
[10:20] <leighman> so I think I might be out of luck?
[10:22] <leighman> but eg. vboxdrv does not appear in modinfo to be signed but is not listed as tainted
[10:23] <apw> no idea how vbox would avoid that, unless it specifically messes with those flags somehow
[10:23] <apw> leighman, it sounds like you have a valid usecase for the patch mentioned, no idea how ugly it would be to port
[10:24] <apw> you might want to start a bug on this against "linux" so we can consider fixing that
[10:24] <apw> as we have a lot of OOT modules which tracing sounds useful in
[10:24] <apw> actually the patch looks pretty self contained, so it might be applicable
[10:24] <apw> leighman, ^
[10:26] <leighman> does look like a nice simple patch actually *he says*
[10:26] <leighman> okay, will file a bug against linux and subscribe you?
[10:28] <leighman> apw: ^
[10:30] <apw> let me know the bug # here as i won't find it otherwise
[10:31] <soren> smb: Thanks for looking into https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1358162
[10:31] <soren> smb: I have a small request, though.
[10:32] <soren> smb: Here's that patch I applied to handle it: https://github.com/JioCloud/contrail-vrouter/commit/c31ab9b1d05acb6814a3ee8ddda16882cdcc0672
[10:33] <soren> smb: After your patch gets applied, skb_get_rxhash will be #defined twice.
[10:33] <apw> then i suggest you make yours say
[10:33] <apw> #ifndef foo
[10:33] <soren> smb: What would you suggest? A more specific KERNEL_VERSION (does that even change between kernel revisions in Ubuntu)?
[10:33] <apw> #define foo
[10:34] <soren> apw: That's what I was meaning to do, but I wasn't sure if that'd be sufficient (since it depends on import order).
[10:34] <apw> in the version check?
[10:34] <apw> soren, though this new version will be a new ABI i am sure
[10:34] <apw> (our new version)
[10:35] <soren> apw: How does that help me?
[10:35] <apw> you know you only need the compat for that one abi
[10:35] <soren> apw: Anyway, what I was wondering was if you could wrap your #define in #ifdef as well... Or am I completely off here?
[10:36] <soren> apw: ...so that it won't depend on a specific order of #include's.
[10:36] <leighman> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1359670
[10:36]  * apw suspects if anything we should #undef it
[10:36] <soren> apw: I dunno. It might not be a problem at all. I just saw the change and wasn't sure if #ifndef'ing on my side would be sufficient.
[10:43] <apw> soren, might not, i think you are lucky in that it has not been uploaded yet.  I suspect for us we should #undef before defining it to be sure we are getting what we expect.
[10:43] <apw> smb, ^
[10:44] <soren> apw: I was exactly hoping to get this addressed before the upload.
[10:44] <soren> apw: Thanks for considering it.
[10:46] <apw> leighman, i assume this is 14.04 which is giving you trouble
[10:46] <leighman> apw: yup
[11:07] <apw> leighman, ok i've pushed some test kernels to your bug, if you could do the do on those.
[11:35] <leighman> apw: is there a linux-tools-3.13.0-35  - I get unsatisfiable dependency on linux-tools-3.13.0-35-generic
[11:36] <leighman> apw: anyway taint bitmask looks correct and no messages in dmesg about disabling tracepoints
[11:36] <apw> leighman, that is good enough for me, i'll push that out for review
[11:38] <leighman> apw: awesome, thanks
[11:38] <leighman> apw: when would it land if so?
[11:40] <apw> if accepted, in the next SRU round, of the order of 3 weeks
[11:41] <leighman> apw: cool,thanks
[17:14] <rtg> stgraber, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1344049/comments/3