[01:02] <jj-afk> back on later
[04:41] <syn-ack> jj-afk: Congrats on the inclusion. ;) It's finally about time! good work to you and Pete and the rest of the crew. :)
[08:02] <jj-afk> here's hoping the latest upgrade doesn't break me
[08:02] <jj-afk> rebooting
[08:03] <jk-> ever the optimist
[08:03] <amitk> heh
[08:04] <jk-> amitk: http://devicetree.org/PowerDomainBindings : do we expect devices to have multiple power inputs?
[08:05] <amitk> jk-: you mean a single device drawing power from multiple regulators?
[08:05] <jk-> amitk: exactly, yup
[08:06] <jk-> (maybe an ethernet device with a separate line for the phy?)
[08:06] <jk-> although, the ethernet and the phy may be considered separate devices...
[08:06] <amitk> jk-: yes, there are such devices. I think the MMC driver in OMAP (atleast the rx51 board) is one such example
[08:06] <amitk> brb
[08:06] <jk-> amitk: ok, thanks
[09:19] <smb> jjohansen, Ok, I cannot find the way from split_vma to make_pages_present. Likely too much inlining there so see it on a glance. In the end make_pages-present is called with an addr >= end. Not sure its worth to try to understand that too much. I go ahead and build kernels for the variations we talked about.
[11:25] <jjohansen> smb: I couldn't find it either
[11:27] <jjohansen> smb: that is I didn't find make_pages_present in split_vma
[11:27] <jjohansen> but mlock_fixup calls it directly
[11:27]  * jjohansen wonders if the stack trace is broken
[11:43] <jj-afk> g'night
[11:52] <lamont> smb: how's things?
[12:48] <dholbach> hi guys
[12:48] <dholbach> can something be done about bug 622583?
[12:48] <ubot2> Launchpad bug 622583 in linux-meta-rt (Ubuntu) "Remove the linux-meta-rt packages (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/622583
[12:48] <dholbach> it says that another kernel was uploaded for review but never received any
[13:00] <smb> lamont, Got two new variations to try... if you ain't bored of it by now. One (pre4) is on tangerine in hardy-amd64 the other I need move out of nc
[13:01] <smb> dholbach, Looks like this is an archive admin question
[13:01] <dholbach> smb: but the kernel that's up for review?
[13:02] <dholbach> smb, the bug I mentioned it also currently stuck at a review-before-archive-admins-do-their-work level and I thought it'd be good to have the kernel team have a look at it
[13:02] <smb> hm, yeah. Wonder whether that is the real rt one or moved over to preempt. Someone needs to chech that
[13:02] <smb> abogani, are you around?
[13:03] <abogani> smb, Yeah
[13:03] <dholbach> thanks guys
[13:03] <smb> dholbach, was looking at your bug above and I am not sure about the kernel for review thing
[13:04] <smb> abogani, Is this the -rt version or something for -preempt that apw was trying to look at?
[13:04] <abogani> smb: Lowlatency should be the preempt replace.
[13:04] <abogani> lowlatency should be kernel which apw should review.
[13:05] <smb> Ah ok and -rt will be continued in universe
[13:05] <smb> or where ever it is now
[13:05] <abogani> smb: No it is died.
[13:06] <smb> Ok, so I am now well confused. :) What kernel is "An updated version was uploaded on http://kernel.ubuntu.com/git but it never receive a review." referencing in the bug report above
[13:07]  * smb is still trying to get some hardy security wreckage fixed and is a bit out of any other context...
[13:07] <lamont> smb: rebooting into pre4 now
[13:08] <abogani> smb: Lowlatency should be replace preempt. Realtime should be replace rt.
[13:08] <abogani> smb: There are only two kernels on Zinc owned by me :-)
[13:10] <lamont> Error: /usr/lib64/xen/bin/xc_restore 23 3 1 2 0 0 0 failed <-- smb
[13:10] <smb> abogani, This would still leave a 50:50 chance to know which kernel you mean. Though I guess as it says remove -rt it means -realtime. Did you ask someone to review?
[13:11] <smb> lamont, So still no joy there.
[13:11] <lamont> correct
[13:11] <smb> lamont, Ok, give me a few minutes to move pre5
[13:12] <abogani> smb: In any case don't bother with the -rt/-realtime, please. I give up to continue that effort.
[13:13] <smb> lamont, btw have you once tried pre2 from the peoples page (or maybe still on tangerine, too)? To at least see what happens when we do not try to do anything smart
[13:14] <smb> abogani, Ok, so basically the request in that bug means: Please remove any -rt kernel and meta package from the maverick archive?
[13:15] <smb> abogani, And sad to hear you give up. Did we have too little time to help you there?
[13:19] <lamont> smb: I haven't
[13:19] <lamont>  http://people.canonical.com/~smb/lp620994/linux-image-2.6.24-28-xen_2.6.24-28.77~pre2_amd64.deb is 404
[13:20] <smb> lamont, *lalala* try again
[13:21] <abogani> smb: No. I would be very happy if I had received the rights to upload these packages after more than 3 years I'm working on it (that is since Feisty/Gusty and I'm the only one).
[13:24] <dholbach> abogani, I can't quite remember, did you apply for those upload rights?
[13:24] <abogani> dholbach, Of course Sir.
[13:24] <smb> abogani, I know the process to get that is a bit long winded. Normally someone has uploaded the packages for you. The problem then is that that someone remains the same one or two people which then can give you their endorsement for upload rights. I did that for one upload but that is not really long enough
[13:24] <dholbach> abogani, how did it work out?
[13:26] <smb> And I am ready to admit that I fail often to review if I am not reminded daily and beaten with sticks. There nearly always seems something urgent going on. :(
[13:28] <abogani> dholbach: Sorry?
[13:28] <dholbach> abogani, the application process, what was blocking the application there?
[13:28] <abogani> dholbach, The lacking of endorsements.
[13:29] <lamont> smb: pre2 only has headers and linux-libc-dev on people.c.c
[13:31] <smb> lamont, hm, ok. Need to fix that up. No idea where those went. pre5 should be there now and complete
[13:31] <dholbach> abogani, that sucks - who's been your main sponsors?
[13:32] <abogani> dholbach, Ben Collins and Luke Yelavich
[13:32] <dholbach> abogani, I see
[13:34] <lamont> smb: rebooting nao
[13:37] <smb> lamont, Ok, seems pre2 I have to compile again. :-/ binaries seem have to have vanished
[13:38] <lamont> Error: /usr/lib64/xen/bin/xc_restore 23 3 1 2 0 0 0 failed <-- pre5
[13:38] <smb> lamont, gah!
[13:39] <smb> lamont, Is in that version the guest unreachable too or can you ssh in like in pre1
[13:40] <lamont> I haven't been able to ssh to any guests in anything pre1-5
[13:41] <lamont> if I rebuild from scratch, I see it come up during that process, then we do a stop & restore and the restore is what fails
[13:41] <smb> lamont, Hm, maybe I got that wrong then. I thought ssh was possible with pre1
[13:42] <lamont> host has booted for all pre1-5, and you asked if I had networking at all: I said I had sshed in (to the host), maybe you took that to mean guest
[13:43] <smb> Yeah, that was my confusion
[13:43] <lamont> and by "up during the rebuild", I mean pingable from off-host
[13:45] <smb> Hm ok which means we have no information at all from within the guest... I assume the guest process is not running anymore when the error occurs
[13:50] <lamont> no it isn't.  we've stopped it and are trying to restore
[14:56] <bjf> ##
[14:56] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[14:56] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[14:56] <bjf> ##
[15:04] <ogasawara> diwic: around?  just had a quick question about two of the patches you sent that you're wanting to land in the Maverick Beta kernel...
[15:04] <ogasawara> diwic: ALSA: HDA: Fix front mic on Dell Precision M6500
[15:05] <ogasawara> diwic: ALSA: HDA: Add Sony VAIO quirk for ALC269
[15:05] <ogasawara> diwic: I didn't see them upstream in Linus' tree, just curious if they're in Takashi's sound tree?
[15:06] <ogasawara> diwic: if so, do you have the sha1's you could point me at, just so I can add them to the commits in our Maverick tree when I apply them.
[15:07] <diwic> ogasawara, I'm around
[15:07] <diwic> ogasawara, so these were submitted upstream yesterday and Takashi hasn't been around today
[15:09] <ogasawara> diwic: ah ok.  They seem harmless enough so I'll still pull them for Maverick.  Just be sure to also submit all 5 to upstream stable.
[15:09] <diwic> ogasawara, the happy users are in bug #519066 and bug #618271
[15:09] <ubot2> Launchpad bug 519066 in alsa-driver (Ubuntu) "Microphone doesn't work on Dell Precision M6500 (affects: 10) (dups: 1) (heat: 70)" [Medium,In progress] https://launchpad.net/bugs/519066
[15:09] <ubot2> Launchpad bug 618271 in alsa-driver (Ubuntu) "[Realtek ALC269] ALSA test tone not correctly played back = no sound at all (affects: 2) (heat: 10)" [Undecided,In progress] https://launchpad.net/bugs/618271
[15:09] <ogasawara> diwic: that way when we rebase to a stable kernel which contain the patches, we'll just drop the one's we're carrying in favor of the official upstream patch.
[15:11] <diwic> ogasawara, so to sum up, when I send the patch to upstream, it should have a "Cc: stable@kernel.org" in the commit message, a launchpad buglink and a sign-off?
[15:11] <diwic> (assuming it's suitable for stable)
[15:12] <ogasawara> diwic: yep
[15:13] <diwic> okay, thanks
[15:13] <ogasawara> diwic: if they went upstream without the "Cc: stable@kernel.org", just send an email to stable@kernel.org once the patch has landed in Linus' tree asking for the patch to be considered for the next stable patch set.
[15:14] <bjf> diwic: this should help some, https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat
[15:14] <ogasawara> diwic: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=blob;f=Documentation/stable_kernel_rules.txt;h=e213f45cf9d7505c9c9e1fbd088eb91cd83292f4;hb=HEAD
[15:16] <diwic> bjf, ogasawara, thanks, I'll have something to read now :-)
[15:18] <diwic> bjf, so for upstream I'd use ogasawara's link, and for the email to ubuntu-kernel mailinglist, I'd use bjf's link?
[15:19] <ogasawara> diwic: yep
[15:19] <bjf> diwic: ack
[15:20] <diwic> Does upstream like launchpad BugLink rows?
[15:21] <bjf> diwic: at this point, i don't think they mind them
[15:21] <ogasawara> diwic: probably depends on the maintainer.  I haven't had issues when I've submitted patches upstream which had a BugLink.
[15:23] <ogasawara> diwic: the nice thing about the BugLink is that either the launchpad janitor or our own scripts will close the bug when it gets into our tree.
[15:28] <diwic> Someday when I'm feeling happy I'm going to add a switch to git commit that adds Cc: stable and BugLink lines ;-)
[15:29] <manjo> tgardner, LTS backports is for servers only ?
[15:29] <tgardner> manjo, that is the supported configuration, but it  seem to work well for many desktops.
[15:30] <JFo> but if it doesn't we let you keep the pieces :)
[15:30] <manjo> tgardner, so there are separate desktop and server kernels that you build? or just one kernel works for both?
[15:31] <tgardner> manjo, the same flavours are built for both Maverick and its backport to Lucid
[15:31] <tgardner> same x86'en flavours that is
[15:31] <manjo> ok thanks
[16:02] <bjf> ##
[16:02] <bjf> ## Ubuntu Kernel Team Meeting - in 1 hour - #ubuntu-meeting
[16:02] <bjf> ##
[16:02] <ogasawara> bjf: 1hr or 2hr?
[16:03] <bjf> ogasawara: you are correct, was looking at london time and not gmt
[16:03] <bjf> ##
[16:03] <bjf> ## Ubuntu Kernel Team Meeting - in 2 hours - #ubuntu-meeting
[16:03] <bjf> ##
[16:43] <JFo> tgardner, have you seen this? https://bugs.launchpad.net/ecryptfs/+bug/623087
[16:43] <ubot2> Launchpad bug 623087 in ecryptfs "ecryptfs file permissions broken with kernel 2.6.36-rc2 (affects: 2) (heat: 12)" [Critical,In progress]
[16:43] <JFo> apparently folks testing against RC1 are losing data
[16:44] <tgardner> JFo, hmm, thats bad. why do we have a bug against 2.6.36 already?
[16:44] <JFo> good question
[16:44] <JFo> apparently some folks are doing some testing with the RC
[16:44] <tgardner> I haven't even officially announced the natty repo
[16:45] <JFo> heh, you know how those folks get when they get the maple syrup in them. All antsy in the pantsy
[16:46] <tgardner> JFo, looks like Tyler is already on it
[16:47] <tgardner> JFo, you should change the package from ecryptfs to linux
[16:47] <JFo> k, will do
[16:51] <JFo> ugh, sometimes I really hate LP
[17:48] <smb> jdstrand, lamont, jjohansen, Just some update: I have installed xen on a test system without any guest configuration. .37 seems to boot ok (though network does not work atm), all of the prex kernels seem to crash when booting Dom0 in page_remove_rmap (which has not been looked at yet at all)
[17:49] <jdstrand> ack
[17:49] <jjohansen> smb: ouch, its spreading
[17:50] <jjohansen> smb: have you verified whether a stack vma split by the mlock is merged back together correctly, or are we getting into a situation where the stack vma is getting really fragmented
[17:50] <smb> jjohansen, Not really spreading. That is probably just the next thing that breaks. I was already somewhat scared of how this guard page might interact
[17:51] <jjohansen> smb: yeah I know, it was a "its spreading like the plague" type statement ;)
[17:51] <smb> jjohansen, I have not had a system up enough to be able to look at that
[17:51] <jjohansen> smb: ack
[17:52] <smb> There is a lot of "in theory" there atm :/
[17:54] <jjohansen> yeah
[17:56] <smb> ouch, page->flags = 7365696666696e does not feel too right
[17:57] <smb> bjf, <chiming sound>
[17:58] <bjf> smb: my clock says 3 min
[17:58] <smb> mine seem to be undecided. but you are right the majority says 2m
[17:59] <bjf> ##
[17:59] <bjf> ## Meeting starting now
[17:59] <bjf> ##
[18:00] <jjohansen> chase: can I get you to look at something quick?
[18:00] <jjohansen> cnd ^
[18:03] <cnd> jjohansen, look at what?
[18:03] <cnd> in #ubuntu-meeting?
[18:03] <jjohansen> no just a sec
[18:23] <smb> jjohansen, *sigh* maybe I have an idea what else could be wrong
[18:23] <jjohansen> smb: oh?
[18:25] <smb> jjohansen, There is also the place where the guard page is added. And that also just checks for very basic things. Which could be wrong for splitted stack vmas...
[18:25] <jjohansen> hrmm, yeah
[18:27] <smb> Might be worth to try. I don't want to try understand why the other thing crashes without really really needing to
[18:28] <smb> And maybe something I need to understand is whether find_vma would expand any vma if it can...
[18:30] <jjohansen> no find_vma shouldn't expand them
[18:31] <jjohansen> my bet is its in the simple tests, that basically assume the stack is a single vma
[18:33] <smb> Which makes the code looking a bit weird as there is this test for find_vma ((addr & PAGE_MASK) - PAGESIZE) != vma. if there is not yet a vma for the address below wouldn't find_vma return NULL?
[18:33] <smb> but yes, the rest assumes that single vma 
[18:34] <smb> ah now, the semantics is different
[19:06]  * tgardner lunches
[19:07]  * smb dinners
[20:49]  * jjohansen -> lunch
[21:21] <smb> jjohansen, lamont, jdstrand Yo! Seems pre6 finally boots in xen mode as badly as the .73 kernel did. It comes up claims to have a network but no pings go well (but as said this was before). I got the 64bit versions moved over but now pgraners tyler seems to have vanished
[21:22] <smb> Hm, no reconnect works... must be network flux
[21:22] <jdstrand> smb: I had networking going here with dhcp, so I can test that
[21:22] <jdstrand> smb: do you have i386 builds?
[21:23] <smb> jdstrand, Yes, but not (yet) for you. Those need moving
[21:23] <jdstrand> smb: k, just ping me and I'll test
[21:23] <smb> sure
[21:24] <jdstrand> smb: thanks for all your work on this :)
[21:26] <smb> jdstrand, Heh, well I broke it, so I have to fix it. :) Though it rather was upstream/Linus.
[21:26]  * smb wonders whether the more recent kernels really work with xen
[21:26] <jdstrand> it would be worth testing
[21:26] <smb> jjohansen, Did you have time to test the ec2 kernels of security?
[21:27] <jjohansen> smb: I haven't yet, I will try it today, but I expect they will fail
[21:30] <smb> Hrm, we might have been a bit quick with the release here. We really should make sure we await at least feedback on the ec2 kernels before claiming the release is good.
[21:30] <jjohansen> smb: sorry, its one of those things, I meant to test, and then it slipped through the cracks
[21:32] <smb> But maybe Lucid or Karmic mm is broken in a way that it handles the badness better. Though the last bug I fixed now would cause asummption of ENOMEM when looking at split vmas of the stack. Well, its not only you having forgotten to do the test. Its also kees and jdstrand to be careful to have all oks.
[21:34] <smb> jdstrand, Ok, pre6 i386 versions now on people.c.c/~smb/lp620944
[21:34] <jdstrand> smb: ack
[21:39] <smb> jjohansen, If you are interested doing a second glance over the patches of pre6, I put them to chinstrap (0005 + 0006)
[21:40] <jjohansen> smb: okay, I'll look at them as soon as I am done testing on EC2 :)
[21:40] <smb> jjohansen, wfm :) thanks
[21:55] <jjohansen> hrmm, Lucid boot testing passed with the security kernel, I expected problems
[21:55] <jdstrand> smb: .77 i386 generic passed qrt test-kernel*
[21:56] <jdstrand> smb: still testing -xen, but so far so good
[21:56] <smb> jjohansen, Well, there is a lot of other things different. Could be even differences in what userspace does
[21:56] <jdstrand> smb: I can say for sure that networking works just fine, and so does xc_restore
[21:56] <smb> jdstrand, \o/ :)
[21:58] <smb> I'd probably give it to lamont tomorrow and then prepare packages to upload. Question is whether we want to do similar fixes to Dapper even as xen does not exist there.
[21:58] <smb> jdstrand, Maybe something to discuss with kees
[22:01] <jdstrand> smb: how similar is the code in dapper?
[22:01] <jjohansen> jdstrand: were you doing anything special to tickle xc_restore?
[22:01] <jdstrand> jjohansen: I start a vm, then reboot the host. it will trigger a save on shutdown and a restore on boot
[22:01] <smb> jdstrand, very similar. I believe between hardy and dapper there was not much change.
[22:02] <jjohansen> jdstrand: right
[22:02] <jdstrand> jjohansen: an easier way would probably be to look in the initscript
[22:02] <jjohansen> jdstrand: nope reboot, and stop for ec2
[22:03] <jdstrand> smb: we can discuss with kees when he comes online, but my feeling is we get hardy fixed, see how it goes and then consider backporting hardy's patches to dapper at the next security update
[22:03] <smb> jdstrand, I think we probably should do it as this now might leave the loophole of allowing a user-space app which partially locks the stack to crash things. Maybe its worth to make a test case for that
[22:03] <smb> jdstrand, But yes, first hardy and see, then look forward
[22:04] <smb> 11pm... /me thinks its a good time for eod
[22:05] <jdstrand> smb: have a good night. thanks again
[22:05] <smb> np. somebody remind me tomorrow to update the bug. :)
[22:06] <jdstrand> smb: do you want me to point people at pre6 so they can maybe test through the night?
[22:06] <smb> yeah that sounds like a good idea
[22:06] <jdstrand> k
[23:07]  * lamont fetches pre6
[23:26] <lamont> Error: /usr/lib64/xen/bin/xc_restore 23 10 1 2 0 0 0 failed <-- jdstrand, smb, et al.
[23:26] <lamont> that's pre6
[23:27] <lamont> there was a known issue with lucid vs xen at one point
[23:29] <lamont> sigh.  let's see if ACTUALLY REBOOTING INTO PRE6 works better for me.