Development/Howto/Test Update Candidate Kernels

From Mandriva

Jump to: navigation, search
How to Test Update Candidate Kernels

This document describes some test procedures for the Update Candidate kernels.

Contents


[edit]

What is an Update Candiate Kernel?

An Update Candidate kernel (AKA, -uc or UC) is a testing release of the next Mandriva 2007's stable kernel update.

[edit]

Basic rules

  1. Please, only try it if you want to help with regression testing. If your environment is supposed to be very stable, the -uc kernel is not for you
  2. Do not open tickets for -uc kernels, you should report any problem directly to
  3. The packages will be available in the mdv2007's testing repository
[edit]

Reporting bugs

First off, if you hit a bug, please make a report as described here: How to report kernel bugs.

[edit]

Just use it

The most basic test procedure for any software is quite simple: just use it.

The kernel is not an exception, just install the RPM package and boot the new kernel.

If something is broken (ie, a bug has been introduced), you may hit it in different ways, the most common symptons are:

  • The new kernel doesn't boot
  • Your system freezes
  • A working hardware (eg, USB key, network card, sound card, etc) stops to work
  • A program you've used with no problem with the previous kernel, now prints a 'segmentation fault' error and exits
[edit]

Checking fixed bugs

You may also help to assure that a fixed bug is really fixed by trying to reproduce it on a non-fixed kernel, and then on the fixed one.

To summarize, you have to:

  1. Read the changelog, and try to find reproducible problems. Bugzilla tickets are good candidates, because you usually can get lots of information from them.
  2. With the bugs you've chosen at hand, try to reproduce them with the non-fixed kernel (AKA, the previous -uc version).
  3. If you get success, try to reproduce it again with the fixed kernel (AKA, the current -uc version).
  4. If you can't reproduce it with the fixed kernel, it's ok. Otherwise report ASAP.

For example, consider the -18uc2mdk changelog:

$ rpm -q --changelog kernel-smp-2.6.12.18.uc2mdk-1-1mdk | less

* Thu Mar 02 2006 Luiz Capitulino <[email protected]> 2.6.12-18.uc2mdk
o Samir Bellabes <[email protected]>
    - Support of the Acer Aspire 5xxx/3xxx series in the acerhk module
    (patch from Olivier Blin <[email protected]>)

  o Luiz Capitulino <[email protected]>
    - Adds the corresponding CVE entry number for ZZ93 patch by renaming
      ZZ93_mlodable_protocols_refcnt_fix.patch to
      ZZ93_CVE-2005-3359_mlodable_protocols_refcnt_fix.patch
    - Rediffed RS02_rsbac-2.6.11-v1.2.4.patch, the current patch has a very
      wierd line which probably got in due to a mistake while making the
      diff (closes #20307)
    - USB storage: remove info sysfs file as it violates the sysfs 1 value per
      file rule (fixes #21245)
    - Fix OOPS in sysfs_hash_and_remove_file()
    - USB: pl2303 driver, makes pl2303HX chip work correctly
    - Security fixes:
      * ZZ95_CVE-2006-0554_xfs_ftruncate_could_expose_stale_data.patch
      * ZZ96_CVE-2006-0555_nfs_local_dos_fix.patch
      * ZZ97_CVE-2006-0741_x86_64_check_bad_elf_entry_addr.patch

The lines with '#NUMBER' are bugzilla references. Let's take a look at:

- USB storage: remove info sysfs file as it violates the sysfs 1 value per
  file rule (fixes #21245)

If you check its ticket ( http://qa.mandriva.com/show_bug.cgi?id=21245 ) you'll see that it's pretty easy to reproduce the problem if you have a USB key. Just plug it and run:

$ udevinfo -a -p /block/sda

(yes, looks like it needs to be accessed through '/dev/sda')

With a non-fixed kernel, you'll get a segmentation fault error and an OOPS in the system logs. With the fixed one, you'll get a nice information listing from sysfs.

[edit]

Hunting regressions

Another cool way of testing is to check if a specific change has introduced a regression.

You'll have to check the changelog as described in the previous section and also check the corresponding patch file.

For example, the following patch was added in 2.6.12-18uc2mdk kernel:

       ZZ95_CVE-2006-0554_xfs_ftruncate_could_expose_stale_data.patch

If you check the patch further, you'll see that it's a XFS' ftruncate() related problem.

A good way to find a regression could be:

  1. Create a XFS partition (or file) and stress it someway
  2. Figure out how the changed function is used and try to use/stress it
  3. Try to write a test program to check whether the new behaivor of the changed function is the expected one

Of course that if you didn't get a OOPs or some strange behaivor (like corrupted files) you'll need to know what you're doing in order to know whether you got a regression or not.

[edit]

Test tools

There is a number of test tools available to test the Linux kernel. This section summarizes some of them.

Autotest

Linux Test Project (AKA, LTP)

dbench

Cerberus

Retrieved from "http://wiki.mandriva.com/Development/Howto/Test_Update_Candidate_Kernels"
Personal tools