[08:13] <rbasak> apw: hello! I see that you've dropped the highbank kernel, but I don't see a generic replacement. What's the plan with this?
[08:56] <apw> rbasak, morning, thats a conundrum indeed.  something that is under discussions of a sort
[08:59] <rbasak> apw: I thought we could just turn on a generic armhf flavour?
[09:00] <apw> rbasak, in theory indeed, and someone is investigating it
[13:15] <rtg> ogra_, are you gonna send your config patch to the kteam list ?
[13:32]  * henrix -> SIGFOOD
[13:53] <ogra_> rtg, will do
[14:06] <ogra_> rtg, sent (as you might have seen) ... dont ask why i didnt make it a module ... 
[14:09] <rtg> ogra_, ack
[14:13] <robher> ogra_: when do expect the flash-kernel fix to go in for quantal?
[14:13] <ogra_> robher, end of the week latest, i have some other SRU bits i want to pull in as well
[14:15] <robher> ogra_: great. Thanks.
[14:36] <apw> henrix, i think rtg has commited that patch i was talking about for precise
[14:37] <henrix> apw: yep, i've seen it. i'm already on that. thanks
[14:37] <apw> henrix, thanks indeed
[14:39] <henrix> apw: btw, is there an easy way for me to cancel a build? i've just realised i'm using the ppc builders for precise kernels, which will be dropped later
[14:39] <apw> i think they may well have a cancel button actually
[14:40]  * henrix looks again...
[14:40] <apw> if you get me the link which looks like this one
[14:40] <apw> https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/4035989
[14:40] <apw> i'll find someone to wack it
[14:41] <henrix> apw: https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/4035989
[14:41] <apw> heh ..
[14:41] <henrix> and also https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/4035994
[14:41] <apw> both of those, ok
[14:42] <henrix> thanks. its just that there's not point keeping them building :)
[14:45] <apw> henrix, there is not indeed
[14:46] <apw> and we are short some computrons in powerpc right now
[14:47] <henrix> apw: yeah, i'm currently blocking a ppc. a 'cancel' would be a nice thing to have..
[14:47] <apw> yeah i concur
[14:48] <henrix> apw: ah, but someone did something, right? because the build failed
[14:48] <henrix> or was that a genuine failure...?
[14:48] <apw> rtg, whats the cross build tools called for arm on x86 ?
[14:48] <rtg> gnuabi something...
[14:49] <apw> henrix, no that was 'me' i got them to 'terminate' it... basically they rm -rf /build on the builder
[14:49] <ogra_> arm-linux-gnueabihf-
[14:49] <henrix> apw: ah! cool :)
[14:49] <henrix> thanks
[14:49] <apw> ogra_, is that the package ?
[14:49] <ogra_> gcc-arm-linux-gnueabihf is the package
[14:50] <ogra_> arm-linux-gnueabihf- is the CROSS_COMPILE prefix
[14:50] <apw> b infinity 
[15:00] <smb> apw, That is a big wish
[15:00] <apw> heh indeed
[16:11] <rtg> apw, https://launchpad.net/~ubuntu-x-swat/+archive/r-lts-backport
[16:12] <apw> ahh great
[16:39] <ppisati> brb
[17:12] <rtg> cking, drivers/acpi/acpica/dsmethod.c acpi_ds_create_method_mutex() looks like it could orphan memory
[17:13] <rtg> I've got a patch if you agree with my assessment
[17:13]  * cking has a look
[17:13] <rtg> diff --git a/drivers/acpi/acpica/dsmethod.c b/drivers/acpi/acpica/dsmethod.c
[17:13] <rtg> index aa9a5d4..fe89ea9 100644
[17:13] <rtg> --- a/drivers/acpi/acpica/dsmethod.c
[17:13] <rtg> +++ b/drivers/acpi/acpica/dsmethod.c
[17:13] <rtg> @@ -151,6 +151,7 @@ acpi_ds_create_method_mutex(union acpi_operand_object *method_desc)
[17:13] <rtg>  
[17:13] <rtg>         status = acpi_os_create_mutex(&mutex_desc->mutex.os_mutex);
[17:13] <rtg>         if (ACPI_FAILURE(status)) {
[17:13] <rtg> +               acpi_ut_delete_object_desc(mutex_desc);
[17:13] <rtg>                 return_ACPI_STATUS(status);
[17:13] <rtg>         }
[17:14] <rtg> cking, raring (by the way)
[17:15] <cking> that looks sane to me
[17:15] <cking> the patch
[17:15] <rtg> cking, k, I'll send it upstream
[17:38]  * ppisati -> gym
[17:41] <henrix> apw: just fyi, the precise kernel is now building
[17:41] <apw> henrix, great thanks
[17:41] <henrix> np
[17:42] <stgraber> hey there
[17:42] <stgraber> I just found a weird kernel bug, introduced by 3.7 (AFAICT, wasn't there in 3.5 at least)
[17:42] <stgraber> http://paste.ubuntu.com/1412921/
[17:43] <stgraber> I tried to reproduce this outside of arkose but can't seem to hit it. arkose does quite a bunch of mounts including some bind mounts, loop mounts and overlayfs mounts, then spawns an lxc container, exits and unmounts everything and cleans up
[17:44] <stgraber> AFAICT nothing is failing, it just appears that the umount triggered against the loop device doesn't actually free it
[17:44] <stgraber> and there's apparently no way of ever freeing it short of rebooting the machine
[17:44] <rtg> stgraber, perhaps hallyn or apw have some thoughts.
[17:44] <stgraber> which is a bit of a problem for me considering we have a default of 7 loop devices and I tend to use dozen of those containers a day ;)
[17:46] <apw> no not seen any issues with loops on raring getting stuck so far anyhow
[17:46] <apw> stgraber, what is arkose ?
[17:47] <apw> stgraber, and does fuser -c say anything about /dev/loop0 in that case
[17:48] <stgraber> root@lantea:~# fuser -c /dev/loop0 
[17:48] <stgraber> root@lantea:~# 
[17:49] <stgraber> apw: arkose is basically a python wrapper setting up an lxc container sharing the rootfs with your machine using overlayfs so that anything you do in it won't affect your machine
[17:49] <stgraber> so basically a simple lxc based sandbox
[17:50] <stgraber> my current guess is that something goes wrong when the rootfs of an lxc container is on overlayfs with the upperdir stored on a loop device but I need to write some script to reproduce this outside of arkose
[17:51] <apw> stgraber, be interested in what you find
[17:51] <stgraber> (running the same test using arkose but without the overlayfs or without the loop mounted ext4 doesn't trigger the bug)
[18:04] <hallyn> stgraber: interesting
[18:05] <hallyn> how is the overlayfs delta 3.5..3.7?
[18:08] <stgraber> alright, got a reproducer outside of arkose, it's really weird though :)
[18:12] <stgraber> hallyn, apw: http://paste.ubuntu.com/1412975/
[18:12] <stgraber> hallyn: the really weird thing is that if you replace my 'su nobody -c "hostname"' by just 'hostname', the bug won't happen :)
[18:14] <hallyn> stgraber: does the umount mount/test actually succeed?  
[18:14] <stgraber> hallyn: would be great if you could try to reproduce on your side as it's clearly happening on all my machines here, but the fact that calling "su" seems to make a difference makes me think it could be sssd related (which I assume you don't have)
[18:14] <stgraber> yep, everything succeeds
[18:14] <hallyn> stgraber: that's on raring right?
[18:15] <stgraber> yep, raring with latest 3.7 kernel
[18:15] <hallyn> ok
[18:15] <stgraber> I don't get this on 3.5
[18:16]  * hallyn doth protest to authenticating to download text version of script
[18:17] <hallyn> hm, can't seem to launch an instance...
[18:41] <hallyn> stgraber: well, definately confirmed...
[18:45] <stgraber> yay!
[18:45] <hallyn> not yay :)
[18:47] <stgraber> well, I like to have reproducable bugs that don't depend on my really weird setup
[18:49] <hallyn> :)
[19:00]  * rtg -> lunch
[19:04] <jsalisbury> herton, bjf, reverting commit a4e4c2b5 fixes bug 1080530 . 
[19:04] <ubot2> Launchpad bug 1080530 in linux (Ubuntu Precise) "v86d prevents suspend from completing" [Medium,Triaged] https://launchpad.net/bugs/1080530
[19:05] <jsalisbury> herton, bjf, Do you want me to submit an SRU request for Precise, or I could also request a revert upstream?  Or both?
[19:06] <herton> jsalisbury, looking, I think it's worth to do both
[19:06] <bjf> jsalisbury, that's a stable patch, so both for sure
[19:07] <bjf> jsalisbury, possibly an email with the original patch submitter pointing them at the bug
[19:08] <jsalisbury> bjf, email the patch submitter first to get feedback, then request a revert if that is what they think is best?
[19:08] <bjf> jsalisbury, yup, you've missed this cycle so you have a little time before the next
[19:08] <jsalisbury> bjf, ack
[19:08] <bjf> herton, that work for you?
[19:09] <herton> bjf, sure, no problem
[19:09] <bjf> jsalisbury, you might want to CC ben h.
[19:09] <jsalisbury> bjf, will do.
[19:09] <jsalisbury> bjf, herton, thanks!
[19:53] <ogasawara> rtg: fyi, herton is still working on shank bot for our automated upload announcements, so I'm just gonna craft and send an announcement for yesterday's upload.
[19:54] <rtg> ogasawara, ok. I guess 'cause it wasn't an ABI bump I didn't ..., or wait . was it ?
[19:54] <ogasawara> rtg: it was, I thought
[19:54] <rtg> oh, huess it was.
[19:54] <rtg> guess*
[19:54] <rtg> dang, I get used to infinity just noticing with me pestering him.
[19:54] <rtg> without*
[19:57] <rtg> ogasawara, so the bot is supposed to send out email when the packages transition from -proposed if the tracking bug is in the changelog ?
[19:58] <ogasawara> rtg: it's my understanding it'll send it once it detects the package has successfully built in proposed
[19:58] <bjf> ogasawara, correct
[19:58] <rtg> ack
[19:59] <rtg> bjf, which might be premature if it takes awhile to get promoted. won't some folks wanna use it immediately upon announcing ?
[20:05] <herton> rtg, we might do the announcement when it hits the release pocket instead, for the devel kernel, is that ok?
[20:06] <rtg> herton, I think that would be better. nobody should be updating from -proposed in the devel release.
[20:12] <herton> rtg, hmm, that may defeat bjf automatic testing, that we want to start when it hits -proposed I guess. But that's fixable sending the special email to the bot, and an additional to QA.
[20:12] <rtg> herton, I suspect the bot is becoming somewhat complex.
[20:12] <bjf> herton, i'd like to do the testing while it's in the -proposed pocket
[20:13] <bjf> rtg, lol, you have no idea
[20:13] <bjf> rtg, right now we are announcing when we do the upload, before it even hits -proposed in some cases
[20:14] <bjf> rtg, we do that to give the installer folks a heads-up. the purpose of doing it with shanky is to kick off automatic testing while also giving installer and other interested parties a heads-up
[20:16] <rtg> bjf, I don't have a real strong case to delay the announcement, so I guess go ahead and do it when its done building.
[20:17] <bjf> rtg, ack, when it is available in -proposed
[20:17] <herton> ack
[20:17] <rtg> yep
[20:19]  * rtg -> EOD
[22:13] <bizhanMona> HI I am using ubuntu 12.04. To DMA large raw video frames from capture device (PCIe device) to host memory, I may need large contiguous phyiscal memory area large than 4MB(page size). How is this possible?
[22:20] <arges> bizhanMona, i'm assuming this is for a device driver?
[22:20] <arges> might want to check out free-electrons.com/doc/books/ldd3.pdf
[22:23] <bizhanMona> arges: yes it is for device driver. I did not find it in any references including ldd3.pdf, but will check again to make sure. Thanks