=== zequence_ is now known as zequence
[08:10] <apw> Hauke (N,BFTL), it does not seem like we have any obvious way currently indeed.  i might be persuaded such a thing is reasonable.
[09:05] <jpds> Could somoene take a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1325260 ?
[09:05] <ubot5> Ubuntu bug 1325260 in linux (Ubuntu) "CompuLab Intense PC2 does not shutdown correctly on 14.04" [Low,Triaged]
[09:05] <jpds> I've found the one line patch that fixes the issue.
[09:05] <apw> jpds, ok
[10:28] <xnox> "E: 10mount: mount: unknown filesystem type 'overlayfs'" hm, wtf.....
[10:36] <brendand> xnox, can you reproduce that?
[10:36] <apw> xnox, what kernel
[10:37] <apw> xnox, cat /proc/version_signature
[10:37] <mlankhorst> isn't it /proc/version, or uname -a ? :p
[10:38] <xnox> apw: hm, looks like i'm running your kernel from the kernel ppa. Let me upgrade to 3.15-4
[10:38] <xnox> Linux version 3.15.0-031500rc5-generic (apw@gomeisa)
[10:38] <xnox> rc5 sounds old, given that rc8 is out the door.
[10:39] <brendand> xnox, aren't you using an ideapad yoga 13 too?
[10:39] <apw> xnox, missing extras perhaps ?
[10:39] <xnox> brendand: i am!
[10:39] <brendand> xnox, updating the kernel usually means i have to rebuild wifi drivers
[10:39] <brendand> xnox, so i avoid it
[10:39] <xnox> brendand: and i have a bunch of things going wrong with it with 3.15 kernel, but it's slowly getting better.
[10:40] <xnox> brendand: i have dkms module for that & it's no longer actually needed, as that driver got merged into staging in 3.14 and is enabled in our config
[10:40] <brendand> xnox, oooh. cool
[10:41] <xnox> brendand: well, it generates kernel oopses on suspend&resume though =(
[10:42] <apw> xnox, getting better, thats no good, i need to inject some more "if (xnox) BUG" code clearly
[10:44] <xnox> apw: michael fry punished me enough for last weeks breakages already
[10:44] <apw> heh likely true
[10:45] <apw> xnox, oh you are runing mainline kernels, yeah they do not have anything non-upstream in them
[10:54] <xnox> apw: 3.15-4 is no good (locks up after graphical login, before compiz/unity get a chance to start)
[10:54] <apw> xnox, lovely
[10:54] <xnox> apw: and loads of oopses if i have any usb3 activity
[10:54] <apw> xnox, what sort of lockup, can you ssh in etc
[10:55] <xnox> apw: didn't check ssh, but graphics were unresponsive.
[10:55] <apw> xnox, you bought an absolute turkey of a machine there didn't you, with hindsite buying a lenovo and having it spraypainted yellow sounds a more sensible plan
[10:55] <xnox> apw: back on 3.13 kernel cause have "work" todo (aka break the archive)
[10:55] <apw> heh, well have a look aback at syslog and see if it recorded anything before you wacked it with a stick
[10:56] <xnox> apw: sabdfl liked it =) 
[10:57] <xnox> apw: yeap http://paste.ubuntu.com/7572245/ search for "cut here" same usb error over and over again.
[10:58] <xnox> not sure if that's upstream rc4 kernel or 3.15-4 though =(
[10:58] <xnox> /home/apw -> that's rc4
[10:58] <xnox> worth reporting at all?
[10:58] <apw> i'd say not, unless you get it with -4
[11:23] <brendand> xnox, maybe it's worth noting that i didn't have any problem last week creating an armhf chroot
[11:23] <brendand> xnox, i wonder was it broken in an update
[14:24] <apw> jpds, ok test kernels are available in your bug
[14:26] <jpds> apw: Ah, cool, though I won't have access to the hardware until at least next week..
[14:26]  * jpds tries to find someone who can turn the machine on.
[16:04] <manjo> rtg, can you enable trusty arm chroot on tangerine ?
[16:05] <rtg> manjo, no support for arm chroots anymore. use the cross compiler in the amd64 chroot
[16:05] <rtg> dpkg-buildpackage -B -aarmhf
[16:05] <manjo> ah ok
[16:06] <rtg> actually, dpkg-buildpackage -d -B -aarmhf
[16:06] <manjo> dpkg-buildpackage -d -B -aarmhf -us -uc
[16:06] <rtg> yeah, that works too
=== hatch__ is now known as hatch
[17:42] <manjo> rtg, dpkg-buildpackage -nc is supposed to recompile .. how do I make it not restart config ? 
[17:42] <manjo> rtg, coz I copied in a .config in build/ 
[17:43] <manjo> rtg, I don't want dpkg to ask me any config qs .. I want it to skip that ... I thought -nc would do it .. but it still is asking me Qs 
[17:49] <rtg> manjo, -nc is "do not clean". if you're usinga local .config, then perhaps you want 'make deb-pkg' instead.
[17:52] <manjo> rtg, how doees that work with arm cross compile ... Ihave not used it 
[17:55] <rtg> manjo, make deb-pkg ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
[18:07] <manjo> rtg, sorry got kicked by irc .. how does make deb-pkg work with cross compile ?
[18:07] <rtg> manjo, make deb-pkg ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
[18:08] <manjo> ok let me try that 
[19:03] <sconklin_> arges: I know you're in sprint recovery but I'm willing to discuss the trusty net ns bug any time :-) We're unable to reproduce it anywhere outside our production environment, where we can't get a crash dump
[19:04] <sconklin_> maybe it's time for "debug by kprint"
[19:06] <rtg> sconklin_, he's not back until Wednesday IIRC
[19:07] <sconklin_> ok, nice. Did he tack on some time off?
[19:07] <rtg> yup
[19:07] <sconklin_> cool.
[19:16] <stgraber> sconklin_: I spent half a day or so last week during the sprint to try and trigger this without much success... I've reproduced it a couple of times by accident but even with linux-coredump installed I can't get a core... My attempt at creating hundreds of netns, flooding them with millions of packets all doing round trips through netfilter + killing them at random didn't trigger any panic either...
[19:17] <sconklin_> stgraber: it's so frustrating that we can trivially reproduce this 100% of the time in our operating environment
[19:18] <stgraber> sconklin_: what kind of load do you have in that prod environment? here I noticed it'd tend to happen a lot more when my machine was crazy busy than when it was mostly idle (it blew up in my face twice when doing kernel builds while playing with lxc...)
[19:19] <sconklin_> checking, stand by
[19:22] <sconklin_> stgraber: very lightly loaded. It's an instance that's only running our supervisory app and a single lxc container
[19:26] <stgraber> sconklin_: interesting
[19:27] <sconklin_> stgraber: rsampaio_ just popped in here, he's been doing the testing and is a lot more familiar than I am with how it all works (or doesn't)
[19:27] <stgraber> sconklin_, rsampaio_: do you also get the panic when killing a container or do you somehow get it during standard operation?
[19:28] <sconklin_> stgraber: and when I said "production environment" what I meant was "a test environment identical to our production environment"
[19:28] <rsampaio_> stgraber, sconklin_, the panic happens after we kill the container, few seconds later
[19:29] <rsampaio_> I was able to get the lockdep files before the panic happens
[19:29] <stgraber> ok, so that matches what I've been seeing here the rare few times it happened to me
[19:30] <rsampaio_> I wish I could get a crashdump from the ec2 instance, it is very easy to reproduce in our environment
[19:31] <rsampaio_> I've tried the kvm image from Chris running for a couple hours but no panic
[19:31] <stgraber> and I guess your EC2 instance depends on other instances so you can't just copy the fs to a local VM and reproduce the panic there?
[19:34] <rsampaio_> yeah there are a few other instances involved in the process
[21:32] <balerion> hi anyone there ??
[21:34] <balerion> i need help with the kernels which control the display ( as in on screen/monitors )
[21:35] <balerion> can anyone help ??