[07:42] <iongraphix> what up people? anybody home?
[07:57] <seb128> hey
[07:58] <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:59] <seb128> it's also ranked quite high on the wily e.u.c daily report
[08:03] <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:04] <seb128> smb, k, I'm just mentioning it because it shows up on errors.u.c
[08:05] <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:06] <seb128> smb, yeah, there are quite a lot of users having proposed enabled it seems
[08:07] <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:09] <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:11] <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
[09:00] <smb> henrix, Do you know how far the whole range of new proposed kernels is in our future? 
[09:01] <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:04] <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:06] <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:22] <apw> smb, enough people that we get reports :)
[09:23] <smb> apw, enough people that we get _many_ reports. :)
[09:40] <apw> smb, indeed
[13:22] <ricotz> rtg, hi
[13:22] <rtg> ricotz, hmm?
[13:22] <ricotz> please push linux-meta-lts-wily to the correct pocket ;)
[13:23] <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:24] <ricotz>  linux-meta-lts-wily - 4.2.0.7.7 is the current one in trusty
[13:26] <rtg> ricotz, uploaded
[13:27] <ricotz> rtg, thanks
[13:27] <ricotz> rtg, make sure to remove the wrong one in wily
[13:27] <rtg> yup, working on it
[13:28] <ricotz> thanks
[13:58] <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/
[14:01] <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}
=== alai` is now known as alai8
[14:03] <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:04] <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:05] <henrix> leftyfb: only 3.19.0-31 is broken, 3.19.0-30 should be good
[14:37] <leftyfb> rtg: henrix: thanks for the help... reverting back to -30 worked this time. I removed -31 for the time being
[15:29] <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:32] <vertago1_> I just checked and it seems to be a problem with the older version to, so maybe I am doing something wrong
[15:40] <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:55] <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:56] <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:57] <apw> we won't see a forum post, do file a bug and dump the bug number in here
[15:58] <vertago1_> ok I will after I check 14.04
[16:01] <vertago1_> yeah it works in 14.04
[16:02] <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:03] <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:04] <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:05] <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:06] <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:16] <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:17] <infinity> hallyn: So, this is something we can't (or won't) fix for wily?
[16:18] <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:53] <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:54] <infinity> hallyn: But with crazy automatic hotplug scenarios like offlining CPUs entirely for power management reasons, etc, something's got to give.
[16:56] <hallyn> yup
[16:57] <hallyn> vertago1_: if you'd like to test with a ppa i can set something up next week
[16:59] <vertago1_> ok
[17:01] <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:34] <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:38] <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:39] <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:40] <ogasawara> ack
[17:45] <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:46] <ogasawara> jsalisbury: when you have a moment, can you work with jdstrand to potentially bisect this
[17:46] <jsalisbury> ogasawara, sure
[17:47] <ogasawara> jsalisbury: he's testing to try and grab some logs, so sit tight
[17:47] <jsalisbury> ogasawara, ack
[17:48] <jdstrand> hmm, installing in a vm and didn't see the issue
=== 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/
[18:08] <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:09] <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:10] <jdstrand> unfortunately, no. this system is considered critical infrastructure
[18:11] <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:13] <jdstrand> jsalisbury: I saw in the bug that someone said rebooting solved it. I could reboot once-- would that help you?
[18:14] <rtg> jdstrand, is your system `date` normal ?
[18:14] <jdstrand> yes
[18:15] <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:16] <rtg> you can just update your RTC by hwsystoclock (I think) lemme check.
[18:17] <rtg> jdstrand, hwclock --systohc
[18:18] <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:19] <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:23] <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:30] <jdstrand> jsalisbury: no issues: [    6.280265] Loaded X.509 cert 'Magrathea: Glacier signing key: d73704f98fab8927e462b2d8aa80377a6fca5db3'
[18:31] <jdstrand> weird
[18:31] <jsalisbury> jdstrand, yeah, that is strange.  I be sure to keep an eye out for others reporting it.
[18:39] <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:40] <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:41] <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:42] <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
=== mwenning is now known as mwenning-appt