| === bjf is now known as bjf[afk] | ||
| bjf[afk] | ogasawara: still around? | 01:06 |
|---|---|---|
| === bjf[afk] is now known as bjf | ||
| ogasawara | bjf: yep | 01:06 |
| 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:07 |
| 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:08 |
| 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:10 |
| === bjf is now known as bjf[afk] | ||
| ogasawara | bjf[afk]: should be about 44G free now, not sure who else is consuming space | 01:11 |
| 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:40 |
| === jjohansen is now known as jj-afk | ||
| 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] | 01:55 |
| === em is now known as emma | ||
| 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:04 |
| 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:11 |
| bbordwell | sconklin-gone, should be since its already fixed upstream. Just want to clean up after the mess its leaving on lp :) | 02:12 |
| 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:14 |
| sconklin-gone | looks fine to me~ | 02:16 |
| sconklin-gone | ! | 02:16 |
| === emma is now known as em | ||
| ikepanhc | lag: https://wiki.ubuntu.com/Kernel/Dev/MultipleISOBootUSBKey | 10:06 |
| lag | Well done ikepanhc - thank you | 10:07 |
| ikepanhc | :) | 10:07 |
| === yofel_ is now known as yofel | ||
| === amitk is now known as amitk-afk | ||
| === amitk-afk is now known as amitk | ||
| === cnd__ is now known as cnd | ||
| === cnd is now known as cnd_ | ||
| === ivoks-away is now known as ivoks | ||
| === cnd_ is now known as cnd | ||
| === ivoks is now known as ivoks_away | ||
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| jdstrand | smb: I appreciate it | 14:10 |
| 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:12 |
| * smb wonders how many properlies he manages to put into one sentence | 14:13 | |
| jdstrand | hehe | 14:13 |
| 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:14 | |
| 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:15 |
| smb | No problem. We love OPPs :) | 14:16 |
| 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:35 |
| tgardner | diwic, there is plenty of help in the command itself, git bisect --help | 14:37 |
| 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:38 |
| diwic | tgardner, I'd like to learn how to do git bisecting then, so I can hold people in their hands later | 14:41 |
| tgardner | diwic, no better way to learn then to just do it | 14:42 |
| 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:47 |
| abogani | diwic, I don't suggest you to build a deb package for a git bisect section. | 14:51 |
| diwic | abogani, but instead...? | 14:53 |
| abogani | diwic, IMHO Upstream method is more easy for that. | 14:54 |
| diwic | abogani, so assume I've compiled an upstream kernel. How do install it? "make install" and then "sudo grub-install"? | 14:56 |
| 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. | 14:59 |
| diwic | abogani, now that is something that should be in a wiki page | 15:00 |
| === amitk is now known as amitk-afk | ||
| === bjf[afk] is now known as bjf | ||
| === lamont` is now known as lamont | ||
| JFo | ogasawara, the current list of those is here: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=gfxpayload%3Dkeep | 16:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| kees | frankly, I think the CAN bug is more pressing. :) | 16:36 |
| kees | anyway, s'all good | 16:36 |
| === jj-afk is now known as jjohansen | ||
| === komputes_ubuntu is now known as komputes | ||
| * smb thinks he now has re-uploaded everything in need and that it is now past boc | 17:04 | |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:18 |
| smb | NP, need to remember to clean up after big build tests | 17:19 |
| 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:21 |
| smb | Stuck in proposed and overrun by security | 17:22 |
| smb | kamal, ^ | 17:22 |
| kamal | smb: got it, thanks | 17:22 |
| * smb -> out (really) | 17:23 | |
| bjf | tgardner: the branch has been rebased | 17:24 |
| tgardner | bjf, lemme know when you've finisihed your rebase | 17:24 |
| tgardner | :) | 17:24 |
| 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:25 |
| * bjf notes the glow in the east even in the bright morning light | 17:26 | |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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 | 19:28 |
| * jjohansen -> lunch | 20:06 | |
| 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:29 |
| DrGrov | No help then, nevermind. | 20:33 |
| 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:06 |
| 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:07 | |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| tgardner | its one of those "it either works, or it doesn't" kind of patch sets | 21:14 |
| 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:15 |
| tgardner | kees, well, float 'em on the list and see what folks think | 21:16 |
| kees | tgardner: okay, I'll wait for npitre's last commit and I'll send 'em. | 21:17 |
| tgardner | kees, EOD for me. see you Monday | 21:23 |
| Kano | hi, when will be 2.6.35.3 mainline be ready | 21:44 |
| 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:55 |
| ogasawara | kees: I want to say yes, are you using the current kteam-tools/buildscripts ? | 21:56 |
| 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:57 |
| ogasawara | kees: https://wiki.ubuntu.com/Kernel/Dev/KernelBuildScripts | 21:58 |
| ogasawara | kees: but it doesn't mention the arm builds :( | 21:58 |
| === kentb is now known as kentb-afk | ||
| bjf | kees: there's a very simple way to do it on tangerine | 22:39 |
| bjf | kees: schroot -c maverick-armel;fdr clean; fdr binary-<flavour> | 22:41 |
| 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:43 |
| cnd | hopefully I can find some time to check it out | 22:44 |
| === bjf is now known as bjf[afk] | ||
| 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:13 |
| kees | bjf[afk]: but that "native" via emulation, right? isn't it pretty slow? | 23:34 |
| bjf[afk] | kees: it's not bad | 23:34 |
| 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 | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!