[00:40] <Darxus> virtuald: In most cases just initiating a normal shutdown would be great.  
[00:44] <JanC> ctrl-alt-del still does a normal shutdown when you're in a console AFAIK
[00:45] <JanC> and doing a normal shutdown with alt+sysrq is impossible
[00:46] <RAOF> When you're hitting the alt+sysrq keys you're clearly in a situation where userspace isn't able to shutdown cleanly anyway.
[00:47] <JanC> RAOF: there are still people who use alt+sysrq to "log out"...   ;)
[00:48]  * RAOF feels safe in declaring them outside the target audience :{
[00:48] <ohsix> uhhh
[00:49] <JanC> RAOF: they are mostly people following wrong advice
[00:50] <JanC> but I agree we don't need to change sysrq behaviour for them  ;)
[00:55] <Darxus> Why can't the kernel initiate a normal shutdown in response to an alt-sysrq combination?
[00:56] <ohsix> besides being a key only a kernel hacker should really know about? you can also assign stuff to ctrl-alt-delete
[00:57] <JanC> Darxus: how would the kernel know what to do to do a normal shutdown?
[01:41] <MTecknology> In bug 673366, wouldn't the file descriptor limit be per process and not per user?
[01:41] <ubot2> Launchpad bug 673366 in nginx (Ubuntu) "default settings are dangerous (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/673366
[01:43] <RAOF> Yes, AFAIK the file descriptor limit is per-process.
[01:44] <ohsix> nginx should probably get a ratelimit if it can generate messages that fast, regardless of the content
[01:44] <RAOF> Note that raising the file descriptor limit for nginx may expose vulnerabilities if nginx isn't coded for it.
[01:45] <ohsix> and only moves the goalposts, the log spamming problem would still exist
[01:46] <ohsix> /me peanut gallery
[01:49] <MTecknology> RAOF: the default is 1024 - the reporter was saying that it's too high
[01:49] <RAOF> No, the reporter was saying that the number of workers spawned is too high.
[01:50] <MTecknology> oh
[01:50] <MTecknology> RAOF: the default is 1..
[01:51] <MTecknology> afaik...
[01:51] <RAOF> Right.  However, nginx will almost certainly have stdin, stdout, and stderr open which are 3 fds.
[01:51] <MTecknology> oh- I lied, it's 4
[01:51] <RAOF> 4 workers by default?
[01:52] <RAOF> How about worker_connections?
[01:52] <MTecknology> 1024
[01:52] <RAOF> Which is probably at least 3 too high.
[01:53] <MTecknology> 1021?
[01:53] <RAOF> (stdin, stderr, stdout)
[01:53] <MTecknology> oh
[01:53] <RAOF> Possibly; it could be using other things which claim an fd.
[01:54] <MTecknology> default could maybe just be dropped to something like 1010 or something a tiny bit lower?
[01:55] <RAOF> It'd probably be worth checking the code.
[01:55] <RAOF> Also, as ohsix says, it should probably have a ratelimit *regardless*
[01:55] <MTecknology> I'll do that - and fire an email off to the mailing list
[01:55] <MTecknology> and mention the rate limit
[01:56] <MTecknology> thanks :)
[04:15] <Darxus> Is the kernel not capable of doing the equivalent of "telinit 6"?
[04:17] <ohsix> it's as capable of doing that as it is spawning init, or the hotplug program
[04:17] <Darxus> So what's the problem with the kernel starting a normal reboot in respons to an alt-sysrq key sequence?
[04:18] <ohsix> whats the problem with it doign all sorts of things that are out of the scope of what alt-sysrq exists for
[04:18] <ohsix> you could use it to turn on a keyboard mode that played an octave of beeps on the pc speaker with the top row of keys
[04:20] <Darxus> If there was a single alt-sysrq key to do a clean reboot, I would not have had two hard drives crash from power cycling recently.  When ctrl-alt-del wasn't working.
[04:20] <ohsix> theres no such thing as a clean reboot in the situations alt-sysrq is for, you only hope it can sync drives
[04:21] <Darxus> It's a hell of a lot cleaner than just shutting power off.
[04:21] <Darxus> Enough that I wouldn't have lost over 2TB of data.
[04:21] <ohsix> it's also best effort
[04:22] <ohsix> best effort isn't a guarantee that your scenario would have turned out any different
[04:22] <ohsix> its pretty wild to lose a whole volume though
[04:22] <Darxus> But it is very likely that it would have.
[04:22] <ohsix> how
[04:22] <Darxus> Yeah, I did.  I've got the dmesg output showing the hard drive freaking out if you're interested.
[04:22] <Darxus> What do you mean how?
[04:23] <Darxus> All processes would've been killed, and the disk would've been unmounted, so the heads wouldn't have been hovering over the platters when power got yanked.
[04:23] <ohsix> i'm interested
[04:23] <ohsix> power yanking? yikes
[04:24] <Darxus> Effectively.  I had to hold the power button in for 4 seconds.
[04:25] <Darxus> If ctrl-alt-del always worked when alt-sysrq did, that would be great.  But since it doesn't I think there should be a single key sequence the average person can be expected to know when their system hangs.
[04:29] <ohsix> theres an ideal and controllable situation where ctrl-alt-del can work, and a hairy ugly failure scenario where alt-sysrq might be able to do something for you; it's really not the place for it
[04:30] <virtuald> you know gnome pulls up the restart dialog when you press ctrl-alt-del and waits 60 seconds before rebooting, so if it's just a gpu hang you might have to wait for that
[04:30] <ohsix> did the platters get eaten or did it seize? if not, what filesystem; theres so little you can do to prompt losing everything, and testdisk will save you from most of the simple mistakes (changing partition table)
[04:31] <ohsix> i've only seen one gpu hang, and lots of compositor hangs; either way i could switch to another tty and shutdown normally
[04:33] <virtuald> i don't think i can tell the difference
[04:34] <ohsix> only time i've lost data was when some seagate spindles seized on some raid drives, and that sucked (same lot, and they failed within 24 hours of eachother, it was bizarre)
[04:34] <Darxus> This is the full output from dmesg, when I booted to a rescue disk:
[04:34] <Darxus> http://www.chaosreigns.com/500gb.2010-11-27.dmesg
[04:35] <Darxus> The good stuff is toward the end:
[04:35] <Darxus> [  184.352364] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[04:35] <ohsix> virtuald: well, xorg's log will have some info if it knows the gpu hanged, you can look in /proc/`pidof compositor`/wchan and see if a compositor has hung
[04:35] <Darxus> fsck gave some kind of error after running for a while, asking if I wanted to ignore the fact that it couldn't read anything.
[04:35] <ohsix> Darxus: ah you ran out of spare sectors
[04:36] <ohsix> palimpsest can warn you about smart errors, the spare/reallocated sector count is one of the counters
[04:36] <ohsix> how did 500gb turn into 2tb?
[04:36] <Darxus> ohsix: It sounds like you should be able to recover some data from that?  That data, fortunately, I had backups of.  It was the other ~1.5tb that was all in one subdirectory that vanished that I didn't have backed up.  Got no errors on that one.
[04:37] <ohsix> what filesystem?
[04:37] <Darxus> The 500gb was ext3, the 2tb disk that lost a ~1.5tb directory was ext4.
[04:38] <ohsix> was that before or after ext4 moved from experimental
[04:38] <Darxus> It was within the last few days, running ubuntu maverick.
[04:38] <ohsix> curious
[04:39] <ohsix> do you still have the volume around?
[04:39] <Darxus> No.
[04:39] <virtuald> ohsix: saved, thank you :>
[04:39] <ohsix> can't recover the stuff then :]
[04:39] <Darxus> I rann extundelete on it and got nothing.  
[04:40] <ohsix> virtuald: xorg detecting gpu hangs can miss a real lockup a bunch, you can look at /proc/`pidof X`/wchan and see if X itself is blocked in the driver & hung too
[04:41] <ohsix> Darxus: any weird mount options? did you have an old fstab that didn't force data=ordered?
[04:41] <virtuald> ok i'll do that next time
[04:42] <ohsix> virtuald: the ubuntu (+kernel team) wiki has a bunch of info for troubleshooting stuff like that :]
[04:43] <Darxus> ohsix: No weird mount options.
[04:43] <virtuald> ohsix: i always forget about that when it happens
[04:52] <ohsix> Darxus: there were some data loss things with ext4 and some settings that ubuntu used; i dunno how recently they changed it but it was recent
[08:25] <Zdra> Morning :)
[08:26] <Zdra> could someone please reopen that bug? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/662946
[08:26] <ubot2> Launchpad bug 662946 in linux (Ubuntu Maverick) (and 2 other projects) "linux kernel 2.6.35 slows down the whole system because of kslowdxxx processes (affects: 35) (dups: 2) (heat: 196)" [Medium,Fix released]
[08:26] <Zdra> no fix was ever released for that, dunno why someone reported he doesn't see the bug anymore, but that's a lie :)
[08:44] <apw> Zdra, done ... if you are affected can you test the natty kernel which is meant to have the fix so we can progress the issue ?
[08:45] <Zdra> apw, yep that's on my todo list, but can't promise when I'll be able to test it
[08:45] <Zdra> apw, thanks :)
[09:04] <apw> Zdra, good enough, as the bug is incomplete it will expire if noone tests
[09:26] <apw> http://people.canonical.com/~platform/workitems/natty/u/stefan-bader-canonical-natty-alpha-2.html
[10:15] <jjohansen> https://wiki.ubuntu.com/LucidReleaseSchedule
[11:53] <ogra_ac_> apw, hrm
[11:53] <apw> ogra_ac_, ?
[11:53] <ogra_ac_> The following packages have unmet dependencies:
[11:53] <ogra_ac_>  linux-headers-omap : Depends: linux-headers-2.6.35-22-omap but it is not installable
[11:53] <ogra_ac_> can we do something about that (temporary at least ) for A1 ?
[11:54] <apw> ogra_ac_, that issue must have been in there since the archive opened for natty
[11:54] <ogra_ac_> it breaks omap4 builds (sillyness: all armel headers are installed by default on all armel images, we have only subarch matching for removing the unwanted ones at the end of the build)
[11:54] <ogra_ac_> apw, it hasnt 
[11:54] <ogra_ac_> its there since the 19th 
[11:54] <ogra_ac_> not sure why
[11:55] <apw> archive must have purged the headers at that time
[11:55] <ogra_ac_> yeah
[11:55] <ogra_ac_> something along these lines
[11:55] <apw> some warning might have been nice
[11:55] <ogra_ac_> also cooloney seem to have started testing linaro kernels on omap3
[11:55] <apw> ogra_ac_, i asked him to as i wasn't seeing any other testing going on
[11:56] <ogra_ac_> apw, GrueMaster_ is supposed to do some, but was traveling and on vacation last week
[11:56] <ogra_ac_> expect some test results this week
[11:56] <apw> ogra_ac_, i am unsure what i can do about this missing header right now
[11:56] <apw> the package it was made form is gone
[11:56] <ogra_ac_> cant you remove it temporary from the meta =
[11:56] <ogra_ac_> ?
[11:56] <apw> so its just cause its in meta you are finding it ?
[11:57] <ogra_ac_> cooloney's comments smelled like linaro kernel wouldnt work so well
[11:57] <ogra_ac_> meta still tries to pull in a non existing packge
[11:57] <ogra_ac_> so i would expect that to go away if you drop that dep
[11:57] <apw> ogra_ac_, so what package are you starting from to pull all these in
[11:57] <ogra_ac_> headers should be enough to make omap4 build
[11:58] <apw> as if i drop the package, you'll just have the old one
[11:58] <apw> ogra_ac_, yeah in fact the meta package doesn't have omap and hasn't for any upload to natty
[11:58] <ogra_ac_> weird
[11:59] <ogra_ac_> where does linux-headers-omap come from then ?
[11:59] <apw> ogra_ac_, how do you find it
[11:59] <apw> as in how does the scripting find it
[12:00] <ogra_ac_> it just installs the ubuntu-minimal and ubuntu-netbook tasks 
[12:00] <ogra_ac_> must come from somewhere in there
[12:00] <apw> probabally the installer then ?
[12:00] <apw> no perhaps not
[12:00] <apw> hrm
[12:00] <apw> they must be holding the binaries live in the archive
[12:00] <ogra_ac_> well, the issue is that linux-headers-omap exists 
[12:01] <ogra_ac_> yeah
[12:01] <apw> i don't think i have control over that
[12:01] <ogra_ac_> yeah, i pinged in #ubuntu-devel
[12:01] <ogra_ac_> theoretically it should be an NBS package
[12:01] <ogra_ac_> if no source builds it
[12:02] <apw> not sure it will fix you though as i suspec tthat the dep will just move up one level
[12:02] <apw> so removing or not removing the package is unlikely to 
[12:02] <apw> help any
[12:02] <ogra_ac_> up one level ?
[12:02] <ogra_ac_> that should be the highest one
[12:10] <sosaited> Does anyone know if kernel 2.6.37-rc2 for maverick has i/o scheduling improvements over 26.35?
[13:17]  * apw doesn't know of any specific ones, but has seen better overall balance due to the scheduler magic changes
[13:20] <smb> But unlikely the magic autogroup patch
[13:32] <tgardner> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/610597
[13:32] <ubot2> Launchpad bug 610597 in linux (Ubuntu) "ecryptfs can orphan mounts after host file system is removed (affects: 1) (heat: 30)" [Medium,In progress]
[13:34] <tgardner> apw, https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/344878
[13:34] <ubot2> Launchpad bug 344878 in linux (Ubuntu) (and 2 other projects) "file name to long when creating new file (ecryptfs_lookup: lookup_one_len() returned [-36] on lower_dentry) (affects: 48) (dups: 5) (heat: 264)" [Undecided,In progress]
[14:07] <diwic> smb, black art of in-comprehensive programming book? :-)
[14:07] <smb> diwic, Definitively! :)
[14:08] <diwic> smb, well, that's in the zone between quirking and coding
[14:10] <diwic> smb, what is a DAC node should really be autodetected, but unfortunately, the HDA driver does not work that way, leaving us into quirking every time a new hw shows up
[14:10] <smb> diwic, I tend to agree. Just looking at a patch that returns 0x25 instead of other numbers and increments an array by one at some other place is hard to put somewhere when looking at it.
[14:11] <diwic> smb, yeah, without more context than diff -u shows, it doesn't say much really 
[14:12] <smb> Right, especially the bigger array, as there is nothing in the patch itself that links this to the changed number.
[14:13] <diwic> smb, so ALC887 has five DACs which does not fit in an array of four
[14:13] <smb> diwic, Ok, and presumably 0x25 encodes the number of DACs 
[14:14] <diwic> smb, 0x25 is the index of the fifth DAC node
[14:14] <diwic> or if it was 0x26
[14:14] <diwic> one is the mixer node, the other is the DAC node
[14:14] <smb> diwic, You see my point of the black art book. ;-)
[14:15] <diwic> smb, yeah, and all these things should be detected, because it is easily detectable
[14:15] <smb> Just not enough people with enough time to completely rewrite the driver I guess
[14:17] <diwic> smb, something like that, the hard part is to avoid regressions for broken, now quirked, hardware 
[14:18]  * smb feel his head spinning
[14:37] <apw> http://lkml.org/lkml/2010/11/26/329
[15:04] <andreoli> hi, not sure if this has already been reported; I just downloaded latest Ubuntu kernel from git (the maverick repository) and the last changelog entry seems borked
[15:04] <andreoli> it says UBUNTU: Ubuntu-2.6.32-23.40; shouldn't it be UBUNTU: Ubuntu-2.6.35-23.40?
[15:05] <bjf__> andersk, correct
[15:05] <apw> andreoli, yes it is textually borked in that version, the changelog is correct and later versions are sorted
[15:05] <andreoli> ah ok
[15:05] <andreoli> and does this break the debian/rules insertchanges script, anyway? I guess so 
[15:06] <apw> tgardner, you have one patch which needs review in the ubuntu delta:   1. UBUNTU: Sony laptop: Some Sony Vaia laptops do not enable wwan power by default
[15:06] <andreoli> can I enter debian/changelogs manually?
[15:06] <apw> tgardner, wonder if you could cast an eye over it
[15:06] <tgardner> apw, will do
[15:06] <bjf> andreoli, yes you can, the script is just for convenience 
[15:07] <andreoli> thx :-)
[15:09] <smb> andreoli, if you want a similar layout: "git log <range of commits>|./debian/scripts/misc/git-ubuntu-log" produces it to stdout
[15:09] <apw> andreoli, yes it breaks insertchanges, but i beleive the latest versions in -proposed is later anyhow isn't it ?
[15:09] <albatros> Hi all
[15:10] <apw> amitk, i think it was originally you who asked us to include arjan's patch for powertop.  where did you find those recomendations?  I want to make sure what we are carrying is still relevant
[15:10] <albatros> I wondered what I can do to get a solution for bug 676644 into the distribution
[15:10] <ubot2> Launchpad bug 676644 in linux (Ubuntu) "sata-via: read errors, slowdowns with VIA VT6420 (affects: 1) (heat: 469)" [Undecided,New] https://launchpad.net/bugs/676644
[15:10] <apw> albatros, do you know of a fix for the issue ?
[15:11] <andreoli> I am actually working on 0bc5a231f5ac5b6081d8f906917a31d9f3643af7 UBUNTU: Ubuntu-2.6.32-23.40
[15:11] <albatros> I suppose a patch was proposed for the linux kernel https://patchwork.kernel.org/patch/323272/
[15:12] <andreoli> thx I'll apply it
[15:12] <albatros> Unfortunately I do not have a lot of experience patching ubuntu-kernels, and I do not have a lot of time, but if I could somehow help...
[15:12] <apw> albatros, what release are you experienceing this on 
[15:13] <albatros> 10.10
[15:13] <albatros> 2.6.35-23-generic-pae #40-Ubuntu
[15:13]  * apw sees if that patch will apply there
[15:14] <apw> albatros, could you get an lspci -nnvv attached to the bug please
[15:14] <albatros> no problem apw, just a minute
[15:17] <albatros> apw: I have attached the output of lspci -nnvv to the bug
[15:18] <apw> albatros, thanks
[15:19] <smb> apw, Looks like some extension of a magic quirk I saw before. Not sure that is already upstream
[15:19] <apw> smb, an updated version is in linus' tree
[15:19] <smb> apw, Sounds reasonable then
[15:20] <apw> albatros, it seems to apply ok, so i'll build you some test kernels
[15:20] <smb> apw, At least I believe the first part has been on stable
[15:20] <apw> smb, i expect the other will come that way to othen
[15:21] <apw> but getting some testing on it is a good thing (tm), and if it passes I'll recommend it there too
[15:21] <albatros> If I can be of any help testing a kernel, I'll be happy to
[15:21] <smb> apw, Right, it may need some hinting if it is not already submitted with the cc
[15:21] <apw> albatros, be about an hourh
[15:22] <tgardner> apw, that patchworks fix appears to have morphed into b1353e4f40f6179ab26a3bb1b2e1fe29ffe534f5
[15:22] <apw> tgardner, ack that is the one i cherry-picked
[15:22] <albatros> Please forgive my ignorance, what are you talking about :P
[15:23] <apw> albatros, the fix you mentioned from peterz was actually superceeded by a very similar fix from someone else
[15:23] <apw> albatros, and so we want to test the one which ended up in linus' tree, the one which will be in the next release from him
[15:23] <albatros> ok, thanks
[15:25] <andreoli> thx guys, worked like a charm
[16:16] <albatros> apw: just a question, if I want to test the patched kernel, where can I get it?
[16:27] <apw> albatros, i'll let you know once it is uploaded, its doing that now
[16:27] <apw> X crashing on me 4 times in an hour and making me restart the push has not helped the speed of upload, nor my mood
[16:27] <albatros> OK great apw, will it be in the testing repository or somewhere else?
[16:27] <apw> i'll shove a URL in the bug as soon as its up
[16:28] <albatros> too bad apw, don't let it get to you ;)
[16:28] <albatros> I wish you luck and thank you
[16:28] <albatros> if the errors i reported disappear i will report it in the bugreport
[16:28] <apw> albatros, let me know either way if you test it, in the bug
[16:29] <albatros> yes of course
[16:32] <apw> tgardner, other than the X issues i am seeing, this natty kernel +200line patch is magnificent
[16:33] <tgardner> apw, you mean the galbraith SID patch?
[16:34] <apw> tgardner, indeed, the behaviour of the machine under high disk load is so much better, and i don't really quite get how the patch helps that, but it does
[16:34] <apw> no more grey windows, no more "getting coffee cause i ran git rebase"
[16:34] <tgardner> apw, I think it round-robins cgroups, and all processes/threads within a SID are in one cgroup.
[16:35] <apw> yep, but how that helps with disk use, i don't know
[16:35] <apw> or are you saying we are getting disk round robin as well
[16:35] <apw> anyhow, under load the machine is slow, not useless
[16:35] <tgardner> apw, dunno why I/O is better.
[16:47] <apw> albatros, ok directions in the bug
[17:44] <amitk> apw: the patch recommendation was in the powertop git tree. git://gitorious.org/meego-developer-tools/powertop.git
[17:46] <apw> amitk, thanks
[17:48] <apw> cnd, hey ... 
[17:49] <cnd> apw, hey
[17:50] <apw> cnd, you have a blueprint, with no work items
[17:50] <cnd> apw, yeah, I saw
[17:50] <cnd> apw, it's not against the kernel, right?
[17:50] <cnd> it's against the mt team?
[17:50] <apw> its owned by you, so i see it
[17:51] <apw> and you are mine :)
[17:51] <cnd> heh
[17:51] <cnd> for better or worse, the MT team hasn't gotten around to setting work items yet
[17:52] <apw> well how useless is that, we are past feature definition so you cannot add any new ones
[18:16] <apw> sconklin, i sub'd you to a bug about a disk issue, and cannot find it anymore, can you see it in your email
[18:17] <sconklin> apw, I cleaned all those out and deleted them this morning
[18:17] <sconklin> all my subscribed bugs
[18:18] <sconklin> looking on launchpad
[18:20] <sconklin> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/682652 this one?
[18:20] <ubot2> Launchpad bug 682652 in linux (Ubuntu) "linux-image-2.6.32-25-generic-pae upgrade yields ata errors (affects: 1) (heat: 8)" [Undecided,New]
[18:20] <apw> sconklin, yeah thats the one thanks
[18:29] <apw> sconklin, so thats not the same as the issue i am poking at, a nice little regression-updates there for you :)
[18:32] <sconklin> apw: yes, thanks
[19:13]  * tgardner --> lunch
[19:23] <jjohansen> apw, smb: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/671103
[19:23] <ubot2> Launchpad bug 671103 in cloud-init (Ubuntu Lucid) (and 1 other project) "backport grub-legacy-ec2 from maverick to lucid (affects: 2) (heat: 20)" [High,Fix committed]
[19:24] <apw> jjohansen, ?
[19:24] <jjohansen> apw: this basically means we need to add lucid-ec2 to mavrick -virtual in the transition table
[19:24] <apw> jjohansen, didn't i already add that one?
[19:25] <smb> jjohansen, that means sru a transition for something out...
[19:25]  * smb thinks its too late to think of that
[19:25] <jjohansen> apw: I said we could ignore that one because you can't install kernels on lucid ec2
[19:26] <apw> jjohansen, do you mean to the documentation ?  it is there already
[19:26] <jjohansen> but it appears the plan is to fix that
[19:26] <smb> But probably means to have it in place for the l to m update
[19:26] <smb> I mean P
[19:26] <jjohansen> apw: yeah
[19:26] <apw> jjohansen, ok so you mean we might need a real transitional package
[19:26] <apw> for maverick for that flavour 
[19:26] <jjohansen> yep
[19:26] <apw> ok thanks
[19:26] <apw> jjohansen, actually think we need a bug for that
[19:27] <jjohansen> apw: okay /me and smoser will take care of it
[19:27] <apw> jjohansen, if you get me the bug number it is easy work
[19:27] <smb> apw, To move them from linux-ec2 to linux. But I wonder whether that is applying to maverick...
[19:28] <apw> to move them from linux-image-ec2 to linux-image-virtual
[19:28] <smb> apw, yeah, ok 
[19:28] <apw> yep, for maverick, as you cannot upgrade to natty direct, thats against the law
[19:28] <smoser> it probably should apply to maverick
[19:29] <smb> Just not sure that there has been any sru to a transitional package
[19:29] <smoser> so its not that big of a deal
[19:29] <smoser> heres why:
[19:29] <apw> sconklin, you have a bunch of outstanding items for natty-alpha-1 and am wondering if they are going to make it
[19:29] <smoser> ec2 images have -virtual and -ec2 kernels installed
[19:29] <apw> smb, i suspect there never has, but i suspect it is demonstrably low risk
[19:29] <smoser> upgrade from lucid -> maverick -> p* will get the -virtual updated and it will be newer than the -ec2 . legacy-grub-ec2 will select that kernel to boot
[19:29] <sconklin> apw: looking
[19:30] <smoser> if someone had purged the -virtual kernel, then they'd not get any updates
[19:30] <apw> sconklin, note i have done half of 'document officially supported flavours on a per release basis and who is responsible for those (eg ti etc)' specifically the supported flavours bit (see Kernel/Dev/Flavours)
[19:30] <smb> apw, No I don't think technically there is. I am usually rather surprised by the policy issues in those cases
[19:30] <sconklin> apw: saw that
[19:31] <apw> smb, indeed,
[19:31] <lamont> Nov 29 11:05:52 rover3 kernel: [14054.882140] intel ips 0000:00:1f.6: MCP power or thermal limit exceeded <-- do I care about these?  (new laptop)
[19:31] <jjohansen> smoser: hrmm, so no transitional package needed unless they have purged -virtual, I think I can live with that
[19:31] <jjohansen> that is just not having a transitional package
[19:32] <smoser> but i guess we might as well put a transitional package in place for natty
[19:32] <apw> lamont, it would depend how often they are coming out
[19:32] <smb> lamont, Sounds a bit scary. Though as the driver is new I am not sure whether how bad it is
[19:33] <smoser> that would fix the lucid -> maverick -> natty -> orchid -> plain path
[19:33] <apw> lamont, that implies either cpu or gpu was allowed to turbo for a little too long
[19:33] <lamont> 5+ hours, 359 occurances in kern.log
[19:34] <jjohansen> apw: not necessarilly other components could trip the thermal warning, if the laptop has poor cooling
[19:34] <lamont> it's not doing any heavy crunching, so I'd expect it to be reasonably quiescent
[19:35] <jjohansen> lamont: what type of disk?  7200+ laptop drives tend to run hotter and can trip up thermals
[19:35] <lamont> the fan is nice and quiet, though. :(
[19:35] <ogasawara> lamont: http://lkml.org/lkml/2010/8/26/471 - I think it's the driver just being overzealous with it's reporting
[19:35] <lamont> 500GB sata drive
[19:35] <apw> lamont, i am not sure i would expect it to be out of spec enough to fire the fans
[19:35] <lamont> how does one find the rotational speed for a drive?
[19:35] <apw> hdparm i think has it
[19:36] <apw> sconklin, i am not sure you haven't done some of these, the documentation one for the process for instance
[19:37] <sconklin> apw: is there a plce I can see all my tasks without drilling through the blueprints?
[19:37] <apw> http://people.canonical.com/~platform/workitems/natty/canonical-kernel-team-natty-alpha-1.html
[19:37] <apw> sconklin, ^^ is the natty ones ... search for your launchpad id
[19:37] <apw> (twice)
[19:38] <apw> sconklin	todo	hardware-kernel-n-stable-process-review	Essential	boiler plate text for bug closure on failure to verify
[19:38] <apw> hardware-kernel-n-stable-process-review	Essential	provide a document that describes the process, bug tracking, and which tests are being performed, etc
[19:38] <apw> hardware-kernel-n-stable-process-review	Essential	process to add the bug to the changelog manually during release process
[19:38] <apw> hardware-kernel-n-version-and-flavours	Medium	document officially supported flavours on a per release basis and who is responsible for those (eg ti etc)
[19:38] <apw> oh that worked _so_ well, thanks xchat
[19:38] <sconklin> yeah found them
[19:38] <apw> these are alll links from the Kernel BurnDown section
[19:39] <apw> of https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Natty
[19:39] <apw> sconklin, ^^
[19:40] <lamont> ogasawara: interesting thread - thanks for the pointer
[19:41] <sconklin> apw: well, the documentation is fairly complete and reflects the process as it stands now, but the item calls for "which tests" and that's being provided by cert and QA. I'm comfortable calling that complete if you are, as we're maintaining it in parallel with decision making
[19:41] <apw> sconklin, works for me
[19:41] <sconklin> I'll update that one
[19:43] <sconklin> apw: we've already reverted fixes for failure to verify and updated the bugs, so you could argue that I
[19:43] <sconklin> I've defined the boilerplate
[19:43] <sconklin> although it's not recorded except in the bugs
[19:43] <sconklin> I'm going to flag that Done also
[19:44] <apw> i say copy that to a wiki page, and call it done
[19:44] <sconklin> apw: I'll put it in a section on the previously linked wiki page
[19:44] <apw> sounds good
[19:44] <apw> albatros, did you test that kernel yet ?
[19:45]  * smb ducks to avoid the whip cracking all around
[19:47] <apw> smb, _you_ i can get to tommorrow
[19:48] <smb> apw, that is what _you_ think :)
[19:48] <apw> smb, don't delude me now, i might come after you _now_ otherwise
[19:48]  * smb cannot hear apw
[19:52] <jdstrand> apw: hi! I'm looking at bug #507148, but you gave maverick kernels for a bug in lucid
[19:52] <ubot2> Launchpad bug 507148 in xserver-xorg-video-ati (Ubuntu Lucid) (and 4 other projects) "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500 (affects: 8) (heat: 46)" [High,Invalid] https://launchpad.net/bugs/507148
[19:53] <albatros> apw: bug 676644 appears to have been fixed
[19:53] <ubot2> Launchpad bug 676644 in linux (Ubuntu) "sata-via: read errors, slowdowns with VIA VT6420 (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/676644
[19:53] <jdstrand> apw: in other words, mdeslaur and I reported the problem back in the lucid cycle, and I followed up on it a lot and it was fixed in lucid. was the regression on lucid or maverick?
[19:54] <albatros> I have tested the interface/disk combination, I could not recreate it with the method that had never failed before
[19:54] <albatros> (reading a few gigabytes at high speed)
[19:55] <albatros> I will continue to watch it if it really does not reoccur
[19:57] <jdstrand> apw: based on http://bugs.freedesktop.org/show_bug.cgi?id=26302#c27, it looks like a problem on the lucid kernel. would you mind making lucid kernels available for testing?
[19:57] <ubot2> Freedesktop bug 26302 in Driver/Radeon "[M7 LW] desktop runs out of video memory on ATI Radeon Mobility 7500" [Major,Resolved: fixed]
[20:03] <jdstrand> apw: acutally, it seems both lucid and maverick, but a lucid kernel would be most appreciated, and I could confirm whether or not reverting/going with upstream causes a regression on lucid release
[20:05] <ogasawara> sconklin, bjf: I'm gonna push the 2.6.32.26+drm33.11 stable patch set (plus the 2 additional kvm patches ben mentioned to avoid a regression) to Lucid master-next.
[20:05] <bjf> ogasawara, wfm
[20:05] <sconklin> ogasawara: ack +1
[20:10] <sconklin> apw: I've documented and flagged as DONE all the ones except the flavours item you started
[20:11] <apw> sconklin, cool
[20:13]  * jjohansen lunches
[20:21] <sconklin> apw: your flavours page is NOT this one, correct? https://wiki.ubuntu.com/Kernel/Dev/TopicBranches
[20:38] <ogasawara> is it me, or is the Karmic ec2 branch showing it hasn't been updated for 5 months?!  that doesn't seem right.
[20:40] <smb-nx> Not sure. I had to push something...
[20:41] <sconklin> ogasawara: fetching to look
[20:43] <ogasawara> it looks like the latest tag was pushed (Ubuntu-2.6.31-307.21), but the branch doesn't seem to match
[20:44] <smb> ogasawara, Yeah odd
[20:44] <tgardner> ogasawara, checkout the tag, then push HEAD
[20:44] <smb> I thought I had that before and had pushed it... Or was that Lucid
[20:45]  * jdstrand uploaded 2.6.31-307.22/karmic and 2.6.32-310.21/lucid to the secppa a little while ago
[20:45] <ogasawara> jdstrand: cool, I'll get out git repos to match then.
[20:46] <jdstrand> ogasawara: they aren't published yet, so if things need to be fixed, we can still do it
[20:46] <sconklin> ogasawara: what tgardner said
[20:47] <ogasawara> jdstrand: just trying to get our git repo in order, nothing for you to worry about, proceed with the publishing.
[20:47] <jdstrand> ogasawara: ack
[20:47] <ogasawara> sconklin: I'm just gonna wait for the official publication and then fix it up.
[20:47] <sconklin> that's fine
[20:48] <smb> ogasawara, Yeah the fix is that. Just wondering what and where I pushed now...
[20:48] <sconklin> It's all in there, just not on the branch
[20:48] <smb> ogasawara, You can push to the last published tag
[20:48] <smb> I mean check it out and push it over ec2
[20:48] <ogasawara> smb: what you pushed to zinc looks good to me, it's just the official repo that looked off
[20:49] <smb> ogasawara, Thats the thing. I thought I had pushed something to the official repo. (like it needs now)
[20:49] <smb> Heck if I would know what
[20:49] <ogasawara> heh
[20:49] <smb> It was one of the ec2s
[20:49] <ogasawara> probably lucid
[20:50] <smb> Yeah, probably
[21:27]  * ogasawara lunch
[21:31] <smoser> smb, so did you want me to separate out the issues in 669496
[21:32] <smoser> i dont think we ended up creating new ones for what was probably separate issues
[21:33]  * smb-nx might remember if he knew what bug 669496 was again
[21:33] <ubot2> Launchpad bug 669496 in linux (Ubuntu) "natty fails ec2 boot on i386 or t1.micro (affects: 1) (heat: 133)" [Critical,Confirmed] https://launchpad.net/bugs/669496
[21:33] <smb-nx> Smoser
[21:34] <smoser> nx ? nomachine ?
[21:34] <smb-nx> Darn. No nexus one
[21:34] <smb-nx> Meaning I am not really working
[21:35] <smb-nx> John wanted to try something
[21:36] <smoser> :) funny.
[21:36] <smoser> thats fine. i just wanted to make sure you weren't expecting something from me
[21:37] <smb-nx> smoser: no. Not really for the moment