/srv/irclogs.ubuntu.com/2010/04/20/#ubuntu-kernel.txt

=== MTeck-ricer is now known as MTecknology
JohnFluxHey all10:30
apwhi10:47
JohnFluxI'm the author of the KDE task manager program10:49
JohnFluxand I can't find any one who would know how to kill a zombie process with a subtask that is using up 100% cpu10:49
JohnFluxsubtask meaning a process thread10:49
apwyou can't kill it cause its already dead10:53
apwas by the time its a Z it shouldn't have any context to run in, its not a combination which should be possible10:53
JohnFluxapw: heh you replied to the email as well10:53
apweither its truly stuck in the kernel or or the accounting is lying10:53
JohnFluxapw: please read what I'm saying though :-)10:53
apwjust tell me here which bit you think i am miss understanding10:54
JohnFluxThe problem is that the task has process threads.  ls /proc/pid/tasks  has two entries10:54
JohnFluxthe pid of the main process and the pid of the sub process10:54
JohnFluxthe main process is a zombie but the other is not10:55
JohnFluxso top etc see it as a zombie process using cpu10:55
apwso they are broken :)10:55
JohnFluxwhy?  it's saying the correct thing10:55
JohnFluxthe kernel reports the process as a zombie using cpu10:55
apwone thread on the process is 'z' one is not so the overall unit of the process is neither R nor Z it is a combination10:56
JohnFluxwhich is correct.  /proc/pid/status  etc give the status of the main thread10:56
apwto represent it as either is wrong10:56
JohnFluxso, question is, how to kill such a beast?10:56
apwps -T here shows they also have their own SPID, their own thread pid10:58
apwi would have expected that to be a killable id also10:59
apwand indeed those appear as first class PIDs in /proc/11:00
JohnFluxapw: I would have thought that too, but nope :-/11:01
JohnFluxls /proc/5728/task/11:01
JohnFlux5728  581011:01
JohnFluxkill -9 581011:01
JohnFluxbut it's still there11:01
JohnFluxstill using 100% cpu11:01
apwJohnFlux, an what state is that subtask in11:09
JohnFluxState:  R (running)11:11
apwconsuming user of system time?11:11
apwand what did kill -9 say when you did it?11:12
JohnFluxapw: it says nothing - it doesn't say invalid pid or anything11:13
JohnFluxapw: how can I see if it's user or system time?11:13
* apw looks11:15
apwalso can you attach strace to it to find out what it is actually doing?11:15
JohnFluxah11:16
JohnFluxapw: it's 100% system time11:16
apwdoes strace tell you which syscall its in?11:16
apwand which kernel is this?11:17
JohnFluxstrace doesn't say anything :-/11:17
apwso it may be stuck in the kernel somewhere11:17
JohnFlux2.6.33-020633-generic11:18
JohnFluxit's ubuntu's kernel11:18
JohnFluxit's ubuntu+1 kernel11:18
apwits a mainline kerenel, without any ubuntuness11:18
apwi suspect its probabally broken11:18
apwyou may be able to find out what if anything that thread is doing, as its likely stuck on the CPU11:19
apwis there anything in dmesg about CPU lockuips?11:19
JohnFlux[  289.396260] ===>rt_ioctl_giwscan. 2(2) BSS returned, data->length = 25611:19
JohnFluxI have lots of these11:19
JohnFluxlots = about 2511:19
apwfailing that you may need to use the 'running process stacks' option from sysrq11:19
apwto see if you can get a stack off it11:20
apwthose are debugging from the staging driver for wireless i believe11:20
=== gnomefreak76 is now known as gnomefreak
AnAntHello, I get this error when compiling kernel:14:10
AnAntII: Checking modules for generic...previous or current modules file missing!14:10
amitkAnAnt: add a skipabi=1 before your build command14:12
AnAntamitk: I did that14:13
amitkor rather skipmodules=114:13
AnAntah14:13
AnAntskipmodules=1 didn't change the situation14:14
amitkAnAnt: try skipmodule (w/o 's')14:15
AnAntamitk: ah, thanks14:19
AnAntamitk: what's the ABI & modules check for ?14:20
amitkAnAnt: 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 changes14:22
AnAntneat14:23
AnAntso 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
cndkamalm: great patch!14:31
cndare 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-meeting16:29
bjf**16:29
kamalmcnd: 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
cndkamalm: so when we write patches, which I assumed you did in this case, we add the signed-off-by tag17:07
cndactually, now that I think of it, that applies to any patches you submit17:08
cndit says you've tested it, it looks good, and it appears to be freely licensed for us to use17:08
cndthe other thing we tend to do is keep notes in a separate email17:08
apwit says you believe it is submittable to an OSS project17:08
apwor that the person who gave it to you said it was and you haven't changed it17:09
sconklincnd: my understandint is that author is enough for a patch that was written by the submitter17:09
cndso the header you put on the email usually goes in a preceding email17:09
kamalmcnd: 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
cndhmmm, I really do not know17:09
cndI was just going by what I thought other people were doing17:09
cndis there some docs somewhere about this?17:10
sconklinI suppose that there's no harm in using author AND SOB, but that may imply an independent ack that doesn't exist17:10
sconklinfor the case where you are applying someone else's patch - it's clear - they are the author, and you should sign off.17:11
apwsconklin, no the sign off is more than a author line, it says its applicable to the project, its yours to do that with17:12
cndsconklin: kamalm: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=72651f788f4e3536149ef5e7ddfbed96a8f14d2f;hb=HEAD17:13
sconklinapw: ok, I stand corrected, and kamalm looks like you should add SOB17:13
cndline 28617:13
apwpretty much the only time you might not, would be to stop someone applying it if you know you don't want it applies17:13
kamalmcnd, sconklin, apw: ok, thanks for that -- I'll examine the doc.17:14
cndkamalm: so then with the extra notes at the top17:14
achiangif you are in the patch delivery path, you need to add an SOB17:14
cndgenerally what I do is I edit the patch subject so it says [PATCH 1/1]17:14
cndthen I use --compose with git-send-email17:14
cndand write my notes in the editor that comes up17:15
cndand use the same subject but with [PATCH 0/1]17:15
cndthat way it's easy to separate what is the patch, with the full commit message17:15
cndand what's a note to go along with it, like a testcase17:15
kamalmcnd: so wait ...  the [PATCH 0/1] message is the "extra information" message, yes?17:16
cndyes17:16
cndhowever, in this case, all the info you provided should be in the commit message anyways17:16
achiangkamalm: a "cover letter" isn't always needed especially when you're sending out a singleton patch17:17
cndso I don't think you need a separate 0/1 cover letter here17:17
kamalmcnd, achiang: okay that was my exact next question.  :-)17:17
achiangkamalm: 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 series17:18
kamalmSo 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
kamalmachiang: re cover letter -- very good, thanks.17:19
achiangkamalm: 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
achiangetc.17:20
achiangkamalm: just read lkml for a while and you'll figure it out. ;)17:20
kamalmcnd, sconklin: So should I now correct those 2 problems (^^) and re-submit the patch, or leave it as is?17:26
sconklinkamalm: correct and resubmit17:27
kamalmsconklin: ok, and do I need to do anything to "rescind" the one I submitted already?17:27
sconklinnah, you can put "resubmit" in the subject of the next one17:28
kamalmsconklin: ok, will do!17:29
kamalmcnd, achiang: thanks for the help!17:29
achiangnp17:29
cndkamalm: often when people resubmit they change the subject to be [PATCH v2] instead of just [PATCH]17:40
kamalmcnd: good tip, thanks!  (I'm studying the SubmittingPatches doc now).17:40
apwkamalm, keep it up18:23
kamalmapw: 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!