| melodie | good night | 00:13 |
|---|---|---|
| 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:15 |
| apw | man o man that is a lovely one | 00:16 |
| apw | we likely have mailine builds in between but it will turn out to be -rc1 | 00:17 |
| infinity | Probably. | 00:20 |
| 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:22 |
| infinity | apw: https://git.kernel.org/linus/f15838e9cac8f78f0cc506529bb9d3b9fa589c1f | 00:35 |
| infinity | apw: Please to cherrypick, thanks. | 00:37 |
| infinity | apw: Pretty please. | 00:43 |
| 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 | 00:49 |
| === BenC_ is now known as BenC | ||
| hallyn | lol i've not had a /. account in 15 years, but they found me for their we 've been bought ut email | 05:04 |
| 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:10 |
| hallyn | all right lemme set up a clean system and see if the guy's recipe works for me. (thogh it seems unlikely) | 05:13 |
| hallyn | guess i'll leave this running for a few hours. no hang so far. | 05:24 |
| stgraber | hallyn: I think you meant for ^ to go to #lxc-dev :) | 05:34 |
| hallyn | doh | 06:14 |
| hallyn | my channels done moved | 06:14 |
| apw | infinity, ack | 09:05 |
| apw | b 7 | 09:07 |
| caribou | apw: from what I can gather, DASD kernel dump is not triggered automatically but requires operator intervention | 10:32 |
| apw | caribou: ahh ok, such is life then | 10:51 |
| 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 | 11:46 |
| apw | cpaelzer, oh thats better indeed | 12:01 |
| cpaelzer | apw: yeah, testers usually configure that as step #1 to capture anything that might happen | 12:02 |
| 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:26 |
| caribou | apw: I should still have access to xnox's instance, lemme check | 12:27 |
| caribou | apw: just emailed it to you | 12:30 |
| apw | caribou, thanks | 12:33 |
| Odd_Bloke | When will linux-hwe-{generic,virtual}-trusty stop pointing at linux-image-{generic,virtual}-lts-utopic? | 13:43 |
| apw | Odd_Bloke, weeeeel it should alread point to -lts-vivid, but perhaps that ship has sailed | 13:47 |
| apw | bjf, ^ we should prolly make a plan on how that changes, what the criteria is | 13:48 |
| 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:32 |
| 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:49 |
| apw | infinity, right i think the same official position, which did not occur for -v | 14:50 |
| infinity | apw: Nor -w. | 14:58 |
| apw | oh yeah, whoops | 15:00 |
| === caribou_ is now known as caribou | ||
| 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:21 |
| xnox | apw, i have rhel system that loads the keys fine... | 17:22 |
| xnox | apw, here is the config from it http://paste.ubuntu.com/15393512/ if that at all relevant. | 17:23 |
| xnox | i don't see anything.... | 17:25 |
| apw | xnox, no indeed, i'll start adding debug, i can see nothing obvious | 17:26 |
| 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:27 |
| 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:29 |
| 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:31 |
| apw | xnox, ok first debug: http://people.canonical.com/~apw/lp1557250-xenial/ | 17:42 |
| 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:10 |
| 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:11 |
| rtg | apw, getting some stack traces ? | 18:13 |
| 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:14 |
| apw | rtg, nope, still debugging it with xnox | 18:15 |
| xnox | rtg, yeah no configs diff that we can spot (i compared with e.g. rhel config where certs are loaded) | 18:16 |
| 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:17 |
| apw | xnox, for s390x ? no | 18:18 |
| xnox | ok, i got to go =( | 18:24 |
| xnox | apw, talk to you later. | 18:24 |
| 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:25 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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 | 18:39 |
| 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:18 |
| jdstrand | jsalisbury: that is *not* the one you mentioned in #27, but rather the one from #24 | 19:19 |
| jsalisbury | jdstrand, thanks for the update. I'll build the next test kernel | 19:32 |
| jdstrand | thanks! | 19:36 |
| smoser | hey | 20:38 |
| smoser | how much do we care ? | 20:38 |
| ohsix | 4 | 20:39 |
| smoser | out of 9 ohsix | 20:39 |
| smoser | http://paste.ubuntu.com/15395889/ | 20:39 |
| 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:40 |
| smoser | in the guest this would cauase a hang: cat /proc/8248/cmdline | 20:41 |
| smoser | rtg, ^ ? i suspect its "not much". | 20:43 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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. | 20:50 |
| apw | and this is why the pre-canned binary form for things is not a good idea | 21:49 |
| apw | tjaalton, isnt broadwell supposed to used thei915 you added ?? | 23:08 |
| apw | tjaalton, does not on my lappy | 23:08 |
| infinity | Is it? I thought the i915 backport was for skylake. | 23:09 |
| apw | i think i saw tjaalton say it was for more than skylake | 23:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!