Jeff Bailey <[EMAIL PROTECTED]> writes:
> If we're coping with a kernel panic, can we count on a kernel
> parameter still being in tact?
Yes. Just set a global variable based on the kernel parameter at boot
time, and then only look at the global variable.
__
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Ah, okay. Is there a special reason not to print it? BogoMIPS has a
> tradition of being the worst benchmark in the world, and we can point at it
> and say: "see? The Hurd has just as many BogoMIPS as Linux." ;)
We shouldn't print it because the k
On Wed, May 16, 2001 at 10:28:32PM +, Adam Olsen wrote:
> My thinking was that a hltonpanic=1 kernel argument would be good.
> The advantage over a configure option is that it doesn't require a
> recompile to use.
If we're coping with a kernel panic, can we count on a kernel
parameter still
From: Marcus Brinkmann <[EMAIL PROTECTED]>
Subject: Re: page fault in mach_msg_trap
Date: Thu, 17 May 2001 09:41:12 +0200
> Ah, okay. Is there a special reason not to print it?
I don't remember well, but I think it might be because the function
"printk" is not functio
On Thu, May 17, 2001 at 03:32:49PM +0900, OKUJI Yoshinori wrote:
> From: Marcus Brinkmann <[EMAIL PROTECTED]>
> Subject: Re: page fault in mach_msg_trap
> Date: Wed, 16 May 2001 23:57:41 +0200
>
> > We don't have BogoMIPS calulcation in GNU Mach.
>
> IIRC, I i
From: Marcus Brinkmann <[EMAIL PROTECTED]>
Subject: Re: page fault in mach_msg_trap
Date: Wed, 16 May 2001 23:57:41 +0200
> We don't have BogoMIPS calulcation in GNU Mach.
IIRC, I included the calculation in GNU Mach. It just doesn't output
anything about the result on the
> I like the idea of adding a --halt-on-panic option to the configure.
Just make it a kernel command line argument.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
On Wed, May 16, 2001 at 03:20:32PM -0700, Jeff Bailey wrote:
> On Wed, May 16, 2001 at 05:44:05PM -0400, Igor Khavkine wrote:
>
> > > > The time it pauses is too short to write down all registers. We should
> > > > consider increasing it.
> > >
> > > The time is a rapid spinning loop, IIRC, and
On Wed, May 16, 2001 at 05:44:05PM -0400, Igor Khavkine wrote:
> > > The time it pauses is too short to write down all registers. We should
> > > consider increasing it.
> >
> > The time is a rapid spinning loop, IIRC, and has gotten shorter as
> > processors have gotten faster; it should be ti
On Wed, May 16, 2001 at 05:44:05PM -0400, Igor Khavkine wrote:
> On Sun, May 13, 2001 at 02:54:14PM -0700, Thomas Bushnell, BSG wrote:
> > Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> >
> > > The time it pauses is too short to write down all registers. We should
> > > consider increasing it.
>
On Sun, May 13, 2001 at 02:54:14PM -0700, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> > The time it pauses is too short to write down all registers. We should
> > consider increasing it.
>
> The time is a rapid spinning loop, IIRC, and has gotten shorter as
>
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> The time it pauses is too short to write down all registers. We should
> consider increasing it.
The time is a rapid spinning loop, IIRC, and has gotten shorter as
processors have gotten faster; it should be timed to bogomips or
something like that
Hi,
I opened a secod buffer in emacs with ^X^F. In three of four cases (only
some files seem to be affected), I got a kernel panic.
EIP was 0x1010cd3, which translates to some place in mach_msg_trap.
I should compile a kernel with debugging symbols...
The trap no is 14 (page fault).
The time
13 matches
Mail list logo