| kharnov | hi, is it known that the 64-bit builds aren't being uploaded to the mainline kernel PPA? | 02:04 |
|---|---|---|
| kharnov | for instance, the 4.2.4 release: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.2.4-unstable/ | 02:05 |
| TJ- | kharnov: Yes, there's build failures | 02:23 |
| kharnov | oh, i see | 02:24 |
| kharnov | when they're fixed, will the missing packages be uploaded? | 02:24 |
| TJ- | kharnov: it's all automatic. You can see the build logs in the web-server directory | 02:24 |
| kharnov | oh, okay | 02:26 |
| kharnov | is the fix currently being worked on? | 02:26 |
| TJ- | I believe apw is looking at it | 02:27 |
| kharnov | okay, thanks | 02:28 |
| kharnov | the other thing i'm wondering, is: if i build the kernel locally, do i need to use the ubuntu configs? what happens if they aren't used? (i'm on ubuntu MATE) | 02:29 |
| kharnov | i built 4.2.4 myself and followed the instructions from the wiki page, including using the ubuntu configs | 02:29 |
| TJ- | It makes sense to use those configs, to ensure it doesn't surprise userspace :) | 02:30 |
| kharnov | ah | 02:30 |
| kharnov | what's the worst that could happen? :P | 02:30 |
| TJ- | You spend a few hours tracking down weird bugs? | 02:31 |
| TJ- | oh, sorry, that's the best. Worst is it eats the hard disk :D | 02:31 |
| kharnov | lol | 02:32 |
| kharnov | i'm new to this whole kernel building business but i'd like to learn more | 02:32 |
| kharnov | is it really possible to optimize performance by setting some kernel options before building? | 02:33 |
| TJ- | It can be a lot of fun, there's always something new to learn from the codebase | 02:33 |
| TJ- | Sure, remember the Ubuntu kernels are built to cover a very wide range of devices and CPUs. If you build for a single hardware specification you can likely configure to leave out stuff that it doesn't have, and use optimisations for things it does have but others don't | 02:34 |
| TJ- | I'm think of the hardware support for NI-AES crypto primitives | 02:34 |
| TJ- | There's lots of other similar features | 02:34 |
| kharnov | i wonder if anyone's made a script that compares your hardware to kernel options and suggests things that can be disabled that you don't use | 02:36 |
| TJ- | look at the kernel Makefile. There are some targets for matching the config to the host system although they've escaped my memory right now | 02:37 |
| kharnov | oh neat, i wasn't aware of that, thanks | 02:37 |
| kharnov | is it also possible to stop the debug symbol package from building? that thing takes an eternity | 02:38 |
| TJ- | That's part of the debian/rules targets; I think there's an ENV override for it | 02:40 |
| TJ- | kharnov: "skipdbg=true" for debian/rules.d/2-binary-arch.mk | 02:48 |
| kharnov | thanks! | 02:49 |
| Tobias_79 | Hi, I recently ran into a bug in the kernel OOM killer that repeadtedly caused complete system freezes when a cgroup went out of memory (trusty, kernel 3.13.0-66), the problem is described here: https://community.nitrous.io/posts/stability-and-a-linux-oom-killer-bug is there any chance that the fixes from kernel 3.14 will be backported to the trusty kernel? | 11:00 |
| apw | Tobias_79, if you have a clean set of commits needed to avoid the issue, and you have the ability to reproduce and confirm it fixed, then yes there is every chance. you would want to file a bug against the kernel "ubuntu-bug linux" and put all the details in it; and drop the number in here | 11:06 |
| apw | that will let us find out if they are on their way to stable etc and see whats waht | 11:07 |
| tseliot | apw: apparently the problem with fglrx dying in 15.10 is being caused by gcc 5 (or rather by the blob being incompatible with it, I imagine). Forcing gcc 4.9 is going to be ugly | 12:05 |
| apw | tseliot, oh goody | 12:05 |
| apw | that sounds like a whole heap of fun | 12:05 |
| tseliot | so, yes, the kernel patches were ok | 12:06 |
| apw | and if the calling convention is incompatible from gcc-5 code to the blob, then if you compile the gpl shim with gcc-4.9 it will be as incompatible with the kernel | 12:06 |
| tseliot | it actually seems to work here | 12:06 |
| apw | well that kinda is illogical | 12:07 |
| tseliot | I'm well beyond logic at this point | 12:07 |
| tseliot | there is a check in the fglrx driver that makes sure that you build with the same gcc version as the one used for the kernel | 12:08 |
| tseliot | but I clearly remember having to override that during the transition to gcc 5 | 12:09 |
| tseliot | (as, somehow, it complained about a mismatch) | 12:09 |
| apw | yeah though, really that is a scarey idea, as is proven by the fact you cannot use it to link to the blob | 12:09 |
| apw | but i guess if it "works" what can we do | 12:09 |
| tseliot | I'll see what the engineers at AMD say but, in the meantime, it would be good to have fglrx up and running on 15.10 again | 12:11 |
| apw | indeed | 12:11 |
| smb | bjf, henrix, kamal, jsalisbury, Looking at the daily incoming bugs today there seems to be some "hanging" in 4.2/wily that feels more prominent. One that involves the e1000e at least had some usable hint and I added a test kernel there. The rest I am not sure, yet | 12:25 |
| rtg | apw, I'm gonna sync Xenial zfs-dkms from upstream, then forward port the Wily ZFS patches to the Xenial kernel which should quite breaking your amd64 builds. | 13:16 |
| rtg | quit* | 13:16 |
| apw | rtg, i've pushed a fix to unstable for that, to let mainline builds turn it off | 13:16 |
| apw | rtg, also i have two fixes for linux-zfs to fix the two ftbfs's | 13:17 |
| rtg | apw, ok, I'm gonna have to rejigger the whole mess though | 13:17 |
| apw | the delta is applied in the bootstrap ppa i think | 13:17 |
| apw | rtg, why so ? | 13:17 |
| apw | remember that linux-zfs is being developed in sync with debian | 13:17 |
| apw | in step (not sync) | 13:17 |
| rtg | apw, config/build/install ordering is a bit different in Xenial then what it should be (IIRC) | 13:18 |
| apw | anyhow, assuming that you have do_zfs in the new way, then the bits i pushed to unstable should still work | 13:18 |
| apw | regardless of what you do to the patchy bits | 13:18 |
| rtg | apw, so who is upstream on zfs-dkms ? | 13:19 |
| rtg | I've just been following the upstream SPL/ZFS repos. | 13:20 |
| rtg | there are some patches there that will enable zfs-dkms to build against a 4.3 kernel | 13:20 |
| apw | rtg, that is a good question to which i have to refer you to cking, which doesn't work | 13:20 |
| apw | why are you trying to pull this zfs dkms bits back into wily btw, i thought the agreement was we used dkms in wily | 13:21 |
| rtg | apw, technology preview. some of the cloudy dudes thought it would be a good idea | 13:21 |
| rtg | besides, the zfs-dkms in Xenail wouldn't build against a 4.3 kernel | 13:22 |
| apw | rtg, its not clear we can pull in a new feature like that into wily without approval | 13:22 |
| rtg | apw, as a new driver in the kernel I believe it satisfies SRU | 13:23 |
| apw | rtg, i would expect we'd need to update linux-zfs in xenail yeah | 13:23 |
| rtg | apw, which is my plan for today | 13:23 |
| ogasawara | rtg: just to clarify, you're going to SRU some ZFS DKMS updates into Wily? | 13:39 |
| ogasawara | rtg: heh, I of course ping you right when you dropped...I just wanted to confirm/clarify, you're going to update zfs-linux (ie ZFS DKMS pacakge) for Xenial, and then SRU those same updates for zfs-linux in Wily? | 13:45 |
| rtg | ogasawara, I could, but shouldn't have to for quite awhile. at least not until Xenial becomes an LTS kernel. | 13:46 |
| rtg | ogasawara, I'll do it in Xenial zfs-dkms first, then backport them | 13:47 |
| ogasawara | rtg: ah, I understand it now. I was confused as to why you were updating bits for Wily. | 13:47 |
| ogasawara | rtg: although, I don't think you will have to SRU anything | 13:49 |
| ogasawara | rtg: because Wily won't have an HWE kernel, and I didn't think we were going to backport it to Trusty | 13:51 |
| ogasawara | rtg: if you want it in an LTS, you'd have to go with 16.04 | 13:51 |
| sforshee | rtg: do you know where this commit in linux-firmware came from? 27e49fa UBUNTU: SAUCE: ath10k: Add firmware | 14:32 |
| rtg | sforshee, checking | 14:33 |
| smoser | is there some doc on how someone would go *back* after having done: | 14:33 |
| smoser | sudo apt-get install linux-generic-lts-vivid | 14:33 |
| smoser | i can come up with it myself, but wondering if there is official documentation describing how to get back to the hwe-t kernel. | 14:34 |
| sforshee | rtg: it partially conflicts with some recent upstream stuff, so I'm wondering if I can just drop it | 14:34 |
| sforshee | but there's no hints as to where it came from or why we applied it | 14:35 |
| rtg | sforshee, I don't even know who committed it. | 14:35 |
| rtg | (though it likely was me) | 14:35 |
| sforshee | yeah, that was my guess :-) | 14:35 |
| rtg | smoser, none that I know of | 14:36 |
| sforshee | rtg: I guess I'll just email Kalle and find out what files we actually need | 14:37 |
| smoser | man. thats gonna be a mess to do too | 14:37 |
| rtg | smoser, is it a common case ? | 14:38 |
| smoser | probably not. but on ppc64el it could become more common. | 14:38 |
| smoser | as maas installs would end up with hwe-v (because "bare metal" really sucks with hwe-t, quite often not booting) | 14:39 |
| smoser | but kvm guests hwe-t is fine. | 14:39 |
| smoser | so i'd like to document how you'd get back to hwe-t in a sane fashion | 14:39 |
| smoser | sudo apt-get --purge remove "linux-(image|headers)-generic-lts-(utopic|vivid|wily).*" | 14:41 |
| smoser | seems maybe good | 14:41 |
| smoser | shoot. nope. | 14:42 |
| smoser | fwiw, the easiest thing i can come up with is: | 15:10 |
| smoser | sudo apt-get install linux-generic | 15:10 |
| smoser | sudo apt-get --purge remove "linux-(image|headers)-(3.16.0|3.19.0|4.2.0)-.*" | 15:10 |
| smoser | sudo apt-get autoremove | 15:10 |
| smoser | sudo reboot | 15:10 |
| smoser | the knowledge of kernel versions is annoying, but copy and paste does work. | 15:10 |
| leftyfb | smoser: FYI, PowerVM also fails with hwe-t | 15:25 |
| leftyfb | basically, 2 out of 3 modes for Power | 15:25 |
| smoser | doesnt really change anything. there is a supported set of use cases that we'd want to have hwe-t support. | 15:27 |
| smoser | leftyfb, does maas support installation of powervm ? | 15:28 |
| leftyfb | smoser: once the LPAR is created, I think newell has recently got that working, yes | 15:29 |
| infinity | smoser: FWIW, kvm guests are much happier with hwe-v too. | 15:40 |
| smoser | i have no experience of anything broken with hwe-t | 15:40 |
| infinity | smoser: Trust me, we have plenty of experience with 3.13 being less stable than 3.19 on the buildds. ;) | 15:40 |
| smoser | and if i were a "real user", i'd prefer 5 years support to much less. | 15:41 |
| infinity | Yes, there's that. But unless we can get all the 3.13 bugs fixed, 3.19 is definitely the better option right now. hwe-x will likely be the best option soon. | 15:41 |
| infinity | Well, "soon". | 15:41 |
| smoser | hwe-x is the point at which i think it becomes an easy decision. | 15:41 |
| infinity | In 6 months. | 15:42 |
| smoser | right. | 15:42 |
| smoser | august 2016. | 15:42 |
| smoser | right ? 8 months. | 15:42 |
| infinity | April 2016, if we do it right. | 15:42 |
| infinity | But sure. | 15:42 |
| infinity | Given it has to be in the archive well before I roll 14.04.5 with it. | 15:42 |
| smoser | true | 15:43 |
| infinity | smoser: Anyhow, was just a data point. I'm with you on prefering LTS kernels, but 3.13 definitely has some nasty bugs we and IBM have thus far failed to nail down. | 15:43 |
| smoser | is there a bug covering hwe-w arrival in archive ? | 15:43 |
| infinity | smoser: But they tend to only pop up under heavy and extended load (ie: buildd type usage). | 15:43 |
| infinity | smoser: hwe-w will be this week, probably. I'm on VAC, but there's only one round of review left before I think we're good to jam it in. | 15:44 |
| smoser | if thats true then i personally would wait https://bugs.launchpad.net/maas-images/+bug/1508565 on that. | 15:44 |
| ubot5 | Launchpad bug 1508565 in maas (Ubuntu) "maas uses 3.13 (hwe-t) kernel which does not work on non-virtual IBM power" [Undecided,New] | 15:44 |
| smoser | ie, jump to hwe-w rather than hwe-v. if it is available and known quantity | 15:45 |
| infinity | smoser: Maybe. 3.19 is well-tested and known-good. 4.2 only has the sort of light testing one gets during development, not any production beatings yet. | 15:45 |
| infinity | We probably should have smacked 4.2 around a bit in scalingstack, but getting scalingstack going at all by the deadline was already painful. | 15:46 |
| smoser | infinity, glad to see you're enjoying your vacation. | 15:47 |
| infinity | :P | 15:47 |
| infinity | I intend to go enjoy it in a few minutes. | 15:47 |
| smoser | i'm good to stick with hwe-v. | 15:47 |
| infinity | And then unenjoy it later. And enjoy it more later still. | 15:47 |
| infinity | smoser: FWIW, IBM's also pretty focussed on HWE kernels and point releases. As in, they ship point releases with HWE kernels on their hardware to customers, etc. So, I think we need to be even more on the ball about our strongly-worded upgrade messaging for 14.04.5/HWE-X than we were with 12.04.5/HWE-T. | 15:51 |
| infinity | smoser: And if we're getting all that right, I see no issues with maas installing hwe-* by default instead of the LTS kernel. | 15:51 |
| smoser | infinity, where does that go ? | 15:51 |
| smoser | i personally am probably never going to see a MOTD message | 15:51 |
| infinity | smoser: There was some update-manager stuff (obviously useless for servers), I think an update-motd snippet, etc. | 15:52 |
| smoser | and i'm *more* likely than to see that then the average "dev ops" person. | 15:52 |
| infinity | smoser: I think rbasak also wanted a nagios check/nag, but that might not have happened. | 15:52 |
| infinity | smoser: Plus we spam mailings lists, etc. | 15:52 |
| smoser | i dont have a good solution, but giving someone a kernel that has 9 months of support and not telling them tehy have to take action to get security upgrades is kind of less than ideal | 15:53 |
| infinity | smoser: Honestly, I'd rather just forcefully redirect metapackages to force the upgrade, but the last time that came up, Mark vetoed it. Maybe we can make a case. | 15:53 |
| infinity | smoser: I think it's irresponsible to leave them with no support and hope they get the message. A forced upgrade is the less bad of the two options, IMO. | 15:53 |
| smoser | i think that has some merrit. | 15:53 |
| smoser | merit. | 15:54 |
| smoser | however you spell that. | 15:54 |
| infinity | ogasawara, slangasek: ^-- I think you literally have a meeting about this very topic in 2 minutes. Do you want me to attend despite my VAC, or do you have it in hand? | 15:57 |
| ogasawara | infinity: I'm sure we'll be ok, you continue with your vacation | 15:59 |
| infinity | ogasawara: Check. | 15:59 |
| th3s3_3y3s | infinity, tell me something | 17:47 |
| th3s3_3y3s | where is the official ubuntu bttracker? | 17:47 |
| th3s3_3y3s | I want to find out why my release doesn't work the same way as the official docs expect. | 17:48 |
| th3s3_3y3s | Prudence can presume an official release o work as official docs expect. | 17:49 |
| apw | bttracker ? | 17:50 |
| th3s3_3y3s | bit torrent | 17:50 |
| apw | http://torrent.ubuntu.com:6969/ maybe ? | 17:51 |
| th3s3_3y3s | apw, it looks like not every official image is there | 17:55 |
| apw | that is possible indeed | 17:57 |
| th3s3_3y3s | apw, is it possible to use 'hybrid' mode graphics where the console ttys use framebuffer and the xserver display uses full graphics mode? | 18:03 |
| th3s3_3y3s | I don't want the ttys to be running on the xserver. | 18:03 |
| apw | i think that is normally how it works, we put a framebuffer on a vt, and then X switches the vt into graphics mode | 18:04 |
| apw | cirtinaly we don't use the X server to display vts other than the ones with X on them | 18:07 |
| infinity | Yeah, X has nothing to do with VTs. | 18:07 |
| infinity | Unless you're confusing "X" and "drm" where, indeed, most modern framebuffers are drm, but that's all kernelspace, nothing userspace, and no X. | 18:08 |
| infinity | s/drm/dri/? I forget where those APIs meet. | 18:08 |
| mjg59 | drm's the kernel side of things | 18:24 |
| th3s3_3y3s | apw, I can tell there is no graphics change when selecting a VT | 18:26 |
| th3s3_3y3s | Now sometimes there is a pause and the resolution changes. | 18:26 |
| apw | well that just means both use the same resolution | 18:26 |
| th3s3_3y3s | This switches instantly. | 18:26 |
| apw | that tells you little to nothing about what is driving it | 18:27 |
| th3s3_3y3s | Isn't this called modesetting? | 18:28 |
| th3s3_3y3s | So if I were to switch to a VT the mode of the GPU can go into text only. | 18:28 |
| th3s3_3y3s | text only is framebuffer right? | 18:28 |
| mjg59 | th3s3_3y3s: No | 18:28 |
| mjg59 | There's VGA text mode | 18:28 |
| mjg59 | Which is what you used to get on console VTs back in the bad old days | 18:29 |
| mjg59 | X used to do mode programming itself | 18:29 |
| th3s3_3y3s | There is a kernel source option for "hybrid" gpu's that do this I am guessing ubuntu opts to not use it. | 18:29 |
| mjg59 | th3s3_3y3s: Which kernel option? | 18:30 |
| th3s3_3y3s | It is called something like "hybrid graphics" | 18:30 |
| mjg59 | Hybrid graphics usually refers to systems with two GPUs | 18:31 |
| th3s3_3y3s | No this is for GPU's which have text only mode. | 18:31 |
| th3s3_3y3s | two GPU's is something that used to be done by hardware hackers and became built in | 18:32 |
| mjg59 | If you can find the precise option I can tell you more about it. But otherwise I'm afraid I don't know what you're talking about. | 18:32 |
| th3s3_3y3s | mjg59, I can look after the source directory is not in use. | 18:34 |
| th3s3_3y3s | It mentions something about hercules graphics cards as an example. | 18:35 |
| mjg59 | CONFIG_MDA_CONSOLE? | 18:38 |
| th3s3_3y3s | Is that what it explains? | 18:45 |
| th3s3_3y3s | Something that switches to text only mode. | 18:45 |
| mjg59 | No | 18:45 |
| th3s3_3y3s | The no. | 18:47 |
| th3s3_3y3s | s/the/then | 18:47 |
| th3s3_3y3s | Going to play quake while waiting for the kernel to compile. | 18:47 |
| th3s3_3y3s | Do you know how to get the hard secret on the first level? | 18:48 |
| MegaBrutal | Hi all! Could you please check bug 1509717? | 19:12 |
| ubot5 | bug 1509717 in linux (Ubuntu) "Wily LVM-RAID1 – md: personality for level 1 is not loaded" [Undecided,Confirmed] https://launchpad.net/bugs/1509717 | 19:12 |
| apw | MegaBrutal, that sounds like one of the dm modules is not in the initrd | 19:14 |
| apw | MegaBrutal, when in vivid what module is loaded for it | 19:14 |
| MegaBrutal | apw, how can I check that? lsmod? | 19:18 |
| MegaBrutal | apw, probably this one: raid1 40960 3 dm_raid | 19:20 |
| apw | MegaBrutal, well that is definatly missing in the 4.2 initrd | 19:23 |
| MegaBrutal | apw, that's no good. What is the solution? | 19:25 |
| apw | MegaBrutal, and they _are_ in /lib/modules ... so most likely an initramfs-tools issue | 19:26 |
| MegaBrutal | apw, who maintains initramfs-tools, who could add the module to initrd? | 19:28 |
| apw | MegaBrutal, i do | 19:28 |
| MegaBrutal | apw, then could you please triage this bug, and assign it to yourself, if you please? | 19:32 |
| MegaBrutal | apw, nothing, I see you already did. | 19:32 |
| quadrispro | jsalisbury, thanks for lp #1439111 | 19:40 |
| ubot5 | Launchpad bug 1439111 in linux (Ubuntu Wily) "Enable full touch support for ELAN0600 touchpad" [Medium,In progress] https://launchpad.net/bugs/1439111 | 19:40 |
| quadrispro | jsalisbury, works great | 19:40 |
| jsalisbury | quadrispro, np. I'm in the process of submitting an sru request for Vivid and Wily now. | 19:40 |
| quadrispro | 👍 cheers! | 19:41 |
| th3s3_3y3s | Why doesn't a kernel compile max out the CPU? | 19:55 |
| th3s3_3y3s | Has it to do with the number of threads? | 19:56 |
| apw | th3s3_3y3s, because compiling is a cpu and disk intensive activity, and it is bounded by whichever is slower | 21:02 |
| th3s3_3y3s | apw, usually it defaults to pipe | 21:18 |
| MegaBrutal | Does Ubuntu 15.10 support kernel live patching for the 4.2 kernel? | 22:39 |
| MegaBrutal | I find no information about this. I only know that 4.0 and newer kernels support live patching, but I heard nothing about how it is utilized by Ubuntu. | 22:40 |
| TJ- | MegaBrutal: "grep LIVEPATCH /boot/config-$(uname -r)" for confirming support; You might want kpatch to create a livepatch module itself. There's a reasonable guide at http://chrisarges.net/2015/09/21/livepatch-on-ubuntu.html | 22:53 |
| apw | being able to apply live patches is rather separate to the creation of them | 22:55 |
| MegaBrutal | So I need to manually make the patch. Many people expect it to work automatically, when you install a new kernel with apt. | 23:04 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!