=== lifelike_ is now known as lifelike === smb` is now known as smb [08:13] 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] rbasak, morning, thats a conundrum indeed. something that is under discussions of a sort [08:59] apw: I thought we could just turn on a generic armhf flavour? [09:00] rbasak, in theory indeed, and someone is investigating it === henrix_ is now known as henrix === amitk is now known as amitk-afk === amitk-afk is now known as amitk === yofel_ is now known as yofel === henrix is now known as henrix_ === henrix_ is now known as henrix [13:15] ogra_, are you gonna send your config patch to the kteam list ? [13:32] * henrix -> SIGFOOD [13:53] rtg, will do [14:06] rtg, sent (as you might have seen) ... dont ask why i didnt make it a module ... [14:09] ogra_, ack [14:13] ogra_: when do expect the flash-kernel fix to go in for quantal? [14:13] robher, end of the week latest, i have some other SRU bits i want to pull in as well [14:15] ogra_: great. Thanks. [14:36] henrix, i think rtg has commited that patch i was talking about for precise [14:37] apw: yep, i've seen it. i'm already on that. thanks [14:37] henrix, thanks indeed [14:39] 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] i think they may well have a cancel button actually [14:40] * henrix looks again... [14:40] if you get me the link which looks like this one [14:40] https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/4035989 [14:40] i'll find someone to wack it [14:41] apw: https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/4035989 [14:41] heh .. [14:41] and also https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/4035994 [14:41] both of those, ok [14:42] thanks. its just that there's not point keeping them building :) [14:45] henrix, there is not indeed [14:46] and we are short some computrons in powerpc right now [14:47] apw: yeah, i'm currently blocking a ppc. a 'cancel' would be a nice thing to have.. [14:47] yeah i concur [14:48] apw: ah, but someone did something, right? because the build failed [14:48] or was that a genuine failure...? [14:48] rtg, whats the cross build tools called for arm on x86 ? [14:48] gnuabi something... [14:49] henrix, no that was 'me' i got them to 'terminate' it... basically they rm -rf /build on the builder [14:49] arm-linux-gnueabihf- [14:49] apw: ah! cool :) [14:49] thanks [14:49] ogra_, is that the package ? [14:49] gcc-arm-linux-gnueabihf is the package [14:50] arm-linux-gnueabihf- is the CROSS_COMPILE prefix [14:50] b infinity [15:00] apw, That is a big wish [15:00] heh indeed [16:11] apw, https://launchpad.net/~ubuntu-x-swat/+archive/r-lts-backport [16:12] ahh great [16:39] brb [17:12] cking, drivers/acpi/acpica/dsmethod.c acpi_ds_create_method_mutex() looks like it could orphan memory [17:13] I've got a patch if you agree with my assessment [17:13] * cking has a look [17:13] diff --git a/drivers/acpi/acpica/dsmethod.c b/drivers/acpi/acpica/dsmethod.c [17:13] index aa9a5d4..fe89ea9 100644 [17:13] --- a/drivers/acpi/acpica/dsmethod.c [17:13] +++ b/drivers/acpi/acpica/dsmethod.c [17:13] @@ -151,6 +151,7 @@ acpi_ds_create_method_mutex(union acpi_operand_object *method_desc) [17:13] [17:13] status = acpi_os_create_mutex(&mutex_desc->mutex.os_mutex); [17:13] if (ACPI_FAILURE(status)) { [17:13] + acpi_ut_delete_object_desc(mutex_desc); [17:13] return_ACPI_STATUS(status); [17:13] } [17:14] cking, raring (by the way) [17:15] that looks sane to me [17:15] the patch [17:15] cking, k, I'll send it upstream [17:38] * ppisati -> gym [17:41] apw: just fyi, the precise kernel is now building [17:41] henrix, great thanks [17:41] np [17:42] hey there [17:42] I just found a weird kernel bug, introduced by 3.7 (AFAICT, wasn't there in 3.5 at least) [17:42] http://paste.ubuntu.com/1412921/ [17:43] 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] AFAICT nothing is failing, it just appears that the umount triggered against the loop device doesn't actually free it [17:44] and there's apparently no way of ever freeing it short of rebooting the machine [17:44] stgraber, perhaps hallyn or apw have some thoughts. [17:44] 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] no not seen any issues with loops on raring getting stuck so far anyhow [17:46] stgraber, what is arkose ? [17:47] stgraber, and does fuser -c say anything about /dev/loop0 in that case [17:48] root@lantea:~# fuser -c /dev/loop0 [17:48] root@lantea:~# [17:49] 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] so basically a simple lxc based sandbox [17:50] 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] stgraber, be interested in what you find [17:51] (running the same test using arkose but without the overlayfs or without the loop mounted ext4 doesn't trigger the bug) [18:04] stgraber: interesting [18:05] how is the overlayfs delta 3.5..3.7? [18:08] alright, got a reproducer outside of arkose, it's really weird though :) [18:12] hallyn, apw: http://paste.ubuntu.com/1412975/ [18:12] 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] stgraber: does the umount mount/test actually succeed? [18:14] 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] yep, everything succeeds [18:14] stgraber: that's on raring right? [18:15] yep, raring with latest 3.7 kernel [18:15] ok [18:15] I don't get this on 3.5 [18:16] * hallyn doth protest to authenticating to download text version of script [18:17] hm, can't seem to launch an instance... [18:41] stgraber: well, definately confirmed... [18:45] yay! [18:45] not yay :) [18:47] well, I like to have reproducable bugs that don't depend on my really weird setup [18:49] :) [19:00] * rtg -> lunch [19:04] herton, bjf, reverting commit a4e4c2b5 fixes bug 1080530 . [19:04] Launchpad bug 1080530 in linux (Ubuntu Precise) "v86d prevents suspend from completing" [Medium,Triaged] https://launchpad.net/bugs/1080530 [19:05] 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] jsalisbury, looking, I think it's worth to do both [19:06] jsalisbury, that's a stable patch, so both for sure [19:07] jsalisbury, possibly an email with the original patch submitter pointing them at the bug [19:08] bjf, email the patch submitter first to get feedback, then request a revert if that is what they think is best? [19:08] jsalisbury, yup, you've missed this cycle so you have a little time before the next [19:08] bjf, ack [19:08] herton, that work for you? [19:09] bjf, sure, no problem [19:09] jsalisbury, you might want to CC ben h. [19:09] bjf, will do. [19:09] bjf, herton, thanks! === henrix is now known as henrix_ [19:53] 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] ogasawara, ok. I guess 'cause it wasn't an ABI bump I didn't ..., or wait . was it ? [19:54] rtg: it was, I thought [19:54] oh, huess it was. [19:54] guess* [19:54] dang, I get used to infinity just noticing with me pestering him. [19:54] without* [19:57] 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] rtg: it's my understanding it'll send it once it detects the package has successfully built in proposed [19:58] ogasawara, correct [19:58] ack [19:59] bjf, which might be premature if it takes awhile to get promoted. won't some folks wanna use it immediately upon announcing ? [20:05] rtg, we might do the announcement when it hits the release pocket instead, for the devel kernel, is that ok? [20:06] herton, I think that would be better. nobody should be updating from -proposed in the devel release. [20:12] 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] herton, I suspect the bot is becoming somewhat complex. [20:12] herton, i'd like to do the testing while it's in the -proposed pocket [20:13] rtg, lol, you have no idea [20:13] rtg, right now we are announcing when we do the upload, before it even hits -proposed in some cases [20:14] 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] 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] rtg, ack, when it is available in -proposed [20:17] ack [20:17] yep [20:19] * rtg -> EOD === johanbr_ is now known as johanbr === lifeless_ is now known as lifeless [22:13] 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] bizhanMona, i'm assuming this is for a device driver? [22:20] might want to check out free-electrons.com/doc/books/ldd3.pdf [22:23] 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