Kernel testing tips

Kernel testing tips

[Sitsofe Wheeler]

While doing very simple testing I have come across a few themes that might
be useful to other people who want to do light testing of the linux kernel.
Previously I posted another post talking about checking options (things
that would hopefully tell you if the kernel is misbehaving sooner) here -
http://groups.google.com/group/linux.kernel/browse_frm/thread/d73bbfdc7455cba5/d676733d10ccd21a?#d676733d10ccd21a .
Hopefully these posts are useful even if they don't get responses...

Learning to use git
I found http://linux.yyz.us/git-howto.html a reasonable guide to starting to
use git. I wound up having to use man git-bisect a lot to learn how to do
bisection.

Using linux-next via git
There are instructions on
http://linux.f-seidel.de/linux-next/pmwiki/pmwiki.php?n=Linux-next.FAQ
(which unfortunately does not turn up in a google search for linux-next). I
found that to fetch the latest version after doing a git remote update I
have to do git checkout linux-next/master though.

Compile everything you need into the kernel and not into modules
If you are doing builds for a single machine it is often easier to build
everything into the kernel rather than using modules. You can even skip
creating an initrd assuming your setup is simple and you are referring to
devices by /dev/sda? syntax. This also makes it easier to transfer a
finished kernel to another machine (as all you need is the bzImage file).

Compiling on multi-CPU machines
Make sure that if your machine has more than one CPU/core you use the -j
option on make. On a two core box -j5 (even though there are only two cores
and no hyperthreading) seems to yield the lowest compile time.

Bisection
Bisection can allow the narrowing down of a bad patch (assuming the kernel
worked in the past and is broken now). The learning curve is very shallow
(it can be used in a brute force fashion with little understanding) but the
tradeoff is time. The number of commits that happen to linux-next in a day
seems to always be more than 1000 which which means at least 10 recompiles
if yesterday's next worked and today's is broken. Instructions on bisection
can be found on 

On my home desktop (an Athlon 850) it takes at least 35 minutes to do a
complete kernel build. Until you are down to the last few compiles you will
mostly be doing complete builds. In contrast the work laptop I am borrowing
(an Intel Core 2 Duo 1.8Ghz) can finish the same clean build in around 5
minutes.

Let's say you are trying to bisect a persistant hang on boot from 1000
patches (arguably the easiest sort of thing to find because it happens
quickly and is very noticeable) on the laptop. If the laptop boots to a
working logged in desktop in 1 minute 30 seconds and shutting down takes
around 1 minute it will take at least 1 hour and 15 minutes to find the
patch.

Send reports to the right people
Experience says that posting a report to only the LKML will not solicit much
of a response. You pretty much have to CC the right people to stand any
chance of getting a reply. If the problem is in a driver you can try the
driver author as mentioned in the MAINTAINERS file. You can also try
subsystem lists. If you have done a bisection include a CC to the person
who wrote the patch (addresses are shown in the git log of the patch).

Likelihood of responses
When it comes to getting responses things that messages about problems that
have been bisected are usually followed up. Problems about regressions also
seem to get replies. Posts about things like lock dependency warnings and
reports about missing features don't tend to see replies so it's probably
best not to bother making such posts unless you have made a patch which
resolves the issue. 

-- 
Sitsofe | http://sucs.org/~sits/

--
To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel testing tips

[Mariusz Kozlowski]

Hello,

> While doing very simple testing I have come across a few themes that might
> be useful to other people who want to do light testing of the linux kernel.
> Previously I posted another post talking about checking options (things
> that would hopefully tell you if the kernel is misbehaving sooner) here -
> http://groups.google.com/group/linux.kernel/browse_frm/thread/d73bbfdc7455cba5/d676733d10ccd21a?#d676733d10ccd21a .
> Hopefully these posts are useful even if they don't get responses...

I think your tips are generally useful. I also think you could try to improve
the Linux Kernel Testers Guide that Michal started. You'll find more info
here:

http://lwn.net/Articles/238838/

as you see there is latex source available. You can try to contact Michal
witch your patches to latex souce of lktg. I think this doc is worth
updating and keeping alive - for sure there is area for improvment.
I haven't heard from Michal for some time so just in case he is not
interested in it anymore I can host updated versions if that's needed.

	Mariusz
--
To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel testing tips

[Rafael J. Wysocki]

On Sunday, 1 of June 2008, Mariusz Kozlowski wrote:
> Hello,
> 
> > While doing very simple testing I have come across a few themes that might
> > be useful to other people who want to do light testing of the linux kernel.
> > Previously I posted another post talking about checking options (things
> > that would hopefully tell you if the kernel is misbehaving sooner) here -
> > http://groups.google.com/group/linux.kernel/browse_frm/thread/d73bbfdc7455cba5/d676733d10ccd21a?#d676733d10ccd21a .
> > Hopefully these posts are useful even if they don't get responses...
> 
> I think your tips are generally useful. I also think you could try to improve
> the Linux Kernel Testers Guide that Michal started. You'll find more info
> here:
> 
> http://lwn.net/Articles/238838/
> 
> as you see there is latex source available. You can try to contact Michal
> witch your patches to latex souce of lktg. I think this doc is worth
> updating and keeping alive - for sure there is area for improvment.
> I haven't heard from Michal for some time so just in case he is not
> interested in it anymore I can host updated versions if that's needed.

In fact I have an updated version of the guide, but I didn't have the time to
finish it and I didn't want to publish the unfinished work.  If anyone is
interested in working on it, I can provide her/him with the LaTeX sources
and/or set up a git repo.

I'm going to work on it myself a bit during the next few months.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel testing tips

[Mariusz Kozlowski]

Hi,

> > > While doing very simple testing I have come across a few themes that might
> > > be useful to other people who want to do light testing of the linux kernel.
> > > Previously I posted another post talking about checking options (things
> > > that would hopefully tell you if the kernel is misbehaving sooner) here -
> > > http://groups.google.com/group/linux.kernel/browse_frm/thread/d73bbfdc7455cba5/d676733d10ccd21a?#d676733d10ccd21a .
> > > Hopefully these posts are useful even if they don't get responses...
> > 
> > I think your tips are generally useful. I also think you could try to improve
> > the Linux Kernel Testers Guide that Michal started. You'll find more info
> > here:
> > 
> > http://lwn.net/Articles/238838/
> > 
> > as you see there is latex source available. You can try to contact Michal
> > witch your patches to latex souce of lktg. I think this doc is worth
> > updating and keeping alive - for sure there is area for improvment.
> > I haven't heard from Michal for some time so just in case he is not
> > interested in it anymore I can host updated versions if that's needed.
> 
> In fact I have an updated version of the guide, but I didn't have the time to
> finish it and I didn't want to publish the unfinished work.  If anyone is
> interested in working on it, I can provide her/him with the LaTeX sources
> and/or set up a git repo.

I'd be interested. git repo is fine - maybe more people will join. Unfortunately my
TODO list at my job ends somewhere in the middle of july so I don't have much time
left even on weekends. Althouhg I'm trying :)

> I'm going to work on it myself a bit during the next few months.

BTW. google says Michal email is invalid.

<michal.k.k.piotrowski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: host
    gmail-smtp-in.l.google.com[216.239.59.27] said: 550-5.1.1 This Gmail user
    does not exist.

	Mariusz
--
To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html