=== MTeck-ricer is now known as MTecknology | ||
JohnFlux | Hey all | 10:30 |
---|---|---|
apw | hi | 10:47 |
JohnFlux | I'm the author of the KDE task manager program | 10:49 |
JohnFlux | and I can't find any one who would know how to kill a zombie process with a subtask that is using up 100% cpu | 10:49 |
JohnFlux | subtask meaning a process thread | 10:49 |
apw | you can't kill it cause its already dead | 10:53 |
apw | as by the time its a Z it shouldn't have any context to run in, its not a combination which should be possible | 10:53 |
JohnFlux | apw: heh you replied to the email as well | 10:53 |
apw | either its truly stuck in the kernel or or the accounting is lying | 10:53 |
JohnFlux | apw: please read what I'm saying though :-) | 10:53 |
apw | just tell me here which bit you think i am miss understanding | 10:54 |
JohnFlux | The problem is that the task has process threads. ls /proc/pid/tasks has two entries | 10:54 |
JohnFlux | the pid of the main process and the pid of the sub process | 10:54 |
JohnFlux | the main process is a zombie but the other is not | 10:55 |
JohnFlux | so top etc see it as a zombie process using cpu | 10:55 |
apw | so they are broken :) | 10:55 |
JohnFlux | why? it's saying the correct thing | 10:55 |
JohnFlux | the kernel reports the process as a zombie using cpu | 10:55 |
apw | one thread on the process is 'z' one is not so the overall unit of the process is neither R nor Z it is a combination | 10:56 |
JohnFlux | which is correct. /proc/pid/status etc give the status of the main thread | 10:56 |
apw | to represent it as either is wrong | 10:56 |
JohnFlux | so, question is, how to kill such a beast? | 10:56 |
apw | ps -T here shows they also have their own SPID, their own thread pid | 10:58 |
apw | i would have expected that to be a killable id also | 10:59 |
apw | and indeed those appear as first class PIDs in /proc/ | 11:00 |
JohnFlux | apw: I would have thought that too, but nope :-/ | 11:01 |
JohnFlux | ls /proc/5728/task/ | 11:01 |
JohnFlux | 5728 5810 | 11:01 |
JohnFlux | kill -9 5810 | 11:01 |
JohnFlux | but it's still there | 11:01 |
JohnFlux | still using 100% cpu | 11:01 |
apw | JohnFlux, an what state is that subtask in | 11:09 |
JohnFlux | State: R (running) | 11:11 |
apw | consuming user of system time? | 11:11 |
apw | and what did kill -9 say when you did it? | 11:12 |
JohnFlux | apw: it says nothing - it doesn't say invalid pid or anything | 11:13 |
JohnFlux | apw: how can I see if it's user or system time? | 11:13 |
* apw looks | 11:15 | |
apw | also can you attach strace to it to find out what it is actually doing? | 11:15 |
JohnFlux | ah | 11:16 |
JohnFlux | apw: it's 100% system time | 11:16 |
apw | does strace tell you which syscall its in? | 11:16 |
apw | and which kernel is this? | 11:17 |
JohnFlux | strace doesn't say anything :-/ | 11:17 |
apw | so it may be stuck in the kernel somewhere | 11:17 |
JohnFlux | 2.6.33-020633-generic | 11:18 |
JohnFlux | it's ubuntu's kernel | 11:18 |
JohnFlux | it's ubuntu+1 kernel | 11:18 |
apw | its a mainline kerenel, without any ubuntuness | 11:18 |
apw | i suspect its probabally broken | 11:18 |
apw | you may be able to find out what if anything that thread is doing, as its likely stuck on the CPU | 11:19 |
apw | is there anything in dmesg about CPU lockuips? | 11:19 |
JohnFlux | [ 289.396260] ===>rt_ioctl_giwscan. 2(2) BSS returned, data->length = 256 | 11:19 |
JohnFlux | I have lots of these | 11:19 |
JohnFlux | lots = about 25 | 11:19 |
apw | failing that you may need to use the 'running process stacks' option from sysrq | 11:19 |
apw | to see if you can get a stack off it | 11:20 |
apw | those are debugging from the staging driver for wireless i believe | 11:20 |
=== gnomefreak76 is now known as gnomefreak | ||
AnAnt | Hello, I get this error when compiling kernel: | 14:10 |
AnAnt | II: Checking modules for generic...previous or current modules file missing! | 14:10 |
amitk | AnAnt: add a skipabi=1 before your build command | 14:12 |
AnAnt | amitk: I did that | 14:13 |
amitk | or rather skipmodules=1 | 14:13 |
AnAnt | ah | 14:13 |
AnAnt | skipmodules=1 didn't change the situation | 14:14 |
amitk | AnAnt: try skipmodule (w/o 's') | 14:15 |
AnAnt | amitk: ah, thanks | 14:19 |
AnAnt | amitk: what's the ABI & modules check for ? | 14:20 |
amitk | AnAnt: ABI is to announce to external modules that the kernel interfaces have changed (so recompile) and module check is so we don't lose some modules during config changes | 14:22 |
AnAnt | neat | 14:23 |
AnAnt | so how can I get the previous ABI & <flavor>.modules files ? are they present somewhere in the installation ? | 14:27 |
=== sconklin-gone is now known as sconklin | ||
=== gnomefreak76 is now known as gnomefreak | ||
cnd | kamalm: great patch! | 14:31 |
cnd | are you familiar with signed-off-by and similar tags? | 14:31 |
=== ink|off|ZNC is now known as inkvizitor68sl | ||
bjf | ** | 16:29 |
bjf | ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting | 16:29 |
bjf | ** | 16:29 |
kamalm | cnd: thanks! I'm aware of Signed-off-by but feel free to share advice and/or wiki pointers -- I'll take all the help I can get. | 17:06 |
cnd | kamalm: so when we write patches, which I assumed you did in this case, we add the signed-off-by tag | 17:07 |
cnd | actually, now that I think of it, that applies to any patches you submit | 17:08 |
cnd | it says you've tested it, it looks good, and it appears to be freely licensed for us to use | 17:08 |
cnd | the other thing we tend to do is keep notes in a separate email | 17:08 |
apw | it says you believe it is submittable to an OSS project | 17:08 |
apw | or that the person who gave it to you said it was and you haven't changed it | 17:09 |
sconklin | cnd: my understandint is that author is enough for a patch that was written by the submitter | 17:09 |
cnd | so the header you put on the email usually goes in a preceding email | 17:09 |
kamalm | cnd: yes, I did write it -- sconklin suggested that I should *omit* any Signed-off-by: tag at this stage -- ah here he is -- fight it out boys! | 17:09 |
cnd | hmmm, I really do not know | 17:09 |
cnd | I was just going by what I thought other people were doing | 17:09 |
cnd | is there some docs somewhere about this? | 17:10 |
sconklin | I suppose that there's no harm in using author AND SOB, but that may imply an independent ack that doesn't exist | 17:10 |
sconklin | for the case where you are applying someone else's patch - it's clear - they are the author, and you should sign off. | 17:11 |
apw | sconklin, no the sign off is more than a author line, it says its applicable to the project, its yours to do that with | 17:12 |
cnd | sconklin: kamalm: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=72651f788f4e3536149ef5e7ddfbed96a8f14d2f;hb=HEAD | 17:13 |
sconklin | apw: ok, I stand corrected, and kamalm looks like you should add SOB | 17:13 |
cnd | line 286 | 17:13 |
apw | pretty much the only time you might not, would be to stop someone applying it if you know you don't want it applies | 17:13 |
kamalm | cnd, sconklin, apw: ok, thanks for that -- I'll examine the doc. | 17:14 |
cnd | kamalm: so then with the extra notes at the top | 17:14 |
achiang | if you are in the patch delivery path, you need to add an SOB | 17:14 |
cnd | generally what I do is I edit the patch subject so it says [PATCH 1/1] | 17:14 |
cnd | then I use --compose with git-send-email | 17:14 |
cnd | and write my notes in the editor that comes up | 17:15 |
cnd | and use the same subject but with [PATCH 0/1] | 17:15 |
cnd | that way it's easy to separate what is the patch, with the full commit message | 17:15 |
cnd | and what's a note to go along with it, like a testcase | 17:15 |
kamalm | cnd: so wait ... the [PATCH 0/1] message is the "extra information" message, yes? | 17:16 |
cnd | yes | 17:16 |
cnd | however, in this case, all the info you provided should be in the commit message anyways | 17:16 |
achiang | kamalm: a "cover letter" isn't always needed especially when you're sending out a singleton patch | 17:17 |
cnd | so I don't think you need a separate 0/1 cover letter here | 17:17 |
kamalm | cnd, achiang: okay that was my exact next question. :-) | 17:17 |
achiang | kamalm: typically i write a cover letter when i'm writing a series of patches ; the cover letter explains the high-level goal of the series ; but each patch within the series has a standalone commit log that makes sense to an outsider even if not in-context of the overall series | 17:18 |
kamalm | So now there are two "known problems" with my patch as submitted: 1. needs my SOB. 2. i should not have included debian.master/changelog in the diff. So should I now correct those issues and re-submit? Or is this one good enough as it stands now? | 17:18 |
kamalm | achiang: re cover letter -- very good, thanks. | 17:19 |
achiang | kamalm: other appropriate info for a cover letter: testing that may have happened, a changelog of the series (typically a complex series needs several revisions, so it's nice to say: v1 -> v2, and list the changes) | 17:19 |
achiang | etc. | 17:20 |
achiang | kamalm: just read lkml for a while and you'll figure it out. ;) | 17:20 |
kamalm | cnd, sconklin: So should I now correct those 2 problems (^^) and re-submit the patch, or leave it as is? | 17:26 |
sconklin | kamalm: correct and resubmit | 17:27 |
kamalm | sconklin: ok, and do I need to do anything to "rescind" the one I submitted already? | 17:27 |
sconklin | nah, you can put "resubmit" in the subject of the next one | 17:28 |
kamalm | sconklin: ok, will do! | 17:29 |
kamalm | cnd, achiang: thanks for the help! | 17:29 |
achiang | np | 17:29 |
cnd | kamalm: often when people resubmit they change the subject to be [PATCH v2] instead of just [PATCH] | 17:40 |
kamalm | cnd: good tip, thanks! (I'm studying the SubmittingPatches doc now). | 17:40 |
apw | kamalm, keep it up | 18:23 |
kamalm | apw: thanks, will do! | 18:24 |
=== yofel_ is now known as yofel | ||
=== sconklin is now known as sconklin-gone |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!