[08:59] <UNIm95> apw: Hi. I got kernel panic again. Where should i paste photos?
[09:01] <apw> UNIm95, file a bug, and add them to that bug: use 'ubuntu-bug linux' to make the bug
[09:01] <UNIm95> apw: what is ubuntu-bug linux? Console program? Website?
[09:01] <apw> something to run in a terminal yes
[09:17] <UNIm95> apw: Damn. I got Launchpad error =)
[09:20] <UNIm95> apw: I have submitted this. What should i do next? Wait?
[09:28] <apw> UNIm95, let us know the LP# here for one
[09:31] <UNIm95> apw: What do you mean with LP#?  if you mean bug number under launchpad it is #1497184. Link here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1497184
[09:31] <ubot5> Ubuntu bug 1497184 in linux (Ubuntu) "Kernel-panic with 3.13-64 generic kernel" [Undecided,Confirmed]
[09:31] <apw> yep that
[09:34] <apw> henrix, ^ looks like a regression in trusty-proposed kernel ...
[09:34] <apw> UNIm95, does that trace seem consistent in your failures ?
[09:35] <apw> UNIm95, particuarly is that "BUG: ..../skbuff.c:1290" part appear in other ones
[09:36] <UNIm95> apw: Not sure. Now I'm still using *-64- kernel and wait for another panic. When it happens i post more photos.
[09:36] <apw> UNIm95, thanks that is exactly what we need, you are not the only person "feeling" there is an issue in here
[09:37] <apw> UNIm95, and thanks for 1) testing -proposed and 2) reporting the issues to us
[09:38] <UNIm95> apw: Please. I is not a problem for me. I have backups =)
[09:38] <apw> heh, thanks
=== apw is now known as apw_
=== apw_ is now known as cafetiere
=== cafetiere is now known as apw
[09:47]  * smb feels a disturbance in the coffee namespace
[09:55] <henrix> smb: ok, i *may* have found something related with this bug.  if your bored, here's what i found:
[09:55] <henrix> smb: trysty -64 kernel includes commit 738ac1ebb96d ("net: Clone skb before setting peeked flag")
[09:55] <apw> that sounds suspicious indeed
[09:56] <henrix> smb: however, there's an upstream commit (not included in trusty yet): a0a2a6602496 ("net: Fix skb_set_peeked use-after-free bug")
[09:56] <henrix> which fixes the other one
[09:56] <apw> nnng
[09:56] <smb> henrix, yeah. I am currently trying to cause it to crash with -64 in a VM. If that succeeds I can have a look with that added
[09:57] <henrix> smb: cool, thanks
[09:57] <smb> henrix, but use-after-free sounds a lot like what may happen
[09:58] <henrix> smb: yeah, the only thing is that none of these functions actually show up in the kernel trace.  but since the kernel is tainted, it could have happen before
[09:58] <henrix> *don't show
[09:58] <smb> henrix, absolutely. the pain with use-after-free
[10:03] <henrix> smb: btw, if the issue you're hitting is really due to this commit, it seems to be related with broadcast/multicast ;-)
[10:03] <henrix> (according to the commit msg)
[10:04] <smb> henrix, hmmm... so the method to trigger it is actually the dhcp client running... likely...
[11:17] <henrix> smb: build on-going in gloin:/tmp/kernel-henrix-RVtd9xTj
[12:39] <henrix> UNIm95: i've commented on the bug with a link to a test kernel
[12:39] <henrix> UNIm95: The comment points to the possible issue (and the fix)
[12:39] <UNIm95> henrix: ok.
[12:40] <apw> UNIm95, how long did it take to reproduce in general ?
[12:40] <henrix> apw: smb: btw, looks like this also impacs vivid
[12:42] <UNIm95> apw: At home laptop worked for 4 hours, than sleep for 8 hours and, finally, after 2 hours word panic.
[12:42] <UNIm95> work*
[12:44] <UNIm95> apw: one time a got this after ~30min uptime
[12:45] <apw> henrix, gah
[12:45] <UNIm95> henrix: i will try this kernel a later. I need to do my work
[12:45] <apw> henrix, i've nom'd it to those two for now
[12:46] <UNIm95> henrix: i have downloaded this kernel
[12:46] <apw> UNIm95, let us know how you get on
[12:46] <UNIm95> Sure
[12:46] <henrix> UNIm95: ack, thanks!
[12:46] <apw> but i am suspicious this is the issue and fix
[12:49] <UNIm95> henrix: the only question: "and introduces a use-after-free bug, fixed with upstream commit"
[12:49] <UNIm95> It means than this bug appers with high memory load?
[12:50] <henrix> UNIm95: from these commits description it should occur in the broadcast and multicast packages receive paths, so not really a memory stress issue
[12:51] <henrix> s/packages/packets 
[12:51] <UNIm95> henrix: network packets?
[12:52] <henrix> UNIm95: yep
[12:52] <UNIm95> should i emulate DDOS?
[12:52] <UNIm95> on my own laptop?
[12:53] <UNIm95> Or is possible to make some thing like this.
[12:53] <apw> UNIm95, it is predicted taht dhcpclient would tickle the bug
[12:53] <apw> UNIm95, so setting your dhcp refresh time on your router to 5m might make it a lot more likley to occur
[12:53] <apw> lots of packets not so likley to trigger it, as tehy are normally unicast
[12:55] <UNIm95> apw: and doesn't matter Wlan or ethernet?
[12:55] <apw> i don't believe so from the description
[12:55] <apw> henrix, ^
[12:57] <henrix> apw: i... don't think so either, it's in the core network code.  anyway, looking at UNIm95 photos, it seems to have occurred while using ethernet (e1000e)
[12:57] <apw> good point
[12:57] <henrix> but again, i believe that's irrelevant -- if this is the issue, it's in the core code, so it doesn't matter
[12:58] <UNIm95> henrix: apw yesterday at home i used wlan and got only kernel oops that was catched with apport-gtk.
[12:59] <UNIm95> do you have access to ubuntu's apport infrastructure?  
[12:59] <apw> UNIm95, the symptoms of this would be pretty random, as it is a use after free which could literally break anything
[12:59] <apw> UNIm95, we may be able to find it yes
[13:00] <UNIm95> look for toshiba tecra laptop a11
[13:01] <UNIm95> It was at evening. 20:00<x<22:00 Berlin time
[13:19] <smb> apw, henrix, so far not been able to hit it in a more artificial environment but I guess its random by nature
[13:43] <apw> tjaalton, hey are you fixing this initramfs-tools thing for the firmware ... i was about to, but i see you ahve it assigned
[13:44] <tjaalton> apw: that's when it was a kernel bug, you can have it :)
[13:44] <apw> tjaalton, ack
[13:44] <tjaalton> thanks
[14:42] <psivaa> cking_: hello, it's me again :) 
[14:42] <psivaa> Just was going to disable the memory threshold for NM health check but noticed that it's been passing for a few days. 
[14:42] <psivaa> *memory threshold tests
[14:42] <psivaa> https://jenkins.qa.ubuntu.com/view/Trusty/view/Smoke%20Testing/job/trusty-desktop-i386-smoke-health-check/
[14:43] <psivaa> so i'm wondering if that's OK to let that run for a few more days to see if this has really settled
[14:43] <cking_> psivaa, ok, lets see how it runs over the next few days
[14:43] <psivaa> cking_: ack, thanks
=== hggdh is now known as hggdh_
=== hggdh_ is now known as hggdh__
=== hggdh__ is now known as hggdh
[15:47] <t3hSteve> hey all, is anyone around that could help me with a cpuacct cgroup question/issue/bug?
[17:20] <apw> t3hSteve, it is eod for me, but it is just best to ask the question and see who responds
[17:22] <t3hSteve> ok, so basically I notice that on (at least up to) 3.13.0-64, the cpu usage reported in cpuacct.stat is significantly lower than the actual CPU usage as reported by say, top or /proc/<pid>/stat
[17:25] <t3hSteve> this is on ubuntu 12.04, I seem to recall on 14.04 it was correct, but oddly enough I think it was on the same kernel version
[17:40] <apw> t3hSteve, hrm, that sounds odd if the kernle version is the same
[17:40] <t3hSteve> yeah, its very odd =/
[17:40] <t3hSteve> looking around bug trackers I cant see any reference to anything like this
[17:41] <t3hSteve> but its a significant under-reporting from the cgroup
[17:41] <apw> t3hSteve, sounds like some repeatable test is required, if you could file a bug against the kernel "ubuntu-bug linux", and could detail the two platforms that produce different numbers, and how to get the numbers
[17:41] <t3hSteve> ex top reports 120% and the cgroup reports .9
[17:41] <apw> t3hSteve, then someone might be able to repro it
[17:41] <t3hSteve> I can do that
[17:41] <t3hSteve> althought we'll see how easy it is to reproduce :P
[17:42] <apw> t3hSteve, heh .. i know ... things like this normaly go away when you try and make them reproducible
[17:43] <t3hSteve> :P
[17:43] <t3hSteve> the full context is we're running mesos in AWS
[17:43] <apw> t3hSteve, drop the LP#number in here when you have done so, so we can find it
[17:43] <t3hSteve> and the numbers I get out of mesos (which just reads the cgroup) are way different from what I see on the machine itself (top, /proc, etc)
[18:34] <UNIm95> henrix: apw damn. without kernel change i have 10 hours uptime without panic.
[19:59] <t3hSteve> so re: my cgroup issue, it looks like the more threads a process has the more the cpuacct.stats numbers diverge
[20:36] <t3hSteve> apw: https://bugs.launchpad.net/ubuntu/+source/linux-lts-raring/+bug/1497447
[20:36] <ubot5> Ubuntu bug 1497447 in linux-lts-raring (Ubuntu) "cgroup cpuacct.stats underreports cpu usage" [Undecided,New]
[20:36] <t3hSteve> I'm not sure if I filed it against the right package?
[20:43] <old_benz> Hi all, I think the "flo" branch needs to be patched to support newer Nexus 7 devices with an updated eMMC controller, I need to compile a new kernel and patch my boot.img and recovery.img in order to get Ubuntu Touch to install on my Nexus 7
[20:43] <old_benz> details are here: https://github.com/ddagunts/UTCWM_N7_patch
[21:41] <apw> old_benz, if you could file a bug against linux-flo with that information and drop the bug # in here ...
[22:27] <old_benz> apw: will do, need to make an account