On Tue, 21 Dec 2004 12:38:43 -0700,
Steven Dake <[EMAIL PROTECTED]> wrote:
>with the x86_64 patch:
>
>Entering kdb (current=0xffffffff80636000, pid 0) on processor 0 due to
>Keyboardy
>[0]kdb> ef 00
> r15 = Unable to handle kernel NULL pointer dereference<1> at 0000000000000
Now I see, you are deliberately passing a bad value to the ef command.
All kdb commands have this "feature", you can feed any address you like
to any kdb command. Most commands do no validation on the address,
trusting the user to know what they are doing.
Even with your oops, kdb should recover and continue. On ia64, if I do
ef 1 I get an oops followed by
kdb: Debugger re-entered on cpu 1, new reason = 5
Attempting to abort command and recover
and kdb continues. The abort and recover mechanism is there to catch
bad user supplied addresses or corrupt addresses in data structures.
It avoids the need for lots of verification code in the rest of kdb.
If x86-64 does not recover from the oops, then there is something wrong
with the x86-64 longjmp code.
---------------------------
Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.
