On Mon, 2003-03-24 09:46:05 -0500, Scott Robert Ladd <coyote@coyotegulch.com>
wrote in message <3E7F1A2D.4050306@coyotegulch.com>:
> For the most part, the 2.5 series has worked very well for me, albeit
> with a few glitches (radeonfb, for example, as reported last week.) I'll
> build the 2.5.65 kernel on my Sparc later today, and see how well it
> works there.
sparc32? If you get it to build or even to boot, please drop me a note
with at least this information I'm *really* interested in:
- Machine type
- CPU(s)
- .config file
- gcc -v
- ld -v
Last time I looked at it, sparc32 wasn't in any good state (esp. SMP) in
2.5.x. This is because Dave S. Miller stopped spending a lot of hacking
time (he has to work for other things now and only merges patches he
gets sent, where he formerly did tons on active development for
sparc32).
I'm in the progress of a (private) attempt to build a Linux Test Centre.
(I've already mentioned that - read my last mail in the thread
aboutremoving .gz files from kernel.org.)
The idea is to have automatic kernel builds (for all available
architectures I've collected test hardware for:) and run tests. This
needs to be achieved with automatic cross-compilation of kernels (you
don't want to let a m68k compile it's own kernel:), installation and
choosing this for booting. I've got some quite nice ideas there
(including electronic power switches, serial console management etc.),
but yet, I'm not assured that I'll get the room I may get near
Halle/Westf (Germany).
What is _most_ important to testing is this:
- *fast* response.
Developers don't like to wait like a month
before they hear they broke something. If there
are (untested) patches timely in between, it may
even get hard to sort the broken part out (cf.
sparc32 at 2.5.x).
So the basics are doing automated _compile_
tests. This includes keeping tables (file name -
responsible person, architecture - responsible
person) for automated notification, as well as a
quite good system to switch certain .config
items off (so if you find some compile error,
you have to automatically (if possible) switch
off the corresponding feature and start again).
- Decoded Oopses.
With the in-kernel kksymoops, this is (most of
the time) quite easy to do if you've got serial
console working.
Possibly implementing kgdb for more
architectures could help also.
If you then get an answer by a developer, you
also need to response on a fast manner. Give any
information to the developers as early as
possible. They don't like asking for every
piece. They like mails containing anything they
need (structured and readable).
If you then receive patches for review, you'd
also be capable of automatically including them,
starting a new compile/install/boot-up, ...
- Runtime test (stability).
Some Kernels first start booting, but freeze
days later. These are the hard ones:( By
possibility, you haven't got any information on
this...
...and all this for as many machines/architectures with as different as
possibly hardware attached.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
This archive was generated by hypermail 2b29 : Mon Mar 31 2003 - 22:00:16 EST