Recruiting Help in Smashing Kernel Bugs?

Orm asks: "As we all know, Linux version 3.0 (or 2.6) is about to get a feature freeze, meaning that it is bug hunting time. And as we saw on the kernel-summit, some people are afraid that not enough people are willing to try this new kernel, to help get those bugs smashed. My idea to get more people into this hunting, is to write a good paper on how to do it. Not a standard 'how to locate and fix bugs' but a document targeted towards people using 2.4.x today, who will want to help out. So what things should one need to know when testing a new kernel?"

"First: What is new? When I am running menuconfig/xconfig, is there something new I should look into? Will the old /dev directory be replaced with the new devfs-magic?

Second: What needs testing? I guess this is hand in hand with what is new, but you never know. The non-kernel-dev people may not know everything that has happened since 2.4.x., and there may be particular features that should be focused on more than others.

Finally: How do we do it? How should we test? What are the best ways to localize the bugs? How should we write a bug report? Whom should we send it to?

You do want our help, don't you?

I do hope to see this document at the same time as the feature-freeze. I also hope it will be a well-written piece, so many will feel the 'urge' to test the new kernel and give good feedback."

Comments

Re:2.5.44 doesn't compile for me...

[psavo]

well, then that's your bug-testing. report compilation failure. heck, make oldconfig debians .config, and send all failed things.

Cover the basics first

[Sherloqq]

1. Make sure software compiles! (judging from some replies, even that can't be taken for granted...)
2. Make sure software runs! (ditto)
3. Make sure all the functionality you expect from the kernel is there (i.e. if you compiled a driver for a network card, it better work and be backwards compatible, unless it's not supposed to anymore)
4. Make sure the software is stable (test the bejeezus out of the features -- if your cdrom or a scsi card requires a particular setting to work, or there are three ways for you to reference a device, test all of them (or at least the ones you care about)
5. If you encounter any bugs (related or unrelated), report them in enough detail for them to be reproducible. Keep it to the point and relevant to the topic. Use spell and grammar checkers :)
6. When updates/bugfixes come out, lather, rinse, repeat.

Whats critical for me...

[crazney]

I had 2.5.34 or something compiled and going. But unfortunatly I wasn't savy enough to hack the nvidia interface to compile against it. So I went back to 2.4

Maybe if one of the kernel hackers could spend an hour or so getting the nvidia drivers to compile without unresolved symbols, itd open the door up to alot of power gaming users and developers (eg myself).

Even though the NVidia drivers don't come with source, there is one source file which is what gets compiled against the kernel - I got as far as getting it to compile, but unfortunatly since the device module interface has changed somewhat there were unresolved symbols that I didn't know howto fix (though all the unresolved symbols where imported from the source file - so it is fixable).

craz

benchmarks

[Midnight Warrior]

Two reasons will exist for people to migrate to the new kernel:

• new hardware support
• better performance

I will let others fight over the hardware support. We have seen a lot of memory manager changes, some changes to the IDE code (although a lot was reversed), and, if I'm not mistaken, some zero-copy improvements on the network layer. It's time we found out if there were actual improvements.

Get code that works against, say, 2.4.18 (Mandrake 8.0 and RH7.x if memory serves) and against each of the new kernels. Assuming no major kernel changes go out this time, we just get testers to run the benchmark suite against their current configuration and then against their new configuration until we get the new kernels working positively.

Then the benchmark program(s) dump all relevant data to an XML file and we build a little database whereby people submit their performance statistics. Of course, the XML would need signed to prevent tampering.

Then, all the news junkies can climb over the performance improvements made in the new kernel and we can have issues like which came up in the early 2.4.x series avoided.