BenC | apw: I've purposely disabled ABI until the package settled down…will enable it on next upload and do a -1 ABI bump | 00:56 |
---|---|---|
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:38 |
dlbike76 | what does the above kernel message indicate? | 04:39 |
dlbike76 | A link to documention would be appreciated. | 04:39 |
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:44 |
RAOF | It's unlikely to be the cause of the OOM killer going on a rampage. | 04:45 |
dlbike76 | RAOF: I just see it immediately before the OOM-killer. | 04:46 |
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:47 |
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:49 |
dlbike76 | RAOF: What do the numbers in parens after audit refer to? | 04:52 |
RAOF | No idea :) | 04:52 |
dlbike76 | RAOF: If I looked up the syscall number correctly then it refers to the epoll_create1 syscall. Does that sound right? | 05:20 |
RAOF | Entirely plausible | 05:21 |
dlbike76 | RAOF: I'm really wondering if that failed syscall is somehow indirectly causing the OMM-kill later. | 05:38 |
RAOF | I think that's unlikely. | 05:39 |
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. | 05:40 |
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:00 |
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:01 |
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:03 |
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:07 |
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:08 |
dlbike76 | RAOF: Thanks for patiently answering my questions. | 06:10 |
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. | 06:21 |
* ppisati notes that the messages indicator doesn't show up anymore... | 09:26 | |
* apw finally finds his cve 'rebase' issue ... sigh | 09:58 | |
apw | ppisati, as in no envelope at all? | 09:58 |
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 | 09:59 |
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:00 |
ppisati | msn too | 10:01 |
ppisati | ok, i'm disconnected... | 10:01 |
apw | ppisati, /me is asking about the envelope on #ubuntu-unity | 10:04 |
ppisati | lemme join | 10:06 |
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:08 |
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:10 |
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:11 |
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:36 |
apw | cking, without modding debian/rules i don't think so | 10:38 |
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:39 |
anon3 | hello everyone | 10:41 |
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:43 |
anon3 | hey apw | 10:44 |
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:46 |
* 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:47 |
anon3 | but, in nearly every kernel version the definition of these variables are the same, but the devices are sending in different intervals | 10:48 |
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:50 |
anon3 | you mean those two variables i have wrote down? | 10:52 |
anon3 | in scan.c? | 10:52 |
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:53 |
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:54 |
anon3 | so apw, thank you for your help and hints! | 10:56 |
anon3 | have a nice day! | 10:56 |
* ppisati -> out for lunch | 11:45 | |
hrw | hi | 13:02 |
hrw | I know that armel is dropped in raring but could kernel support it at least for headers? | 13:02 |
hrw | I need them for armhf/armel cross compiler | 13:03 |
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:05 |
hrw | ogra-cb: not necessary | 13:06 |
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:08 |
* ogra-cb doesnt think thats something you can easily do on a buildd | 13:12 | |
ogra-cb | but i might be wrong | 13:12 |
ogra-cb | also how would you publish the resulting binary ? the archive doesnt have any armel support anymore | 13:14 |
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:18 |
* 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:19 |
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:21 |
hrw | and this blocks whole arm{el,hf} cross compiler stuff | 13:23 |
hrw | aarch64 one is now pbuilding | 13:24 |
ppisati | has anyone ever experienced fs corption on the haswell box? | 14:01 |
ppisati | *corruption | 14:01 |
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:50 |
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:51 |
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:53 |
cking | i blame every problem now on entropy | 14:54 |
ppisati | :) | 14:54 |
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:14 |
rtg | I've seen this error before but can't remember what it was. | 15:15 |
apw | Compiling 49 OIDs | 15:16 |
apw | presumably that was meant to make the .c | 15:16 |
rtg | oid_registry.c is just a regular file | 15:17 |
rtg | oid_registry_data.c is the one that is generated | 15:17 |
apw | erp, then no that cannot happen :) | 15:18 |
rtg | maybe I'll just rerun the build | 15:18 |
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:20 |
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:21 |
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:22 |
rtg | apw, don't think so. its -j1 | 15:23 |
rtg | apw, oh well, maybe I'll start grinding through all of the firmware issues | 15:24 |
* 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:25 |
* ogasawara back in 20 | 15:58 | |
Theodoros | Is the plan to ship 3.5 by default in 12.04.2? | 16:10 |
rtg | Theodoros, yes. The Raring kernel will get shipped in 12.04.3 | 16:12 |
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:13 |
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:14 |
Theodoros | Thanks for the prompt answer btw :D | 16:15 |
* bjf is going to go soak his head | 16:16 | |
=== rsalveti_ is now known as rsalveti | ||
* ppisati -> EOW | 17:45 | |
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:47 |
ogra_ | so i heard there will be config 2normalization" for the nexus7 kernel | 17:53 |
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:54 |
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 | 17:55 |
* rtg -> lunch | 18:18 | |
* apw wanders off for beer ... | 18:19 | |
infinity | apw: emergency lowlatency is in proposed, so the new rebase can head to the PPA whenever you're appropriately drunk. | 18:58 |
=== bryceh_ is now known as bryce | ||
* rtg -> EOW | 19:47 | |
=== yofel_ is now known as yofel | ||
patr|ck | is there a newer kernel package for testing a graphics driver issue, than the one that ships with Ubuntu 12.10? | 22:29 |
infinity | patr|ck: There's the one in 13.04, of course. | 22:43 |
patr|ck | infinity, can that package be installed on 12.10 or would that require other packages to be updated, too? | 22:45 |
infinity | patr|ck: Should install fine on 12.10, I don't think any deps got bumped. | 22:53 |
patr|ck | nice, thank you | 22:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!