| === hughhalf_ is now known as hughhalf | ||
| === hughhalf is now known as hugh_afk | ||
| === hugh_afk is now known as hughhalf | ||
| === TooLmaN_ is now known as ToLmaN | ||
| === ToLmaN is now known as TooLmaN | ||
| === TooLmaN is now known as DaiBot | ||
| === DaiBot is now known as TooLmaN | ||
| === hughhalf is now known as hugh_afk | ||
| === hugh_afk is now known as hughhalf | ||
| === ohsix is now known as OHSIX | ||
| === OHSIX is now known as ohsix | ||
| apw | ramsudharsan (N,BFTL), i have a great many answers, no idea which one you want | 08:04 |
|---|---|---|
| Kano | hi, do you want to use 3.16 or 3.17 for 14.10? | 09:42 |
| apw | we will be using 3.16 for 14.10 | 09:44 |
| Kano | with hawaii backports? | 09:44 |
| Kano | i am thinking about using 3.17 from your unstable branch, after you rebased it | 09:45 |
| Kano | mesa 10.3 is very interesting | 09:46 |
| Kano | but needs 3.17 for latest amd hardware | 09:47 |
| apw | Kano, we will be keeping it rebased for sure, but it will likely skip from v3.17 to v3.18 quite quick | 09:57 |
| Kano | hm | 09:57 |
| Kano | well should not be hard to update it a bit on your own | 09:58 |
| binBASH | apw: you saw my updates on https://bugs.launchpad.net/bugs/1318551 ? | 10:00 |
| ubot5 | Launchpad bug 1318551 in linux (Ubuntu) "Kernel Panic - not syncing: An NMI occurred, please see the Integrated Management Log for details." [High,Confirmed] | 10:00 |
| apw | binBASH, the next logical step is to test the v3.8-rcN candidates between 3.7 and 3.8 to see if we can narrow it down | 11:27 |
| === TooLmaN_ is now known as TooLmaN | ||
| binBASH | apw: ok tested and it's also crashing @ 3.8-rc1 | 13:30 |
| apw | binBASH, the worst place ... | 13:48 |
| mlankhorst | also most likely place ;-) | 13:50 |
| binBASH | :-) | 13:50 |
| apw | binBASH, we need to do a proper bisect then between those, i'll ask a collegue to help with that | 13:53 |
| binBASH | ok | 13:54 |
| apw | binBASH, what i am proposing is this described here: https://wiki.ubuntu.com/Kernel/KernelBisection | 13:56 |
| === ghostcube_ is now known as ghostcube | ||
| tyhicks | rtg: Hi - thanks for processing all of the AA pull requests. When should we expect the generic kernel to migrate from proposed and new goldfish/mako/manta/flo kernels to be uploaded? | 14:27 |
| rtg | tyhicks, I'm still working on a goldfish build problem, but the rest could be pocket copied. rsalveti normally handles that. | 14:28 |
| tyhicks | rtg: I was unaware of a goldfish problem. Is it due to the AA pull request? | 14:28 |
| rtg | tyhicks, the generic kernel should migrate as soon as its added to the d-i | 14:29 |
| rtg | tyhicks, I think the goldfish build problem is unrelated, but I need to get back to it | 14:29 |
| tyhicks | ok | 14:29 |
| tyhicks | rtg: 'd-i'? | 14:29 |
| rtg | debian installer | 14:29 |
| tyhicks | ah | 14:29 |
| tyhicks | thanks :) | 14:29 |
| ricotz | rtg, hi :), i am curious will the kernel ppa receive some preview/testing packages of 3.17 for utopic? | 14:32 |
| tyhicks | rtg: one more question - who/what adds kernels to the debian-installer? | 14:32 |
| rtg | tyhicks, generally soneone in foundations, e.g., infinity (or sometimes apw) | 14:32 |
| rtg | ricotz, there is a mainline 3.17 build at http://kernel.ubuntu.com/~kernel-ppa/mainline/ | 14:33 |
| ricotz | rtg, ah, right, i meant proper builds with apparmor support likely based on http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-utopic.git;a=shortlog;h=refs/heads/unstable | 14:34 |
| tyhicks | ricotz: the kernel team doesn't provide that | 14:35 |
| tyhicks | ricotz: the security team will soon be in the process of upstreaming those apparmor patches | 14:35 |
| rtg | ricotz, the unstable branch will eventually morph into 15.04, but we won't start producing builds for it until after 14.10 is released | 14:36 |
| ricotz | tyhicks, ok, that is why i was asking tim since he is updating and rebasing this branch | 14:36 |
| ricotz | rtg, alright, thanks | 14:37 |
| === ev__ is now known as ev | ||
| === Guest26752 is now known as jpds | ||
| rsalveti | tyhicks: rtg: we should only promote those kernel packages once goldfish is also fixed, as we got apparmor related changes | 15:38 |
| rsalveti | but yeah, I'm taking care of testing and copying | 15:38 |
| jdstrand | I don't think they have to be all copied en masse | 15:38 |
| jdstrand | the goldfish kernel would continue functioning as it is now | 15:39 |
| rsalveti | jdstrand: otherwise the cache will be invalid for a few | 15:39 |
| jdstrand | does that matter? | 15:39 |
| rsalveti | jdstrand: well, emulator will take way longer to boot | 15:39 |
| rsalveti | that's a regression | 15:39 |
| jdstrand | rsalveti: I guess what I am asking is why the cache precompilation for goldfish is tied to the other kernels | 15:40 |
| jdstrand | rsalveti: does the server logic all use the same features file or something? | 15:40 |
| rsalveti | jdstrand: because you said the feature file would change | 15:40 |
| rsalveti | and yeah, we use only one feature file for every kernel | 15:40 |
| rsalveti | at least atm they are all the same | 15:40 |
| rsalveti | that's why the cache is valid for every device we support | 15:41 |
| rtg | rsalveti, the build failure is a firmware rule (whch has me a bit mystified). I could work around it by just disabling the firmware part of the build. Does goldfish actually use any firmware since its an emulated environment ? | 15:42 |
| rsalveti | rtg: I don't think it uses any | 15:42 |
| jdstrand | rsalveti: I think we are not communicationg well. when the kernels are going to be copied, we should change the feature file. if you aren't going to copy the goldfish kernel, don't change its feature file | 15:42 |
| rtg | rsalveti, ok, lemme experiment with just turning it off. | 15:43 |
| rsalveti | jdstrand: what I said is that we have one single feature files that are the same for every kernel package we support | 15:43 |
| rsalveti | because the rootfs is generic, so it needs a generic feature file | 15:43 |
| jdstrand | rsalveti: right, but isn't linux-goldfish a different kernel package than linux-mako? | 15:43 |
| rsalveti | jdstrand: it is | 15:43 |
| rsalveti | but the final feature file is still the same | 15:43 |
| jdstrand | oh I misread what you said | 15:44 |
| jdstrand | I thought you meant one per kernel | 15:44 |
| rsalveti | oh, sorry, no, we have one common feature file in live-build | 15:44 |
| jdstrand | I see. ok, then yes, waiting makes sense | 15:44 |
| jdstrand | rsalveti: how does this relate to krillin? | 15:45 |
| rsalveti | jdstrand: will coordinate with the PES team | 15:45 |
| rsalveti | jdstrand: because they are the ones publishing the device tarball for it | 15:45 |
| jdstrand | ok, perfect | 15:45 |
| El_Presidente | hi, i may have run into a bug on my fathers machine, he is running ubuntu 14.04 on a sandy bridge cpu with hd2000 (onboard) video. since some kernel upgrades the system freezes nearly every time when the "plymouth" xubuntu logo appears. i installed 3.17 rc5 mainline kernel for testing and now this error does not appear anymore. have you got similar reports or do i have to bisect this issue? | 17:00 |
| apw | El_Presidente, i do not recall that specifically, i would file a bug against linux, and test the mainline kernels nearer the ubuntu version | 17:11 |
| El_Presidente | apw, ty | 17:11 |
| El_Presidente | it must have been in the last two weeks | 17:12 |
| apw | El_Presidente, do you thik this occured in a kernl update, ie an older ubuntu kernel was ok? if so you can test those too | 17:13 |
| El_Presidente | apw, well i installed his system in april with a fresh dvd | 17:13 |
| El_Presidente | and he has problems since 35 or 34 im not sure | 17:14 |
| apw | and it worked then, and does not now, so that sounds like a kernel update ... | 17:14 |
| El_Presidente | yes he had no problems till that | 17:14 |
| apw | ok so finding the exact last working ubunru kernel and first non-working ubuntu one would be best | 17:14 |
| apw | as there are a lot less changes in that range | 17:14 |
| El_Presidente | okay i will start there | 17:15 |
| El_Presidente | ty again | 17:15 |
| El_Presidente | apw, well according to the changelogs there are tons of i915 changes to 35-62 | 17:23 |
| El_Presidente | and below that the first i915 change is on 31-55 | 17:24 |
| El_Presidente | i will check that | 17:25 |
| === maxb_ is now known as maxb | ||
| catbus1 | Dear kernel people, can someone please tell me about what the warn_slowpath_common and warn_slowpath_fmt are about in the kernel call trace? | 19:14 |
| apw | catbus1, they are just the functions which produce the WARN messages that the caller of those is trying to emit | 19:19 |
| === mwenning is now known as mwenning-afk | ||
| catbus1 | apw: thank you! | 19:42 |
| === mwenning-afk is now known as mwenning | ||
| cmagina | is the sru-workflow page on kernel.ubuntu.com a good place to watch the status of the current sru kernel? | 20:31 |
| infinity | zyga: And it starts all over again: https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1372685 | 23:54 |
| ubot5 | Launchpad bug 1372685 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress] | 23:54 |
| infinity | Err... | 23:54 |
| infinity | zyga: Not you. | 23:54 |
| infinity | zequence: See above. :P | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!