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