On Tue, Oct 08, 2002 at 01:39:40PM -0400, Brian J. Murrell wrote:
> When I try to use the umlgdb tool, umlgdb seems to start OK and tells
> me to start "linux" with "debug gdb-pid=31968" which I do, and then I
> go back to the gdb and hit return at the "att 1" prompt and then type
> "cont" and hit return. The UML continues to run but dies very shortly
> tracing thread pid = 32006
> Linux version 2.4.19-16mdkcustom-9um (brian@...) (gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk)) #7 Mon Oct 7 14:57:03 EDT 2002
> On node 0 totalpages: 8192
> zone(0): 8192 pages.
> zone(1): 0 pages.
> zone(2): 0 pages.
> Kernel command line: root=/dev/ubd0
> Calibrating delay loop... 610.98 BogoMIPS
> Memory: 30496k available
> Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
> Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
> Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
> Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
> Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
> Checking for host processor cmov support...Yes
> Checking for host processor xmm support...No
> Checking that ptrace can change system call numbers...OK
> Checking that host ptys support output SIGIO...Yes
> Checking that host ptys support SIGIO on close...No, enabling workaround
> POSIX conformance testing by UNIFIX
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> Initializing RT netlink socket
> Kernel panic: Segfault with no mm
This looks like gcc-3.2 uncovered some hiding bug. First, apply latest
patch, ie -12um. Then, if the problem is still there, try to get
backtrace and other things from the debugger. Let's see if it reveals
Segfault with no mm is a standart oops (unable to handle kernel paging
request) from kernel thread (or in this case before init is started).
Note, that i just tested 2.4.19-12um from umlgdb and it came up, loaded
and unloaded my module and shut down ok.
Another note: I tried the signal method too and got a "Segfault in
signals" message in the xterm where debuger should have come up and the
> The second part is that I tried to simply get a gdb by signalling UML
> with USR1. When I do that, the gdb seems to be running fine but any
> time I try to get a stack trace I only ever get frame #0. It does not
> seem to show any of the prior frames.
> Does anyone have _any_ ideas at all why this would be? It seems like it
> is something to do with gcc 3.2, but any further ideas would be welcome.
> I am happy to go bug the gcc guys if I can get some idea of what to bug
> them about.
No idea to this. But I just switched to gcc-3.2, so if I hit it too
(well, I am not using this way to get debuger, since I need the
module-tracking stuff from umlgdb).
Jan 'Bulb' Hudec <bulb@...>