* virtuald wonders what systems hotplug cpus | 00:02 | |
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:17 |
apw | but i think the hotplug also includes turning off cores to save .... what raof said | 00:18 |
virtuald | :> | 00:18 |
elmo | and people who want to be able to replace broken CPUs on the fly | 00:19 |
apw | elmo, that one was a given :) | 00:20 |
virtuald | don't we all want that :) | 00:22 |
=== bjf is now known as bjf[afk] | ||
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:30 |
pscoe2 | hi | 08:54 |
pscoe2 | I am facing some problems with my ubuntu server | 08:54 |
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:55 |
pscoe2 | anyone has any idea about futex_wait_queue_me? | 08:58 |
=== _LibertyZero is now known as LibertyZero | ||
apw | pscoe2, futexes are interprocess locks in userspace | 09:00 |
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:01 |
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:05 |
apw | i would suggest filing a bug against apache, and get the stack trace in there so people can see it | 09:06 |
pscoe2 | http://pastebin.com/T1qmS9Xv is the stack trace | 09:07 |
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:08 |
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:10 |
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:11 |
apw | pscoe2, do you have a pointer to this information | 09:12 |
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:13 |
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:20 |
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:21 |
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:22 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
pscoe2 | everything hangs anyways | 09:29 |
pscoe2 | i will file the bug.. | 09:29 |
pscoe2 | Thanks | 09:29 |
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: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? | 09:31 |
apw | diwic, yes ... we have issues booting it on arm | 09:31 |
diwic | apw, ok | 09:31 |
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 | 09:56 |
ohsix | hrm @ typo's and extra s's, must be tired | 10:09 |
=== yofel_ is now known as yofel | ||
apw_ | cking: did he win yet ? | 12:56 |
kaushal | hi | 12:56 |
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:57 |
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:58 |
* 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 | 12:59 |
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:00 |
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:01 |
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:02 |
kaushal | so old history is lost ? | 13:03 |
kaushal | I dont see anything in syslog,dmesg | 13:03 |
kaushal | apw_: please suggest | 13:03 |
apw_ | kaushal: nope i don't know of any persistant information of that nature which is kept, it would be simply too big | 13:04 |
kaushal | apw_: Thanks | 13:09 |
kaushal | apw_: any example to use blktrace | 13:09 |
kaushal | I mean some form of monitoring it | 13:09 |
apw_ | kaushal: there muct be some examples in the man, but not something i've used extensivly | 13:10 |
cking | apw, no idea | 13:19 |
apw | cking, he did in the end | 13:19 |
cking | rats, I missed that - got distracted | 13:19 |
=== diwic is now known as diwic_afk | ||
=== sconklin-gone is now known as sconklin | ||
=== bjf[afk] is now known as bjf | ||
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:40 |
JFo | k, thanks | 15:41 |
sconklin | JFo: anything with "kernel-tracking-bug" should not be spammed | 15:42 |
JFo | ok | 15:42 |
bjf | JFo, also anything tagged "kernel-release-tracker" | 15:44 |
JFo | k | 15:44 |
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:45 |
apw | JFo, is this the 'test upstream version' script ? | 15:56 |
apw | JFo, and did you get any joy from the launchpad dude ? | 15:56 |
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:16 |
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:18 |
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:19 |
apw | cking, you are not meant to be able to see it by now | 16:21 |
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:27 |
sforshee | cnd, you know much about the ntrig synthesizers? | 16:28 |
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:41 |
smoser | maybe run some benchamrks, leave it up for a while. | 16:42 |
smoser | try to recreate on your newer instance.. | 16:42 |
smb | smoser, I got one running at the moment. Though without anything running. I'll get same "noise" started and see where it leads | 16:43 |
=== sconklin is now known as sconklin-lunch | ||
* apw wa | 17:21 | |
* apw wanders off to see a panto | 17:21 | |
* tgardner wonders what is a panto ? | 17:23 | |
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:24 |
JFo | <- lunch | 17:36 |
=== sforshee is now known as sforshee-lunch | ||
=== sconklin-lunch is now known as sconklin | ||
* tgardner --> lunch | 19:08 | |
=== sforshee-lunch is now known as sforshee | ||
* jjohansen -> lunch | 20:19 | |
JFo | enjoy | 20:19 |
JFo | :) | 20:19 |
sforshee | JFo, question about bug statuses when they affect upstream linux | 20:24 |
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:25 |
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:26 |
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 | :) | 20:27 |
=== Quintasan_ is now known as Quintasan | ||
* vanhoof waves bye | 23:12 | |
=== vanhoof is now known as vanhoof[weekend] |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!