=== harsh is now known as harshpb === jussio1 is now known as jussi [09:00] morning [09:31] yawn [09:41] * apw yawns [09:42] cmorning [09:42] -c [10:03] in Oneiric, I regularly get notices from various CLI and GNOME apps that memory forking failed. I have never seen this until now. What causes this? To answer an obvious question, I indeed have a (large enough) swap partition. [10:04] Q-FUNK, what is the exact text of the message [10:04] as memory forking really doesn't make any sense [10:07] fork epäonnistui: Muistin varaaminen ei onnistu [10:08] (fork failed: memory allocation failed) [10:08] that's from CLI [10:08] I see a similar message from gnome-shell whenever starting GUI apps from it, too. [10:09] ok so some memory pool or other was depleted at the time of the fork. this may not be a general pool of course [10:09] was there anything notable at the bottom of the dmesg at the same time [10:10] nothing malloc related. [10:12] in fact, the newest dmesg entry is from about 30 minutes ago and not memory related at all. [10:12] a tricky one then, as ENOMEM has any number of actual meanings not all even related to memory (such are the vaguaries of error codes) [10:12] is this 32 or 64 bit [10:13] it isn't a general issue for everyone as none of my oneiric installs are seeing it [10:13] 32-bit. 686 centrino [10:13] it could be that my swap partition has gone awry but since nobody ever got around inveting any fsck.swap, I wouldn't know. [10:14] swap is empty once you reboot, it isn't persistant [10:14] (deemed empty) [10:14] but you might check it is actually activated [10:14] that says nothing about the sanity of the blocks within the swap partition. [10:14] define sanity, the kernel should never assume the contents of any of them after reboot [10:14] Swap: 494 494 0 [10:15] well, does the kernel at least perform a badblock check on it at reboot? [10:15] nope, no bad block scans. modern drives are assumed to remap blocks [10:16] you should however get errors in dmesg for disk realted failure [10:17] ok [10:17] is the failure persistant or transient [10:18] random. mostly seems to happen whenever firefox has run into too many broke javascripts and started utilizing more than 60% of available memory. [10:18] and you don't have to do anything for the next attempt to be successful ? [10:18] which attempt? [10:19] at doing what? [10:19] you do "something" and it fails, you do "something" again and it works? [10:19] running what ever throws the error message [10:19] or you do "something" and it fails, you take a machette to various programs, and you do "something" and it works [10:20] it doesn't work again until I have Quit Firefox, let it close itself down and reached 0% of resource consumptions. [10:20] then, other applications are able to malloc again. [10:21] so it could genuinly be an issue with firefox then [10:21] could we sub in say chromium for a few days to see if that is immune [10:22] possibly. then again, I wonder why the kernel would let firefox consume all the resources to the point of also filling the swap. [10:22] why would the kernel not let you fill up all your resources with things you are running [10:22] if you overcommit all of ram and all of swap on your system, it cannot do anything to help you [10:23] how much swap do you even have [10:23] it can TERM the offending app. [10:23] in a serious memory crunch it would, but it takes the simpler [10:23] and safer course and prevents you asking for more in your fork [10:24] at least that way you get to chose which apps are surplus and kill those cleanly [10:24] instead of them going pop and you getting annoyed cause it loses something [10:24] grsec was very good at this. if an app requests an insane amount of RAM, it would sigterm it. if that didn't do the trick, it would sigkill it. [10:25] that this is new, that it "only" happens with firefox, and exiting firefox restores the world tends to lean to a problem with firefox leaking memory [10:25] well, the thing is that a normal user wouldn't know what those messages mean or how to debug it. here, I happen to know about 'ps' and 'top' enough to notice, but even then. [10:25] but in your case it really isn't requesting an insane amount of ram, it is taking it over time :) [10:25] and they would not be able to cope with apps dieing at random when they got big either [10:25] apw: my thoughts exactly [10:26] that your machine wasn't too small on natty and is on oneiric it says there is a bug somewhere [10:26] that exiting firefox helps means its less likely to be a kernel memory leak [10:26] as those tend to just persist across exiting the app [10:26] so i'd start by blaming firefox, and try and prove that is to blame [10:27] subbing in an equivalent app temporarily should tell us something i'd hope [10:27] it probably is. firefox has never been a well-behaved app. [10:27] they would be very interested to know if they are broken though [10:27] they are pretty popular [10:28] judging from what you said about it being after running too many broken javascripts, it is most likely in the javascript parser [10:30] yeah, or indeed if the apparent brokenness of those is a side effect [10:31] yeah [10:33] well, I simply notice that after firefox has popped too many alerts about runaway scripts, asking me if I want to intereupt them, its memory consuption goes to absurd extremes. [10:34] it apparently doesn't know about freeing the memory after stopping those runaway scripts. [10:34] so that could be part of the effect not the cause [10:35] Q-FUNK, are these alerts new or more frequent since the upgrade [10:43] apw: they started happening since oneiric. [10:44] so lets start with a bug against firefox [10:44] before that, the kernel never had any problem offering more memory to new applications, even though it sometimes resulted in furious drive spins because of heaving swaping. [10:46] i wonder if we could make apparmor TERM firefox gently when it exceeds a certain amount of memory usage, though. [10:47] Q-FUNK: that would rather stop it being usable [10:47] Q-FUNK: its not exactly svelt [10:47] i personally would rather find new thing stopped, than existing things just dissappeared when i wasn't looking [10:47] the user experience is very poor if firefox just goes pop [10:47] it becomes unusuable after it exceeds a certain amount of memory usage anyhow. it becomes as slow as molasses. [10:48] yes and you can click remember this specific page and the like, read whats there, make a decision to close it [10:48] Q-FUNK: mine is up at 3G, still responsive [10:48] either way its sick and needs a bug [10:48] right, except that stoping new apps doesn't tell anything useful to the user as to why new apps cannot be launched. [10:48] 3G for firefox, wtf [10:48] and it dissappearing is better. neither is good [10:49] apw: yes, which is lean compared to chromium :)( [10:49] and it is clearly broken papering over it isn't appropriate [10:49] I cannot use chromium. its resource consumption has become even worse than FF3 used to be. [10:50] well then even more of a reason to file a bug on it [10:51] FF4 and newer eventually became slightly better at resource consumptions, but the handling of broken content is still dumb. it expects users to add items to an ever-growing blacklist, rather than have a sane policy of killing faulty content after a while and asking the user whether we should attempt to re-load. [10:53] I've already suggested changing that model to upstream. never got any response. [10:53] browsers have been pretty bad lately [10:54] feature creap [10:54] instead of waiting for content to go awry and request 100% of availble resource and then try to allocate more resources for a pop-up asking the user whether it should kill the bad content, [10:55] I suggested that it should promptly kill misbehaved content and then notify the user that this happened, offering to reload. [10:55] my uptime is pretty low at the moment cause I just rebooted, and chrome is already using 490MB ram on 8 tabs [11:03] lilstevie: I'm not surprised. here, I keep chromium as a backup, in case firefox really becomes unusable, so that I at least have something to access online banking, but even then, I'm not putting my hopes too high. [11:04] mind you, I wouldn't entirely put the blame on browsers (at least not for recent firefox). rather, the issue is all those sites with real-time content refresh and tons of javascript. [11:06] by the time you have 20 tabs, each trying to refresh the number of Facebook Likes for that page and the number of backtracks on every syndicated blog, in real-time, even the new and improved firefox slows to a crawl in no time. [11:15] heh I don't do that stuff [11:15] I have 2 self updating pages [11:16] uni email, and my domains webmail, powered by gmail [11:23] herton: O/ti-omap4 3.0.0.-1206-11 has been superseded by 3.0.0-1207-12, so according to the new workflow i should mark as "duplicate" the old tracking bug [11:23] herton: but does it apply even if 1206-11 is already in -proposed? [11:24] ppisati: yes, we will just build the new package to replace the old one in -proposed [11:24] ok [13:35] Hallo, what do you blame linux or xorg ? bug 881830 thanks [13:35] Launchpad bug 881830 in linux "Track pad does not respond properly" [Undecided,Confirmed] https://launchpad.net/bugs/881830 [13:46] njin, hard to say, likely as its an apple product its something stupidly complex and undocumented [13:46] you may be able to tell using input-events on the appropriate input channel [13:46] if you see the 'wrong' clicks etc there then its kernel side [13:46] but being an apple touchpad, we may well not be able to do anything [13:48] njin, also do we know why they are running a random upstream kernel? [13:51] apw, thanks is an ubuntu member using the macbook === yofel_ is now known as yofel [15:02] * ogasawara back in 20 [17:12] ppisati: still around? [17:22] herton: yep [17:23] ppisati: I was looking at the ti-omap4 (oneiric), does it need an abi bump on the new rebase? [17:24] ppisati: on the latest rebase you did, from 1206.11 to 1207.12 [17:27] ppisati: as there was only the rebase, and the master oneiric tree didn't bump the abi from 13.21 to 13.22, I was expecting the ti-omap4 to not bump as well [17:30] - $(kmake) O=$(hdrdir) -j1 silentoldconfig prepare scripts [17:30] + $(kmake) HOSTCC=$(CROSS_COMPILE)gcc KBUILD_SCRIPTROOT=$(kbsr) O=$(hdrdir) -j1 silentoldconfig prepare scripts [17:37] herton: but it goes from Ubuntu-3.0.0-13.20 to -22 in my case [17:37] herton: the rebase i mean [17:44] ppisati: well, I see it here only as a rebase between 13.21 to 13.22 (12.20 was the previous from these two): http://pastebin.ubuntu.com/731144/ [17:47] ppisati: do you get a abi mismatch or some like that while building after the rebase? [17:48] (the diff from pastebin is the differences between origin/ti-omap4 and your ppisati ti-omap4 with commits removed so the diff is easier spotted) [17:48] herton: wait [17:52] smb`, you have any thoughts on a target for having bug 881076 fixed ? [17:53] Launchpad bug 881076 in linux "precise kernels do not boot on ec2" [High,Triaged] https://launchpad.net/bugs/881076 [18:26] * tgardner -> lunch [18:30] herton: should be fixed now [18:31] ppisati: thanks, will check and push [18:58] * ppisati -> bails out [19:14] bjf, sconklin, herton regression in Lucid, that has a possible commit identified that caused the issue: bug 875300 [19:14] Launchpad bug 875300 in linux "[Realtek ALC268] ALSA test tone not correctly played back (regression in lucid from 2.6.32-33.72)" [Medium,Triaged] https://launchpad.net/bugs/875300 [19:15] jsalisbury: ack, we will check that [19:15] herton, thanks === ppetraki_ is now known as ppetraki [20:09] tgardner: hey. your --reap patch to iptables pretty much has to be reworked for iptables 1.4.12 [20:10] jdstrand, um, how so ? [20:10] tgardner: upstream made quite a few changes. I'd like to do the merge, but don't want to rewrite your patch. I'm wondering how to proceed-- perhaps I could do the merge and back out the --reap change, and then file a bug for that functional regression and assign it to you? [20:11] jdstrand, you mean the user space portion? I thought that got accepted upstream. [20:11] tgardner: they redid the struct and the arg parsing, etc [20:11] tgardner: (yes the userspace bits) no it didn't. we've been carrying this delta for a long time [20:12] jdstrand, huh. ok, I'll see about getting the patch redone and accepted upstream [20:12] tgardner: sounds great. looks like openwrt picked it up (noticed in my google search) [20:13] so hopefully upstream will be willing [20:13] I'll back it out for now and assign a new bug to you [20:13] jdstrand, ok, thanks for the note [20:14] tgardner, ogasawara: I tested hid-ntrig in oneiric vs the latest daily mainline [20:14] I motion for reverting all our patches and just going with upstream [20:14] cnd: Ooo, nice [20:14] cnd, in oneiric or precise ? [20:14] or both [20:14] tgardner, in precise [20:14] I don't want to mess with oneiric [20:14] cnd, works for me. [20:14] though I'll be requesting a hardware ID addition soon [20:15] however, I don't know how to send patches for this [20:15] cnd, that is a deeply curious statement [20:16] sorry, I need to be more clear [20:16] I know how to send a patch for the new ID that needs to go into an oneiric SRU [20:16] I don't know how to fix up precise [20:16] the git log in precise for drivers/hid/hid-ntrig.c does not show the upstream commits at all [20:17] I expected to see upstream, then a bunch of upstream reverts until our commits applied cleanly, then our commits [20:17] but I only see upstream up to 7b2a64c96ad53c4299f7e6ddf8c2f99cb48940a9 [20:17] cnd, are you assuming we've been following the merge window? we generally don't until -rc1 [20:17] then sauce patches [20:18] tgardner, there's been no change to ntrig during this merge window [20:18] cnd, huh, you should consult with ogasawara I guess [20:18] * tgardner ducks out for a moment [20:19] if I had to take a stab, I would send a pull request which included ~10 sauce patch reversions and then another ~10 upstream patches that we don't have [20:21] cnd: this is what I see --> http://pastebin.ubuntu.com/731333/ [20:22] cnd: so I assuming you're saying we can drop the first 10? === allison_ is now known as wendar [20:22] ie revert the following: [20:22] 961ed450b0e8019a615774712b05db18e36bbea7 UBUNTU: SAUCE: HID: ntrig: fix suspend/resume on recent m [20:22] 712ad9598cb31639546faa2b57311bc32145a978 UBUNTU: SAUCE: HID: hid-ntrig: add support for 1b96:0006 [20:22] b624fabc45a8b9bd42af2f066ce52934d44df028 hid: ntrig: Mask pen switch events [20:22] f5180d5875606b3e4fd68be65373326e60c835b6 hid: ntrig: Support single-touch devices [20:22] 11238108398464f35574fec4e0360d6cce32a742 UBUNTU: SAUCE: hid: ntrig: New ghost-filtering event logi [20:22] b0613584b5f5c2c393ba46fcab5ea073f15cef95 UBUNTU: SAUCE: hid: ntrig: Setup input filtering manually [20:22] 25826a386b28c76aa9580b05d5c75f5ade02f781 UBUNTU: SAUCE: hid: ntrig: remove sysfs nodes [20:22] 489814f46a3c69da2109a076a81620aeb476b927 UBUNTU: SAUCE: hid: ntrig: zero-initialize ntrig struct [20:22] 4fff4d1f822e3dc85942598cbe2727f1bdb271bb UBUNTU: SAUCE: hid: ntrig: Correct logic for quirks [20:22] 5dc230ad38578ceb9d88218eb6507bf0b858dab6 UBUNTU: SAUCE: hid: ntrig: Remove unused device ids [20:23] ogasawara, yep [20:24] ogasawara, and then pull in all the latest upstream changes [20:24] oh wait [20:24] I guess they all are in the tree [20:25] cnd: right, there's no additional changes upstream we'd need to pull in [20:25] yeah [20:25] so reverting those commits is all that needs to happen [20:26] somewhere in those commits there must be a large amount of changes that are nothing but reversions of previous upstream commits :) [20:26] cnd: cool. how about I build you a quick test kernel with the 10 commits reverted just confirm before I actually drop them. [20:26] ogasawara, sure [21:43] apw: you still around [21:44] cnd: test kernel -> http://people.canonical.com/~ogasawara/ntrig/ [21:44] ogasawara, thanks! [22:11] ogasawara, kernel looks good [22:11] is there anything else you need me to do? [22:11] I can send a pull request for the revert if you like [22:52] I am installing ubuntu 11.10 on a brand new system. 8 core AMD FX-8150 CPU with a ASUS M5A97 -- AMD 970 motherboard and 16 gig of ram. When I go to install I get as far as 864 and detecting the usb keyboard and then it just hangs. Any ideas? [22:53] cosmosis: unplug the keyboard [22:53] ok will give it a shot [22:58] now its getting hung after 5.36 detecting the sr0 device (cd drive) [22:59] its not locked its just sitting there sort of.. [22:59] but its not proceeding with install [23:00] i would probably just start testing the hardware to make sure [23:00] you can try #ubuntu and/or #ubuntu-beginners as well... this is not really a support channel [23:01] ok sorry its just I tried the ubuntu-installer channel and they said ask the kernel guys [23:38] cnd: no need to do anything else. I'll just add a note to the commits that they were dropped per our delta review. [23:47] ogasawara, great [23:47] ta