Re: [LTP] Patch to record kernel dump message to each testcases log

Subrata Modak
2010-10-13T07:05:36Z

On Wed, 2010-10-13 at 15:00 +0800, hake huang wrote:
> Hi Subrata,
>
> one question:
> -K will only record all kernel message, but can not match each testcase, right?

It will record kernel messages for each individual test case by
recording it inside ltp*/output/<DMESG_DIR_NAME>/<testname>.dmeg

Once test run is over it will delete all .dmeg* files of zero size and
will retain only those having real entries. So, you will get exactly
which tests generated kernel messages and what the messages exactly are
for each individual test.

Regards--
Subrata

>
> Regards,
>
> Hake
>
> 2010/10/13 Subrata Modak <subrata@linux.vnet.ibm.com>:
> > On Wed, 2010-10-13 at 12:22 +0530, Subrata Modak wrote:
> >> On Wed, 2010-10-13 at 13:30 +0800, hake huang wrote:
> >> > 2010/10/13 Garrett Cooper <yanegomi@gmail.com>
> >> > >
> >> > > On Tue, Oct 12, 2010 at 9:38 PM, hake huang <hakehuang@gmail.com> wrote:
> >> > > > Hi
> >> > > >
> >> > > > I see this simple solution is no quite fit. But the kernel dump message for
> >> > > > each test case is necessary for analysing. I can work on this further, with
> >> > > > below help:
> >> > > > 1. Where can I find the reason for the IIRC break?
> >> > >
> >> > > IIRC -> If I remember correctly.
> >> > so I need ask Subrata about this problem, right? what is the existing
> >> > functionality?
> >>
> >> I believe the functionality your original patch was proposing is already
> >> in LTP . I guess they will solve your problem. See the following
> >> commits:
> >>
> >> git show e3bc3758d3e4d17a0e04009ef873df53819b9ec6
> >> git show bd9d440be1da8020c93ac92e497e3a16e66e9fa3
> >>
> >> Just use:
> >>
> >> ./runltp -K <DMESG_DIRECTORY_NAME>
> >
> > Basically, its a choice given to users who would like to record the
> > kernel messages, and not forcing recording all kernel messages which
> > your original patch is proposing :-)
> >
> > Regards--
> > Subrata
> >
> >>
> >> option while running ltp.
> >>
> >> Regards--
> >> Subrata
> >>
> >> > >
> >> > > > 2. Can it be an option to avoid the size limitation on some embedded
> >> > > > system?
> >> > >
> >> > > No. This is outside the realm of LTP, but we must remain conscious of
> >> > > the fact that there are folks running LTP on cellphones, etc, where
> >> > > space is very much a luxury.
> >> > I see. but why can't they run in quit_mode?
> >> > >
> >> > > > 3. A kind of seperating tag is needed for kernel message, right? e.g
> >> > > > <kernel_dump_start>dump message<kernel_dump_end>
> >> > >
> >> > > I think that adding an optional capture feature might be worthwhile,
> >> > > but you'll no doubt quickly find with some processes that the dmesg
> >> > > buffer will fill up quickly.
> >> > I have seen such events, and such cases need to be checked manually.
> >> > >
> >> > > > 4. I see in ltp-pan.c the file descriptors, terminals are changed in child
> >> > > > process. if the system(3) has problem, the worst cases is there are no
> >> > > > kernel messge output in parent process, but the pan can still function well.
> >> > >
> >> > > Can you say that with 100% certainty? One of the potential problems
> >> > > with system is the fact that it allocates a shell and depending on how
> >> > > processes are executed and how file descriptors are cleaned up,
> >> > >
> >> > > Actually, pan makes zero attempts at closing open file descriptors and
> >> > > the like, so the problem is still very much with pan.
> >> > >
> >> > So your concerns is about file descriptors which open in ltp process,
> >> > I think this is an existing problem. I mean maybe pan need to attempt
> >> > to close open file descriptors. system(3) only increases the change of
> >> > occurrence caused by this problem, right?
> >> > > > if not use system(3), can you give your suggestion on this, exec(3) seems to
> >> > > > have the same problem as system(3)?
> >> > >
> >> > > Yes and no. In this case the problems that exist with open file
> >> > > descriptor inheritance, etc are unfortunately no worse from that
> >> > > perspective than your proposed code would do, but there are still
> >> > > other problems that need to be resolved with your proposed change
> >> > > anyhow that are much more pressing.
> >> > >
> >> > > -Garrett
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Beautiful is writing same markup. Internet Explorer 9 supports
> >> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
> >> Spend less time writing and rewriting code and more time creating great
> >> experiences on the web. Be a part of the beta today.
> >> http://p.sf.net/sfu/beautyoftheweb
> >> _______________________________________________
> >> Ltp-list mailing list
> >> Ltp-list@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/ltp-list
> >
> >