[00:02] * kees looks around for tgardner [00:03] here's what seccomp_bpf will look like, most likely... https://lkml.org/lkml/2012/3/1/504 just to give folks a heads-up. [00:06] ogasawara: ^^ if you're interested. === ogasawara_ is now known as ogasawara === smb` is now known as smb [09:56] * apw yawns [09:57] UBUNTU: SAUCE: iwlwifi: fix key removal [09:57] if that isn't the fix for my constant disconnects i will be amazed [09:59] That being SAUCE even? [10:00] Err, I mean I am (positively) surprised about it [10:03] ah, sauce because it may not yet be upstream [10:39] apw: Oh, iwlwifi is going to stop being crap? Yay! [10:41] apw: P/omap4 failed to build - missing module [10:44] ppisati, ? [10:45] ppisati, so much for updating the tree and emailing tim [10:46] ppisati, will sort it out [11:09] ppisati, so i think what happened was that the previous version was already uploaded, just stuck in the freeze queue. but you can't tell that easily from the normal interfaces we check in the archive [11:09] ppisati, anyhow, i've uploaded the fix over the top [11:09] apw: cool, thanks [11:10] ppisati, we tried at least to avoid it [11:11] apw: we fought an unfair battle, we knew we would loose but we did our best, rust in peace previous P/omap4 HEAD... [11:12] * ppisati feels extremely stupid today :) [11:23] heh [12:26] * cking notes that systemtap for Precise works in the kernel space fine [12:40] tgardner, fyi i re-uploaded precise/ti-omap4 to fix a build failure [12:40] apw, ack [12:41] apw, what was it? I test cross compiled first [12:41] tgardner, we forgot that armhf is also built when handling the module being removed [12:41] apw, ah [12:41] doh! [12:41] its going to happen a few times before we remember :) [12:43] * tgardner reboots after update [13:02] ppisati, bug 927526 is still unverified, if we think the config changes are enough we can just verify the config on new kernel and mark as verified, what do you think? [13:02] Launchpad bug 927526 in linux-ti-omap4 "missing support for some LIRC devices" [Undecided,Fix committed] https://launchpad.net/bugs/927526 [13:03] herton, if all we have done is turned things on it is pretty low risk, as they clearly didn't work before [13:04] yeah, the only worry I had was that the guy talks about other config options we didn't touch, anyway if there is more to turn on can be done later [13:20] herton: sorry, i was in a call [13:21] herton: since it's just a config change (and actually someone rported it was ok IIRC), i think we can move fwd [13:21] that being said -> lunch === yofel_ is now known as yofel [13:41] ppisati, apw: marked as verified, in case something more is needed I just requested feedback on the bug [13:46] bjf - i set the certification-testing-passed tag on the Lucid tracking bug, but now Launchpad is barfing so I can't update the task status. hope it doesn't mess anything up [13:58] brendand, I set the task there to fix released [14:20] * tgardner must deliver a vehicle for repair. back in 30 or so... [14:29] amitk: ping [14:29] amitk: so I think I'm reproducing your byobu bug here, I saw that creep up last week [14:29] amitk: I think it's a very recent regression [14:29] amitk: I have a few questions for you, if you have a minute === bladernr_afk is now known as bladernr_ [14:48] ogasawara, fyi i think you should find gcc already published [14:48] (so i am told) [14:48] apw: yep, saw the note. I'm planning to kick off some test builds/boots and then upload by eod [14:49] ogasawara, awsome, that Intel wireless fix sounds just like the problem i have here on my boxes [14:49] apw: yep, I think a few people are going to be happy with that one [14:49] apw: I say we flipped aufs back on too [14:49] s/say/saw/ [14:50] ogasawara, i think tgardner already did that [14:50] tgardner, ^^ [14:50] ogasawara, after this upload i'll recheck aufs is up to date, was last i checked [14:51] apw: ack [14:56] * tgardner is back [15:02] ogasawara, the arm chroots on gomeisa are broken again. looks like I'll have to re-install. you can use tangerine in the meantime. [15:02] tgardner: ack [15:02] cking, herton ^^ [15:03] tgardner, ok [15:04] ok [15:04] tgardner, did you just destroy all the precise chroots on gomisa? [15:04] apw, just now [15:05] tgardner, that explains why my build just went bang rather specitacularly then [15:05] apw, dang, I checked to see if anyone was using the chroots [15:05] apw, wouldn't there be mounts against the chroot ? [15:06] tgardner, i'd assume so, it got about half way through, so it had been going about 5m when objdump went away [15:06] tgardner, i am using schroot to get in em [15:06] apw, hmm, maybe my checking was defective [15:07] oh well, done now [15:07] apw, I'll have x86'en back in 10 mins or so [15:07] sorry [15:10] hopfully my build will finish before leann lets loose and kills it [15:11] heh [15:13] apw, I am going to box up my emerald today and send it too the Boston DC so we'll have a tangerine duplicate [15:16] tgardner, sounds good ... [15:16] * apw pops out to get some supplies [15:20] kirkland: hiya [15:21] amitk: hey! [15:21] amitk: couple of questions for you... [15:21] kirkland: how goes it? [15:21] sure [15:21] amitk: pretty well [15:21] amitk: I think I might be seeing the same thing as you [15:21] amitk: but I'm not sure [15:21] amitk: does this feel like a recent regression? [15:22] kirkland: TBH, I don't know. I switched to the tmux backend in January I think. But I never really looked at cpu usage. [15:22] amitk: k [15:23] amitk: also, are you seeing this on real hardware, or vm's? [15:23] amitk: or both? [15:23] amitk: and how much mem/cpu does your system(s) have [15:23] kirkland: amazon ec2 [15:24] amitk: instance size? [15:24] kirkland: large (dual core 2.7GHz, 8Gb RAM) [15:24] amitk: hmmf [15:25] amitk: okay [15:25] and it consistently takes 15-30% whether I'm attached or not [15:25] amitk: yeah, that's definitely not right [15:26] amitk: okay, I'll spend some good time on it this weekend [15:26] amitk: this should absolutely be fixed asap [15:32] kirkland: I was just helping out a friend when I saw this. Thought you'd like to know. I'll let him know it is being looked at urgently. Thanks a lot! [15:33] amitk: thanks -- so you're not experiencing it yourself directly? [15:33] I am [15:33] amitk: k [15:33] kirkland: i'll be able to help debug it if you need [15:33] amitk: k [15:34] ogasawara, do you think my message about aufs was sufficient to put the fear of *choose your deity* into current aufs consumers ? [15:35] tgardner: heh, yep. I liked it. [15:36] ogasawara, please remember to continue dissing aufs during the Q cycle [15:37] tgardner: ack. I'm gonna flip it back off for Q. [15:40] * ogasawara back in 20 [15:56] * tgardner is off to box an Emerald [16:03] amitk: the next time you see it, can you post a screenshot of top running? [16:03] amitk: so that I see the processes that are running? [16:19] kirkland: I've switched back to tmux, but the problem is failing to show up ATM. Will post to the bug if I see it again. === bladernr_ is now known as bladernr_afk === bladernr_afk is now known as bladernr_ === ehw is now known as ehw|l1 === ehw|l1 is now known as ehw [16:43] [1531525.609275] nf_ct_sip: dropping packetIN=eth0 OUT= MAC=00:0e:0c:5c:1c:78:00:0c:85:be:5a:85:08:00 SRC=192.168.133.192 DST=192.168.133.1 LEN=591 TOS=0x10 PREC=0x40 TTL=64 ID=45472 PROTO=UDP SPT=50855 DPT=5060 LEN=571 [16:43] that is bothersome [16:43] mostly since it happens every second or 4 [16:50] someone calling in? [16:50] bjf: Hey, I'm having trouble testing a mainline kernel for bisecting bug 929111 - the machine doesn't boot completely w/ mainline kernels like linux-image-3.2.1-030201-generic 3.2.1-030201.201201121644. I can get to a VT, and in top I see that a number of modprobe calls are hung in I/O wait. Commands like 'lsmod' hang in I/O wait too. Any suggestions (try a different mainline kernel?) [16:50] seems destined to sip [16:50] Launchpad bug 929111 in linux "Repeated freezes when running on battery power" [High,Confirmed] https://launchpad.net/bugs/929111 [16:51] smagoun: yes, the only thing i can suggest right now is to try a different one [16:51] k [16:53] bah... nf_ct_sip should be clear it is sip. stupid me [17:02] smb: it's a cisco 7940 phone registering... over and over and over. [17:02] and netfilter going "hey, wtf? I don't understand. HALP HOW MAKE COMPUTAR WORK?" and so on. [17:02] lamont, Ah, fun... not [17:03] On the bright side, the phone is demonstrating that it can count, since the source port goes up by one each time [17:03] there is no established connection between the two, and nf doesn't think there should be, apparently [17:03] * smb wonders what happens when it wraps back to 0... [17:04] 46095 now === arun__ is now known as arun_ [17:05] wasnt that 50855 already [17:08] sigh. ID!=SPT [17:08] 51583 [17:12] lamont, Oh, looking at the modules code there does not seem to be much desire to have it be more specific about what is bad if it is bad... :/ === amitk is now known as amitk-afk [18:14] * smb decides to have reached wheat-o-clock [18:32] * apw is of a similar position ... later [18:32] * cking --> winding down, EOD [18:55] * tgardner -> lunch [20:30] * tgardner makes yet another trip to town to fetch repaired vehicle. [21:11] apw: so... dieter is a troll === bladernr_ is now known as bladernr_afk === dduffey_afk is now known as dduffey