[00:13] <melodie> good night
[00:15] <infinity> apw: Going through the xenial history ended up being one of those bisects we hate:
[00:15] <infinity> linux-image-4.2.0-19-powerpc64-smp_4.2.0-19.23_powerpc.deb -- good
[00:15] <infinity> linux-image-4.3.0-0-powerpc64-smp_4.3.0-0.9_powerpc.deb -- bad
[00:15] <infinity> apw: So, yay, that's a huge chunk to drill through between them still.
[00:16] <apw> man o man that is a lovely one
[00:17] <apw> we likely have mailine builds in between but it will turn out to be -rc1
[00:20] <infinity> Probably.
[00:22] <infinity> I still need to understand why that ISO didn't work.
[00:22] <infinity> Or maybe I don't need to, because it doesn't make sense.
[00:35] <infinity> apw: https://git.kernel.org/linus/f15838e9cac8f78f0cc506529bb9d3b9fa589c1f
[00:37] <infinity> apw: Please to cherrypick, thanks.
[00:43] <infinity> apw: Pretty please.
[00:49] <infinity> Based on the CC, I'd assume it'll come in via Greg's tree "sometime", but I'd rather that be now. :P
=== BenC_ is now known as BenC
[05:04] <hallyn> lol i've not had a /. account in 15 years, but they found me for their we 've been bought ut email
[05:10] <hallyn> but so i guess my thought wasn't to paper over bugs in the lxc monitor, but rather to make sure you can still list containers and figure out what's going on
[05:13] <hallyn> all right lemme set up a clean system and see if the guy's recipe works for me.  (thogh it seems unlikely)
[05:24] <hallyn> guess i'll leave this running for a few hours.  no hang so far.
[05:34] <stgraber> hallyn: I think you meant for ^ to go to #lxc-dev :)
[06:14] <hallyn> doh
[06:14] <hallyn> my channels done moved
[09:05] <apw> infinity, ack
[09:07] <apw> b 7
[10:32] <caribou> apw: from what I can gather, DASD kernel dump is not triggered automatically but requires operator intervention
[10:51] <apw> caribou: ahh ok, such is life then
[11:46] <cpaelzer> caribou: apw: https://github.com/qemu/s390-tools/blob/master/etc/sysconfig/dumpconf
[11:46] <cpaelzer> caribou: apw: I don't know if we have this in our s390-tools/utils package yet
[11:46] <cpaelzer> caribou: apw: but in genereal one can set dump-on-panic instead of operator intervention
[12:01] <apw> cpaelzer, oh thats better indeed
[12:02] <cpaelzer> apw: yeah, testers usually configure that as step #1 to capture anything that might happen
[12:26] <apw> caribou, did you get access to that s390x instance yet ?  if so would you be able to get me a dmesg off it (for an unrelated bug)
[12:27] <caribou> apw: I should still have access to xnox's instance, lemme check
[12:30] <caribou> apw: just emailed it to you
[12:33] <apw> caribou, thanks
[13:43] <Odd_Bloke> When will linux-hwe-{generic,virtual}-trusty stop pointing at linux-image-{generic,virtual}-lts-utopic?
[13:47] <apw> Odd_Bloke, weeeeel it should alread point to -lts-vivid, but perhaps that ship has sailed
[13:48] <apw> bjf, ^ we should prolly make a plan on how that changes, what the criteria is
[14:32] <apw> xnox, as this could be host tools fooking up the key or the kernel fooking up the key, i have built a cross compiled kernel which would therefore have used the x86 userspace to build the key... would you be able to boot the s390x kernel here sometime:  http://people.canonical.com/~apw/master-next-xenial/
[14:49] <infinity> apw: It should probably change at the same time as point releases go out (since that's when we officially recommend people use the newer HWE stack), but clearly that's not been happening. :P
[14:50] <apw> infinity, right i think the same official position, which did not occur for -v
[14:58] <infinity> apw: Nor -w.
[15:00] <apw> oh yeah, whoops
=== caribou_ is now known as caribou
[17:21] <xnox> apw, BAD
[17:21] <xnox> [    0.687893] Problem loading in-kernel X.509 certificate (-74)
[17:21] <xnox> Linux DEVAC02 4.4.0-14-generic #30~masternext201603151358 SMP Tue Mar 15 13:59:23 UTC 2016 s390x s390x s390x GNU/Linux
[17:21] <apw> ok so not likely to be userspace tools breaking it as those were HOST compiled in that build
[17:22] <xnox> apw, i have rhel system that loads the keys fine...
[17:23] <xnox> apw, here is the config from it http://paste.ubuntu.com/15393512/ if that at all relevant.
[17:25] <xnox> i don't see anything....
[17:26] <apw> xnox, no indeed, i'll start adding debug, i can see nothing obvious
[17:27] <xnox> apw, anyway i can make things faster for you? would you want an ubuntu libvirt-qemu VM or some such?
[17:27] <apw> xnox, if you are happy to test kernels that works for me
[17:27] <xnox> apw, ok =)
[17:29] <xnox> apw, any point in me fetching and trying an older kernel (e.g. 4.3) to check if things used to work back then?
[17:31] <apw> xnox, yep, thats is a good idea, find me a first broke if you can
[17:31] <apw> and i'll add some printks
[17:42] <apw> xnox, ok first debug: http://people.canonical.com/~apw/lp1557250-xenial/
[18:10] <xnox> apw, call trace at http://paste.ubuntu.com/15393871/
[18:10] <xnox> load_system_certificate_list
[18:10] <xnox> or do you want more things from console too?
[18:11] <apw> [    0.678674] preparse -> ret=-74
[18:11] <apw> that is the info i wanted, the call trace it the new bits tim added, so we find out this is happening in the wild if it comes back
[18:11] <apw> rtg, your warn_on_once is working
[18:13] <rtg> apw, getting some stack traces ?
[18:14] <apw> rtg, yep, on s390x where we know it is broke
[18:14] <rtg> apw, did you find any encryption configs that need enabling ?
[18:15] <apw> rtg, nope, still debugging it with xnox
[18:16] <xnox> rtg, yeah no configs diff that we can spot (i compared with e.g. rhel config where certs are loaded)
[18:17] <xnox> apw, is there any vanilla kernel i can try, to see if things are dire upstream? (but i guess we kind of know that now...)
[18:18] <apw> xnox, for s390x ?  no
[18:24] <xnox> ok, i got to go =(
[18:24] <xnox> apw, talk to you later.
[18:25] <apw> xnox, no worries, i'll shove you a new debug kernel and you can get to it when you do
[18:25] <TJ-> is there any plan to include trim/discard support in the zfs driver?
[18:35] <apw> TJ-, is there a bug associated with that ?
[18:35] <apw> so i can check
[18:35] <TJ-> on Launchpad, or on the ZFSonLinux project?
[18:36] <TJ-> I've been following the upstream work and the merge proposal *finally* looks to be ready: https://github.com/zfsonlinux/zfs/pull/3656
[18:37] <apw> xnox, there is a new debug kernel in the same place ... have fun
[18:37] <apw> TJ-, if its not a standard feature i am not expecting it to be something on our radar at this time, this being the first lts with this in, its not clearly its a good plan to have anything experimental in there
[18:38] <TJ-> apw: right; it might be worth flagging up in prominent docs about lack of discard/trim support for those that are intending deploying it to SSD systems
[18:39] <TJ-> especially as a major use-case appears to be for supporting containers etc.
[18:39] <apw> TJ-, i am sure anyone buying into zfs would know, but possible i guess
[19:18] <jdstrand> jsalisbury: fyi, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1547619/comments/28
[19:18] <ubot5> Launchpad bug 1547619 in linux (Ubuntu Xenial) "Intermittent screen blinking with 4k external mini display port with 4.4 kernels" [Medium,In progress]
[19:19] <jdstrand> jsalisbury: that is *not* the one you mentioned in #27, but rather the one from #24
[19:32] <jsalisbury> jdstrand, thanks for the update.  I'll build the next test kernel
[19:36] <jdstrand> thanks!
[20:38] <smoser> hey
[20:38] <smoser> how much do we care ?
[20:39] <ohsix> 4
[20:39] <smoser> out of 9 ohsix 
[20:39] <smoser> http://paste.ubuntu.com/15395889/
[20:40] <smoser> how much do we care about the stacktrace above ^
[20:40] <smoser> coupled with host kernel dmesg http://paste.ubuntu.com/15395901/
[20:40] <smoser> that is trusty on xenial through vagrant. 
[20:41] <smoser> in the guest this would cauase a hang: cat /proc/8248/cmdline
[20:43] <smoser> rtg, ^ ? i suspect its "not much".
[20:46] <apw> smoser, is taht really on 3.13.0-32 ?  thats like 50 releases behind
[20:46] <rtg> smoser, it is hard for us to do much with vbox
[20:47] <apw> and we had known issues with vbox back in the old days
[20:47] <apw> smoser, why is it booting such an old kernel anyhow ?
[20:47] <smoser> apw, that is a good point.
[20:47] <smoser> the user was booting that old kernel because they did an iso instll (through a tool called packer) 
[20:48] <smoser> and the only isos that install a 3.13 get you that level
[20:48] <apw> hrm, so they may have a bit of a chicken/egg issue
[20:50] <smoser> yeah, could be. but in this case it wasnt the intsaller trying to install a newer kernel. the vagrant box that was published had the very old kernel there.
[21:49] <apw> and this is why the pre-canned binary form for things is not a good idea
[23:08] <apw> tjaalton, isnt broadwell supposed to used thei915 you added ??
[23:08] <apw> tjaalton, does not on my lappy
[23:09] <infinity> Is it?  I thought the i915 backport was for skylake.
[23:13] <apw> i think i saw tjaalton say it was for more than skylake