[00:30] <eruditehermit> hey, does anyone know why amd64 versions are no longer being built in the kernel ppa?
[04:13] <eruditehermit> hey
[04:13] <eruditehermit> does anyone know why the ubuntu kernel ppa doesn't have amd64 builds for the newer kernels?
[04:18] <BenC> ericm|ubuntu: could be a build failure
[04:24] <BenC> eruditehermit: ^^
[04:39] <eruditehermit> BenC, how do I check?
[04:41] <BenC> The buildd reports for the latest package in the ppa
[07:54] <apw> eruditehermit, which kernel specifically is missing the build
[08:19]  * apw yawns loudly
[08:19] <jk-> hey apw
[08:19] <apw> jk- hey, hows it hangng
[08:20] <jk-> sleepy
[08:20] <jk-> you?
[08:21] <apw> always sleepy ... UDS is a killer
[08:22] <ohsix> hm what sort of pages exactly are these page allocation warnings about; i get them a lot when running perf while swapping
[08:26] <apw> ohsix, nominally they are reported against a process which is consuming them
[08:27] <ohsix> is it fatal to that process or is it just advisory
[08:27] <ohsix> perf doesn't die or seem to malfunction; neither does any other thing thats warned about
[08:28] <apw> most cases unless we see the oom killer stepping in you are fine, though they are telling you the kernel is struggling to get what people are asking for
[08:29] <apw> it is probabal that perf is falling back to smaller available blocks in that case
[08:29] <apw> and reducing efficiency of reporting to userspace or similar
[08:32] <ohsix> hm i'll have to check how much overcommit there is next time it happens; i know there was swap space still available in all cases that i saw
[08:33] <ohsix> i thought it was waiting for some sort of special pages but it's pretty agnostic with respect to what it is, happens to perf a lot though
[08:36] <ohsix> ooh found one, http://paste.ubuntu.com/608856/
[08:36] <apw> ohsix, perf is likely to put demands on real memory which cannot be paged
[08:36] <apw> May 15 17:43:36 krang kernel: [491791.506159] perf_2.6.38-9: page allocation failure. order:4, mode:0xc0d0
[08:37] <apw> so perf is asking for large allocations, 16 pages at a time and being denied
[08:39] <ohsix> okie dokie, i'll look more closely at the report it generates next time it's not perf; thanks for the info
[08:40] <ohsix> i have one other but its from the intel gpu dump tool running, might be similar situation to perf
[08:41] <apw> yeah probabally needs a big buffer to get the state
[08:42] <ohsix> http://paste.ubuntu.com/608862/ happened in quick succession as apport was trying to report a render error
[08:44] <ohsix> i see some suggestions about tweaking min_free_kbytes, i thought with overcommit stuff could sleep until allocations succeeded? and stuff could be ejected to satisfy it
[08:46] <apw> ohsix, yes at order 3 and below that occurs, above that there is no likelyhood of success of the eviction
[08:46] <ohsix> whats the "hi: " on per-cpu? all my reports have 186 and so do the ones i can see on google; fixed size area right?
[08:46] <apw> anyone wanting to allocate at that size is expected to handle failure gracefully
[08:46] <ohsix> ahh
[08:47] <ohsix> interesting
[08:47] <apw> hi: is the high watermark on the per node page allocation caches
[08:47] <apw> so when you free the 186 order 0 page on a cpu a batch will be given back to the global pool
[08:48] <ohsix> so where it's expected to be seen it shouldn't be a problem, unless it is and the tool needs to be fixed to accomodate the error?
[08:51] <apw> right, and you are seeing no symptoms other than the failures i think, perf keeps working so it must be moving to smaller buffers
[08:53] <ohsix> i'll have to see why it raises the error; i don't know how an app would get a chunk of memory or vm without __NOWARN ono it
[08:53] <ohsix> __GPF_NOWARN
[08:53] <ohsix> ok night; thanks for the info
[08:54] <apw> ohsix, yeah it is probabaly they should have that if they know they are coping
[09:12] <apw> smb, are we expecting any work items on your other-kernel-o-server-requirements blueprint
[09:14] <smb> apw, We could place them there though the discussion happened in the other session(s)
[09:14] <smb> I have not yet checked what is visible where
[09:14] <apw> seems reasonable to pull them onto that one, and you can own the delivery of them
[09:14] <smb> So I probably should go over things you put into your blueprints
[09:16] <apw> https://blueprints.launchpad.net/ubuntu/+spec/tr-oneiric-kernel-team
[09:16] <apw> smb, the above blueprint seems to have been made with the sole purpose of attaching all kernel blueprints to it, useful to find out blueprints though
[09:18] <smb> apw, neat. yeah I think there might be some workitems I would be adding to the server-requirement blueprint if those are not already somewhere else
[09:18] <apw> smb, where items belong on that once do move them, i moved one from config to delta cause it was more appropriate there
[09:19] <smb> apw, ok, will do
[09:20] <ogra_> hmm, is there something like skipabi=1 for the aliases check ? my custom package always dies in that part 
[09:21] <apw> cking, didn't you have some blueprints on fwts ?
[09:22] <smb> ogra_, aliases? Not sure I know what you mean. There would be skipmodules=1 for the modules check
[09:22] <ogra_> with an s ?
[09:23]  * ogra_ has skipmodule=true on his cmdline
[09:23] <smb> ogra_, maybe without. It is usually so long time between usages I look into the code
[09:23] <cking> apw, minimal one
[09:23] <apw> cking, i don't see it at all on our list, whats it called ?
[09:24] <cking> lemme recall..
[09:24] <smb> ogra_, Ok, it is without the s
[09:24] <apw> cking, also do you have a launchpad team for your team ?
[09:24] <ppisati> ogra_: watch out, sometimes it's skipmodule, others skipmodules
[09:24] <ogra_> damned, i though i had simply typoed 
[09:24] <cking> https://blueprints.launchpad.net/ubuntu/+spec/hwe-o-fwts-enhancements
[09:25] <ogra_> ppisati, sometimes ? 
[09:25] <cking> apw,  a LP team for my team??
[09:25] <ppisati> ogra_: wait
[09:26] <ogra_> debian/rules suggests it is without s
[09:26] <cking> apw, https://launchpad.net/~canonical-hwe-team perchance
[09:26] <apw> cking, was trying to work out whi i can't find the thing
[09:26] <smb> ogra_, Yep, that is right
[09:26] <apw> or more why it cannot find you
[09:26] <ppisati> watch out
[09:26] <ppisati> [flag@newluxor ubuntu-natty]$ git co ti-omap4
[09:26] <ppisati> Switched to branch 'ti-omap4'
[09:26] <ppisati> [flag@newluxor ubuntu-natty]$ grep -Ri skipmodule debian.*
[09:26] <ppisati> debian.master/rules.d/ppc64.mk:skipmodule       = true
[09:26] <ppisati> debian.master/rules.d/powerpc.mk:skipmodule     = true
[09:26] <ppisati> debian.master/rules.d/armhf.mk:skipmodules      = true
[09:26] <ppisati> it bite me once already
[09:27] <smb> ppisati, that looks a bit like arm sets it wrong...
[09:27] <ogra_> that seems to be a bug in the armhf port 
[09:27] <ogra_> which we dont use yet
[09:27] <ppisati> dunno, but yes, it's not consistent
[09:28] <smb> ogra_, Which sort of brings us back to what exactly is the failure?
[09:29] <ogra_> Checking for dupe aliases in ac100...
[09:29] <ogra_> Could not open /home/ogra/kernel/linux-ac100-2.6.37.6/debian/linux-image-2.6.37.6-1-ac100/lib/modules/2.6.37.6-1-ac100/modules.alias at debian/tests/check-aliases line 10.
[09:29] <ogra_> run-parts: debian/tests/check-aliases exited with return code 2
[09:29] <ogra_> what would create modules.alias ?
[09:30] <ogra_> seems there is no skip option for it 
[09:30] <apw> isn't that a depmod output
[09:30] <smb> That was what I was thinking too
[09:30] <apw> that is very fatal, we don't want any kernels with bad aliases, so i am not supprised there is no skip for it
[09:31] <apw> without the module.aliases your package is likely no good regardless
[09:31] <ogra_> weird, why wouldnt it be called then ... i copied my debian dirs from another package and the compile runs fine up to that point
[09:31] <apw> i think we'd need the whole log to know much more
[09:32] <smb> And probably know what exactly "copied the debian dirs from another package" means. Somehow I have a bad feeling there...
[09:32] <ogra_> bah
[09:32] <ogra_> ogra@isis:~/kernel/linux-ac100-2.6.37.6$ ls debian/linux-image-2.6.37.6-1-ac100/lib/modules/
[09:32] <ogra_> 2.6.37-1-ac100  2.6.37.6-1-ac100
[09:33] <ogra_> the latter dir is empty ... the former has the missing bits
[09:33] <apw> cking, ahh you were only proposed for oneiric
[09:33] <cking> what should it be then?
[09:33] <apw> ogra_, thats a version problem
[09:34] <apw> what is the version number in your changelog
[09:34] <ogra_> yeah i guessed as much now
[09:34] <ogra_> 2.6.37.6-1.1
[09:34] <apw> i am not sure you can have the .6 in there
[09:34] <apw> don't think that works
[09:34] <ogra_> k
[09:34] <smb> ogra_, maybe missing clean run
[09:34] <ogra_> upstream builds use it
[09:34] <smb> to update the control files 
[09:35] <ogra_> i'll drop it and re-run 
[09:35] <apw> ogra_, do you mean the mainline ones ?
[09:35] <ogra_> apw, the tree i'm building from 
[09:35] <ogra_> its a chromeos based branch with ac100 stuff on top
[09:36] <ogra_> with the last mainline merge the .6 appeaderd
[09:36] <apw> not sure how it ever built for them
[09:36] <apw> .6 in Makefile is fine, its in debian.*/changelog that its not
[09:36] <ogra_> *appeared
[09:36] <ogra_> k
[09:37]  * ogra_ starts over
[09:45] <diwic> a quick question, how do I skip building the pae kernel?
[09:46] <smb> diwic, I don't know whether you can skip individual kernels, but you can only build one flavour
[09:47] <diwic> smb, right, that's the semantic I meant to say
[09:47] <smb> diwic, with "fakeroot debian/rules binary-<flavour>"
[09:47] <smb> diwic, You may want to additionally run binary-headers once to get the generic headers part
[09:47] <smb> I mean general
[09:49] <diwic> hmm. I mistakenly thought that the backport modules shared the same infrastructure, but probably they don't (No rule to make target binary-generic)
[09:49] <diwic> Anyway I'll build both then
[09:49] <smb> diwic, No, that tends to be a bit more painful
[09:50] <diwic> argh
[09:50] <smb> First you have to get the headers from the kernel build and extract them somewhere, and then you would run the build with binary-modules-<flavour> and also need to set KDIR (I believe) to the dir where the headers are
[09:51] <diwic> I'll build the entire kernel, that's probably simplest
[09:51] <diwic> I'm making patches to the include stuff as well
[09:51] <smb> It is a bit simpler in a chroot where you can install packages. Then you can install the headers package from the kernel build
[10:01] <smb> apw, So I added some workitems to my blueprint. The target may move and I need to speak to  jjohansen about him being assigned to one
[10:01] <apw> heh you are in charge of server for the kernel, so feel free to abuse him :)
[10:02] <smb> He seemed to be more on the task there anyway. So I hope it is not really abuse. :)
[10:54] <ogra_> dpkg-deb: building package `linux-image-2.6.37-1-ac100' in `../linux-image-2.6.37-1-ac100_2.6.37-1.1_armel.deb'.
[10:55] <ogra_> ...
[10:55] <ogra_> dpkg-deb: building package `linux-headers-2.6.37-1-ac100' in `../linux-headers-2.6.37-1-ac100_2.6.37-1.1_armel.deb'.
[10:55] <ogra_> ...
[10:55]  * ogra_ hugs apw
[10:55] <apw> ogra_, yay
[10:56] <ogra_> btw, that build took 70min locally on the tegra 
[10:57] <apw> thats pretty quick
[10:57] <ogra_> i guess even if i do a complete build in chroot it will beat out builders
[10:57] <ogra_> by hours
[10:57] <amitk> ogra_: -ac100?
[10:57] <ogra_> amitk, yep
[10:58] <ogra_> rolling an image in oneiric :)
[10:58] <amitk> ogra_: congrats!
[10:58] <diwic> gaah...what's the fakeroot target for changing config options?
[10:58] <apw> glad to see you are past a .31 kernel
[10:58] <ogra_> well, the kernel is far from being done, but having an upgardeable package will help a lot to get more people working on it 
[10:59] <diwic> fdr target 
[10:59] <apw> diwic, i normally just add the option to the leaf i want it in and run fdr updateconfigs
[10:59] <apw> i think there is an fdr editconfigs but thats rather boring
[10:59] <ogra_> and david has some secret plans to equip more people with ac100's
[11:00] <smb> which is probably not so secret anymore now. :-P
[11:00] <ogra_> hehe :)
[11:02] <ogra_> LOL
[11:02] <ogra_> http://bellard.org/jslinux/ finally i can emulate x86 on arm 
[11:05] <soren> Fabrice is nuts.
[11:06] <ogra_> soren, well, that will solve all virtualization issues we have on arm ... we can just set up a webserver now *g*
[11:08] <soren> ogra_: You don't even need that, afaict. Just a javascript engine.
[11:11] <apw> ogra_, this thing eats CPU :)
[11:11] <ogra_> apw, we'll just add a "dont-eat-CPU" CSS :)
[11:12] <soren> It's an emulator written in javascript. What did you expect? :)
[11:12] <apw> soren, i expected it to be a fake ...
[11:12] <apw> heh even the compiler works
[11:12] <soren> apw: This is Fabrice Bellard, we're talking about.
[11:13] <soren> He does not have a sense of humour we're aware of.
[11:13] <soren> If he says he wrote an emulator in javascript, he means it :)
[11:15] <apw> :)
[12:13] <ogra_> apw, do you usually call debsign ../*.changes manually or are my debian dirs broken ? my package doesnt ask for a passphrase here
[12:14] <ogra_> (during source package build)
[12:14] <apw> dpkg-buildpackage -S -rfakeroot -I.bzr -I.bzr-builddeb -I.git -I.gitignore -i'\.git.*'
[12:14] <apw> ogra_, i use that and it does ask yes
[12:15] <apw> though in my common cause it fails cause i don't have the keys where i build and then i debsign -r anyhow
[12:15] <ogra_> dpkg-buildpackage -rfakeroot -S -sa -kogra@ubuntu.com
[12:15] <ogra_> thats what i use (no git bits in my source)
[12:16] <apw> so yes i would expect it to ask, cirtainly asked me last time i maked one
[12:16] <ogra_> weird
[12:17] <ogra_> it doesnt with the n900 debian dirs i used as template 
[12:19] <apw> isn't asking a something you can turn on/off by default in your personal config
[12:21] <apw> ogra_, do you have gpg installed ?
[12:21] <apw> as it won't ask you to sign unless you have gpg or pgp installed where you make the package
[12:22] <ogra_> yes, indeed i do, i use this machine for development regulary
[12:22] <ogra_> though let me check
[12:22] <apw> then i am stumped
[12:22] <ogra_> BAH !
[12:23] <ogra_> ogra@isis:~/kernel/linux-ac100-2.6.37$ LANG=C ls ~/.gnupg
[12:23] <ogra_> ls: cannot access /home/ogra/.gnupg: No such file or directory
[12:23]  * ogra_ hangs his head in shame
[12:34]  * ppisati -> lunch
[14:09] <Q-FUNK> could anybody help me with bug #783989   ?
[14:09] <ubot2> Launchpad bug 783989 in linux "spurrious EXT4 errors remount /home read-only" [Undecided,New] https://launchpad.net/bugs/783989
[14:10] <Q-FUNK> the end of dmesg seems to indicate what the cause might be, except that I don't know ext4 error codes.
[14:15] <ogasawara> kernel dudes, did we want to resume our weekly IRC meetings today?  If so, I'll prep the agenda in bjf's absence.  If not, we'll defer and start back up next week.
[14:16]  * ogasawara back in 20
[14:16] <tgardner> ogasawara, I think next week should be fine.
[14:16]  * smb does not object to push to next week
[14:26] <apw> ogasawara, yeah we have no idea whats what till the blueprints settle down
[16:09] <sconklin> tgardner: do you want to see whether you have any opinions on this before I revert the patch? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/735171
[16:09] <ubot2> Launchpad bug 735171 in linux "driver ath9k is too slow or not responding" [Undecided,Fix committed]
[16:09] <sconklin> The Natty commit is 0ce260b37b523766f7fa0dc33b6981f0d85de9e2
[16:10] <sconklin> no huge hurry, I'm about to go to the dentist and it may be tomorrow before I actually rip it
[16:11] <tgardner> sconklin, looking
[16:25] <tgardner> sforshee, can you have a look at bug #735171 ? I'm running out of time today, and sconklin thinks the patch should be reverted. '(pre stable) ath9k_hw: partially revert "fix dma descriptor rx error bit parsing' - but it may already be upstream stable.
[16:25] <ubot2> Launchpad bug 735171 in linux "driver ath9k is too slow or not responding" [Undecided,Fix committed] https://launchpad.net/bugs/735171
[16:26] <sforshee> tgardner, will do
[16:37] <jcastro> jjohansen: here's our bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/782127
[16:37] <ubot2> Launchpad bug 782127 in linux "RTL8192CE causes a lockup on a Thinkpad X120e" [Undecided,Confirmed]
[16:37] <jcastro> jjohansen: I am trying with an oneiric kernel now, it hasn't frozen yet.
[16:44] <jjohansen> jcastro: yeah but your home again, the real test is a noisy environment
[16:44] <jjohansen> jcastro: that said I installed an oneiric kernel too :)
[16:45] <jcastro> jjohansen: I will endevaour to find a noisy spot.
[16:45] <jjohansen> :)
[16:47] <jjohansen> smb: re sever work item, I had assumed I was doing that anyways as I have an apparmor work item for it from the security side of things :)
[16:47] <smb> jjohansen, I was assuming that, so I felt less guilty when volunteering you to the task. :)
[16:54] <ppisati> guys, do we have a list of options that should be turned on to make a vanilla kernel happy with an ubuntu userland?
[16:56] <apw> ppisati, nothing definative i know of
[16:57] <apw> ppisati, things we absolutly require are added to the enforce file, but thats only things we have added more recently
[16:58] <ppisati> uhm
[16:58] <ppisati> k
[16:58] <sforshee> sconklin, re bug #735171, the patch is already in the .38.5 stable release, and a couple of testers reported that the kernel in proposed fixed their problems, so I'd think we should keep the patch
[16:58] <ubot2> Launchpad bug 735171 in linux "driver ath9k is too slow or not responding" [Undecided,Fix committed] https://launchpad.net/bugs/735171
[16:59] <sforshee> probably a case of similar symptoms with different causes
[17:00] <mfilipe> will kernel-2.6.39  be released in natty?
[17:02] <apw> mfilipe, there are no plans for that no
[17:02] <mfilipe> hum...
[17:02] <mfilipe> thanks
[17:03] <apw> mfilipe, we only backport kernels to the previous LTS and only then after release
[17:05] <mfilipe> I want solve a problem with my intel graphic-card but the ickle releases patch to only 2.6.39 upstream :S
[17:06] <apw> mfilipe, we do do unsupported builds of mainline
[17:06] <apw> and if you can find the fix, we can try and get that fix into the natty kernel
[17:09] <mfilipe> https://bugs.freedesktop.org/show_bug.cgi?id=36599
[17:09] <ubot2> Freedesktop bug 36599 in Driver/intel "[i915 VGA] VGA output blurred" [Normal,Resolved: duplicate]
[17:10] <mfilipe> I tried apply the patch in kernel but the intel_bios.c is out-of-date 
[17:10] <apw> mfilipe, is there an ubuntu bug yet?
[17:10] <mfilipe> yeah... I one second that I will get the link in launchpad
[17:13] <mfilipe> apw, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/671921
[17:13] <ubot2> Launchpad bug 671921 in xserver-xorg-video-intel "External monitor using VGA has sync issues with KMS" [Undecided,New]
[18:46] <ogra_> apw, so i'm using your patch to lower the console loglevel ... if i set it to 2 as you do, i still get a lot of messages, only setting 1 quietens it, am i missing any additional bits you use with loglevel 2 ?
[18:47] <ogra_> or is my kernel just a noisy beast ?
[18:49] <apw> likely the latter i am afraig ogra_ 
[18:49] <ogra_> ok, i'll just patch it to 1 then
[18:49] <apw> heh
[18:50]  * ogra_ is really proud, the first kernel package i ever created and it builds *and* even works on first go
[18:51] <ogra_> if one looks into the build stuff its actually easier than it appears on first sight 
[18:51] <apw> ogra_, its a hairy beast, but it gives good hugs if you are nice to it
[18:51] <ogra_> hehe, well put
[20:22] <bryceh_> apw, fugly console in oneiric @ 784217
[20:26] <jjohansen> bryceh_: now that is some nice corruption
[21:21] <lamont> did 2.6.37 make getrlimit() privileged such that a non-$foo process cannot determine, among other things, it's open file limit?
[22:02] <jjohansen> lamont: not that I know of, there was some rlimit work to rework how its done in the kernel, change the locking and move around where the security check is done but getrlimit shouldn't be privileged
[22:13] <lamont> jjohansen: so bugs.debian.org/626928 (and 627026) should be referred to the kernel there?
[22:13]  * jjohansen looks
[22:21] <jjohansen> lamont: commit fc832ad3645f0507f24d11752544525a50a83c71 at least at first glance seems to be the fix
[22:21] <jjohansen> so yeah forward to their kernel with that commit #
[22:26] <jjohansen> lamont: or it might be commit aa5bd67dcfdf9af34c7fa36ebc87d4e1f7e91873 that fixed it