[09:00] <ppisati> morning
[09:31] <cking> yawn
[09:41]  * apw yawns
[09:42] <lilstevie> cmorning
[09:42] <lilstevie> -c
[10:03] <Q-FUNK> 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] <apw> Q-FUNK, what is the exact text of the message
[10:04] <apw> as memory forking really doesn't make any sense
[10:07] <Q-FUNK> fork epäonnistui: Muistin varaaminen ei onnistu
[10:08] <Q-FUNK> (fork failed: memory allocation failed)
[10:08] <Q-FUNK> that's from CLI
[10:08] <Q-FUNK> I see a similar message from gnome-shell whenever starting GUI apps from it, too.
[10:09] <apw> 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] <apw> was there anything notable at the bottom of the dmesg at the same time
[10:10] <Q-FUNK> nothing malloc related.
[10:12] <Q-FUNK> in fact, the newest dmesg entry is from about 30 minutes ago and not memory related at all.
[10:12] <apw> 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] <apw> is this 32 or 64 bit
[10:13] <apw> it isn't a general issue for everyone as none of my oneiric installs are seeing it
[10:13] <Q-FUNK> 32-bit.  686 centrino
[10:13] <Q-FUNK> 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] <apw> swap is empty once you reboot, it isn't persistant
[10:14] <apw> (deemed empty)
[10:14] <apw> but you might check it is actually activated
[10:14] <Q-FUNK> that says nothing about the sanity of the blocks within the swap partition.
[10:14] <apw> define sanity, the kernel should never assume the contents of any of them after reboot
[10:14] <Q-FUNK> Swap:          494        494          0
[10:15] <Q-FUNK> well, does the kernel at least perform a badblock check on it at reboot?
[10:15] <apw> nope, no bad block scans.  modern drives are assumed to remap blocks
[10:16] <apw> you should however get errors in dmesg for disk realted failure
[10:17] <Q-FUNK> ok
[10:17] <apw> is the failure persistant or transient
[10:18] <Q-FUNK> 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] <apw> and you don't have to do anything for the next attempt to be successful ?
[10:18] <Q-FUNK> which attempt?
[10:19] <Q-FUNK> at doing what?
[10:19] <apw> you do "something" and it fails, you do "something" again and it works?
[10:19] <lilstevie> running what ever throws the error message
[10:19] <apw> or you do "something" and it fails, you take a machette to various programs, and you do "something" and it works
[10:20] <Q-FUNK> it doesn't work again until I have Quit Firefox, let it close itself down and reached 0% of resource consumptions.
[10:20] <Q-FUNK> then, other applications are able to malloc again.
[10:21] <apw> so it could genuinly be an issue with firefox then
[10:21] <apw> could we sub in say chromium for a few days to see if that is immune
[10:22] <Q-FUNK> 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] <apw> why would the kernel not let you fill up all your resources with things you are running
[10:22] <apw> if you overcommit all of ram and all of swap on your system, it cannot do anything to help you
[10:23] <apw> how much swap do you even have
[10:23] <Q-FUNK> it can TERM the offending app.
[10:23] <apw> in a serious memory crunch it would, but it takes the simpler
[10:23] <apw> and safer course and prevents you asking for more in your fork
[10:24] <apw> at least that way you get to chose which apps are surplus and kill those cleanly
[10:24] <apw> instead of them going pop and you getting annoyed cause it loses something
[10:24] <Q-FUNK> 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] <apw> 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] <Q-FUNK> 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] <lilstevie> but in your case it really isn't requesting an insane amount of ram, it is taking it over time :)
[10:25] <apw> and they would not be able to cope with apps dieing at random when they got big either
[10:25] <lilstevie> apw: my thoughts exactly
[10:26] <apw> that your machine wasn't too small on natty and is on oneiric it says there is a bug somewhere
[10:26] <apw> that exiting firefox helps means its less likely to be a kernel memory leak
[10:26] <apw> as those tend to just persist across exiting the app
[10:26] <apw> so i'd start by blaming firefox, and try and prove that is to blame
[10:27] <apw> subbing in an equivalent app temporarily should tell us something i'd hope
[10:27] <Q-FUNK> it probably is.  firefox has never been a well-behaved app.
[10:27] <apw> they would be very interested to know if they are broken though
[10:27] <apw> they are pretty popular
[10:28] <lilstevie> judging from what you said about it being after running too many broken javascripts, it is most likely in the javascript parser
[10:30] <apw> yeah, or indeed if the apparent brokenness of those is a side effect
[10:31] <lilstevie> yeah
[10:33] <Q-FUNK> 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] <Q-FUNK> it apparently doesn't know about freeing the memory after stopping those runaway scripts.
[10:34] <lilstevie> so that could be part of the effect not the cause
[10:35] <apw> Q-FUNK, are these alerts new or more frequent since the upgrade
[10:43] <Q-FUNK> apw: they started happening since oneiric.
[10:44] <apw> so lets start with a bug against firefox
[10:44] <Q-FUNK> 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] <Q-FUNK> i wonder if we could make apparmor TERM firefox gently when it exceeds a certain amount of memory usage, though.
[10:47] <lifeless> Q-FUNK: that would rather stop it being usable
[10:47] <lifeless> Q-FUNK: its not exactly svelt
[10:47] <apw> i personally would rather find new thing stopped, than existing things just dissappeared when i wasn't looking
[10:47] <apw> the user experience is very poor if firefox just goes pop
[10:47] <Q-FUNK> it becomes unusuable after it exceeds a certain amount of memory usage anyhow. it becomes as slow as molasses.
[10:48] <apw> yes and you can click remember this specific page and the like, read whats there, make a decision to close it
[10:48] <lifeless> Q-FUNK: mine is up at 3G, still responsive
[10:48] <apw> either way its sick and needs a bug
[10:48] <Q-FUNK> right, except that stoping new apps doesn't tell anything useful to the user as to why new apps cannot be launched.
[10:48] <apw> 3G for firefox, wtf
[10:48] <apw> and it dissappearing is better.  neither is good
[10:49] <lifeless> apw: yes, which is lean compared to chromium :)(
[10:49] <apw> and it is clearly broken papering over it isn't appropriate
[10:49] <Q-FUNK> I cannot use chromium. its resource consumption has become even worse than FF3 used to be.
[10:50] <apw> well then even more of a reason to file a bug on it
[10:51] <Q-FUNK> 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] <Q-FUNK> I've already suggested changing that model to upstream.  never got any response.
[10:53] <lilstevie> browsers have been pretty bad lately
[10:54] <apw> feature creap
[10:54] <Q-FUNK> 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] <Q-FUNK> I suggested that it should promptly kill misbehaved content and then notify the user that this happened, offering to reload.
[10:55] <lilstevie> my uptime is pretty low at the moment cause I just rebooted, and chrome is already using 490MB ram on 8 tabs
[11:03] <Q-FUNK> 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] <Q-FUNK> 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] <Q-FUNK> 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] <lilstevie> heh I don't do that stuff
[11:15] <lilstevie> I have 2 self updating pages
[11:16] <lilstevie> uni email, and my domains webmail, powered by gmail
[11:23] <ppisati> 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] <ppisati> herton: but does it apply even if 1206-11 is already in -proposed?
[11:24] <herton> ppisati: yes, we will just build the new package to replace the old one in -proposed
[11:24] <ppisati> ok
[13:35] <njin> Hallo, what do you blame linux or xorg ? bug 881830 thanks
[13:35] <ubot2> Launchpad bug 881830 in linux "Track pad does not respond properly" [Undecided,Confirmed] https://launchpad.net/bugs/881830
[13:46] <apw> njin, hard to say, likely as its an apple product its something stupidly complex and undocumented
[13:46] <apw> you may be able to tell using input-events on the appropriate input channel
[13:46] <apw> if you see the 'wrong' clicks etc there then its kernel side
[13:46] <apw> but being an apple touchpad, we may well not be able to do anything
[13:48] <apw> njin, also do we know why they are running a random upstream kernel?
[13:51] <njin> apw, thanks is an ubuntu member using the macbook
[15:02]  * ogasawara back in 20
[17:12] <herton> ppisati: still around?
[17:22] <ppisati> herton: yep
[17:23] <herton> ppisati: I was looking at the ti-omap4 (oneiric), does it need an abi bump on the new rebase?
[17:24] <herton> ppisati: on the latest rebase you did, from 1206.11 to 1207.12
[17:27] <herton> 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] <apw> -       $(kmake) O=$(hdrdir) -j1 silentoldconfig prepare scripts
[17:30] <apw> +       $(kmake) HOSTCC=$(CROSS_COMPILE)gcc KBUILD_SCRIPTROOT=$(kbsr) O=$(hdrdir) -j1 silentoldconfig prepare scripts
[17:37] <ppisati> herton: but it goes from Ubuntu-3.0.0-13.20 to -22 in my case
[17:37] <ppisati> herton: the rebase i mean
[17:44] <herton> 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] <herton> ppisati: do you get a abi mismatch or some like that while building after the rebase?
[17:48] <herton> (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] <ppisati> herton: wait
[17:52] <smoser> smb`, you have any thoughts on a target for having bug 881076 fixed ?
[17:53] <ubot2> 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] <ppisati> herton: should be fixed now
[18:31] <herton> ppisati: thanks, will check and push
[18:58]  * ppisati -> bails out
[19:14] <jsalisbury> bjf, sconklin, herton regression in Lucid, that has a possible commit identified that caused the issue: bug 875300
[19:14] <ubot2> 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] <herton> jsalisbury: ack, we will check that
[19:15] <jsalisbury> herton, thanks
[20:09] <jdstrand> tgardner: hey. your --reap patch to iptables pretty much has to be reworked for iptables 1.4.12
[20:10] <tgardner> jdstrand, um, how so ?
[20:10] <jdstrand> 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] <tgardner> jdstrand, you mean the user space portion? I thought that got accepted upstream.
[20:11] <jdstrand> tgardner: they redid the struct and the arg parsing, etc
[20:11] <jdstrand> tgardner: (yes the userspace bits) no it didn't. we've been carrying this delta for a long time
[20:12] <tgardner> jdstrand, huh. ok, I'll see about getting the patch redone and accepted upstream
[20:12] <jdstrand> tgardner: sounds great. looks like openwrt picked it up (noticed in my google search)
[20:13] <jdstrand> so hopefully upstream will be willing
[20:13] <jdstrand> I'll back it out for now and assign a new bug to you
[20:13] <tgardner> jdstrand, ok, thanks for the note
[20:14] <cnd> tgardner, ogasawara: I tested hid-ntrig in oneiric vs the latest daily mainline
[20:14] <cnd> I motion for reverting all our patches and just going with upstream
[20:14] <ogasawara> cnd: Ooo, nice
[20:14] <tgardner> cnd, in oneiric or precise ?
[20:14] <tgardner> or both
[20:14] <cnd> tgardner, in precise
[20:14] <cnd> I don't want to mess with oneiric
[20:14] <tgardner> cnd, works for me.
[20:14] <cnd> though I'll be requesting a hardware ID addition soon
[20:15] <cnd> however, I don't know how to send patches for this
[20:15] <tgardner> cnd, that is a deeply curious statement
[20:16] <cnd> sorry, I need to be more clear
[20:16] <cnd> I know how to send a patch for the new ID that needs to go into an oneiric SRU
[20:16] <cnd> I don't know how to fix up precise
[20:16] <cnd> the git log in precise for drivers/hid/hid-ntrig.c does not show the upstream commits at all
[20:17] <cnd> I expected to see upstream, then a bunch of upstream reverts until our commits applied cleanly, then our commits
[20:17] <cnd> but I only see upstream up to 7b2a64c96ad53c4299f7e6ddf8c2f99cb48940a9
[20:17] <tgardner> cnd, are you assuming we've been following the merge window? we generally don't until -rc1
[20:17] <cnd> then sauce patches
[20:18] <cnd> tgardner, there's been no change to ntrig during this merge window
[20:18] <tgardner> cnd, huh, you should consult with ogasawara I guess
[20:18]  * tgardner ducks out for a moment
[20:19] <cnd> 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] <ogasawara> cnd: this is what I see --> http://pastebin.ubuntu.com/731333/
[20:22] <ogasawara> cnd: so I assuming you're saying we can drop the first 10?
[20:22] <ogasawara> ie revert the following:
[20:22] <ogasawara> 961ed450b0e8019a615774712b05db18e36bbea7 UBUNTU: SAUCE: HID: ntrig: fix suspend/resume on recent m
[20:22] <ogasawara> 712ad9598cb31639546faa2b57311bc32145a978 UBUNTU: SAUCE: HID: hid-ntrig: add support for 1b96:0006 
[20:22] <ogasawara> b624fabc45a8b9bd42af2f066ce52934d44df028 hid: ntrig: Mask pen switch events
[20:22] <ogasawara> f5180d5875606b3e4fd68be65373326e60c835b6 hid: ntrig: Support single-touch devices
[20:22] <ogasawara> 11238108398464f35574fec4e0360d6cce32a742 UBUNTU: SAUCE: hid: ntrig: New ghost-filtering event logi
[20:22] <ogasawara> b0613584b5f5c2c393ba46fcab5ea073f15cef95 UBUNTU: SAUCE: hid: ntrig: Setup input filtering manually
[20:22] <ogasawara> 25826a386b28c76aa9580b05d5c75f5ade02f781 UBUNTU: SAUCE: hid: ntrig: remove sysfs nodes
[20:22] <ogasawara> 489814f46a3c69da2109a076a81620aeb476b927 UBUNTU: SAUCE: hid: ntrig: zero-initialize ntrig struct
[20:22] <ogasawara> 4fff4d1f822e3dc85942598cbe2727f1bdb271bb UBUNTU: SAUCE: hid: ntrig: Correct logic for quirks
[20:22] <ogasawara> 5dc230ad38578ceb9d88218eb6507bf0b858dab6 UBUNTU: SAUCE: hid: ntrig: Remove unused device ids
[20:23] <cnd> ogasawara, yep
[20:24] <cnd> ogasawara, and then pull in all the latest upstream changes
[20:24] <cnd> oh wait
[20:24] <cnd> I guess they all are in the tree
[20:25] <ogasawara> cnd: right, there's no additional changes upstream we'd need to pull in
[20:25] <cnd> yeah
[20:25] <cnd> so reverting those commits is all that needs to happen
[20:26] <cnd> somewhere in those commits there must be a large amount of changes that are nothing but reversions of previous upstream commits :)
[20:26] <ogasawara> 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] <cnd> ogasawara, sure
[21:43] <jjohansen> apw: you still around
[21:44] <ogasawara> cnd: test kernel -> http://people.canonical.com/~ogasawara/ntrig/
[21:44] <cnd> ogasawara, thanks!
[22:11] <cnd> ogasawara, kernel looks good
[22:11] <cnd> is there anything else you need me to do?
[22:11] <cnd> I can send a pull request for the revert if you like
[22:52] <cosmosis> 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] <holstein> cosmosis: unplug the keyboard
[22:53] <cosmosis> ok will give it a shot
[22:58] <cosmosis> now its getting hung after 5.36 detecting the sr0 device (cd drive)
[22:59] <cosmosis> its not locked its just sitting there sort of..
[22:59] <cosmosis> but its not proceeding with install
[23:00] <holstein> i would probably just start testing the hardware to make sure
[23:00] <holstein> you can try #ubuntu and/or #ubuntu-beginners as well... this is not really a support channel
[23:01] <cosmosis> ok sorry its just I tried the ubuntu-installer channel and they said ask the kernel guys
[23:38] <ogasawara> 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] <cnd> ogasawara, great
[23:47] <cnd> ta