[00:56] <BenC> apw: I've purposely disabled ABI until the package settled down…will enable it on next upload and do a -1 ABI bump
[04:38] <dlbike76> Hi I'm seeing logs in kern.log like the following immediately before OMM-Killer kills my chromium task.
[04:38] <dlbike76> Nov 15 20:41:09 artemis kernel: [ 1980.410410] type=1701 audit(1353030069.602:24): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=2060 comm="chromium-browse" reason="seccomp" sig=0 syscall=20 compat=0 ip=0xb2f76424 code=0x50000
[04:39] <dlbike76> what does the above kernel message indicate?
[04:39] <dlbike76> A link to documention would be appreciated.
[04:44] <RAOF> dlbike76: That's the seccomp security filtering system kicking in. I'm not sure if there *is* documentation to point you at, sorry.
[04:45] <RAOF> It's unlikely to be the cause of the OOM killer going on a rampage.
[04:46] <dlbike76> RAOF: I just see it immediately before the OOM-killer.
[04:47] <dlbike76> RAOF: and I'm partly just curious what the log is indicating.
[04:47] <Sarvatt> I really wish I knew how to disable seccomp with a kernel command line option instead of having to launch chrome with --disable-seccomp-filter-sandbox so it didn't spam dmesg so bad :P
[04:47] <RAOF> It's indicating that the process tried to do something that it shouldn't.
[04:49] <dlbike76> RAOF: What does the debugging information in the log point to?
[04:49] <RAOF> It says that pid 2060 (chromium-browse) from user uid=1000 (ie: you) had a syscall (specifically, syscall 20) denied.
[04:52] <dlbike76> RAOF: What do the numbers in parens after audit refer to?
[04:52] <RAOF> No idea :)
[05:20] <dlbike76> RAOF: If I looked up the syscall number correctly then it refers to the epoll_create1 syscall.  Does that sound right?
[05:21] <RAOF> Entirely plausible
[05:38] <dlbike76> RAOF: I'm really wondering if that failed syscall is somehow indirectly causing the OMM-kill later.
[05:39] <RAOF> I think that's unlikely.
[05:40] <RAOF> More likely is that chromium is spawning a process, which during its initialisation harmlessly tries to do something that seccomp denies, then allocates too much memory.
[06:00] <dlbike76> RAOF: Just to be clear, I wasn't suggesting that this was necessarily a problem in the kernel.  At least not at this point.
[06:00] <dlbike76> RAOF: I am curious about what's going on in Chromium around the time that syscall is blocked though.
[06:01] <RAOF> Probably process startup.
[06:01] <RAOF> Which is going to dirty a bunch of memory, which is going to cause the OOM killer to kick in if you've got memory pressure.
[06:03] <dlbike76> RAOF: I guess the docs referring to file descriptors are throwing me off.  I also haven't done any low level programming in awhile, so...
[06:07] <dlbike76> RAOF: I can't reproduce the same thing in either firefox or midori, but then again neither of them spawn a bunch of child processes.
[06:07] <RAOF> Nor do they use seccomp :)
[06:08] <dlbike76> RAOF: I'm assuming that's related to the chrome-sandbox?
[06:08] <RAOF> Chrome's sandbox uses seccomp, yes.
[06:08] <dlbike76> RAOF: 
[06:08] <dlbike76> RAOF: Yeah, that's what I meant.
[06:10] <dlbike76> RAOF: Thanks for patiently answering my questions.
[06:21] <dlbike76> RAOF: Oh, and I agree now that the seccomp thing and the OMM-killer thing are unrelated.  I think you described the situation pretty well.
[09:26]  * ppisati notes that the messages indicator doesn't show up anymore...
[09:58]  * apw finally finds his cve 'rebase' issue ... sigh
[09:58] <apw> ppisati, as in no envelope at all?
[09:59] <ppisati> apw: rigt
[09:59] <ppisati> apw: right, i don't have the envelope icon at all
[09:59] <ppisati> i just moved my desktop to the haswell box and reinstalled Q from scratch
[10:00] <apw> hmmm ... try an apt-get install ubuntu-desktop^
[10:00] <apw> ppisati, did you say Q ... i notice its gone here too 
[10:00] <apw> ppisati, i hadn't noticed as i don't use any apps which use it
[10:00] <ppisati> :(
[10:00] <ppisati> skype is somehow broken
[10:01] <ppisati> msn too
[10:01] <ppisati> ok, i'm disconnected...
[10:04] <apw> ppisati, /me is asking about the envelope on #ubuntu-unity
[10:06] <ppisati> lemme join
[10:08] <apw> ppisati, it seems it is normal if you have not yet run anything which uses it, trying to work out of this is a change or we are just unobservant
[10:08] <ppisati> ?!?!
[10:08] <ppisati> no no
[10:10] <ogra_> ppisati, now that you mention it, i dont have the message indicator either on my raring install (on a chromebook though, i thought it was just arm fallout)
[10:11] <ppisati> :(
[10:11]  * ppisati wants to die
[10:11] <ogra_> geez, you italians are always so fatal :)
[10:11] <cking> its that bad is it?
[10:36] <cking> apw, I want to build a kernel using "debian/rules build" and also set CHECK and CC so I can run smatch at compile time, any idea how I can easily do that?
[10:38] <apw> cking, without modding debian/rules i don't think so
[10:39] <apw> you might look at how CROSSCOMPILE is done for something we could apply
[10:39] <cking> yeah, if only it was that easy 
[10:39] <cking> no worries, I will hack around a bit more
[10:41] <anon3> hello everyone
[10:43] <apw> cking, ok there is a CC override, see LOCAL_ENV_CC
[10:43] <anon3> can somebody give me adive? i would like to change the active sending behavior of IEEE 802.11 probe requests for an active ap search
[10:43]  * cking looks
[10:43] <apw> cking, see how that is done in debian/rules.d/0*
[10:43] <cking> apw, thanks!
[10:43] <apw> cking, and there might be where to add a new stanza for it too, as kmake is the right thing to mod
[10:43] <anon3> my laptop is using the iwlwifi driver, i guess =)
[10:43] <apw> anon3, hi
[10:44] <anon3> hey apw
[10:46] <anon3> the reason why i want to change the interval of sending probe requests: i'm writing my thesis about fingerprinting of individual devices with help of probe requests..(sorry about my bad english). therefore i have to analyze how a device is sending the probe requests and where is the sending behavior implemented
[10:46] <apw> cking, i recon a LOCAL_ENV_SMATCH or something would work pretty well
[10:47]  * cking nods
[10:47] <anon3> i've found some interesting variable in /net/mac80211/scan.c   
[10:47] <anon3> IEEE80211_CHANNEL_TIME (HZ / 33) and IEEE80211_PROBE_DELAY (HZ / 33)
[10:48] <anon3> but, in nearly every kernel version the definition of these variables are the same, but the devices are sending in different intervals
[10:50] <anon3> is here anybody who is well schooled in this topic? =)
[10:50] <apw> anon3, well some devices do background scanning in firmware, so perhaps that is what you are seeing
[10:50] <apw> those may only be used for devices with no firmware suppotr
[10:50] <apw> but then i am no expert
[10:52] <anon3> you mean those two variables i have wrote down?
[10:52] <anon3> in scan.c?
[10:53] <anon3> if the sending behavior is implemented in the firmware i won't have a chance to see the implementation?
[10:53] <apw> yeah, i am pretty sure a lot of devices do scanning on their own
[10:53] <apw> from the firmware, not necessarily from higher levels
[10:54] <anon3> okay
[10:54] <anon3> i've tried to edit theses variables and recompiled the kernel
[10:54] <anon3> but that didn't make much effect
[10:56] <anon3> so apw, thank you for your help and hints!
[10:56] <anon3> have a nice day!
[11:45]  * ppisati -> out for lunch
[13:02] <hrw> hi
[13:02] <hrw> I know that armel is dropped in raring but could kernel support it at least for headers?
[13:03] <hrw> I need them for armhf/armel cross compiler
[13:05] <ogra-cb> hrw, wouldnt that require that there is a buildd that builds the source targeted for armel ?
[13:05] <ogra-cb> i dotn think we have that in raring
[13:06] <hrw> ogra-cb: not necessary
[13:08] <hrw> ogra-cb: I take linux-source-3.7.0 package and run dpkg-buildpackage -aarmel with some options just to get headers
[13:08] <hrw> do not need it to be able to build kernel
[13:12]  * ogra-cb doesnt think thats something you can easily do on a buildd
[13:12] <ogra-cb> but i might be wrong
[13:14] <ogra-cb> also how would you publish the resulting binary ? the archive doesnt have any armel support anymore
[13:18] <hrw> armel-cross-toolchain-base does it
[13:18] <ogra-cb> what ? publish a non existing arch ?
[13:18] <hrw> check which binaries it generates
[13:18] <ogra-cb> there is no more Packages.gz for armel, how would you provide it ?
[13:19]  * ogra-cb thinks this discussion would be better suited for #ubuntu-release
[13:19] <hrw> I do not publish arch:armel but arch:all packages
[13:19] <ogra-cb> ah
[13:21] <hrw> armel-cross-toolchain-base (actb in short) generates linux-libc-dev-armel-cross from linux-source-3.x.0 package as arch:all
[13:21] <hrw> but for that I need partial support for armel
[13:21] <ogra-cb> ah, k
[13:23] <hrw> and this blocks whole arm{el,hf} cross compiler stuff
[13:24] <hrw> aarch64 one is now pbuilding
[14:01] <ppisati> has anyone ever experienced fs corption on the haswell box?
[14:01] <ppisati> *corruption
[14:50] <cking> ppisati, nope, not yet
[14:50] <ppisati> when i came back, the fs was in ro and the screen was full of 'sda retry failed blablabla"
[14:51] <ppisati> but not panic or oops
[14:51] <ppisati> i'll try to catch it early next time, and scroll to the beginning of the carnage
[14:53] <cking> ppisati, my earlier SDPs had flaky SATA connector plugs which caused errors like this
[14:53] <ppisati> weird
[14:53] <ppisati> becasue yesterday i had no prob at all
[14:54] <cking> i blame every problem now on entropy
[14:54] <ppisati> :)
[15:14] <rtg> apw, here is a puzzler: https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport/+build/3988532/+files/buildlog_ubuntu-precise-amd64.linux-lts-raring_3.7.0-2.8%7Eprecise1_FAILEDTOBUILD.txt.gz
[15:15] <rtg> I've seen this error before but can't remember what it was.
[15:16] <apw> Compiling 49 OIDs
[15:16] <apw> presumably that was meant to make the .c
[15:17] <rtg> oid_registry.c is just a regular file
[15:17] <rtg> oid_registry_data.c is the one that is generated
[15:18] <apw> erp, then no that cannot happen :)
[15:18] <rtg> maybe I'll just rerun the build
[15:20] <apw> rtg maybe, i cannot see any reason it would go missing ... sigh
[15:20] <rtg> i386 is already past that point in the build.
[15:20] <apw> double erp
[15:20] <rtg> I kind of hate instabilities on the buildds
[15:21] <apw> i have heard of removing the /build directory being an approved way to stop a build; maybe something like that happened
[15:21] <apw> i wish there was some way to tell if human intervention was the cause
[15:22] <rtg> apw, well whats weird is that I've seen this exact same build failure before
[15:22] <apw> rtg, so it has to be a parallel race somehow then ... but quite how
[15:23] <rtg> apw, don't think so. its -j1
[15:24] <rtg> apw, oh well, maybe I'll start grinding through all of the firmware issues
[15:25]  * apw utterly fails to test steam
[15:25] <apw> utter fail on my system, 3.7gb download to say "not compatible with your system"
[15:25] <rtg> ya gotta love it :)
[15:58]  * ogasawara back in 20
[16:10] <Theodoros> Is the plan to ship 3.5 by default in 12.04.2?
[16:12] <rtg> Theodoros, yes. The Raring kernel will get shipped in 12.04.3
[16:13] <bjf> Raring != 3.5
[16:13] <rtg> bjf, and 12.04.3 != 12.04.2
[16:13] <Theodoros> Okay so after some false starts I was able to fully understand my issues with samba and 3.5 in precise
[16:13] <Theodoros> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1075670
[16:13] <ubot2> Launchpad bug 1075670 in linux (Ubuntu) "samba panics with sys_setgroups failed" [High,Incomplete]
[16:14] <bjf> rtg, so "yes" meant what exactly? :-)
[16:14] <rtg> bjf, yes meant that we _are_ shipping 3.5 in 12.04.2
[16:14] <bjf> ack
[16:15] <Theodoros> Thanks for the prompt answer btw :D
[16:16]  * bjf is going to go soak his head
[17:45]  * ppisati -> EOW
[17:47] <apw> bjf, herton, fyi i have just uploaded an emergency linux-lowlatency identicle to that in -updates but with -pae enabled, this is going round the back and you can ignore it
[17:47] <apw> i'll be doing the -34 version as soon as that is out of the way
[17:53] <ogra_> so i heard there will be config 2normalization" for the nexus7 kernel
[17:54] <ogra_> *s/2/\"/
[17:54] <ogra_> it would be good to restrict that to modules for HW you can actualy attach to the device than making it to ubuntu generic like
[17:55] <rtg> ograjust USB mostly, right ?
[17:55] <ogra_> yeah
[17:55] <ogra_> probably some BT 
[17:55] <ogra_> not swure the kernel has anything for the client side 
[18:18]  * rtg -> lunch
[18:19]  * apw wanders off for beer ...
[18:58] <infinity> apw: emergency lowlatency is in proposed, so the new rebase can head to the PPA whenever you're appropriately drunk.
[19:47]  * rtg -> EOW
[22:29] <patr|ck> is there a newer kernel package for testing a graphics driver issue, than the one that ships with Ubuntu 12.10?
[22:43] <infinity> patr|ck: There's the one in 13.04, of course.
[22:45] <patr|ck> infinity, can that package be installed on 12.10 or would that require other packages to be updated, too?
[22:53] <infinity> patr|ck: Should install fine on 12.10, I don't think any deps got bumped.
[22:53] <patr|ck> nice, thank you