=== bjf is now known as bjf[afk]
=== emma_ is now known as emma
=== hrw|gone is now known as hrw
[08:37] <apw> yawn
[08:37] <smb> Coffee!
[08:37] <smb> Reminds me there is some in the Kitchen I forgot to bring with me
[08:38] <RAOF> I *always* do that!
[08:39] <smb> Must be some natures law... :)
[08:44] <jk-> that's to tell you that you need a coffee :)
[08:55] <cooloney> kengyu: around? my FISH man
[09:04] <kengyu> cooloney, anything can I help, guess we move to hwe?
[10:03] <kraut> moin
=== amitk is now known as amitk-afk
=== smb is now known as smb-afk
=== amitk-afk is now known as amitk
=== fddfoo is now known as fdd
=== smb-afk is now known as smb
[12:38] <apw> https://edge.launchpad.net/ubuntu/+source/linux
[12:47] <lag> apw: https://edge.launchpad.net/ubuntu/lucid/+package/linux-image-2.6.32-22-generic
[12:48] <apw> https://edge.launchpad.net/~ubuntu-security/+archive/ppa/+build/1770776/+files/linux-image-2.6.32-22-generic-pae_2.6.32-22.36_i386.deb
[13:26] <pgraner> apw: http://pastebin.ubuntu.com/461105/
[14:11] <lag> ubuntu-2.6$ addr2line -f -e debian/build/build-omap/vmlinux bf1baad0
[14:11] <lag> ??
[14:11] <lag> ??:0
[14:11] <lag> apw --^
[14:44] <Flek74> Hello Ubuntu-Developers!
[14:44] <Flek74> I have a problem on my Ubuntu 10.04
[14:46] <JFo> Flek74, is it kernel related and have you opened a bug?
[14:46] <Flek74> I already opened an issue on launchpad
[14:47] <JFo> ok, what is the bug number?
[14:47] <Flek74> maybe it is kernel related, maybe not
[14:48] <Flek74> ok it's bug 581847
[14:48] <ubot2> Launchpad bug 581847 in linux (Ubuntu) "system crash after changing power supply (affects: 1) (heat: 69)" [Undecided,Incomplete] https://launchpad.net/bugs/581847
[14:49] <Flek74> with my probook 6545b
[14:50] <Flek74> I already tried to install the ubuntu mainline kernel
[14:52] <Flek74> It's running, with the restriction, that W-LAN isn't working anymore because it's a Broadcom device
[14:56] <Flek74> I know how to develop in C/C++, therefore I already tried to locate the bug.
[14:57] <Flek74> But it is very difficult if you didn't do anything on the kernel so far.
[15:11] <JFo> this looks like something in the power control area of the kernel perhaps.
[15:12] <marco74> I also thought about this
[15:12] <JFo> I've tagged it as such and will ask about it when manoj gets in to see what he thinks
=== amitk is now known as amitk-afk
[15:12] <marco74> i already tried to compile some kernel.org-kernles
[15:12] <marco74> thank you
[15:13] <JFo> no problem
[15:13] <JFo> did you try the mainline builds?
[15:14] <marco74> 2.6.31, 2.6.32. 2.6.33
[15:15] <marco74> also 2.6.34 from the website you meantioned
[15:15] <JFo> any difference in behavior?
[15:15] <marco74> yes
[15:16] <marco74> 2.6.31 work, with problems in graphics and sound
[15:16] <JFo> would you mind describing the difference and which kernel it was in on the bug?
[15:16] <JFo> that way all who look at it can see what progression there is
[15:16] <marco74> you mean on lauchpad?
[15:16] <JFo> yes, please :)
[15:16] <marco74> ok I'll do that
[15:17] <JFo> thank you
[15:17] <marco74> the tests with the kernel.org kernel result was that all 2.6.32 kernels do not work
[15:18] <marco74> Therefore I also tried 2.6.31 and 2.6.32-rc*
[15:18] <JFo> I suspect that may be due to missing ubuntu configs that are in the mainline builds
[15:19] <marco74> I used make localmodconfig
[15:19] <marco74> then i set the option with the SATA-Driver from module to an asterisk * that I was able to boot from it
[15:20] <marco74> because the initrd option on make-kpkg doesn't work
[15:25] <JFo> add that information to the bug as well please, that is good to know.
=== permalac is now known as permalac_
[15:47] <jcrigby> apw: ping?
[15:47] <apw> hi
[15:48] <jcrigby> apw: I've been reading the AbstractedDebian wiki page and have some questions
[15:49] <jcrigby> apw:I'm doing the packaging for the linaro kernel
[15:50] <jcrigby> and one possibility would be to follow the directions for creating my own branch, but I really want my debian.linaro to track debian.master so copying seems like it will create more work in the long run
[15:51] <bjf> pgraner, http://kernel.ubuntu.com/~bradf/table.html (still needs work and data specific to 'linux')
[15:52] <tgardner> jcrigby, the point of the abstracted debian is that your debian.linaro branch should contain nothing more then configs, control.d flavour files, and ABIs
=== sconklin-gone is now known as sconklin
[15:53] <tgardner> everything else should be in debian
[15:53] <pgraner> bjf: looking good very interesting results
[15:54] <jcrigby> tgardner:yes, I realize that
[15:55] <tgardner> jcrigby, so, what is it in debian.master that you wish to track?
[15:56] <jcrigby> tgardner:as I look at the branch history it seems like the debian.master changes as often as the actual content so it seems a shame to redo that for debian.linaro
[15:57] <tgardner> jcrigby, mostly config changes I assume ?
[15:57] <jcrigby> tgardner:I think my actual problem is having no experience with the actual release process
[15:58] <jcrigby> tgarder:and the abi changes
[15:58] <tgardner> jcrigby, there are likely a lot of changelog and ABI noise that don't really have any relevance to Linaro
[15:58] <tgardner> the only stuff that might be relevant are config changes 
[15:59] <jcrigby> tgarder:yes, so I will stop over thinking this and go ahead and make my branch and go from there
[15:59] <tgardner> jcrigby, we'd be happy to review one you have something in place
[15:59] <tgardner> once*
[15:59] <jcrigby> tgardner:great, thanks
[15:59] <smoser> hey all. I'm wondering what the suggested way of avoiding building a ramdisk would be.
[16:00] <smoser> It appears that setting 'ramdisk = /bin/true' in kernel-img.conf will work.
[16:01] <BenC> smoser: I'm pretty sure do_initrd = false in that same file will do it
[16:01] <smoser> and, building on that, my guess is I can specify something that would wrap /usr/sbin/update-initramfs , not invoking it if the version based on some criteria.
[16:01] <apw> jcrigby, ok am in a meeting now for a bit
[16:01] <jcrigby> apw:tgardner stepped in and helped me
[16:02] <jcrigby> no more questions for now
=== bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - July-13 - 17:00 UTC
=== panda is now known as Guest52344
[16:07] <smoser> BenC, no. it has no effect.  neither that, nor ramdisk is documented in man pages installed by kernel-package
[16:07] <smoser> but going based on http://www.tin.org/bin/man.cgi?section=5&topic=kernel-img.conf
[16:09] <BenC> smoser: interesting...the kernel postinst checks that do_initrd value but never uses it :-/
[16:09] <BenC> sounds like a bug
[16:09] <smoser> yeah. i think its just old.
[16:10] <smoser> but that link, the documentation doesn't even suggest that this indicates whether or not a ramdiks will be built. but rather only about silencing a warning.
[16:17] <BenC> smoser: do_initrd is supposed to do this
[16:18] <smoser> well, even then, i'd like to do it based on criteria. and a global boolean wouldn't suffice.
[16:19] <BenC> smoser: you can also do something like: 
[16:19] <BenC> sudo dpkg-divert --local --divert /usr/sbin/update-initramfs.orig --add /usr/sbin/update-initramfs
[16:19] <BenC> sudo ln -s /bin/true /usr/sbin/update-initramfs
[16:19] <BenC> but that's pretty hard core
[16:20] <smoser> with the update-initramfs wrapper, i can check kernel characteristics of the specific kernel
[16:20] <maks_> we don't support !initramfs, as going down that road lots of things break
[16:20] <smoser> maks_, thats not true.
[16:20] <maks_> no UUID, fun with latest md
[16:20] <maks_> smoser: you  know nothing.
[16:21] <BenC> maks_: it should be supported on VM's and chroots
[16:21] <smoser> well, i know that a.) no initrd does function b.) things that break it are considered bugs and are fixed c.) we have supported images without ramdisks.
[16:21] <maks_> no Ubuntu has never supported that.
[16:21] <maks_> it happened to work.
[16:22] <BenC> maks_: regardless of ubuntu supporting it, he wants to do it, and that's his choice
[16:22] <maks_> sure if he wants to shoot in his foot I won't give him a gun for that
[16:22] <BenC> There's tons of reasons outside of your limited scope that could warrant disabling ramdisk generation
[16:22] <smoser> as for "supported", it was a feature added to lucid EC2 and UEC images.  they ship without a ramdisk.
[16:22] <BenC> maks_: then shut it, and let me talk to him
[16:23] <jpds> Is there another around who can help me with an ACPI issue on a Toshiba laptop? (http://ubuntuforums.org/showthread.php?t=1473317)
[16:23] <BenC> smoser: exactly...I use EC2 that doesn't have ramdisk support as well
[16:24] <smoser> (well, it does have ramdisk support, but we chose not to use ramdisks there for both speed and maintainance reasons)
[16:24] <maks_> lol
[16:24] <maks_> BenC: good.
=== hrw is now known as hrw|gone
[16:25]  * BenC is anti gun control
[16:26] <BenC> let 'em all have guns
[16:26] <warewolf> guns don't kill people, apes with guns kill people
[16:27] <TeTeT> how do I get a current or past ABI file for my kernel to be compiled in a PPA? See http://launchpadlibrarian.net/51628419/buildlog_ubuntu-lucid-i386.linux_2.6.32-24.38~lvm0_FAILEDTOBUILD.txt.gz for details
[16:27] <BenC> TeTeT: you should just always bump the ABI in a PPA build
[16:28] <BenC> TeTeT: and maybe set the var that disables ABI checking
[16:28] <TeTeT> BenC: how to do that?
[16:28] <BenC> abi_check=false?
[16:28] <smoser> BenC, well, it looks to me like the only functional way to do this is via 'ramdisk ='.  i went looking once before (possibly lucid time frame) and saw the 'do_initrd', and believe that then it still had no affect.
[16:28] <BenC> Can't remember, but it's in debian/rules.d/0-* IIRC
[16:29] <BenC> smoser: I'd file a bug...kernel-img.conf should either honor do_initrd or remove it from existence
[16:29] <smoser> well, its not documented in the man page
[16:29] <smoser> and ignored in the post install scripts
[16:30] <smoser> so, other than a useless variable name in a post install script, its gone from existance.
[16:30] <maks_> kernel-img.conf is disappearing
[16:31] <maks_> it is a vestige from kernel-package times as you'd know BenC 
[16:32] <smoser> maks_, would you care to share what it is being replaced with ?
[16:32] <maks_> why would I as you know everything smoser 
[16:34] <smoser> well, for others in the room of course.  maybe if I admit to my non-omnipotence
[16:38] <jjohansen> apw: you doing the status meeting?
[16:39] <apw> jjohansen, have already done kernel yes
[16:39] <apw> jjohansen, though you could talk me through where we are with AA and EC2 plan wise
[16:40] <smoser> seriously, i'm not intending to be rude, but would like to know what the best solution to this.
[16:40] <jjohansen> apw: already :(
[16:41] <BenC> smoser: sounds like a hack is in order since kernel-img.conf is broken and doesn't seem to have a plan to be fixed
[16:42] <smoser> well, even if it were functioning properly, it wouldn't get me what i'm interested in.
[16:42] <smoser> i'd like to disable ramdisk creation, and then consumption by grub, on a per-kernel basis.
[16:43] <smoser> but ideally, i'd like to do so in a way that will continue to work in the future.
[16:44] <jjohansen> apw: AA just pulling together patches and updates, I have some test kernels for Bug #599450, Bug #581525 that I am testing and will push out for verification, I also need to test the userside component for Bug #581525, basically I am trying to pull together my next submission today
[16:44] <ubot2> Launchpad bug 599450 in linux (Ubuntu Maverick) (and 1 other project) "[apparmor] getattr handled incorrectly in 2.6.35-6.7 (affects: 3) (dups: 2) (heat: 457)" [High,New] https://launchpad.net/bugs/599450
[16:44] <ubot2> Launchpad bug 581525 in apparmor (Ubuntu) "Lucid: system becomes unstable randomly, seems related with apparmor (affects: 4) (heat: 89)" [Undecided,New] https://launchpad.net/bugs/581525
[16:45] <jjohansen> apw: EC2, I got a nive little email from amazon about pv-ops and hope to kick off a test build of a new pv-ops kernel this morning
[16:46] <apw> jjohansen, sounds about what i wrote :)  excellent
[16:46] <apw> hows the upstreaming looking?
[16:46] <apw> any sign of it getting into security tree?
[16:47] <jjohansen> apw: well I am hopeful
[16:47] <jjohansen> it should be soon
[16:48] <jjohansen> basically I am hoping before sprint, quick turn around next week if needed type of thing
[16:49] <BenC> smoser: sounds like you will have to divert update-initramfs and replace it with a wrapper that checks your own config file...put that in a package, and you have something that works pretty well for your usage
[16:50] <pgraner> jjohansen: sooner is better
[16:52] <jjohansen> pgraner: ack
[17:01] <kees> apw: did you get a chance to look at my i915 fix?  it's really trivial, but would let me actually boot a maverick kernel again...
[17:01] <apw> sorry no that i recall
[17:08] <tgardner> kees, you got some heat about the constant. did you ever reconcile that with upstream?
[17:09] <kees> tgardner: upstream wants a perfect fix; but it _was_ a constant in all versions prior.
[17:09] <kees> tgardner: this just unbreaks it without re-breaking the piece they fixed for other hardware
[17:10] <tgardner> kees, well, you're so good at windmill tilting lately, why don't you have a go at them about it ?
[17:10] <kees> tgardner: I have for weeks, they're just ignoring me.
[17:10] <tgardner> kees, ok, I'll have a look at it.
[17:10] <kees> tgardner: but as it stands, it's a regression, and the fix is insanely trivial.
[17:11] <tgardner> kees, I agree, but wanted to make it did not in turn introduce a regression
[17:11] <tgardner> make sure*
[17:13] <kees> tgardner: right, understood.  if you look at the patch, it replaces two sets of constants (for G33 and non-G33) with autodetection magic.  the intent was to fix this for the non-G33 case, which is nice and all, but they _added_ autodetection for G33 that is not needed and is wrong.  So by making the G33 case static again, it fixes the regression they introduced without re-breaking the non-G33 case they fixed.
[17:13] <kees> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f1befe71fa7a79ab733011b045639d8d809924ad
[17:13] <kees> it was this:
[17:13] <kees> int gtt_map_size = 256 * 1024;
[17:13] <kees> if (IS_G33)
[17:13] <kees>     gtt_map_size = 1024 * 1024; /* 1M on G33 */
[17:14] <kees> now it's:
[17:14] <kees> gtt_map_size = intel_i915_get_gtt_size();
[17:14] <kees> and if you look in that new function, the G33 case is what's regressed.
=== psurbhi is now known as csurbhi-afk
[17:14] <apw> kess, the only thing thats odd is you leave in the autodetect login
[17:15] <kees> apw: I'm happy to remove it.
[17:15] <kees> I just want to boot maverick again.  :P
[17:16] <tgardner> kees, refresh my memory on where your patch is?
[17:17] <tgardner> its on the k-t list, right?
[17:17] <kees> yup
[17:17] <kees> https://lists.ubuntu.com/archives/kernel-team/2010-July/011457.html
[17:19] <tgardner> kees, well, that just slams the previous calculation of size. what is your gmch_ctrl for that device? It looks like there is a missing case.
[17:20] <kees> tgardner: mine reports 2M, which is wrong because half is a shadow gtt.  upstream said, "yeah 1M is correct.  gee, we should find someone that knows the hardware better"
[17:20] <kees> tgardner: see https://bugzilla.kernel.org/show_bug.cgi?id=16294
[17:20] <ubot2> bugzilla.kernel.org bug 16294 in Video(DRI - Intel) "[Q35 bisected] hang at init of i915 driver" [High,New]
[17:20] <tgardner> ah, I remember taht now.
[17:22] <kees> tgardner, apw: here's a new patch that throws the entire auto-detect section out: https://lists.ubuntu.com/archives/kernel-team/2010-July/011575.html
[17:23] <tgardner> kees, how old is this laptop? it must be approaching 3 years
=== sconklin is now known as sconklin-afk
[17:24] <tgardner> I wonder if there is a way to quirk this on sub-vendor ID ?
[17:24] <kees> tgardner: this is not my laptop; it's my all-Intel primary desktop.  A very common Q35 motherboard.
[17:24] <kees> tgardner: my Dell laptop with the ATI issues I gave up on.
[17:25] <kees> http://www.google.com/search?client=ubuntu&channel=fs&q=intel+q35
[17:25] <tgardner> well, I thought the i810 was dead. little did I know...
[17:26] <kees> it's not i810.  I wish it was -- then I'd have a built-in RNG.
[17:26] <kees> tgardner: anyway, the issue isn't trying to do the calculation correctly (I'll leave that to upstream to figure out), it's to get rid of a regression.
[17:27] <tgardner> kees, well, lemme study it. I might be able to do both.
[17:28] <kees> tgardner: could you maybe study it after fixing the regression?  I can't test any maverick kernels without rebuilding them first.  :P
[17:28] <kees> the gtt size for G33 has been 1M since the beginning of time.
[17:28] <tgardner> I promise I'll either find a solution or implement your patch today. OK?
[17:29]  * kees hugs tgardner
[17:29] <kees> tgardner: thanks!  I've literally spent days tracking this down and trying to get it fixed.
[17:46] <tgardner> apw, does ureadahead run on every boot cycle?
[17:51] <apw> tgardner, yes only recording when the pack is missing
[17:52] <apw> which is cleaned up by any updated to 'main' or somethign in dpkg
[17:56] <tgardner> apw, I guess I'm not clear on if it even loads if the pack is not missing.
[17:57] <apw> if the pack is missing then it runs in learn about the system mode and and uses ftrace
[17:57] <apw> otherwise it just uses the pack to load things
[17:57] <tgardner> apw, so it loads in either casem which means tracing gets enabled.
[18:01] <apw> hrm, ok ... not so hot
[18:02]  * bjf running an errand, biab
=== bjf is now known as bjf[afk]
[18:16] <tgardner> kees, you running amd64 I assume?
=== sconklin-afk is now known as sconklin
[18:38] <kees> tgardner: yeah
[18:39] <tgardner> kees, k, I'll have a test kernel in a bit. the dope that coded this used the wrong macros
[18:39] <tgardner> I think.
[18:39] <kees> tgardner: wrong macros?
[18:39] <tgardner> I'll reply to the m-l with my patch.
[18:45] <JFo> <-lunch
[18:50]  * apw cracks a cold one ... its tooo hot to concentrate here
[18:50] <tgardner> kees, tangerine.buildd:kern/maverick/kern-64/linux-image-2.6.35-7-generic_2.6.35-7.12_amd64.deb
[18:51] <tgardner> server will be up soon
=== bjf[afk] is now known as bjf
=== tgardner is now known as tgardner-lunch
[18:51]  * bjf is back
[19:03] <cking> apw, you are making me drool
[19:03]  * cking has things to attend to. Have a good weekend
[19:07]  * gnarl makes final uploads while reaching half of his cold one
[19:14] <tgardner-lunch> kees, tangerine.buildd:kern/maverick/kern-64/linux-image-2.6.35-7-server_2.6.35-7.12_amd64.deb
=== tgardner-lunch is now known as tgardner
[20:32] <jjohansen> -> Lunch
[20:37] <mpoirier> git bisect start
[20:37] <mpoirier> git bisect good v2.6.35-rc4
[20:37] <mpoirier> git bisect bad v2.6.35-rc3
[20:40] <tgardner> mpoirier, git log v2.6.35-rc3.. -- arch/arm/
[21:23] <kees> tgardner: booting it now...
[21:32] <kees> tgardner: \o/ it worked!  :)
[21:32] <tgardner> kees, cool
[21:34] <tgardner> kees, can I add your tested-by ?
=== sconklin is now known as sconklin-gone
[22:52]  * jjohansen heads for a walk, back on in a bit
=== bjf is now known as bjf[afk]