[00:02] * virtuald wonders what systems hotplug cpus [00:17] virtuald, bigger ones :) [00:17] no shit :p [00:17] And laptop users who want to actually turn off a core. [00:18] but i think the hotplug also includes turning off cores to save .... what raof said [00:18] :> [00:19] and people who want to be able to replace broken CPUs on the fly [00:20] elmo, that one was a given :) [00:22] don't we all want that :) === bjf is now known as bjf[afk] [08:30] apw, it seems linux has been updated to 2.6.38, but linux-meta is still at 2.6.37. Is this intentional? [08:54] hi [08:54] I am facing some problems with my ubuntu server [08:55] some processes..on closing dont die.. but rather they stay alice with futex_wait_queue_me in their stack [08:55] alive [08:58] anyone has any idea about futex_wait_queue_me? === _LibertyZero is now known as LibertyZero [09:00] pscoe2, futexes are interprocess locks in userspace [09:01] pscoe2, Not immediately. But its even unclear what release you are talking of [09:01] pscoe2, what release you running, what processes are they, etc [09:05] i am running 10.04 [09:05] LTS [09:05] and the process is apache [09:05] i can provide the stack if you need it [09:06] i would suggest filing a bug against apache, and get the stack trace in there so people can see it [09:07] http://pastebin.com/T1qmS9Xv is the stack trace [09:08] pscoe2, that simply looks like a normal interprocess wait ... from the stack trace [09:08] from the info we have i am inclined to say its more likely a userspace problem than a kernel issue [09:08] so i would file a bug on apache, unless you have some specific reason to say its a kernel issue [09:10] pscoe2, is that the whole trace or is there more of that? [09:10] but this process has been in state from 1296205546 seconds [09:10] it is the data in the /proc//stack file [09:11] pscoe2, a futex is userspace locking support, so if the other end of the lock is not exiting either it won't complete [09:11] also i looked up on google about processes hanging on futex_wait_queue_me and found that there is a bug in ubuntu kernel which might lead to this [09:12] pscoe2, do you have a pointer to this information [09:13] http://www.uluga.ubuntuforums.org/showthread.php?t=1517043 [09:13] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/480497 [09:13] Launchpad bug 480497 in linux "Various applications freeze on exit." [Undecided,Confirmed] [09:20] pscoe2, nothing in the kernel bug 480497 actually shows any kernel issue. the processes are stuck on a futex waiting but they can be killed ... which implies futex misshandling [09:20] Launchpad bug 480497 in linux "Various applications freeze on exit." [Undecided,Confirmed] https://launchpad.net/bugs/480497 [09:21] which wouldn't be a kernel issue unless you cannot get rid of the process [09:21] hmm..so if i can successfully do a kill -9 on the process it is not a kernel issue? [09:22] pscoe2, if the process dies when killed then its likely the kernel is doing what is intended yes. there may be a bug but its as likley a futex producer consumer issue in userspace [09:22] hmm.. [09:22] the kernel bug there is just a dog pile of issues with any app which might use pulseaudio ... so i am inclined to think its a bug with that for most of the games people [09:23] pscoe2, without knowing how apache is trying to use its futexs it is hard to know whats happening [09:23] the issue i am facing has nothing to do with games though :) [09:23] ok [09:23] i do have another problem which i am facing on my personal laptop [09:23] so i would normally recommend starting at the consumer of the futex and see if they can tell us what they wanted to happen as against what did happen [09:23] ok [09:24] from time to time a process kslowd used to pop up eating most of my cpu power [09:24] i read a lot about this problem only to find t has something to do with the mouse driver [09:25] i am running ubuntu 10.10 [09:25] yep i have seen that with grphics polling as well [09:25] is it still happening? [09:25] u t [09:25] u [09:25] ya [09:25] i think the ones we knew about have been fixed nw [09:26] then that needs a kernel bug filed [09:26] i upgraded my kernel to the newest version [09:26] now a different process kworker eats up the cpu [09:26] causing the same problem [09:26] pscoe2, that is the same process in essence, just its name has changed [09:27] i am forced to use windows to keep my work going [09:27] heh nice for you [09:27] i dont like windows though [09:27] so anything i can do momentarily to ease the discomfort [09:28] i do a renice on the process and decrease its priority [09:28] that eases it up for a bit but is not a solution [09:28] we need a bug filed on the exact version you are seeing it: filed with ubuntu-bug linux [09:28] i am not sure those processes will respond well to being reniced [09:29] everything hangs anyways [09:29] i will file the bug.. [09:29] Thanks [09:30] pscoe2, there used to be kslowd debugging available, i don't know about kworker [09:30] hmm.. [09:30] i guess i will boot in with the older kernel and try debugging kslowd [09:31] apw, it seems linux has been updated to 2.6.38, but linux-meta is still at 2.6.37. Is this intentional? [09:31] diwic, yes ... we have issues booting it on arm [09:31] apw, ok [09:56] apw: #709128 [09:56] bug #709128 [09:56] Launchpad bug 709128 in linux "suspendand resumes only works once, freezes on second suspend" [Undecided,New] https://launchpad.net/bugs/709128 [10:09] hrm @ typo's and extra s's, must be tired === yofel_ is now known as yofel [12:56] cking: did he win yet ? [12:56] hi [12:57] I get CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO % at the bottom while running iotop [12:57] on 8.04 [12:57] Please suggest/guide [12:57] what does it mean [12:57] kaushal: 8.04 ... someone remind me which that is [12:58] I see this host has high IO [12:58] high IOwait [12:58] apw_, Hardy [12:58] that option was not enabled in older kernels, as it was experimental and thought to cause performance regressions i believe [12:58] is there a way to look for reason why there was high IO ? [12:58] smb: ahh, i doubt we are going to retroactivly enable anything back there for the general population [12:59] * apw_ tried to remeber if blocktrace works on hardy [12:59] * apw_ wished we at least called it 8.hardy.04 :) [12:59] smb: can you remember if blktrace is that old ? [12:59] apw_, Not really wihtout more compelling reason and no I do not know either from the top of my head [13:00] kaushal: worth trying blktrace, that might give you the hints you want [13:00] (if it existed back in hardy days) [13:00] ok [13:00] otherwise you might be forced to build a kernel with that enabled, not sure [13:01] ok [13:01] apw_: what does blktrace do [13:01] is there a way to know why there was high IO ? [13:02] At the moment there is no IO [13:02] blktrace records the IO that is occuring, so you can review it to see where etc it is going, can help determine if it is swap etc [13:02] only of use when the problem is occuring of course [13:03] so old history is lost ? [13:03] I dont see anything in syslog,dmesg [13:03] apw_: please suggest [13:04] kaushal: nope i don't know of any persistant information of that nature which is kept, it would be simply too big [13:09] apw_: Thanks [13:09] apw_: any example to use blktrace [13:09] I mean some form of monitoring it [13:10] kaushal: there muct be some examples in the man, but not something i've used extensivly [13:19] apw, no idea [13:19] cking, he did in the end [13:19] rats, I missed that - got distracted === diwic is now known as diwic_afk === sconklin-gone is now known as sconklin === bjf[afk] is now known as bjf [15:40] sconklin, when you get a moment, I am looking over the arsenal scripts now. What tags do you want me to omit from my processing? I've found the place to add them [15:40] :-) [15:40] JFo: hold on while I collect those tags for you [15:41] k, thanks [15:42] JFo: anything with "kernel-tracking-bug" should not be spammed [15:42] ok [15:44] JFo, also anything tagged "kernel-release-tracker" [15:44] k [15:45] is it ever possible for one of the revert or reapply bugs to be brand new ever? [15:45] wondering if they should be on there [15:56] JFo, is this the 'test upstream version' script ? [15:56] JFo, and did you get any joy from the launchpad dude ? [16:16] still haven't heard from him [16:16] yes, this is the one that asks for upstream testing [16:16] apw ^ [16:18] hmmmm, there is still a cking lurking about :-) [16:18] JFo, we might want to modify waht it suggests for regression-* [16:18] * JFo points apw at cking [16:18] apw, it looks like it is supposed to be ignoring them [16:19] hey, I'm just flushing my buffers for the week [16:19] I am working to find out what it is actually doing [16:19] cking, sure you are ;) [16:19] * apw imagines cking on the crapper [16:19] heh [16:19] that's not a pleasant visual image [16:21] cking, you are not meant to be able to see it by now [16:27] smb, bug 708920, they've only seen it on the older lucid for sure. [16:27] Launchpad bug 708920 in linux-ec2 "Strange 'fork/clone' blocking behavior under high cpu usage on EC2" [Undecided,New] https://launchpad.net/bugs/708920 [16:27] but apparently it has to run a while to see it. [16:28] cnd, you know much about the ntrig synthesizers? [16:41] smoser, Yes, saw that somewhere in either mail or bug report. Still we should get confirmation about the newer image before spending time there and to find out we had been chasing a ghost. [16:41] yeah. i'd agree. [16:41] do you have an instance up ? [16:42] maybe run some benchamrks, leave it up for a while. [16:42] try to recreate on your newer instance.. [16:43] smoser, I got one running at the moment. Though without anything running. I'll get same "noise" started and see where it leads === sconklin is now known as sconklin-lunch [17:21] * apw wa [17:21] * apw wanders off to see a panto [17:23] * tgardner wonders what is a panto ? [17:24] tgardner: a show in a theatre that tends to involve lots of audience interaction and is often aimed primarily at kids [17:24] pantomimes playing [17:24] elmo, that explains why apw is so jazzed :) [17:36] <- lunch === sforshee is now known as sforshee-lunch === sconklin-lunch is now known as sconklin [19:08] * tgardner --> lunch === sforshee-lunch is now known as sforshee [20:19] * jjohansen -> lunch [20:19] enjoy [20:19] :) [20:24] JFo, question about bug statuses when they affect upstream linux [20:25] do we set the status to fix released when the fix is in an rc kernel, or do we wait for the final release? [20:26] we wait until it is in our kernel [20:26] for the "Linux (Ubuntu)" package, yes [20:26] for upstreams we have a bugwatch that automatically does the upstream status change [20:27] maybe I am misunderstanding [20:27] want to chat via mumble? [20:27] maybe a more concrete example would help [20:27] yeah, that sounds good [20:27] :) === Quintasan_ is now known as Quintasan [23:12] * vanhoof waves bye === vanhoof is now known as vanhoof[weekend]