[01:06] <bjf[afk]> ogasawara: still around?
[01:06] <ogasawara> bjf: yep
[01:07] <bjf> i just started two builds before noticing that we will probably run out of disk space on tangerine
[01:07] <bjf> i was wondering how to kill builds started with the build scripts
[01:07] <ogasawara> bjf: yeek, lemme go clear out some stuff
[01:07] <ogasawara> bjf: my builds have finished
[01:08] <ogasawara> bjf: I don't think it's scripted to kill the builds, so I usually just run screen -ls, then reattach to the session I want to kill and manually kill it
[01:08] <bjf> ack
[01:10] <bjf> ogasawara: killed both of mine
[01:10] <ogasawara> bjf: I've cleaned out my trees
[01:10] <bjf> ogasawara: will start them again some time later (will check disk space first)
[01:10] <bjf> ogasawara: ack
[01:11] <ogasawara> bjf[afk]: should be about 44G free now, not sure who else is consuming space
[01:40] <marcosroriz> Hi guys
[01:40] <marcosroriz> Can anyone help me with my bug --> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/571422
[01:40] <ubot2> Launchpad bug 571422 in linux (Ubuntu) "[LUCID] suspend/resume issue on Dell Inspiron 1464/1564/1764 (affects: 10) (heat: 52)" [Undecided,Confirmed]
[01:40] <marcosroriz> ?
[01:55] <bbordwell> Hey everyone I am just noticing all the scheduling while atomic bugs popping up since the -16 kernel update in maverick and it looks like they are caused by this upstream bug: https://bugzilla.kernel.org/show_bug.cgi?id=16588  the regression was caused by the fix to the x exploit. Would anyone object to me setting one of the reports as master by linking the upstream bug report and then marking all the others as dups?
[01:55] <ubot2> bugzilla.kernel.org bug 16588 in Other "Regression introduced in 2.6.35.2 causes freezing, crashing, oopsing" [Normal,Resolved: code_fix]
[02:04] <bbordwell> Well I am pretty confident this is the right course of action so I will go ahead and do so. Hopefully no one gets mad at me :)
[02:11] <sconklin-gone> bbordwell: unless I'm mistaken there's already a fix for that in the repo, which means that tomorrow's daily will have it. So this should be a dhort-lived bug.
[02:12] <bbordwell> sconklin-gone, should be since its already fixed upstream. Just want to clean up after the mess its leaving on lp :)
[02:14] <bbordwell> Here is the master I made: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/620810
[02:14] <ubot2> Launchpad bug 620810 in linux (Ubuntu) (and 1 other project) "[MASTER] BUG: scheduling while atomic (affects: 7) (dups: 7) (heat: 62)" [Medium,Triaged]
[02:16] <sconklin-gone> looks fine to me~
[02:16] <sconklin-gone> !
[10:06] <ikepanhc> lag: https://wiki.ubuntu.com/Kernel/Dev/MultipleISOBootUSBKey
[10:07] <lag> Well done ikepanhc - thank you
[10:07] <ikepanhc> :)
[14:03] <jdstrand> smb: hi! so it looks like the maverick rebase to 2.6.35.2 grabbed the CVE-2010-2240 fixes (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.35.2), I don't see that CVE-2010-2803 or CVE-2010-2959 are fixed in maverick
[14:03] <ubot2> jdstrand: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2240)
[14:03] <ubot2> jdstrand: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2803)
[14:03] <ubot2> jdstrand: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2959)
[14:03] <jdstrand> thanks ubot2
[14:04] <jdstrand> smb: I've updated the tracker for CVE-2010-2240 just now
[14:04] <ubot2> jdstrand: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2240)
[14:04] <jdstrand> ubot2: dude, stop
[14:04] <ubot2> Factoid 'dude, stop' not found
[14:04] <smb> jdstrand, Ok. Don't even try to convince a bot. :)
[14:05] <jdstrand> :)
[14:05] <smb> jdstrand, Yes, I think Leann got them pulled. Though I have not been looking whether those were all of them
[14:05] <jdstrand> smb: well, the changelog.Debian.gz file didn't seem to have it either
[14:05] <jdstrand> (2.6.35-16.22)
[14:06] <smb> Somehow I believe it was only one to fix another issue... tgardner are you more up to date in Maverick than I am
[14:06] <smb> ?
[14:07] <tgardner> smb, I asked ogasawara to upload yesterday to fix the mm regression that came via stable. she might not have gotten to the CVEs just yet
[14:08] <smb> OK, right so that was just incidentally one of the cve patches
[14:08] <smb> jdstrand, ^ (but give me a sec and I look into the repo to be sure)
[14:10] <jdstrand> smb: I appreciate it
[14:12] <smb> jdstrand, I think there is one of the fixups for 2240 missing, so 4/5 complete there (the missing one properly fixes the error case properly). So the main issue might be ok
[14:13]  * smb wonders how many properlies he manages to put into one sentence
[14:13] <jdstrand> hehe
[14:14] <jdstrand> smb: so, can you follow up with Leann when she comes online or shall I?
[14:14]  * jdstrand isn't sure based on this conversation who should be fixing maverick
[14:15] <tgardner> jdstrand, we assure you, its Leann
[14:15] <smb> jdstrand, Maybe you. Depending on when she gets up it might be beer 'o clock here
[14:15] <jdstrand> hehe
[14:15] <jdstrand> ok, I'll just follow up with her directly
[14:15] <jdstrand> thanks guys! :)
[14:16] <smb> No problem. We love OPPs :)
[14:35] <diwic> Is there a wiki guide for doing git bisect? I e if somebody says it worked in version x but not in version y and is willing to take the time to do a git bisect
[14:37] <tgardner> diwic, there is plenty of help in the command itself, git bisect --help
[14:38] <diwic> tgardner, right, I'm just looking for a stock reply / wiki link to point people to
[14:38] <diwic> tgardner, which also includes which tree to start with
[14:38] <tgardner> diwic, I'm thinking if they can't figure it out from the help notes, then they probably are gonna need more hand holding then the wiki provides
[14:41] <diwic> tgardner, I'd like to learn how to do git bisecting then, so I can hold people in their hands later
[14:42] <tgardner> diwic, no better way to learn then to just do it
[14:47] <diwic> tgardner, fair enough, so to get started I'd probably follow Kernel/BuildYourOwnKernel, which will create a deb, which I will install, and reboot, and that's basically one git bisect iteration
[14:51] <abogani> diwic, I don't suggest you to build a deb package for a git bisect section.
[14:53] <diwic> abogani, but instead...?
[14:54] <abogani> diwic, IMHO Upstream method is more easy for that.
[14:56] <diwic> abogani, so assume I've compiled an upstream kernel. How do install it? "make install" and then "sudo grub-install"?
[14:59] <abogani> sudo make modules_install, copy bzImage into /boot with an appropriate name, create initramfs with mkinitramfs, reboot and edit GRUB command line for boot the just compiled kernel. 
[15:00] <diwic> abogani, now that is something that should be in a wiki page
[16:22] <JFo> ogasawara, the current list of those is here: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=gfxpayload%3Dkeep
[16:23] <jdstrand> ogasawara: hi! smb and tgardner directed me to you regarding the recent CVE fixes for maverick
[16:23] <jdstrand> ogasawara: from backscroll:
[16:23] <jdstrand> 08:03 < jdstrand> smb: hi! so it looks like the maverick rebase to 2.6.35.2 grabbed the CVE-2010-2240 fixes (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.35.2), I don't see that CVE-2010-2803 or CVE-2010-2959 are fixed in maverick
[16:23] <ubot2> jdstrand: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2240)
[16:23] <ubot2> jdstrand: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2803)
[16:23] <ubot2> jdstrand: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2959)
[16:23] <jdstrand> 08:12 < smb> jdstrand, I think there is one of the fixups for 2240 missing, so 4/5 complete there (the missing one properly fixes the error case properly). So the main issue might be ok
[16:24] <ogasawara> jdstrand: getting the remaining maverick CVE's are also on my todo list this morning
[16:24] <jdstrand> ogasawara: would you mind pulling what's needed to get maverick patched?
[16:24] <jdstrand> ogasawara: thanks! :)
[16:25] <jdstrand> ogasawara: you seem busy this morning ;)
[16:25] <ogasawara> jdstrand: heh, yep :)
[16:25] <ogasawara> jdstrand: I'd have shoved the CVE fixes in yesterday's upload but the 2.6.35.2 regression we were seeing needed to go up asap
[16:26] <jdstrand> ogasawara: that's cool-- based on what smb said about the rebase, the CVE everyone is talking about should be fixed
[16:26] <jdstrand> ogasawara: (well, fixed enough to not be a vuln)
[16:27] <smb> ogasawara, Just a note that the regression patch was part of one of the cves, so now there is only one of the set missing
[16:27] <ogasawara> smb: cool
[16:36] <kees> frankly, I think the CAN bug is more pressing. :)
[16:36] <kees> anyway, s'all good
[17:04]  * smb thinks he now has re-uploaded everything in need and that it is now past boc
[17:13] <tgardner> sconklin, bjf: whats the story on 2.6.32.[18,19] ? there looks to be some serious goodness for intel wireless, ext4 deadlock, btrfs, etc.
[17:14] <bjf> tgardner: i've got the patches applied to my public repo, i've done test builds, just waiting review by smb and sconklin
[17:14] <bjf> tgardner: looks like btrfs was re-written in that patchset :-)
[17:14] <smb> I'll do a quick review Monday. We should get it then applied that day or Tuesday
[17:15] <bjf> tgardner: sconklin is out today as well
[17:15] <tgardner> ah, ok
[17:15] <tgardner> bjf, whats your branch? I'll run some tests
[17:15] <bjf> tgardner: sru-18+19
[17:16] <bjf> it doesn't have smb's writeback patches though
[17:16] <bjf> tgardner: ^
[17:16] <tgardner> rebases are us
[17:16] <bjf> tgardner: was just about to fix that
[17:18] <smb> bjf, I am now at 6G. Would that be good enough?
[17:18] <tgardner> for those who don't know bjf's whole name, his repo is at git://kernel.ubuntu.com/bradf/ubuntu-lucid
[17:18] <bjf> smb, sure
[17:18] <bjf> smb, and thanks
[17:19] <smb> NP, need to remember to clean up after big build tests
[17:21] <tgardner> don't forget we have  emerald as well
[17:21] <kamal> I'm curious why Lucid jumped from #39 to #41... why was there was no 2.6.32-24.40 ?
[17:22] <smb> Stuck in proposed and overrun by security
[17:22] <smb> kamal, ^
[17:22] <kamal> smb: got it, thanks
[17:23]  * smb -> out (really)
[17:24] <bjf> tgardner: the branch has been rebased
[17:24] <tgardner> bjf, lemme know when you've finisihed your rebase
[17:24] <tgardner> :)
[17:25] <bjf> tgardner: i'll go spin some test builds and make them available
[17:25] <tgardner> I'll light up my big honking server and have -generic done in 15 minutes.
[17:26]  * bjf notes the glow in the east even in the bright morning light
[19:21] <cnd> jjohansen, how sure are you that the load avg patch is incorrect for Xen machines?
[19:21] <jjohansen> 100%
[19:21] <cnd> every machine's load avg went up with the fix in
[19:21] <cnd> jjohansen, can you explain in more detail what's wrong?
[19:22] <jjohansen> cnd: well in the Lucid case the kernel isn't tickless
[19:22] <cnd> the patch doesn't add in any load that isn't real
[19:22] <jjohansen> it really does
[19:22] <cnd> how?
[19:22] <jjohansen> I can simulate loads of 2 and 3 on an idle machine
[19:23] <cnd> how do you do that?
[19:23] <jjohansen> cnd: I'm still poking at that, but it is interacting with the Xen patches in a bad way
[19:23] <cnd> it's worth noting that the patch that went upstream was different, but with the same semantics
[19:23] <cnd> you can try that patch out
[19:23] <jjohansen> cnd: start up an ec2 instance, launch some applications to idle (they aren't doing anything) and that is it
[19:24] <jjohansen> cnd: did, it works better on Lucid
[19:24] <cnd> jjohansen, even though the applications are idle, the machine is still doing stuff
[19:24] <jjohansen> but reverting your patch is just as easy
[19:24] <jjohansen> cnd: yes but its not doing stuff to the point of maxing out each cpu
[19:25] <cnd> so you're saying you are actually seeing load of 2 or 3 (not 0.02 or 0.03) when idle?
[19:25] <jjohansen> if I take and revert you patch, and apply upstream the problem is fixed on Lucid
[19:25] <cnd> and you've double checked with top that nothing is running?
[19:25] <jjohansen> yes
[19:25] <jjohansen> yes
[19:25] <jjohansen> I have ftraced, run different loads,
[19:25] <jjohansen> run tons of different kernels
[19:25] <cnd> it just seems really odd to me
[19:26] <jjohansen> yeah it is
[19:26] <cnd> cause I don't understand how the code could be doing that
[19:26] <jjohansen> right, well I am still working on that one
[19:26] <cnd> are you saying you've taken the upstream fix for this issue and it works correctly?
[19:26] <jjohansen> yes
[19:26] <cnd> ok, in that case I have no real qualms myself
[19:26] <jjohansen> well sort of
[19:26] <jjohansen> it works for Lucid but not Maverick
[19:26] <cnd> I just saw the revert on kernel-team without the proposed patch from upstream
[19:27] <jjohansen> right
[19:27] <jjohansen> no point applying the upstream patch as it actually does nothing for Xen
[19:27] <cnd> ok, I'll let you continue sorting through the issues then
[19:27] <jjohansen> if you fallow it through, there are if defs for non-tickless kernels
[19:28] <cnd> oh, I guess it's a different branch for ec2
[19:28] <jjohansen> yes, only ec2
[19:28] <jjohansen> I need to poke at it more for Maverick, as that is a different story
[19:28] <jjohansen> in Maverick the upstream patch is there, the kernel is tickless, and we see the problems again
[20:06]  * jjohansen -> lunch
[20:29] <DrGrov> What is the issue with the new kernel? It kind of gives a lot of kernel panic once in a while, not every rebooting but every 3rd or so. The 10.04 stock kernel did work a lot better.
[20:33] <DrGrov> No help then, nevermind. 
[21:06] <kees> ogasawara: is it possible to get the linaro kernel patches into the non-linaro arm kernel builds?
[21:06] <tgardner> kees, you mean ti-omap in Maverickl?
[21:07] <kees> tgardner: honestly, I'm not sure. I've still got the giant list from Lucid in my head
[21:07]  * kees checks ABIpackages....
[21:08] <tgardner> kees, we've only one external ARM branch for maverick right now.
[21:08] <kees> tgardner: yeah, looks like it.
[21:08] <kees> tgardner: and the internal ARM build that is part of "linux", right?
[21:08] <tgardner> kees, yep, same source code
[21:08] <kees> I mean, ultimately, I know the linaro stuff is going upstream
[21:08] <kees> tgardner: wait, which is the same?
[21:09] <tgardner> kees, I meant that the "internal" ARM branch is from the same source code as x86/x86_64
[21:09] <kees> right
[21:09] <tgardner> you know, ther normal stuff
[21:10] <kees> so, I guess I'm curious if we can get some of the linaro patches into both "linux" and "linux-ti-omap4"
[21:10] <kees> specfically, npitre's ASLR
[21:10] <tgardner> I guess that depends on how intrusive they are.
[21:10] <tgardner> hmm, what is ASLR ?
[21:10] <kees> address space layout randomization
[21:10] <tgardner> ah
[21:11] <kees> tgardner: I'll ask npitre if he has time to prepare a diff. I know he has plans to upstream it, so it should be the same work.
[21:11] <tgardner> do you have a reference in his tree? we can certainly take a look.
[21:12] <kees> tgardner: 
[21:12] <kees> http://git.linaro.org/gitweb?p=linaro/linux-linaro.git;a=commitdiff;h=df0698be14c6683606d5df2d83e3ae40f85ed0d9
[21:12] <kees> http://git.linaro.org/gitweb?p=linaro/linux-linaro.git;a=commitdiff;h=c743f38013aeff58ef6252601e397b5ba281c633
[21:12] <kees> http://git.linaro.org/gitweb?p=linaro/linux-linaro.git;a=commitdiff;h=cc92c28b2db5b406657ecc05235d4ca4e222ae34
[21:13] <kees> http://git.linaro.org/gitweb?p=linaro/linux-linaro.git;a=commitdiff;h=990cb8acf23cab19a2930f1ed5e7dc108f89079b
[21:13] <kees> and one more is coming
[21:13] <tgardner> kees, those don't look too bad.
[21:14] <tgardner> its one of those "it either works, or it doesn't" kind of patch sets
[21:15] <kees> well, true for stack protector, and mostly true for ASLR, but there have been subtle issues in the past with ASLR. However, at this point, I think I've got a good enough regression testing suite that the corner-case collisions are detected. (and currently this passes with the linaro kernel)
[21:16] <tgardner> kees, well, float 'em on the list and see what folks think
[21:17] <kees> tgardner: okay, I'll wait for npitre's last commit and I'll send 'em.
[21:23] <tgardner> kees, EOD for me. see you Monday
[21:44] <Kano> hi, when will be 2.6.35.3 mainline be ready
[21:55] <kees> ogasawara: is the magic for arm cross compilation on the build resources documented? all I can find on the wiki is amitk's blog post
[21:56] <ogasawara> kees:  I want to say yes, are you using the current kteam-tools/buildscripts ?
[21:57] <ogasawara> kees: lemme try to find the doc, but it's pretty much the same, for ex ./build-prep --dist maverick tangerine-armel
[21:57] <kees> ogasawara: I can be; I have a local copy of that you gave me a while bakc.
[21:57] <kees> ogasawara: okay, lemme, going afk for a bit.
[21:58] <ogasawara> kees: https://wiki.ubuntu.com/Kernel/Dev/KernelBuildScripts
[21:58] <ogasawara> kees: but it doesn't mention the arm builds :(
[22:39] <bjf> kees: there's a very simple way to do it on tangerine
[22:41] <bjf> kees: schroot -c maverick-armel;fdr clean; fdr binary-<flavour>
[22:43] <bjf> cnd: i have build images of my sru-18+19 at http://kernel.ubuntu.com/~bradf/sru-18+19/
[22:43] <cnd> bjf, cool
[22:44] <cnd> hopefully I can find some time to check it out
[23:13] <syte> Hi, I've tried for the first time to compile my own kernel (2.6.35.2). I've used my current kernel's configuration settings, and then applied "make oldconfig". I complied with "make && make install_modules", and then finally installed with make install. When I tried to boot up my new kernel, I got the error "Couldn't mount because of unsupported optional features (240)." For some reason it was trying to mount ext2 and ext3, when i
[23:13] <syte> t should've been mounting ext4
[23:34] <kees> bjf[afk]: but that "native" via emulation, right? isn't it pretty slow?
[23:34] <bjf[afk]> kees: it's not bad
[23:35] <kees> okay, cool. I'll give it a shot.
[23:35] <bjf[afk]> kees: i don't build arm much anymore so i've kind of lost my frame of reference