=== BenC1 is now known as BenC
[01:27] <ogasawara> kees: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/597075/comments/20 , I posted the test kernel in that comment
[01:27] <ubot2> Launchpad bug 597075 in linux (Ubuntu) "2.6.35 hangs at boot due to regression in i915 or intel_agp (affects: 1) (heat: 3382)" [Undecided,Triaged]
[01:28] <ogasawara> kees: I've gotta bail for a few hours but let me know (either here or in the bug) if that kernel boots or hangs
[03:22] <psusi> jjohansen, you remember that screwed up memory problem I was talking about the other night?  it's back... and I found a thread on the maverick testing boards and think it correctly identifies the cause as ureadahead doing a profile and mounting the debugfs... funny though though, is that the slab info doesn't seem to show the allocated memory anywhere
[03:36] <psusi> son of a bitch... it's the fscking trace buffer...
[07:30] <cking> morning lag
[07:30] <lag> Morning :)
[07:30]  * lag has a fuzzy head :)
[07:33] <jjohansen> cking, lag: good evening and good night :)
[08:41] <dmarkey> anyone know where i can get the config.gz for http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.34-lucid/
[08:42] <amitk> dmarkey: don't you see it in /proc/config.gz when you boot the kernel?
=== ogra_ is now known as ogra
[08:43] <dmarkey> nope, aint there
[08:44] <dmarkey> cant waste precious memory on that it seems :)
[08:47] <soren> dmarkey: All Ubuntu supplied kernel packages should be accompanied they their config in /boot/config-<version string>
[08:51] <dmarkey> ah yes, there we go
[08:51] <dmarkey> hanks
[08:55] <VanessaE> question:  I have a Dell Inspiron 9200 laptop.  All components seem to work fine except USB.  The kernel detects it, but no devices are recognized.  Nothing I plug in seems to get any reaction at all, except that power to the port seems to work.
[08:56] <VanessaE> no USB-related messages of any kind are added to dmesg except during the kernel's initial scans of the USB controller/hub.
[09:49] <dholbach> hey guys
[09:50] <dholbach> we're planning Ubuntu Developer Week right now - would anyone of you interested in talking a bit about kernel team workflow, getting fixes in, dkms or anything else?
[09:50] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the preliminary schedule
[09:54] <kraut> moin
[12:39] <apw> moin
[12:56] <ogra> apw, up early ? 
[12:56] <smb> ogra, Heh, its just one hour difference in tz
[13:09] <apw> cking, http://www.mail-archive.com/debian-bugs-forwarded@lists.debian.org/msg13966.html
[13:09] <apw> this might be what is triggering which seems like a miss implementation of the backoff mechanism
[13:09] <cking> apw, that's great - thanks!
[13:10] <apw> cking, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509089
[13:10] <ubot2> Debian bug 509089 in dhcp3-client "dhcp lease negotiation takes longer than necessary" [Normal,Open]
=== kentb is now known as kentb_home
[13:11] <apw> cking, that bug has the patches, and it looks like if we had them you'd need a configuration change too in /etc/something
[13:14] <cking> apw, hopefully awe can pick that work up as it's his kinda domain
[13:14]  * cking punts
[13:14] <apw> cking, yep
[13:28]  * cking lunches
[13:45] <tgardner> ccheney, that last commit 41440ffe21f29bdb985cab76b2d0b06d83e63b19 didn't build. Am investigating
[13:47] <ccheney> tgardner, ok
[14:39] <Daviey> Hey!  Is there an informal freeze date for the A2 release?
[14:42] <ccheney> tgardner, Daviey's question is in relation to potentially getting the kernel fixed for the issue we are investigating before A2
[14:43] <tgardner> ccheney, dunno about a fix yet. today is likely the last day that ogasawara will accept patches for A2
[14:43] <ccheney> tgardner, ok
[14:43] <ccheney> Daviey, see ^
[14:43] <tgardner> it depends on _what_ the fix is.
[14:43] <ccheney> ok
[14:44] <tgardner> ccheney, plan a lucid kernel for your UEC A2 release
[14:44] <ccheney> o
[14:44] <tgardner> plan on*
[14:44] <ccheney> er ok
[14:58] <tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/41440ffe21f29bdb985cab76b2d0b06d83e63b19-maverick/linux-image-2.6.32-020632g41440ff-generic_2.6.32-020632g41440ff_amd64.deb
[14:58] <ccheney> tgardner, thanks
[15:05] <ccheney> tgardner, appears good, test still running
=== sconklin-gone is now known as sconklin
[15:06] <tgardner> ccheney, k, lemme know for sure.
[15:35] <ccheney> tgardner, i'm doing an extra test this time to make sure that lack of the error means its actually fixed, may take about 30m, will let you know when i'm done, that kernel though didn't show the error message expected
[15:35] <tgardner> ccheney, ack
[15:37]  * ccheney had to reinstall his node controller due to breakage, so he can make it run an instance using the image that was supposedly properly registered
=== bjf[afk] is now known as bjf
[16:07] <ccheney> tgardner, it got a bit more involved my cloud controller apparently forgot how to see nodes so i am reinstalling it too
[16:08] <ccheney> tgardner, once that is done i will test the 701791c to make sure it still fails and then retest 41440ff to see it works and then run the instance, assuming it can see the NC again
[16:08] <tgardner> ccheney, ack
[16:08] <tseliot> apw: I've sent both of my patches for radeon to the kernel mailing list
[16:11] <ogasawara> tseliot: The second email doesn't seem to include the patch, "Add support for the ATIF ACPI method to the radeon driver"
[16:12] <tseliot> ogasawara: oops, let me attach the patch then
[16:12] <ogasawara> tseliot: you mention it's been accepted upstream and should land in 2.6.36 which is great.  Is the patch residing in an upstream maintainers tree at the moment?
[16:13] <ogasawara> tseliot: if so, could you point us to which tree and commit just so we can track it
[16:14] <tseliot> ogasawara: AFAIK they're trying to see if they can include it in 2.6.35 (if Linus agrees)
[16:14] <ogasawara> tseliot: Ooo even better
[16:14] <tseliot> patch sent
[16:41] <MaximLevitsky> what udev maveric will eventually use?
[16:48] <sconklin> https://bugs.launchpad.net/ubuntu/lucid/+source/linux/+bug/590783
[16:48] <ubot2> Launchpad bug 590783 in linux (Ubuntu Lucid) (and 1 other project) "Lucid sfc stable updates from 2.6.33.4 (affects: 1) (heat: 241)" [Medium,In progress]
[16:54] <gnarl> sconklin, Are there newer things than there are already in or did that not get updated with the upload?
[16:55] <sconklin> gnarl: I'm not following you
[16:56] <gnarl> sconklin, I just saw you posting the sfc update bug number
[16:56] <gnarl> sconklin, And the current proposed kernel wold contain some updates to sfc from 2.6.33
[16:56] <sconklin> That's one of the patches I'm putting on my branch for you to inspect, and I was adding the buglink, and the bug was marked incomplete, so I asked Tim about it
[16:56] <dholbach> we're planning Ubuntu Developer Week right now - would anyone of you interested in talking a bit about kernel team workflow, getting fixes in, dkms or anything else?
[16:57] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the preliminary schedule
[16:57] <sconklin> gnarl: that's interesting because the patch applies
[16:57] <gnarl> sconklin, Hm, maybe I so much was about to do it that I thought I had ...
[16:57] <sconklin> gnarl: I'm about to fetch a fresh tip and reapply them, let me try that
[16:58] <gnarl> sconklin, Ok. It could really just be that I thought to have done without actually having done so
[16:58] <sconklin> gnarl: possibly, because there was no APPLIED message sent and it was not marked as acked in patchworks
[16:59] <gnarl> sconklin, So you better just ignore me
[16:59] <gnarl> sconklin, Cannot see anything sfc related applied recently
[16:59] <sconklin> gnarl: at my peril . . . :)
[17:01] <sconklin> gnarl: yes, it applied ok, and I've just pushed to the stable-lucid branch in my repo on zinc. If that passes your inspection I will apply those patches to the master and push to the distro repo
[17:02] <gnarl> sconklin, Ok let me look right away
[17:03] <sconklin> in sconklin/ubuntu-lucid.git
[17:03] <gnarl> That would have been my guess
=== Azelphur is now known as World
[17:09] <gnarl> sconklin, Ok, two things which sadly will cause work for you, sorry about that. First (simpler) in the patch from Keng-Yü I'd add his signed-off-by (as he should have done). As those patches are actually in 2.6.33.y I would take those add a buglink, our acks and your sob. So we really follow the specific updates instead of one monolithic patch.
[17:15] <sconklin> gnarl: add a buglink, our acks and my sob to what?
[17:15] <sconklin> 2.6.33y patches somewhere?
[17:15] <gnarl> sconklin, to the patches you would export from the 2.6.33.y tree
[17:16] <sconklin> oh, I see.
[17:16] <apw> gnarl, does he know about your mass patch updater script
[17:16] <sconklin> gnarl: well ok, that's why we're doing it this way. Let me refactor it and then you can look again
[17:16] <apw> ie, about exporting them as patches using that to add acks to the right ones etc and them git am ing them back onto the branch
[17:16] <gnarl> sconklin, yes. You know you can get only those by git log (or format-patch) with the path added?
[17:17] <gnarl> apw, Since yesterday, he should I beleive
[17:17] <sconklin> gnarl: yes, thanks, though
[17:17] <gnarl> If I did not dream again
[17:17] <apw> good enough :)
[17:17] <sconklin> no, we talked about it yesterday
[17:18]  * bjf will brb
=== bjf is now known as bjf[afk]
[17:35] <sconklin> The Best Buy chumby-like ARM device is intentionally hackable, and $179 USD http://www.bunniestudios.com/blog/?p=1140
[17:41] <ccheney> tgardner, the 41440ff is good
[17:41] <tgardner> ccheney, ack
[17:41] <ccheney> tgardner, verified with a running instance after rebuilding my cloud
[17:42] <tgardner> ccheney, did you reverify the other versions? Or do you think it necessary ?
[17:42] <ccheney> tgardner, i don't think its necessary, i saw something in the log for 41440ff that i thought might mean it was still broken but differently, but its running ok
[17:43] <ccheney> tgardner, the older failed ones showed the pad block corrupted issue
[17:43] <ccheney> i can do a quick smoke test to make sure its broken on 701791c
[17:43] <tgardner> ccheney, k, I'll start the next build in the meantime
[17:43] <ccheney> shouldn't take more than 10m to verify its actually broken
[17:49] <apw> tgardner, homing in on a bug ?
[17:50] <tgardner> apw, bisecting to see when the UEC guest kernel stopped loading
[17:50] <apw> is this one where we seem to have a kernel interaction with uec, with the java bit ?
[17:50] <tgardner> yep
[17:51] <apw> getting close yet ?
[17:51] <tgardner> apw, oh yeah, we're homing in on it. perhaps 3 or 4 more kernels
[17:51] <ccheney> tgardner, its in pending state now, will wait a couple minutes to make sure it is stuck
[17:52] <tgardner> apw, bug #588861
[17:52] <ubot2> Launchpad bug 588861 in linux (Ubuntu Maverick) (and 4 other projects) ""pad block corrupted" error when trying to register an image with 2.6.34 kernel (affects: 1) (heat: 12)" [High,In progress] https://launchpad.net/bugs/588861
[17:52] <ccheney> apw, we're down to 2 days of commits, which may be a lot for the kernel (not sure the exact number in between)
[17:53] <tgardner> ccheney, 641 commits left after this next build
[17:53] <apw> ccheney, could be lots, could not be all depends 
[17:53] <ccheney> heh ok, yea i thought they get a pretty large amount per day
[17:53] <ccheney> should be less than 10 kernels anyway :)
[17:54] <ccheney> maybe we'll get lucky
[17:54] <ccheney> ok i'm calling 701791c bad its still not starting and had the same pad block corrupted message
[17:55] <tgardner> ccheney, wfm
=== bjf[afk] is now known as bjf
[18:40] <sconklin> gnarl: I just pushed a new stable-lucid branch to my repo, which should address the things we talked about.
=== sconklin is now known as sconklin-lunch
[18:40] <gnarl> ok looking
[18:43] <ccheney> tgardner, new kernel failed to build also, not sure if its the same issue as before
[18:43] <tgardner> ccheney, it is, I've corrected it and am continuing the build
[18:43] <ccheney> ok
[18:43] <gnarl> sconklin-lunch, sfc patches look good. The sob of keng-yü should be reordered to be the first one. then the acks and you sob
[18:44] <tgardner> gnarl, what does keng-yu have to do with the sfc patches?
[18:44] <gnarl> tgardner, nothing. thats another patch
[18:45] <gnarl> I might have been a bit ambiguous there
[18:45] <tgardner> hmm, just a bit
[18:54] <tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/23eb3b64b5e44680c867e165fe1cd18e57fba255-maverick/linux-image-2.6.32-020632g23eb3b6-generic_2.6.32-020632g23eb3b6_amd64.deb
=== sconklin-lunch is now known as sconklin
[18:59] <sconklin> gnarl: should I that one thing (kengyu sob) and push to distro?
[18:59] <gnarl> sconklin, sure go ahead
[19:00] <ccheney> tgardner, thanks
[19:02] <tgardner> ccheney, lunch, back in 20-30
[19:02] <ccheney> tgardner, ok
[19:10] <ccheney> tgardner, that one looks good as well, will run an instance since you will be gone for a bit
[19:15] <sconklin> gnarl: pushed, you can review it if you want and make sure it's ok
[19:15] <gnarl> sconklin, np. a sec
[19:21] <gnarl> sconklin, Looks fine by me. So we will see that tomorrow as a new pre-proposed if apw has not broken things while fixing them. :-P
[19:28] <kees> ogasawara: gah, sorry, I got it wrong.  .35-1.1 works, .35-2.2 fails.  I've updated 597075 to reflect this.
[19:28] <ogasawara> kees: cool, maybe less to look at then
[19:29] <ogasawara> kees: if I recall correctly, 2.6.35-1.1 was -rc1 based and 2.6.35-2.2 was -rc2 based
[19:29] <kees> oh good, I was worried it would be worse.  :P
[19:33] <tgardner> ccheney, ack, will start the next build
[19:41] <ccheney> tgardner, thanks, just had phone call, sorry for the lag
=== sconklin is now known as sconklin-afk
=== ayan is now known as ayan-afk
[20:02] <ogasawara> kees: http://people.canonical.com/~ogasawara/lp597075/9553426/ , whenever you have time to test
[20:02] <ogasawara> kees: the deb has an odd 2.6.34 version name but please test anyways
[20:07] <kees> ogasawara: rebooting, brb
[20:12] <kees> ogasawara: 2.6.34-020634g9553426 fails
[20:12] <ogasawara> kees: k, I'll kick off the next build
[20:12] <kees> cool
=== sconklin-afk is now known as sconklin
[20:14] <ogasawara> kees: just fyi, I'm putting notes in the bug
[20:14] <ogasawara> kees: no need for you to respond
[20:14] <kees> ogasawara: okay, cool.  was just going to ask if you wanted me to reply here, the bug, or both.  :)
[20:16] <tgardner> kees, would expect a powerpc qemu schroot to work? It seems to get hung up in /usr/bin/make
[20:19] <kees> tgardner: I've never tried that -- does the qemu emulator actually work for that?
[20:19] <tgardner> kees, yep, I can get into the schroot, its breaking on Hardy, gonna try Maverick
[20:19] <kees> tgardner: I've done armel and mips, and both of those were fine.  yeah might be a ppc-specific glitch.  the emulators are a little weird.
[20:20] <tgardner> kees, we're doing a bunch of armel schroots
[20:20] <tgardner> ogasawara pounds the hell out of 'em :)
[20:23] <jjohansen> -> Lunch
[20:38] <ogasawara> kees: http://people.canonical.com/~ogasawara/lp597075/734b415/
[20:40] <ogasawara> kees: no hurry
[20:40]  * ogasawara lunch
[20:42] <tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/79a56ed0e11c7d924762062a0e2a46b87014498d-maverick/linux-image-2.6.32-020632g79a56ed-generic_2.6.32-020632g79a56ed_amd64.deb
[20:42] <kees> ogasawara: 734b415 boots ok
[20:42] <ccheney> tgardner, yep rebooting into it now :)
[20:42] <tgardner> ccheney, you must be tailing the build log
[20:43] <ogasawara> kees: ok nice, I'll kick off the next
[20:43] <ccheney> tgardner, refreshing the page occasionally
[20:43] <ccheney> seemed to hit it at just the right time, heh
[20:43] <kees> ogasawara: your build will be done before my disk checks finish. :P
[20:43] <ogasawara> heh
[20:47] <ccheney> tgardner, bad
[20:48] <tgardner> ccheney, ack
[20:56] <ccheney> tgardner, how wide is the range now, ~ 150 ?
[20:57] <tgardner> ccheney, Bisecting: 169 revisions left to test after this
[20:59] <tgardner> ccheney, I'm also working on moving the build scripts to a much faster machine. They are unfortunately somewhat specific to zinc.
[21:00]  * apw looks bashful ... its on my list
[21:01] <ccheney> tgardner, great :)
[21:03] <tgardner> apw, what is BUILD_CONFIG_OVERRIDE ? I can't find it
[21:05] <apw> its an old way of setting the config in older releases, replaced by OVERRIDES
[21:05] <apw> note that we put the data in OVERRIDES and the point BUILD_C_O to it, backwards compatible
[21:05] <tgardner> apw, I'm trouble getting schroot to digest that command line
[21:06] <apw> well you can drop the variable for any release where git grep doesn't find it in debian*
[21:07] <tgardner> apw, ah, seems much happier without that
[21:07] <apw> tgardner, i must admit in a lot of my scripting i change things into
[21:07] <apw> { echo "commands" } | chroot /bin/bash
[21:08] <tgardner> apw, duh, that looks like a simple work around. I've even done it for other cases. why didn'tI remember :)
[21:09] <apw> tgardner, heheh always the way ... good luck
[21:10] <tgardner> apw, I've got it building on emerald. it runs circles around zinc
[21:13] <apw> tgardner, nice ... that should get u moving what about 3x the speed
[21:14] <tgardner> apw, closer to 10x
[21:15] <apw> i'll bet, you might want to also setup a ccache in the shell that you run it from too
[21:15] <apw> bet that'll speed up the second one
[21:17] <tgardner> apw, actually, I've done some benchmarking with ccache on the emerald class machines. It doesn't really save much. In a few runs I found it made only about 10 seconds difference
[21:18] <apw> interesting .. 
[21:18] <tgardner> I think the disk is fast enough....
[21:18] <tgardner> multiple spindles and all
[21:20] <tgardner> ogasawara, are you doing anything on emerald.mills? I think I'm gonna revert to the Lucid kernel. 
[21:27] <ccheney> wow 10x faster is nice, then i might be the slow factor :)
[21:39] <ogasawara> kees: http://people.canonical.com/~ogasawara/lp597075/9962c92/
[21:43] <ccheney> new image :)
[21:43] <tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/e33c01972239fee4696679ae5f7d1f340f424999-maverick/linux-image-2.6.32-020632ge33c019-generic_2.6.32-020632ge33c019_amd64.deb
[21:43] <ccheney> :-)
[21:50] <ogasawara> jjohansen: the atop patch set, is that something the server team is hoping to land in Alpha2? or can it wait post Alpha2
[21:50] <tgardner> ogasawara, it needs some more study as I think its a bit crackful
[21:50] <jjohansen> ogasawara: it needs debate
[21:51] <jjohansen> definitely not alpha2
[21:51] <ogasawara> jjohansen: cool, cuz I didn't want to have to slam them in :)
[21:51] <tgardner> jjohansen, do they have a good use case?
[21:52] <jjohansen> tgardner: hrmm, when I asked they said it was something that had been repeatedly requested and would be really nice to have
[21:52] <jjohansen> I will but jose, a ttx for specific use cases
[21:52] <tgardner> jjohansen, repeatedly ? first I've heard of it
[21:53] <jjohansen> well, I guess its more of a server thing
[21:53] <jjohansen> I hadn't heard of it until a couple weeks ago
[21:54] <kees> ogasawara: 996 fails
[21:54] <jjohansen> there is a bug filed from 2007 though
[21:54] <jjohansen> Bug #134159
[21:54] <ubot2> Launchpad bug 134159 in atop (Ubuntu) " atop Kernel patch doesn't work (heat: 3)" [Undecided,Confirmed] https://launchpad.net/bugs/134159
[21:55] <jjohansen> tgardner: also not that it is a nice to have, it isn't a hard requirement
[21:55] <tgardner> jjohansen, thats not exactly a bug.
[21:55] <ogasawara> kees: ack, will build the next
[21:55] <kees> ogasawara: thanks :)
[21:55] <jjohansen> tgardner: no, but it shows some time line of interest
[21:55] <ccheney> tgardner, bad
[21:55] <tgardner> ccheney, ack
[22:17] <tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/951c30d135390a108f102b0f6e3cfa6241f2a1aa-maverick/linux-image-2.6.32-020632g951c30d-generic_2.6.32-020632g951c30d_amd64.deb
[22:17] <ccheney> thx
[22:22] <ccheney> tgardner, bad
[22:22] <tgardner> ccheney, ack
[22:24] <tgardner> ccheney, I'm breaking for a couple of hours. I've started the next cycle. If successful it should copy bits to zonc.
[22:24] <ccheney> ok
[22:24] <tgardner> zinc*
=== tgardner is now known as tgardner-afk
[22:27] <jjohansen> ogasawara: hey on the AA patch rebase, instead of splitting kees's patch I could probably just move it to after the AA patches and fix the AA conflict if that would be easier for you
[22:29] <ogasawara> jjohansen: no worries, I've already got it applied to my local tree.  I kept it split like you had it
[22:29] <jjohansen> ogasawara: cool
[22:29] <ogasawara> jjohansen: just finishing up test builds, then will do a few boot tests and upload
[22:29] <jjohansen> okay let me know if you need anything
[22:30] <kees> ogasawara, jjohansen: hopefully that should change when I request Yama get pulled into maverick.  I'll have a patch that bolts it to AppArmor so hopefully it won't cause conflicts.
[22:31] <ogasawara> kees: cool
[22:31] <tgardner-afk> kees, does that mean we'll drop the other soft/hard link patches?
[22:31] <jjohansen> kees: cool, let me know if you want any help on it
[22:32] <kees> tgardner-afk: yeah, the symlink/hardlink/ptrace stuff will be done via Yama, and then I'll add a patch to bolt Yama into the kernel somehow.. maybe not against AppArmor since that would mean running SELinux on ubuntu would lose the protection.
[22:33] <tgardner-afk> kees,  oh, 'cause we can't yet chain or stack LSMs ?
[22:33] <kees> tgardner-afk: yup :(
[22:37] <sbeattie> kees: clearly you need to take eparis' patch against selinux. :-)
[22:38] <kees> sbeattie: that too
[22:40]  * ccheney is somewhat confused, trying to read through the commits that are in between what is good and bad and found it seems 2.6.32 was released in the middle of that, and thought we already proved 2.6.32 was good
[22:41] <ccheney> maybe i didn't look at the right spot
[22:42] <ccheney> hmm yea i didn't, but i don't see the commit in the list on the web ui
[22:43] <ccheney> ogasawara, is there a way using the git.kernel.org to see all commits between two git revisions?
[22:43] <ccheney> the log for the commits i mean
[22:44] <tgardner-afk> ccheney, http://kernel.ubuntu.com/~rtg/mainline/476d42f138ba82389a92a894d8a630a70d36278f-maverick/linux-image-2.6.32-020632rc5g476d42f-generic_2.6.32-020632rc5g476d42f_amd64.deb
=== tgardner-afk is now known as tgardner
[22:44] <tgardner> got delayed by a t-storm
[22:45] <ogasawara> ccheney: hrm, not sure how to do that via the web
[22:45] <ccheney> ogasawara, ok
[22:45] <ogasawara> ccheney: if you have a local clone of the git tree I can give you the command
[22:45] <ccheney> ah ok, i thought maybe there was way to do it on the web interface
[22:45] <ogasawara> ccheney:  there might be, I'm just unaware
[22:46] <ccheney> ok
[22:48] <ogasawara> kees: http://people.canonical.com/~ogasawara/lp597075/7648fa9/
[22:49] <ccheney> the timestamps seem out of order but its probably because the commit i am looking at is part of a merge
[22:49] <ccheney> tgardner, bad
[22:50] <tgardner> ccheney, ack
[22:50] <erichammond> jjohansen & co: Haven't chatted in a while.  Hope things are going well.  I have a client who runs Asterisk on Amazon EC2 using Ubuntu 10.04.  He's having problems with choppy voice and limits on the number of concurrent phone calls per server because of the 100Hz Ubuntu kernels on EC2.  Back in 2009 we discussed this and you were interested in building a 1000Hz kernel for him to try, but things sort of fizzled out as other prioriti
[22:50] <erichammond> How should I or he go about making the request for a test 1000Hz Ubuntu kernel for EC2?
[22:51]  * ccheney thinks the next one should be in the 10 commit range :-)
[22:51] <tgardner> ccheney, Bisecting: 18 revisions left to test after this
[22:51] <ccheney> ok
[22:51] <jjohansen> erichammond: file a bug against maverick and subscribe me and ttx
[22:51] <ccheney> tgardner, do you have a way to pastebin the log of those commits?
[22:52] <erichammond> jjohansen: Cool, will do.  No chance for Lucid given the development process?
[22:52] <jjohansen> I think it unlikely
[22:53] <jjohansen> but maverick kernels will be supported on Lucid
[22:53] <tgardner> ccheney, https://pastebin.canonical.com/33985/
[22:53] <ccheney> thanks
[22:53] <erichammond> jjohansen: Fascinating, thanks.
[22:54] <tgardner> erichammond, they already are, look in the kernel-ppa
[22:54] <erichammond> tgardner: What already are what?
[22:55] <ccheney> heh probably one of the big merges in the list :)
[22:55] <tgardner> The Maverick kernels are already being built for Lucid: http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu
[22:55] <tgardner> erichammond, or a better URL is: https://edge.launchpad.net/~kernel-ppa/+archive/ppa
[22:56] <erichammond> tgardner: I see, thanks.  This Asterisk/EC2 user would still need ones built with 1000Hz for EC2 which is a different process, I believe.
[22:56] <kees> ogasawara: 7648fa9 boots ok
[22:56] <tgardner> erichammond, its worth trying just to see if the scheduler fixes help, HZ setting not withstanding
[22:57] <erichammond> tgardner: We were told that back when upgrading from Jaunty to Karmic and now he's running Lucid.  Are there significant changes between Lucid and Maverick?
[22:57] <ogasawara> kees: cool, will kick off the last test build
[22:58] <tgardner> erichammond, oh yeah, though I don't have hard numbers.
[23:03] <erichammond> tgardner: Cool.  He sounds very motivated, so I'll provide him with instructions on how to test with Lucid against the Karmic kernel on EC2.  I guess I'll need to get the new kernel modules installed on a new image as well as RightScale integration, and so on.
[23:03] <tgardner> erichammond, I assume you know how to do that? 'cause I sure done :)
[23:03] <tgardner> don't*
=== bjf is now known as bjf[afk]
[23:07] <ccheney> tgardner, build failed
[23:08] <tgardner> ccheney, I fixed it, its copying right now
[23:08] <ccheney> ok
[23:09] <tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/5db5d64277bf390056b1a87d0bb288c8b8553f96-maverick/linux-image-2.6.32-020632rc3g5db5d64-generic_2.6.32-020632rc3g5db5d64_amd64.deb
[23:09] <ccheney> ok
[23:10] <tgardner> ccheney, now I'm really gone. back in an hour or two
[23:10] <ccheney> ok
=== tgardner is now known as tgardner-afk
[23:14] <ccheney> tgardner-afk, prelim looks good
[23:20] <ogasawara> kees: http://people.canonical.com/~ogasawara/lp597075/9908ff7/
[23:23]  * ccheney guesses at the next one failing since the log entries point that way
[23:31] <kees> ogasawara: 9908ff7 fails
[23:31] <ogasawara> kees: ack
[23:32] <kees> ogasawara: does that leave us at the end, or is there one more?
[23:33] <ogasawara> kees: I lied, I thought that was going to be the last test build, kicking off one more.
[23:33] <kees> ogasawara: cool.  I wasn't sure how to part the git bisect output
[23:34] <ogasawara> kees: once we isolate the commit, I'll have you do two more tests.  one with a mainline tree with the commit reverted and one with the maverick tree with the commit reverted.
[23:38] <ogasawara> kees: it's down the following 3 commits
[23:38] <ogasawara> 9908ff736adf261e749b4887486a32ffa209304c drm/i915: Kill dangerous pending-flip debugging
[23:38] <ogasawara> 9a7e8492d17394a81d5534abf90b5b2ada7ea3c0 drm/i915: Storage class should be before const qualifier
[23:38] <ogasawara> 7648fa99eb77a2e1a90b7beaa420e07d819b9c11 drm/i915: add power monitoring support
[23:38] <ogasawara> kees: the first you confirmed is bad, the last you confirmed is good, and I'm building the middle one as we speak
[23:40] <ccheney> tgardner-afk, yea 5db5d64 is good
[23:52] <ogasawara> kees: http://people.canonical.com/~ogasawara/lp597075/9a7e849/
=== sconklin is now known as sconklin-gone