=== solarion_ is now known as Solarion
=== ailo_ is now known as help
[02:01] <beata|lemur> Howdy y'all. I'm following the Ubuntu kernel compile guides, checking out natty, running the 'debian/rules binary-$local' method, on AMD64 system. What I'd like to figure out how to do, is build for i386 on that same tree.
[02:02] <AceLan> beata|lemur: you need to setup chroot environment
[02:03] <beata|lemur> I presume, then, I can use the same build tree in the chroot?
[02:03] <AceLan> beata|lemur: https://wiki.ubuntu.com/Kernel/Action/BuildChroot
[02:04] <AceLan> beata|lemur: yes
[02:04] <beata|lemur> I'll read it up then, thanks.
[02:04] <AceLan> beata|lemur: no problem
[02:15] <psusi> I'm trying to chase down a kernel BUG I just ran into on natty in dput().  It does BUG_ON(inode->i_state & I_CLEAR);  this was tripped when removing a dmraid partition device ( linear mapping ).  what is I_CLEAR?
[02:24] <beata|lemur> *giggle* The last chroot experience I had was trying to build the natty kernel on hardy. That was..ugh..painful.
[02:25] <psusi> hrm... maybe a multiple free problem?  hrm...
[02:26]  * psusi sure is glad for make -j4
[02:28] <beata|lemur> Hey. I'm happy for auto-jobbing. We didn't have that back in 1999.
[02:38] <psusi> auto jobbing?
[02:39] <psusi> you know what we DID have in 1999 that we don't anymore?  a defrag package ;)
[02:39]  * psusi really needs to get that put back into the main archive, or at least universe
[02:43] <beata|lemur> *laugh*
[02:43] <beata|lemur> Oh dear. The chroot is grabbing over half a gig of archives.
[02:44] <beata|lemur> It wasn't that long ago I wouldn't have had space on the whole disk. ;)
[02:47] <ohsix> it's going to be much huger by the time it gets underway
[02:49] <beata|lemur> I can believe it.
[04:31] <beata|lemur> This chroot thing is a *lot* harder than I expected, even given the other one.
[08:21]  * apw yawns
[08:59] <apw> cking, moin
[08:59]  * smb returns
[09:00] <smb> apw, cking morning
[09:00] <apw> smb, and to you
[09:02] <cking> morning
[09:07] <abogani> morning all
[09:07] <smb> abogani, morning
=== smb` is now known as smb
[10:30] <apw> smb, bug 
[10:30] <apw> bug #723066
[10:30] <ubot2> Launchpad bug 723066 in linux "[STAGING] ENE card reader fails with IO errors on streaming reads" [Medium,Triaged] https://launchpad.net/bugs/723066
[10:31] <smb> apw, ok, thanks. I will include that into the reply
[10:32] <apw> yeah, its pretty bust, we do not want it backported as it is for sure
=== diwic is now known as diwic_afk
[12:19] <herton> apw, there are two bugs which also will be fixed by latest rebase, bug 722689 and bug 722310
[12:19] <ubot2> Launchpad bug 722689 in linux "visual corruption of all screen after upgrading to 2.6.38.4.18" [Undecided,Confirmed] https://launchpad.net/bugs/722689
[12:19] <ubot2> Launchpad bug 722310 in linux "Suspend fails due to tpm_tis: error -62 with kernel 2.6.38-4 (2.6.38-3 works)" [High,Triaged] https://launchpad.net/bugs/722310
[12:19] <herton> I asked the reporters to test with the fixes included and they confirmed
=== jjohansen is now known as jj-afk
=== hito_jp0 is now known as hito_jp
=== yofel_ is now known as yofel
[13:09] <apw> herton, thanks, will make sure they are listed in the changelog  before i upload it
[14:57] <rsajdok> Where is the list of bugs to bug day?
[15:08] <apw> JFo, ^^
[15:09] <JFo> rsajdok, we are looking at all the new status bugs
[15:09] <JFo> I'll get you a link :)
[15:12] <JFo> rsajdok, http://goo.gl/f5CAz
[15:12] <JFo> that is the list of all kernel bugs in the new status
[15:12] <JFo> we'll be working from there
[15:23] <bjf> ##
[15:23] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:23] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[15:23] <bjf> ##
[15:26] <JFo> rsajdok, here is a better list http://goo.gl/2wO4A
[15:27] <tgardner> bjf, how about some CVE reviews so I can get them scraped off my list ?
=== alex_jon1 is now known as alex_joni
[15:28] <bjf> tgardner, i'll add you to my list
[15:31] <tgardner> apw, your -rc5 kernel seems to be working well on emerald
[15:31] <apw> tgardner, excellent ... just finishing up the boot tests here ... will shove it shortly
[15:32] <tgardner> apw, one of the commit messages is wrong. it says -rc5 when it should say -rc6.
[15:33] <apw> doh will correct
[15:33] <tgardner> UBUNTU: v2.6.38-rc5 rebased fixes Bug #716811 ?
[15:33] <ubot2> Launchpad bug 716811 in linux "[SandyBridge] kernel BUG at /build/buildd/linux-2.6.38/fs/nfsd/nfs4state.c:3132!" [Undecided,Fix released] https://launchpad.net/bugs/716811
[15:33] <apw> tgardner, no that one is actually correct, it was an older bug
[15:33] <tgardner> although it may be correct
[15:33] <tgardner> ok
[15:33] <apw> just added it for completeness as i closed it out
[15:36] <tgardner> apw, the scheduler really seems to work well. even at 322 load average its fairly responsive on another SID
[15:36] <apw> tgardner, that is most in-credible
[15:50] <rsajdok> JFo: thanks
[15:50] <JFo> rsajdok, thank you :)
[15:53] <tgardner> apw, lemme know when you've pushed natty master so I can start the ti-omap-dev rebase.
[15:53] <apw> tgardner, it should be as you have, i have just pushed the tag
[15:54] <tgardner> apw, ack
[15:54] <apw> oh its not on master yet sorry
[15:54] <apw> will do that right now
[15:54] <apw> tgardner, ok done on master correctly
[15:55] <tgardner> apw, got it
[15:55]  * apw goes do the lucid ones
[16:01] <JFo> need cofee brb
=== herton is now known as herton_lunch
[16:15] <kees> tgardner: seriously, can't we just remove debugfs?? http://seclists.org/oss-sec/2011/q1/229
[16:15] <kees> tgardner: it's horrible
[16:19] <tgardner> kees, IMHO its no worse then a regular sysfs. Its just that folks are paying less attention to debug interfaces. Perhaps we can get smb to agree to not mount it by default? We should also fix these holes.
[16:20] <kees> tgardner: sysfs has a regular interface, debugfs has become a dumping ground
[16:21]  * smb had no issues with not mounting it by default
[16:21] <tgardner> kees, well, maybe we can look at turning off the worst offenders (after fixing some of the permission problems)
[16:21] <kees> tgardner: we can also mount it somewhere that only root can get to
[16:22] <kees> tgardner: right, I want to keep the arbitrary memory writing interfaces totally gone (acpi/custom_method)
[16:22] <apw> kees, might that not be achieveable by just chanign permissions on the directory to be mounted on
[16:22] <kees> tgardner: but mostly this is just me pointing out yet more vulnerabilities in debugfs globally.
[16:22] <kees> apw: yup.
[16:22] <tgardner> kees, would mounting somewhere else be sufficient ?
[16:22] <tgardner> nm
[16:23] <apw> what mounts them up?  is that upstart
[16:23] <apw> i think it needs to use debugs
[16:23] <kees> tgardner: there are two classes of issue: root gaining arbitrary write (which we've fixed by dropping acpi/custom_method) and non-root messing with the system (for which there are tons of holes it seems)
[16:23] <apw> for its boot tracing
[16:23] <apw> so we might need to fix it there
[16:23] <kees> afaik, ureadahead and the dri debugging hooks need debugfs
[16:23] <kees> both should be running as root
[16:24] <sforshee> I think debugfs is also needed for perf, isn't it?
[16:24] <kees> none on /sys/kernel/debug type debugfs (rw)
[16:24] <kees> none on /var/lib/ureadahead/debugfs type debugfs (rw,relatime)
[16:25] <kees> sforshee: not sure.
[16:26] <abogani> ftrace
[16:27] <apw> kees, i meant more that upstart is likely mounting it early
[16:27] <kees> abogani: ftrace is a rootly thing, though, right?
[16:28] <kees> apw: likely mountall, but yeah
[16:29] <apw> kees, so something you could just try probabally
[16:30]  * kees has 2 days before feature freeze. :)
[16:31] <sforshee> kees, looks like debugfs is needed for some perf functionality: https://perf.wiki.kernel.org/index.php/Perf_examples
[16:31] <kees> sforshee: but that's all rootly stuff.
[16:32] <kees> sforshee: i.e. not mounting it or making the mount 0600 shouldn't wreck that.
[16:32] <sforshee> kees, yep, just an argument for not ripping out debugfs support completely
[16:33] <kees> sforshee: well... I'm against allowing the root user instrumenting the kernel in general. I'd prefer a "debug" flavor for that kind of thing, but I know it's a losing battle. :)
[16:34] <kees> sforshee: the middle ground is to just keep from allowing root to manipulate arbitrary memory.
[16:35] <kees> apw: setting 0600 is still a kernel change (since the mounted fs determines the mode of the root node)
[16:38] <apw> kees, i thought it was the OR of the root in the FS and the directory onto which it was mounted
[16:38] <kees> apw: looks like not
[16:39] <apw> ok, then likely yes a small change kernel wise
[16:39] <apw> as its just that top directory
[16:44] <bjf> ubuntu-meeting
[16:48] <bjf> ##
[16:48] <bjf> ## Kernel team meeting in 12 minutes
[16:48] <bjf> ##
[16:49] <kees> apw: I don't see a way to make the root inode 0600 without patching fs/libfs.c simple_fill_super()
=== jj-afk is now known as jjohansen
=== herton_lunch is now known as herton
[16:55] <apw> kees, hm
[16:56] <apw> probabally needs a _mode() version
[16:56] <kees> apw: well, actually, I could change the mode after the simple_fill_super call
[16:58] <kees> apw: in debug_fill_super, test the simple_fill_super return, then set sb->s_root->d_inode->i_mode
[16:58] <kees> seems like a psychotic hack, though
[17:01] <apw> i think add a new versionw hcih takes a mode
[17:01] <apw> and make the existing one pass 0600 to it
[17:02] <kees> apw: yeah. there aren't many users of simple_fill_super
[17:13] <JFo> grabbing a bite bbiab
=== Quintasan_ is now known as Quintasan
[17:15] <jjohansen> smb: good news, the hardy -xen kernels do boot on ec2
[17:15] <smoser> wait
[17:16] <smoser> maybe
[17:16] <smoser> i don't know that they dont
[17:16] <smoser> i can test that fairly quickly
[17:16] <jjohansen> smoser: oh, I took it as you had already tested
[17:16] <smoser> no. i only know that i did something wrong when they failed.
[17:16] <smoser> lets see.
[17:16] <jjohansen> smoser: ah
[17:18] <smb> jjohansen, partially good news then :)
[17:19] <jjohansen> smb: yes
[17:19] <jjohansen> smb: smoser and I were discussing whether it was worth while pulling pv-grub back to hardy
[17:19] <smoser> oh wait...
[17:19] <smoser> i wasn't necessarily going that far...
[17:20] <smoser> first would be to get to using the archive kernels
[17:20] <jjohansen> hehe, /me over enthusistic again
[17:20] <smoser> that would require some changes in image building
[17:20] <jjohansen> smoser: right
[17:20] <smb> jjohansen, I was just commenting like that. :)
[17:20] <smoser> using pv-grub would be wonderful.
[17:20] <jjohansen> I think archive kernels is a given
[17:20] <jjohansen> yes it would be
[17:20] <smoser> ok. 
[17:20] <smoser> so
[17:21] <smoser> let me upload a kernel and ramdisk and see if they boot.  this is such a pain for hardy :)
[17:21] <smoser> which is why we'd want to get to pv-grub
[17:21] <jjohansen> yep
[17:23] <kees> apw: I'm testing this now, what do you think? http://kernel.ubuntu.com/git?p=kees/ubuntu-natty.git;a=commitdiff;h=eca3653fb5aaa514c734821dc68813bb0fdc49fc http://kernel.ubuntu.com/git?p=kees/ubuntu-natty.git;a=commitdiff;h=f787804f21a3070e14df32ce8098b3f0b4a40646
[17:23] <smb> jjohansen, smoser Though I think I noticed a slight pain with pv-grub once an ami is not booting. Just overriding the aki seemes not to work as simple (I guess I would need to publish a ramdisk there)
[17:24] <smoser> smb, well, maybe
[17:24] <smb> But I generally agree on the beauty of pv-grub
[17:24] <jjohansen> smb: with hardy and lucid you could always just manually specify an aki instead of using the pv-grub aki
[17:25] <smoser> well, they dont run
[17:25] <jjohansen> so it should be no worse than now
=== bjf is now known as bjf[afk]
[17:25] <jjohansen> smoser: darn
[17:25] <smoser> as there is no network driver in the image
[17:25] <smoser> unless you get the -modules into the image
[17:25] <jjohansen> smoser: okay, /me and smb will persue getting -xen to work
[17:25] <smoser> although... we could potentially fix that by getting the netowrk driver into the ramdisk
[17:25] <smoser> i think that would be very worth it
[17:26] <smb> yep. just having to fiddle with the network driver does sound like it could be done without breaking our ppa builders
[17:28] <smoser> smb, well, the ramdisks are manually built
[17:29] <smb> Ok, so that would be an option, too. Probably even better than arguing for a change of the xen image if it can be avoided.
[17:30] <smoser> yeah.
=== diwic is now known as diwic_afk
[17:31] <smoser> smb, i might have been wrong on network
[17:31] <smoser> http://paste.ubuntu.com/570675/
[17:31] <smoser> that is output of lsmod in a current instance
[17:32] <smoser> none of those look like network module to me 
[17:33] <smb> smoser, neither to me. at least not an nif driver
[17:34] <smoser> off topic, but i'm personally happy to see that kernel clock apparent time travel occurred on this hardy kernel (http://paste.ubuntu.com/570676/) ... ie, htats not a regression in lucid or maverick its been there for quite a while. i had never looked on hardy before
[17:34] <smb> Is ifconfig -a show something
[17:35] <smb> smoser, I saw it occasionally when restoring an instance
[17:35] <jjohansen> smoser: time travel problems have plagued virtualization for a long time
[17:37] <smoser> smb, yes, there is definitely a network device
[17:41] <jjohansen> CONFIG_XEN_NETDEV_BACKEND=y
[17:41] <jjohansen> CONFIG_XEN_NETDEV_FRONTEND=y
[17:41] <jjohansen> smoser, smb ^
[17:41] <smoser> so maybe it was disk that was failing 
[17:41] <smoser> hold on
[17:41] <smb> jjohansen, yup that makes sense with a network interface there but not in modules
[17:42] <smoser> smb, you can poke around at ec2-50-17-93-174.compute-1.amazonaws.com if you'd like. please don't modify anhything though
[17:42] <jjohansen> smb: yep, /me was just double checking
[17:43] <smoser> smb, http://paste.ubuntu.com/570680/ is output of a hardy i386 instance booted with a differnet kernel ramdisk than it is expecting
[17:43] <smoser> thats why i had suspected no network driver
[17:45] <smb> hm, yes. on a very quick glance that looks like either the network driver is not working, the network not setup or the magic http-meta server missing
[17:45] <smoser> well meta data service isn't missing multiple times in a row
[17:45] <smoser> i've only seen that happen maybe 3 times ever
[17:47] <smb> smoser, Yeah, I only came up with it because that is what usually happened to me when trying on my test-system (thanks for the uncloudify script btw, though unfortunately time seems to have warped without me having any to try again)
[17:47] <smoser> yeah
[17:47] <smoser> right
[17:47] <smoser> but it seems like its something else, and i suspect that it is solved by installation of the apprpriate linux-modules package
[17:48] <smb> It is really hard to say. Disk and network look to be ok from the messages...
[17:52] <smb> smoser, If I have understood jjohansen correctly he was syncing up the patches for the ppa image. So that would only leave some configuration difference to be found
[17:53] <smoser> right.
[17:53] <jjohansen> hence the question does, the new image boot
[17:53] <smoser> well. it boots.
[17:53] <smoser> that is for sure.
[17:54] <smoser> i suspect that re-bundling an image with its modules instlaled will work.
[17:55] <smoser> so i guess, we need to test that putting them there would fix this
[17:55] <smoser> and then try to work out exactly what is going wrong
=== sforshee is now known as sforshee-lunch
=== bjf[afk] is now known as bjf
=== bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - March-01 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
[19:03]  * tgardner --> lunch
=== sforshee-lunch is now known as sforshee
=== shadeslayer is now known as shadeslayer_
[19:14] <apw> JFo, you there?
[19:15] <JFo> apw, yep
[19:16]  * apw mumbles at you
[19:16]  * JFo is on there
[19:16] <JFo> I don't see you apw
[19:17] <apw> and i cannot connect hrm
[19:17] <JFo> ah, there you are
[19:25] <kees> tgardner: well there you have it; greg doesn't want to take it.
=== ogra is now known as Guest4712
=== Guest4712 is now known as ogra_
[19:43] <apw> kees, what was his objection
[19:43] <JFo> apw, bug 709591 is one we only tagged kj-triage
[19:43] <ubot2> Launchpad bug 709591 in linux "i915 doesn't detect HDMI display" [Undecided,New] https://launchpad.net/bugs/709591
[19:45] <apw> JFo, and weher can i find the script which did this
[19:46] <apw> JFo, cranberry?  if so where
[19:46] <tgardner> kees, is he only objecting to 'debugfs: only allow root access to debugging interfaces' ?
[19:46] <JFo> it is in the kernel team branch of arsenal
[19:47] <JFo> it is the new-process-new-bugs.py under the contrib/linux/ dir
[19:48] <apw> and what output did the run produce for that bug
[19:49]  * JFo digs back
[19:49] <kees> tgardner: I would note that viro just said that debugfs "should not be mounted on production systems".
[19:49] <kees> apw: "debugfs has no rules and is for debugging only"
[19:50] <tgardner> kees, I'm just replying in email something to that effect.
[19:50] <kees> tgardner: okay
[19:51] <tgardner> kees, and it was Alan Cox that said "don't mount debugfs"
[19:51] <JFo> apw, can't find that one in the output. but I did find bug 714415
[19:51] <ubot2> Launchpad bug 714415 in linux "BUG: unable to handle kernel paging request at 80808080" [Undecided,New] https://launchpad.net/bugs/714415
[19:51] <JFo> the output is here https://pastebin.canonical.com/43753/
[19:52] <JFo> same deal
[19:53] <apw> what was the next line of the output
[19:53] <tgardner> sforshee, wren't you having tpm suspend issues for awhile ?
[19:53] <JFo> apw, it was for the next bug
[19:53] <JFo> want me to pull out a few more?
[19:54] <JFo> I should note, the output there is with the --verbose option enabled
[19:54] <JFo> so there isn't much more for us to get without debugging print statements
[19:54] <JFo> or rather debug print statements
[19:55] <sforshee> tgardner, not me
[19:55] <sforshee> mine was an i915 regression
[19:55] <tgardner> sforshee, hmm, ok
=== Quintasan_ is now known as Quintasan
[19:56] <smb> tgardner, reading the tales from the unkown stable mailing list?
[19:56] <tgardner> smb, about what?
[19:57] <smb> About the regression they caused on some tpm hardware
[19:57] <tgardner> smb, oh thatt. no, I saw some patches going by on LKML that fix the tpm patch that was reverted
[19:58] <smb> tgardner, Yeah, noted the story on the stable mailing list. 
[20:02]  * jjohansen -> lunch
[20:10] <apw> JFo, for it to print Action: <blank> i think something odd happened in skipit
[20:10] <JFo> I wondered that too
[20:10] <JFo> but I still can't wrap my head around it enough to determine what
[20:14] <apw>         if result and not self.reason:
[20:14] <apw>             self.reson = "skip it returned true"
[20:14] <apw> perhaps add (a correct) version of that to the bottom of skipit
[20:22] <apw> and run it in ry run and verbose
[20:24] <apw> dry
[20:25] <JFo> k
[20:32] <JFo> is it sad that it took me a bit of looking at that to determine what needed to be fixed? ;-P
[20:40] <skaet_> JFo, which specific packages do your tools search for, for identifying interesting bugs?  my guess is linux,  linux-ec2, and ???
[20:40] <JFo> the tools are looking only at linux for the moment
[20:40] <JFo> we are still working out some issues
[20:40] <skaet_> ok thanks.
=== sconklin-lunch is now known as sconklin
[21:39] <bdmurray> I've been looking at some kenrel debugging documentation particularly https://wiki.ubuntu.com/Kernel/CrashdumpRecipe - is it current / accurate?
[21:44] <bdmurray> apw: are you still affected by bug 451390?
[21:50] <ubot2> Launchpad bug 451390 in launchpad "limited upload rights no longer give series nomination accept/decline rights" [High,Triaged] https://launchpad.net/bugs/451390
=== Nafallo_ is now known as Nafallo
[22:06] <apw> bdmurray, has it been fixed?  i cannot trivially tell without asking mr watson to remove the work around
[22:07] <bdmurray> apw: which work around is that?
[22:08] <apw> the bug is that package sets do not give you the nom rights for the packages in, for the linux package mr watson added linux to each of the kernel uploaders direct rights
[22:08] <apw> this works round the issue for the main package for which we use nominations, but does not solve the bug
[22:09] <bdmurray> apw: ah okay I wasn't aware of *that* workaround
[22:10] <apw> yeah though it means the other 20 packages on my list i don't have noms for
[22:10] <apw> i think i'd need to find a bug on another package to confirm
[22:10] <bdmurray> apw: its okay I'm playing with it on staging now
[22:10] <apw> bdmurray, that was the only thing stopping me moaning every single day
[22:12] <bdmurray> apw: actually if you could try one of the other 20 packages on staging.launchpad.net that'd be interesting
[22:14] <apw> bdmurray, ok
[22:15] <apw> shame everything i do on launchpad also triggers timeouts
[22:15] <apw> dammit
[22:15] <apw> fileing a bug doesn't work on staging for me ... 
[22:17] <apw> bdmurray, it may be working (nomination s for other packages) i need to test it on live i guess
[22:17] <apw> https://bugs.staging.launchpad.net/ubuntu/+source/linux-meta/+bug/722414
[22:17] <ubot2> Launchpad bug 722414 in ubuntuone-android-files "syncable icon too small" [Medium,Confirmed]
[22:39] <bryceh> apw, upstream is telling me "for all the 915/945 bugs can you please have the reporters test the latest kernel with the enlarged unfenced alignment."
=== sconklin is now known as sconklin-gone
[22:39] <bryceh> google isn't informing me what an "enlarged unfenced alignment" is... do you recognize that?
[22:45] <cking> apw, do you never sleep?
[22:45] <RAOF> bryceh: That sounds like a libdrm commit to me?
[22:47] <bryceh> RAOF, didn't get much more context than that
[22:47] <bryceh> Bryce, for all the 915/945 bugs can you please have the reporters test the
[22:47] <bryceh> latest kernel with the enlarged unfenced alignment. That's the most likely
[22:47] <bryceh> cause of random writes, though I don't suspect it in this case.
[22:48] <bryceh> figure I shouldn't forward all the rest of these bug reports until I've gotten people to test whatever he's referring to
[22:48] <bryceh> but I suspect if it doesn't occur in tip, he won't care and we'll be on our own to dig out what patch(es) provide the fix
[22:49] <jjohansen> cking: of course he doesn't
[22:50] <RAOF> bryceh: Sounds about right :)
[22:50] <bryceh> RAOF, however `git log | grep "unfenced alignment"` in linus' tree returns null
[22:51] <bryceh> nor found anything in ickle's drm-intel tree
[22:51] <bryceh> wonder if he is sending me on a snipe hunt ;-)
[22:55] <bryceh> RAOF, hmm wonder if this is a possible solution to the vesafb bug?  http://git.kernel.org/?p=linux/kernel/git/ickle/drm-intel.git;a=commit;h=86b27d8050b6b2aec31063fa9f40b16fb347afb3
[23:11] <RAOF> bryceh: I suspect ickle's talking about 5e7833
[23:19] <bryceh> RAOF, ah thanks!
[23:24] <smoser> jjohansen, smb i kicked off a hardy-server uec build that is going to use linux-xen from the ubuntu archive.  it should appear in a couple hours on uec-images.  its not using -proposed kernel, but it is loads closer.
[23:25] <jjohansen> smoser: nice
[23:31] <kees> smoser: do you recognize "2.6.31-302.7-rs" as an Ubuntu kernel version? looks like a fork of an early karmic linux-ec2 version or something.
[23:32] <jjohansen> kees: that isn't one of ours
[23:32] <kees> jjohansen: I didn't think so.
=== panda is now known as Guest34992
[23:35] <chrismsnz> Hi Guys, I have a set of Supermicro 2u twins (4 nodes) running Lucid. A couple of them have been having OS trouble under high load
[23:36] <chrismsnz> usually what happens is the machine is still reachable via connecting to a port (i.e. you can connect to the http port, memcache port and it will respond to ping), but anything further than that is unresponsive
[23:37] <chrismsnz> so you can connect to the HTTP port, but you cannot request a document - it will hang
[23:37] <chrismsnz> It can work pretty hard but as soon as it "crashes" like this the only thing you can do is reboot
[23:38] <chrismsnz> I think it's a kernel problem with the version that comes with Lucid - what is the recommended kernel upgrade to try while still sticking with 10.04?
[23:41] <chrismsnz> running 2.6.32-27-server