Hello again!
Another kernel crash. The console was running at that time, so perhaps
I missed some messages.
The kernel debugger (Ctrl-Alt-d), however, offered the following to me:
#v+
Stopped at 0x17673a: ret
db> trace
0x17673a(0)
Kernel page fault at address 0x30, eip = 0x16ef1c
Kernel page faul
What version of glibc are you compiling by the way? And with what
options?
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
On Wed, Feb 23, 2005 at 02:43:35PM +0100, Alfred M. Szmidt wrote:
>> Could you remind me abit more about that thread?
>
>Shall I send you the messages or does that
>http://lists.gnu.org/archive/html/bug-hurd/2004-10/msg00365.html>
>suffice?
>
> Ah, CS thingy... Try the patch and
When will they be merged upstream -- or why not?
They will get merged when I get of my lazy ass and annoy a couple of
other lazy asses. :-) Actually, the only "important" patch that
Debian has is my NIC patch; the rest is just some clean up to autoconf
if I recall and that doesn't change the b
On Wed, Feb 23, 2005 at 01:01:05PM +0100, Alfred M. Szmidt wrote:
>How can I tell GNU Mach _not_ to reboot the system on this ...
>
> Hack panic() and add a for-ever loop.
Ok, I'll rebuild GNU Mach.
There are a lot of patches in Debian's version of GNU Mach (and the other
packages concerning
How can I tell GNU Mach _not_ to reboot the system on this ...
Hack panic() and add a for-ever loop.
I'm probably getting the same error while trying to build glibc,
too, and can reproduce it -- but I couldn't write down the error
message, because the system immediatelly rebooted.
Co
Hello!
How can I tell GNU Mach _not_ to reboot the system on this ...
On Sun, Oct 31, 2004 at 09:49:25PM +0100, Alfred M. Szmidt wrote:
> While compiling libc I got the following panic (note that I wasn't
> doing any funky things at all, just had libc compiling):
>
> Kernel General protection tr
Yeah, so inst_fetch or its callers are buggy. The segment registers are
never validated. The fault recovery stuff is not there for GP faults,
though I don't think it would be real hard to add. Since the callers are
in fault-handling cases already, it's probably easiest just to validate the
segme
Try this on for size. Hopefully this will result in some user
program crashing rather than a kernel panic when whatever problem
you hit happens.
Why thanks, right when I was hacking gnumach todo exactly this, it decided to panic!!!
:-)
___
B
Try this on for size. Hopefully this will result in some user program
crashing rather than a kernel panic when whatever problem you hit happens.
--- gnumach/i386/i386/trap.c.~1.5.~ 2002-05-27 16:02:30.0 -0700
+++ gnumach/i386/i386/trap.c2004-10-31 13:23:44.246363356 -0800
@@ -503,
> Kernel General protection trap, eip 0x1403b8
> kernel trap, type 13, code = 14
Any time you get a kernel trap, you need to look at the disassembly of the
kernel code around the trap and show it to us. (You also haven't said which
kernel this is.) That plus the register values wi
> Kernel General protection trap, eip 0x1403b8
> kernel trap, type 13, code = 14
Any time you get a kernel trap, you need to look at the disassembly of the
kernel code around the trap and show it to us. (You also haven't said which
kernel this is.) That plus the register values will probably ind
I forgot to mention that the kernel should be avaiable at
www.update.uu.se/~ams/home/gnumach-1. Though, last time I checked
that box was done, but it should be up soon.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/b
13 matches
Mail list logo
