[00:56] 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] Hi I'm seeing logs in kern.log like the following immediately before OMM-Killer kills my chromium task. [04:38] 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] what does the above kernel message indicate? [04:39] A link to documention would be appreciated. [04:44] 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] It's unlikely to be the cause of the OOM killer going on a rampage. [04:46] RAOF: I just see it immediately before the OOM-killer. [04:47] RAOF: and I'm partly just curious what the log is indicating. [04:47] 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] It's indicating that the process tried to do something that it shouldn't. [04:49] RAOF: What does the debugging information in the log point to? [04:49] It says that pid 2060 (chromium-browse) from user uid=1000 (ie: you) had a syscall (specifically, syscall 20) denied. [04:52] RAOF: What do the numbers in parens after audit refer to? [04:52] No idea :) [05:20] RAOF: If I looked up the syscall number correctly then it refers to the epoll_create1 syscall. Does that sound right? [05:21] Entirely plausible [05:38] RAOF: I'm really wondering if that failed syscall is somehow indirectly causing the OMM-kill later. [05:39] I think that's unlikely. [05:40] 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] 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] RAOF: I am curious about what's going on in Chromium around the time that syscall is blocked though. [06:01] Probably process startup. [06:01] 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] 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] 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] Nor do they use seccomp :) [06:08] RAOF: I'm assuming that's related to the chrome-sandbox? [06:08] Chrome's sandbox uses seccomp, yes. [06:08] RAOF: [06:08] RAOF: Yeah, that's what I meant. [06:10] RAOF: Thanks for patiently answering my questions. [06:21] 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] ppisati, as in no envelope at all? [09:59] apw: rigt [09:59] apw: right, i don't have the envelope icon at all [09:59] i just moved my desktop to the haswell box and reinstalled Q from scratch [10:00] hmmm ... try an apt-get install ubuntu-desktop^ [10:00] ppisati, did you say Q ... i notice its gone here too [10:00] ppisati, i hadn't noticed as i don't use any apps which use it [10:00] :( [10:00] skype is somehow broken [10:01] msn too [10:01] ok, i'm disconnected... [10:04] ppisati, /me is asking about the envelope on #ubuntu-unity [10:06] lemme join [10:08] 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] ?!?! [10:08] no no [10:10] 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] :( [10:11] * ppisati wants to die [10:11] geez, you italians are always so fatal :) [10:11] its that bad is it? [10:36] 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] cking, without modding debian/rules i don't think so [10:39] you might look at how CROSSCOMPILE is done for something we could apply [10:39] yeah, if only it was that easy [10:39] no worries, I will hack around a bit more [10:41] hello everyone [10:43] cking, ok there is a CC override, see LOCAL_ENV_CC [10:43] 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] cking, see how that is done in debian/rules.d/0* [10:43] apw, thanks! [10:43] cking, and there might be where to add a new stanza for it too, as kmake is the right thing to mod [10:43] my laptop is using the iwlwifi driver, i guess =) [10:43] anon3, hi [10:44] hey apw [10:46] 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] cking, i recon a LOCAL_ENV_SMATCH or something would work pretty well [10:47] * cking nods [10:47] i've found some interesting variable in /net/mac80211/scan.c [10:47] IEEE80211_CHANNEL_TIME (HZ / 33) and IEEE80211_PROBE_DELAY (HZ / 33) [10:48] but, in nearly every kernel version the definition of these variables are the same, but the devices are sending in different intervals [10:50] is here anybody who is well schooled in this topic? =) [10:50] anon3, well some devices do background scanning in firmware, so perhaps that is what you are seeing [10:50] those may only be used for devices with no firmware suppotr [10:50] but then i am no expert [10:52] you mean those two variables i have wrote down? [10:52] in scan.c? [10:53] if the sending behavior is implemented in the firmware i won't have a chance to see the implementation? [10:53] yeah, i am pretty sure a lot of devices do scanning on their own [10:53] from the firmware, not necessarily from higher levels [10:54] okay [10:54] i've tried to edit theses variables and recompiled the kernel [10:54] but that didn't make much effect [10:56] so apw, thank you for your help and hints! [10:56] have a nice day! [11:45] * ppisati -> out for lunch [13:02] hi [13:02] I know that armel is dropped in raring but could kernel support it at least for headers? [13:03] I need them for armhf/armel cross compiler [13:05] hrw, wouldnt that require that there is a buildd that builds the source targeted for armel ? [13:05] i dotn think we have that in raring [13:06] ogra-cb: not necessary [13:08] ogra-cb: I take linux-source-3.7.0 package and run dpkg-buildpackage -aarmel with some options just to get headers [13:08] 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] but i might be wrong [13:14] also how would you publish the resulting binary ? the archive doesnt have any armel support anymore [13:18] armel-cross-toolchain-base does it [13:18] what ? publish a non existing arch ? [13:18] check which binaries it generates [13:18] 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] I do not publish arch:armel but arch:all packages [13:19] ah [13:21] 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] but for that I need partial support for armel [13:21] ah, k [13:23] and this blocks whole arm{el,hf} cross compiler stuff [13:24] aarch64 one is now pbuilding [14:01] has anyone ever experienced fs corption on the haswell box? [14:01] *corruption [14:50] ppisati, nope, not yet [14:50] when i came back, the fs was in ro and the screen was full of 'sda retry failed blablabla" [14:51] but not panic or oops [14:51] i'll try to catch it early next time, and scroll to the beginning of the carnage [14:53] ppisati, my earlier SDPs had flaky SATA connector plugs which caused errors like this [14:53] weird [14:53] becasue yesterday i had no prob at all [14:54] i blame every problem now on entropy [14:54] :) [15:14] 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] I've seen this error before but can't remember what it was. [15:16] Compiling 49 OIDs [15:16] presumably that was meant to make the .c [15:17] oid_registry.c is just a regular file [15:17] oid_registry_data.c is the one that is generated [15:18] erp, then no that cannot happen :) [15:18] maybe I'll just rerun the build [15:20] rtg maybe, i cannot see any reason it would go missing ... sigh [15:20] i386 is already past that point in the build. [15:20] double erp [15:20] I kind of hate instabilities on the buildds [15:21] i have heard of removing the /build directory being an approved way to stop a build; maybe something like that happened [15:21] i wish there was some way to tell if human intervention was the cause [15:22] apw, well whats weird is that I've seen this exact same build failure before [15:22] rtg, so it has to be a parallel race somehow then ... but quite how [15:23] apw, don't think so. its -j1 [15:24] apw, oh well, maybe I'll start grinding through all of the firmware issues [15:25] * apw utterly fails to test steam [15:25] utter fail on my system, 3.7gb download to say "not compatible with your system" [15:25] ya gotta love it :) [15:58] * ogasawara back in 20 [16:10] Is the plan to ship 3.5 by default in 12.04.2? [16:12] Theodoros, yes. The Raring kernel will get shipped in 12.04.3 [16:13] Raring != 3.5 [16:13] bjf, and 12.04.3 != 12.04.2 [16:13] Okay so after some false starts I was able to fully understand my issues with samba and 3.5 in precise [16:13] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1075670 [16:13] Launchpad bug 1075670 in linux (Ubuntu) "samba panics with sys_setgroups failed" [High,Incomplete] [16:14] rtg, so "yes" meant what exactly? :-) [16:14] bjf, yes meant that we _are_ shipping 3.5 in 12.04.2 [16:14] ack [16:15] Thanks for the prompt answer btw :D [16:16] * bjf is going to go soak his head === rsalveti_ is now known as rsalveti [17:45] * ppisati -> EOW [17:47] 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] i'll be doing the -34 version as soon as that is out of the way [17:53] so i heard there will be config 2normalization" for the nexus7 kernel [17:54] *s/2/\"/ [17:54] 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] ograjust USB mostly, right ? [17:55] yeah [17:55] probably some BT [17:55] not swure the kernel has anything for the client side [18:18] * rtg -> lunch [18:19] * apw wanders off for beer ... [18:58] apw: emergency lowlatency is in proposed, so the new rebase can head to the PPA whenever you're appropriately drunk. === bryceh_ is now known as bryce [19:47] * rtg -> EOW === yofel_ is now known as yofel [22:29] is there a newer kernel package for testing a graphics driver issue, than the one that ships with Ubuntu 12.10? [22:43] patr|ck: There's the one in 13.04, of course. [22:45] infinity, can that package be installed on 12.10 or would that require other packages to be updated, too? [22:53] patr|ck: Should install fine on 12.10, I don't think any deps got bumped. [22:53] nice, thank you