=== MTeck-ricer is now known as MTecknology [10:30] Hey all [10:47] hi [10:49] I'm the author of the KDE task manager program [10:49] 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] subtask meaning a process thread [10:53] you can't kill it cause its already dead [10:53] 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] apw: heh you replied to the email as well [10:53] either its truly stuck in the kernel or or the accounting is lying [10:53] apw: please read what I'm saying though :-) [10:54] just tell me here which bit you think i am miss understanding [10:54] The problem is that the task has process threads. ls /proc/pid/tasks has two entries [10:54] the pid of the main process and the pid of the sub process [10:55] the main process is a zombie but the other is not [10:55] so top etc see it as a zombie process using cpu [10:55] so they are broken :) [10:55] why? it's saying the correct thing [10:55] the kernel reports the process as a zombie using cpu [10:56] 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] which is correct. /proc/pid/status etc give the status of the main thread [10:56] to represent it as either is wrong [10:56] so, question is, how to kill such a beast? [10:58] ps -T here shows they also have their own SPID, their own thread pid [10:59] i would have expected that to be a killable id also [11:00] and indeed those appear as first class PIDs in /proc/ [11:01] apw: I would have thought that too, but nope :-/ [11:01] ls /proc/5728/task/ [11:01] 5728 5810 [11:01] kill -9 5810 [11:01] but it's still there [11:01] still using 100% cpu [11:09] JohnFlux, an what state is that subtask in [11:11] State: R (running) [11:11] consuming user of system time? [11:12] and what did kill -9 say when you did it? [11:13] apw: it says nothing - it doesn't say invalid pid or anything [11:13] apw: how can I see if it's user or system time? [11:15] * apw looks [11:15] also can you attach strace to it to find out what it is actually doing? [11:16] ah [11:16] apw: it's 100% system time [11:16] does strace tell you which syscall its in? [11:17] and which kernel is this? [11:17] strace doesn't say anything :-/ [11:17] so it may be stuck in the kernel somewhere [11:18] 2.6.33-020633-generic [11:18] it's ubuntu's kernel [11:18] it's ubuntu+1 kernel [11:18] its a mainline kerenel, without any ubuntuness [11:18] i suspect its probabally broken [11:19] you may be able to find out what if anything that thread is doing, as its likely stuck on the CPU [11:19] is there anything in dmesg about CPU lockuips? [11:19] [ 289.396260] ===>rt_ioctl_giwscan. 2(2) BSS returned, data->length = 256 [11:19] I have lots of these [11:19] lots = about 25 [11:19] failing that you may need to use the 'running process stacks' option from sysrq [11:20] to see if you can get a stack off it [11:20] those are debugging from the staging driver for wireless i believe === gnomefreak76 is now known as gnomefreak [14:10] Hello, I get this error when compiling kernel: [14:10] II: Checking modules for generic...previous or current modules file missing! [14:12] AnAnt: add a skipabi=1 before your build command [14:13] amitk: I did that [14:13] or rather skipmodules=1 [14:13] ah [14:14] skipmodules=1 didn't change the situation [14:15] AnAnt: try skipmodule (w/o 's') [14:19] amitk: ah, thanks [14:20] amitk: what's the ABI & modules check for ? [14:22] 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] neat [14:27] so how can I get the previous ABI & .modules files ? are they present somewhere in the installation ? === sconklin-gone is now known as sconklin === gnomefreak76 is now known as gnomefreak [14:31] kamalm: great patch! [14:31] are you familiar with signed-off-by and similar tags? === ink|off|ZNC is now known as inkvizitor68sl [16:29] ** [16:29] ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [16:29] ** [17:06] 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] kamalm: so when we write patches, which I assumed you did in this case, we add the signed-off-by tag [17:08] actually, now that I think of it, that applies to any patches you submit [17:08] it says you've tested it, it looks good, and it appears to be freely licensed for us to use [17:08] the other thing we tend to do is keep notes in a separate email [17:08] it says you believe it is submittable to an OSS project [17:09] or that the person who gave it to you said it was and you haven't changed it [17:09] cnd: my understandint is that author is enough for a patch that was written by the submitter [17:09] so the header you put on the email usually goes in a preceding email [17:09] 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] hmmm, I really do not know [17:09] I was just going by what I thought other people were doing [17:10] is there some docs somewhere about this? [17:10] 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] 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] 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] 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] apw: ok, I stand corrected, and kamalm looks like you should add SOB [17:13] line 286 [17:13] 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] cnd, sconklin, apw: ok, thanks for that -- I'll examine the doc. [17:14] kamalm: so then with the extra notes at the top [17:14] if you are in the patch delivery path, you need to add an SOB [17:14] generally what I do is I edit the patch subject so it says [PATCH 1/1] [17:14] then I use --compose with git-send-email [17:15] and write my notes in the editor that comes up [17:15] and use the same subject but with [PATCH 0/1] [17:15] that way it's easy to separate what is the patch, with the full commit message [17:15] and what's a note to go along with it, like a testcase [17:16] cnd: so wait ... the [PATCH 0/1] message is the "extra information" message, yes? [17:16] yes [17:16] however, in this case, all the info you provided should be in the commit message anyways [17:17] kamalm: a "cover letter" isn't always needed especially when you're sending out a singleton patch [17:17] so I don't think you need a separate 0/1 cover letter here [17:17] cnd, achiang: okay that was my exact next question. :-) [17:18] 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] 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] achiang: re cover letter -- very good, thanks. [17:19] 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] etc. [17:20] kamalm: just read lkml for a while and you'll figure it out. ;) [17:26] cnd, sconklin: So should I now correct those 2 problems (^^) and re-submit the patch, or leave it as is? [17:27] kamalm: correct and resubmit [17:27] sconklin: ok, and do I need to do anything to "rescind" the one I submitted already? [17:28] nah, you can put "resubmit" in the subject of the next one [17:29] sconklin: ok, will do! [17:29] cnd, achiang: thanks for the help! [17:29] np [17:40] kamalm: often when people resubmit they change the subject to be [PATCH v2] instead of just [PATCH] [17:40] cnd: good tip, thanks! (I'm studying the SubmittingPatches doc now). [18:23] kamalm, keep it up [18:24] apw: thanks, will do! === yofel_ is now known as yofel === sconklin is now known as sconklin-gone