[10:30] <JohnFlux> Hey all
[10:47] <apw> hi
[10:49] <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:53] <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:54] <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:55] <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:56] <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:58] <apw> ps -T here shows they also have their own SPID, their own thread pid
[10:59] <apw> i would have expected that to be a killable id also
[11:00] <apw> and indeed those appear as first class PIDs in /proc/
[11:01] <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:09] <apw> JohnFlux, an what state is that subtask in
[11:11] <JohnFlux> State:  R (running)
[11:11] <apw> consuming user of system time?
[11:12] <apw> and what did kill -9 say when you did it?
[11:13] <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:15]  * apw looks
[11:15] <apw> also can you attach strace to it to find out what it is actually doing?
[11:16] <JohnFlux> ah
[11:16] <JohnFlux> apw: it's 100% system time
[11:16] <apw> does strace tell you which syscall its in?
[11:17] <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:18] <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:19] <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] [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:20] <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
[14:10] <AnAnt> Hello, I get this error when compiling kernel:
[14:10] <AnAnt> II: Checking modules for generic...previous or current modules file missing!
[14:12] <amitk> AnAnt: add a skipabi=1 before your build command
[14:13] <AnAnt> amitk: I did that
[14:13] <amitk> or rather skipmodules=1
[14:13] <AnAnt> ah
[14:14] <AnAnt> skipmodules=1 didn't change the situation
[14:15] <amitk> AnAnt: try skipmodule (w/o 's')
[14:19] <AnAnt> amitk: ah, thanks
[14:20] <AnAnt> amitk: what's the ABI & modules check for ?
[14:22] <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:23] <AnAnt> neat
[14:27] <AnAnt> so how can I get the previous ABI & <flavor>.modules files ? are they present somewhere in the installation ?
[14:31] <cnd> kamalm: great patch!
[14:31] <cnd> are you familiar with signed-off-by and similar tags?
[16:29] <bjf> **
[16:29] <bjf> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[16:29] <bjf> **
[17:06] <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:07] <cnd> kamalm: so when we write patches, which I assumed you did in this case, we add the signed-off-by tag
[17:08] <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:09] <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:10] <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:11] <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:12] <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:13] <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:14] <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:15] <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:16] <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:17] <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:18] <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:19] <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:20] <achiang> etc.
[17:20] <achiang> kamalm: just read lkml for a while and you'll figure it out. ;)
[17:26] <kamalm> cnd, sconklin: So should I now correct those 2 problems (^^) and re-submit the patch, or leave it as is?
[17:27] <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:28] <sconklin> nah, you can put "resubmit" in the subject of the next one
[17:29] <kamalm> sconklin: ok, will do!
[17:29] <kamalm> cnd, achiang: thanks for the help!
[17:29] <achiang> np
[17:40] <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).
[18:23] <apw> kamalm, keep it up
[18:24] <kamalm> apw: thanks, will do!