On Sat, May 05, 2007 at 10:33:22PM +0200, Jan Ploski wrote:
> I repeated the tests with linux-2.6.21-rc7-mm2 (didn't compile right
> away, required a one-liner fix)
What fix?
> and also linux-2.6.21-mm1 (didn't
> compile right away either, as the file required-features.h was missing
> in include/asm-um).
This will be fixed soonish.
> 1) [Note: this has nothing to do with the previously reported problem,
> but might be interesting anyway:] Compiling the UML kernel on SLES10
> with its shipped gcc-4.1.0 (ignoring warnings during the compilation) is
> a bad idea. With such a miscompiled kernel, 80% of my test cases hang at
> random points.
Hmmm, I've got 4.1.1 here with no problems and I haven't noticed
problems with gcc recently, although I haven't kept track of what I
had.
> 2) Using 2.6.21-rc7-mm2 and 2.6.21-mm1 (this time compiled with Debian's
> gcc 4.0.4) yields good results. I cannot reproduce the previously
> reported problem with "INIT: Id 0 respawning too fast", regardless of
> whether UML_REAL_TIME_CLOCK is set or not.
OK, I guess that's good news.
> 3) I noticed that the UML console output, which I redirected to a file
> with > in my wrapper shell script, was being randomly truncated. As a
> remedy, I changed "con0=fd:0,fd:1" to "con0=pts,fd:1" on the command
> line. Now I'm getting the complete console output from each run
> collected, which is good.
One UML per log file, so they're not stepping on each other?
> 4) I am now experiencing random segmentation faults - for example, in 18
> out of 842 UML instances in today's test. The root_fs is Debian stable,
> so I wouldn't blame it. It also does not seem to be flaky hardware, as
> the instances crash on different hardware nodes. In over half of the
> faulty cases, fsck on boot will crash:
This one I need to fix. This is with rc7-mm2 or 2.6.21-mm1? Can you
point me to the filesystem you're booting?
> 5) Something which I observed only once so far: the UML process does not
> terminate, but instead starts consuming 100% CPU time. The captured
> console output ends with "System halted." and does not differ from a
> successful run.
If that happens again, can you attach gdb to it and see where it is?
> 6) When running a UML instance to edit my root_fs (with all other
> instances killed, of course) I get:
>
> F_SETLK failed, file already locked by pid 934
> Failed to lock 'root_fs', err = 11
> Failed to open 'root_fs', errno = 11
> ubda: Can't open "root_fs": errno = 11
>
> with a subsequent Kernel panic. There is never any process with pid 934,
> nor any other UML instance which could be the culprit.
There is some UML process still hanging around - it may not be
obviously UML, but it should be there. If not, then this is a host
kernel bug, but I would put good money on there being a UML process
that you're not noticing.
Jeff
--
Work email - jdike at linux dot intel dot com
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
User-mode-linux-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
