iongraphix | what up people? anybody home? | 07:42 |
---|---|---|
seb128 | hey | 07:57 |
seb128 | could somebody make bug #1503977 looked at rather than dismissed with the usual "collect more info"? it's likely that there is not going to have a reply since that's an e.u.c created bug and not an user filed one, but it did start with 4.2.0-15.17 | 07:58 |
ubot5` | bug 1503977 in linux (Ubuntu) "BUG: unable to handle kernel paging request at location RIP: 0010:location location kmem_cache_free+0x69/0x1e0" [Undecided,Incomplete] https://launchpad.net/bugs/1503977 | 07:58 |
seb128 | it's also ranked quite high on the wily e.u.c daily report | 07:59 |
smb | seb128, I need to check but there was a whole set of badness in the last upload over all releases which is already in the process of being updated | 08:03 |
smb | Just not sure where the replacement kernels are stuck right now | 08:03 |
seb128 | smb, k, I'm just mentioning it because it shows up on errors.u.c | 08:04 |
smb | seb128, Yeah, I check version but there might be various kernels showing up there recently which is slightly surprising. There are more people having proposed enabled than one thought | 08:05 |
seb128 | smb, yeah, there are quite a lot of users having proposed enabled it seems | 08:06 |
smb | seb128, ok, so there is a wily 4.2.0-15.18 in proposed which will likely fix the bug you mentioned | 08:07 |
seb128 | good | 08:07 |
smb | seb128, Though for wily it better has to be in the main archive as nobody should have proposed enabled there, yet | 08:09 |
seb128 | right | 08:09 |
smb | seb128, hm having said that... the -15.18 was never in the main pocket... :-P I see -14.16 is still there | 08:11 |
smb | but thats nitpicking, I hope things settle down around today | 08:11 |
smb | henrix, Do you know how far the whole range of new proposed kernels is in our future? | 09:00 |
henrix | smb: some of them are ready to be copied; that could happen today, i guess... | 09:01 |
henrix | smb: the ones missing (and i'm working on those) are the lts-* kernels | 09:01 |
smb | henrix, Not sure how widespread the use of proposed is with those. It is kind of amazing to see how far those kernels get even then | 09:04 |
henrix | smb: yeah, looking at the # of bug reports, looks like there are quite a few people using them | 09:06 |
smb | henrix, yep... seems a constant stream of those | 09:06 |
apw | smb, enough people that we get reports :) | 09:22 |
smb | apw, enough people that we get _many_ reports. :) | 09:23 |
apw | smb, indeed | 09:40 |
ricotz | rtg, hi | 13:22 |
rtg | ricotz, hmm? | 13:22 |
ricotz | please push linux-meta-lts-wily to the correct pocket ;) | 13:22 |
rtg | uh, did it go to wily ? | 13:23 |
ricotz | https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+sourcepub/5480236/+listing-archive-extra | 13:23 |
ricotz | rtg, yeah, several times ;) | 13:23 |
rtg | dammit. I get dyslexic some days | 13:23 |
ricotz | linux-meta-lts-wily - 4.2.0.7.7 is the current one in trusty | 13:24 |
rtg | ricotz, uploaded | 13:26 |
ricotz | rtg, thanks | 13:27 |
ricotz | rtg, make sure to remove the wrong one in wily | 13:27 |
rtg | yup, working on it | 13:27 |
ricotz | thanks | 13:28 |
leftyfb | hey, can someone help with a stack trace I've been getting on my laptop since last night after rebooting? The laptop is unusable at this point because of it. https://pastebin.canonical.com/141435/ | 13:58 |
rtg | leftyfb, reboot to the previous kernel. we're working to release the regression fix for this | 14:01 |
leftyfb | rtg: i've tried that .. didn't seem to help | 14:01 |
leftyfb | rtg: tried 3.19.0-{28,29,30,31} | 14:01 |
=== alai` is now known as alai8 | ||
henrix | leftyfb: the problem you're hitting with that pastebin is bug #1503655 and older kernels are not affected | 14:03 |
ubot5` | bug 1503655 in linux (Ubuntu Wily) "Kernel bug in eventpoll_release_file+0x46/0xa0 with 3.13.0-66.107" [Undecided,Confirmed] https://launchpad.net/bugs/1503655 | 14:03 |
henrix | leftyfb: since you're using an lts-vivid kernel, it will take a couple more hours until the fix hits -proposed | 14:04 |
leftyfb | henrix: is there a kernel that yo suggest I try that might not have the issue? | 14:04 |
henrix | leftyfb: only 3.19.0-31 is broken, 3.19.0-30 should be good | 14:05 |
leftyfb | rtg: henrix: thanks for the help... reverting back to -30 worked this time. I removed -31 for the time being | 14:37 |
vertago1_ | I am having a problem with kernel 4.2.0 where if I offline a cpu and bring it back up it isn't usable until reboot. | 15:29 |
vertago1_ | I just checked and it seems to be a problem with the older version to, so maybe I am doing something wrong | 15:32 |
vertago1_ | It seems like I am doing everything right. the cpu shows up in the online set, in /proc/cpuinfo, but nproc shows it as missing and I cannot get processes to use it | 15:40 |
apw | vertago1_, if you could file a bug against the kernel "ubuntu-bug linux" and describe in there how to reporoduce, we can have a look | 15:55 |
vertago1_ | I am writing a forum post because it seems to affect 15.04 too. I am pretty sure it works in 14.04 but I will have to do a test. | 15:56 |
apw | we won't see a forum post, do file a bug and dump the bug number in here | 15:57 |
vertago1_ | ok I will after I check 14.04 | 15:58 |
vertago1_ | yeah it works in 14.04 | 16:01 |
vertago1_ | should I submit the bug as two seperate reports or is there a way for me to include apport data from two different releases (15.04 and 15.10 | 16:02 |
vertago1_ | I could check 14.10 too | 16:02 |
infinity | I give 20-to-1 odds that's a userspace bug, not a kernel bug. | 16:03 |
infinity | cgroups are thpethial. | 16:03 |
vertago1_ | infinity, is there a good way for me to check? | 16:03 |
vertago1_ | I coudl restart cgroups | 16:03 |
infinity | Offlining a CPU in a cgroup makes it never come back in that same cgroup. So, it's there at the ring0 level, but never again in that process group. | 16:03 |
infinity | I'm sure there are open bugs about this for, at least, cgmanager. But I wouldn't be surprised if systemd itself has the same bug/misfeature. | 16:04 |
infinity | https://bugs.launchpad.net/ubuntu/+source/cgmanager/+bug/1392176 | 16:05 |
ubot5` | Ubuntu bug 1392176 in linux (Ubuntu) "mounts cgroups unconditionally which causes undesired effects with cpu hotplug" [Medium,Confirmed] | 16:05 |
infinity | vertago1_: ^-- I believe that's the issue you're seeing. | 16:05 |
infinity | Or, something similar. | 16:06 |
infinity | vertago1_: I'd recommend having a chat with hallyn about it to get a handle on the current state (and the behaviour you're seeing). | 16:06 |
vertago1_ | infinity, it looks like that is the problem. I can't tell from the bug page if they decided on how to fix the issue yet. | 16:16 |
hallyn | infinity: vertago1_: i'm hoping as soon as 16.04 opens up we drop the auto-login cgroups from systemd and get libpam-cgroup into main in its place | 16:16 |
hallyn | libpam-cgm does not put you into cpusets by default | 16:16 |
infinity | hallyn: So, this is something we can't (or won't) fix for wily? | 16:17 |
vertago1_ | hallyn, on multiuser systems isn't cpusets nice for enforcing fairness? | 16:18 |
infinity | hallyn: The bug report makes it sound ppc-specific, but it's really not. CPU hotplugging is a thing on all the arches we support, it's just less common on the others. | 16:18 |
hallyn | infinity: yeah... mind you the real but is int he kernel, but maintainer refuses to fix it other than in the unified cgroup hierarchy | 16:53 |
infinity | hallyn: Well, s/bug/misfeature/, I suppose. Which is the problem. People can easily argue that the behaviour is "correct", while everyone else yells at them that they're wrong, and yay stalemate. | 16:53 |
infinity | hallyn: But with crazy automatic hotplug scenarios like offlining CPUs entirely for power management reasons, etc, something's got to give. | 16:54 |
hallyn | yup | 16:56 |
hallyn | vertago1_: if you'd like to test with a ppa i can set something up next week | 16:57 |
vertago1_ | ok | 16:59 |
vertago1_ | this is my active launchpad account: https://launchpad.net/~vertago1-s, I also have https://launchpad.net/~vertago1, but I would have to recover the password and it isn't linked ot my openid | 17:01 |
jdstrand | ogasawara: I just updated a system to 3.13.0-65.106~precise1-generic and am seeing: Request for unknown module key 'Magrathea: Glacier signing key: d73704f98fab8927e462b2d8aa80377a6fca5db3' err -11. is something not right in that kernel? | 17:34 |
ogasawara | jdstrand: I know there are respins of the kernels in proposed taking place for bug 1503655, but that doesn't appear what you're seeing. | 17:38 |
ubot5` | bug 1503655 in linux (Ubuntu Wily) "Kernel bug in eventpoll_release_file+0x46/0xa0 with 3.13.0-66.107" [Undecided,Confirmed] https://launchpad.net/bugs/1503655 | 17:38 |
jdstrand | it seems to be running fine | 17:38 |
ogasawara | jdstrand: can you do an `ubuntu-bug linux` to capture the logs etc | 17:38 |
jdstrand | it is just complaing a lot | 17:38 |
jdstrand | I can't on that machine actually | 17:39 |
jdstrand | what do you need from it? | 17:39 |
ogasawara | jdstrand: can you grab the full dmesg | 17:39 |
jdstrand | maybe I can in a vm | 17:39 |
jdstrand | let me try that first | 17:39 |
ogasawara | ack | 17:40 |
ogasawara | jdstrand: I'm seeing recent similar comments in bug 1253155 | 17:45 |
ubot5` | bug 1253155 in linux (Ubuntu Trusty) "Failure to validate module signature at boot time" [High,Fix released] https://launchpad.net/bugs/1253155 | 17:45 |
ogasawara | jsalisbury: when you have a moment, can you work with jdstrand to potentially bisect this | 17:46 |
jsalisbury | ogasawara, sure | 17:46 |
ogasawara | jsalisbury: he's testing to try and grab some logs, so sit tight | 17:47 |
jsalisbury | ogasawara, ack | 17:47 |
jdstrand | hmm, installing in a vm and didn't see the issue | 17:48 |
=== jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Oct 20th, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! If the question is should I file a bug for something, likely you can assume yes. || Channel logs: http://irclogs.ubuntu.com/ | ||
jdstrand | jsalisbury (and ogasawara): sorry, I can't reproduce in a vm (I even tried upgrading from 3.13.0-63.104~precise1 to 3.13.0-65.106~precise1. the system I saw the issue on is... specialized and I only have reduced logs: http://paste.ubuntu.com/12717229/ | 18:08 |
jsalisbury | jdstrand, would you be able to test some kernels on the system where you can reproduce the bug? | 18:09 |
jdstrand | all I can say is that it is on an i386 system. All I did was apt-get upgrade the linux-image-generic-lts-trusty kernel then rebooted and saw that | 18:09 |
jdstrand | unfortunately, no. this system is considered critical infrastructure | 18:10 |
jdstrand | I'm sorry for not being as helpful as I'd like. if it was almost any other system, I could | 18:11 |
jsalisbury | jdstrand, ack | 18:11 |
jdstrand | jsalisbury: I saw in the bug that someone said rebooting solved it. I could reboot once-- would that help you? | 18:13 |
rtg | jdstrand, is your system `date` normal ? | 18:14 |
jdstrand | yes | 18:14 |
jdstrand | (it uses ntp and I verified with date that it is correct) | 18:15 |
rtg | jdstrand, I mean your RTC. I seem to remember if the time of day was way out of whack, then the certificate check failed | 18:15 |
jdstrand | that could be | 18:15 |
jdstrand | how do I check that? | 18:15 |
rtg | you can just update your RTC by hwsystoclock (I think) lemme check. | 18:16 |
rtg | jdstrand, hwclock --systohc | 18:17 |
rtg | I think that is generally part of the NTP update anyways | 18:18 |
jdstrand | $ sudo hwclock -r | 18:18 |
jdstrand | Thu 08 Oct 2015 01:18:14 PM CDT -0.564058 seconds | 18:18 |
jdstrand | that is supposed to show it | 18:18 |
rtg | that looks close enough | 18:18 |
jdstrand | yeah date shows it is close | 18:19 |
rtg | ok, red herring then | 18:19 |
jdstrand | $ sudo hwclock -r ; date | 18:19 |
jdstrand | Thu 08 Oct 2015 01:19:27 PM CDT -0.588061 seconds | 18:19 |
jdstrand | Thu Oct 8 13:19:27 CDT 2015 | 18:19 |
jsalisbury | jdstrand, I guess you could try a reboot and see if it resolves things, since it fixed it for someone else. I'll keep a close eye out for similar bugs being reported. | 18:23 |
jdstrand | jsalisbury: no issues: [ 6.280265] Loaded X.509 cert 'Magrathea: Glacier signing key: d73704f98fab8927e462b2d8aa80377a6fca5db3' | 18:30 |
jdstrand | weird | 18:31 |
jsalisbury | jdstrand, yeah, that is strange. I be sure to keep an eye out for others reporting it. | 18:31 |
TJ- | jdstrand: looking at those log timestamps, the original log showed '[701031.xxx]', which equates to ~ 8 days up-time. Is that when the problem boot occurred? | 18:39 |
jdstrand | TJ-: no. I upgraded that kernel today | 18:39 |
jdstrand | is it possible that the newer kernel's modules tried to get loaded on the old kernel? | 18:40 |
TJ- | jdstrand: Hmmm, I wonder how the timestamp appears to not have reset at boot. | 18:40 |
jdstrand | note this: Oct 8 10:13:34 <redacted> kernel: Kernel logging (proc) stopped. | 18:41 |
jdstrand | that was left out of my previous paste | 18:41 |
jdstrand | when I rebooted a moment ago, I saw this pop out: Oct 8 13:24:49 <redacted> kernel: Kernel logging (proc) stopped. | 18:41 |
jdstrand | that suggests to me that the new modules either got loaded prior to reboot, or the key from the new modules was used to evaluate the old modules | 18:42 |
=== mwenning is now known as mwenning-appt |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!