| === harsh is now known as harshpb | ||
| === jussio1 is now known as jussi | ||
| ppisati | morning | 09:00 |
|---|---|---|
| cking | yawn | 09:31 |
| * apw yawns | 09:41 | |
| lilstevie | cmorning | 09:42 |
| lilstevie | -c | 09:42 |
| 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:03 |
| apw | Q-FUNK, what is the exact text of the message | 10:04 |
| apw | as memory forking really doesn't make any sense | 10:04 |
| Q-FUNK | fork epäonnistui: Muistin varaaminen ei onnistu | 10:07 |
| 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:08 |
| 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:09 |
| Q-FUNK | nothing malloc related. | 10:10 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| apw | you should however get errors in dmesg for disk realted failure | 10:16 |
| Q-FUNK | ok | 10:17 |
| apw | is the failure persistant or transient | 10:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| lilstevie | judging from what you said about it being after running too many broken javascripts, it is most likely in the javascript parser | 10:28 |
| apw | yeah, or indeed if the apparent brokenness of those is a side effect | 10:30 |
| lilstevie | yeah | 10:31 |
| 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:33 |
| 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:34 |
| apw | Q-FUNK, are these alerts new or more frequent since the upgrade | 10:35 |
| Q-FUNK | apw: they started happening since oneiric. | 10:43 |
| 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:44 |
| Q-FUNK | i wonder if we could make apparmor TERM firefox gently when it exceeds a certain amount of memory usage, though. | 10:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| apw | well then even more of a reason to file a bug on it | 10:50 |
| 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:51 |
| 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:53 |
| 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:54 |
| 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 | 10:55 |
| 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:03 |
| 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:04 |
| 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:06 |
| lilstevie | heh I don't do that stuff | 11:15 |
| lilstevie | I have 2 self updating pages | 11:15 |
| lilstevie | uni email, and my domains webmail, powered by gmail | 11:16 |
| 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:23 |
| herton | ppisati: yes, we will just build the new package to replace the old one in -proposed | 11:24 |
| ppisati | ok | 11:24 |
| 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:35 |
| 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:46 |
| apw | njin, also do we know why they are running a random upstream kernel? | 13:48 |
| njin | apw, thanks is an ubuntu member using the macbook | 13:51 |
| === yofel_ is now known as yofel | ||
| * ogasawara back in 20 | 15:02 | |
| herton | ppisati: still around? | 17:12 |
| ppisati | herton: yep | 17:22 |
| herton | ppisati: I was looking at the ti-omap4 (oneiric), does it need an abi bump on the new rebase? | 17:23 |
| herton | ppisati: on the latest rebase you did, from 1206.11 to 1207.12 | 17:24 |
| 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:27 |
| 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:30 |
| 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:37 |
| 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:44 |
| herton | ppisati: do you get a abi mismatch or some like that while building after the rebase? | 17:47 |
| 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:48 |
| smoser | smb`, you have any thoughts on a target for having bug 881076 fixed ? | 17:52 |
| ubot2 | Launchpad bug 881076 in linux "precise kernels do not boot on ec2" [High,Triaged] https://launchpad.net/bugs/881076 | 17:53 |
| * tgardner -> lunch | 18:26 | |
| ppisati | herton: should be fixed now | 18:30 |
| herton | ppisati: thanks, will check and push | 18:31 |
| * ppisati -> bails out | 18:58 | |
| 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:14 |
| herton | jsalisbury: ack, we will check that | 19:15 |
| jsalisbury | herton, thanks | 19:15 |
| === ppetraki_ is now known as ppetraki | ||
| jdstrand | tgardner: hey. your --reap patch to iptables pretty much has to be reworked for iptables 1.4.12 | 20:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| cnd | however, I don't know how to send patches for this | 20:15 |
| tgardner | cnd, that is a deeply curious statement | 20:15 |
| 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:16 |
| 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:17 |
| 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:18 | |
| 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:19 |
| ogasawara | cnd: this is what I see --> http://pastebin.ubuntu.com/731333/ | 20:21 |
| ogasawara | cnd: so I assuming you're saying we can drop the first 10? | 20:22 |
| === allison_ is now known as wendar | ||
| 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:22 |
| cnd | ogasawara, yep | 20:23 |
| 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:24 |
| 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:25 |
| 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 | 20:26 |
| jjohansen | apw: you still around | 21:43 |
| ogasawara | cnd: test kernel -> http://people.canonical.com/~ogasawara/ntrig/ | 21:44 |
| cnd | ogasawara, thanks! | 21:44 |
| 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:11 |
| 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:52 |
| holstein | cosmosis: unplug the keyboard | 22:53 |
| cosmosis | ok will give it a shot | 22:53 |
| cosmosis | now its getting hung after 5.36 detecting the sr0 device (cd drive) | 22:58 |
| cosmosis | its not locked its just sitting there sort of.. | 22:59 |
| cosmosis | but its not proceeding with install | 22:59 |
| 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:00 |
| cosmosis | ok sorry its just I tried the ubuntu-installer channel and they said ask the kernel guys | 23:01 |
| 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:38 |
| cnd | ogasawara, great | 23:47 |
| cnd | ta | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!