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
Oops: 0000
CPU 0
Pid: 0, comm: swapper Not tainted
RIP: 0010:[<ffffffff8031536c>]{kdba_getregcontents+363}
RSP: 0000:ffffffff805f5e88 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffffffff80378b17 RCX: 0000000000000003
RDX: 0000000000000003 RSI: ffffffff80378b1a RDI: ffffffff80378b1b
RBP: 0000000000000000 R08: ffffffff80378b17 R09: 0000000000000000
R10: ffffffff8038d2c8 R11: ffffffff8038cf80 R12: 0000000000000000
R13: ffffffff805f5f20 R14: 0000000000000000 R15: ffffffffffffffff
FS: 0000000000000000(0000) GS:ffffffff805f1280(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000088 CR3: 0000000000101000 CR4: 00000000000006e0
Process swapper (pid: 0, stackpage=ffffffff80637000)
Stack: ffffffff805f5e88 0000000000000000 ffffffff80315319 ffffffff8056fec0
ffffffff801c246c ffffffff805f5f38 ffffffff805f5f40 ffffffff805f5f48
ffffffff805f5f50 ffffffff8056ff83 ffffffff8056ff83 0000000000000000
Call Trace: [<ffffffff80315319>]{kdba_getregcontents+280}
[<ffffffff801c246c>]{kdbnearsym+90} [<ffffffff80315656>]{kdba_dumpregs+1
[<ffffffff801c57e3>]{kdb_ef+68} [<ffffffff801c396b>]{kdb_parse+812}
[<ffffffff801c3fae>]{kdb_local+1179} [<ffffffff801c4146>]{kdb_main_loop+
[<ffffffff80315806>]{kdba_main_loop+71} [<ffffffff801c491a>]{kdb+1670}
[<ffffffff801f8604>]{receive_chars+167} [<ffffffff801f8bc8>]{rs_interrup
[<ffffffff80111dc6>]{handle_IRQ_event+94} [<ffffffff80112043>]{do_IRQ+16
[<ffffffff8010cc2c>]{default_idle+0} [<ffffffff8010f5a3>]{common_interru
<EOI> [<ffffffff8010cc4a>]{default_idle+30}
[<ffffffff8010cca2>]{cpu_id
[<ffffffff8010b06b>]{rest_init+107}
On Thu, 2004-12-16 at 04:16, Keith Owens wrote:
> On Thu, 16 Dec 2004 02:15:12 -0700,
> Steven Dake <[EMAIL PROTECTED]> wrote:
> >Folks
> >
> >Find a patch against the x86_64 4.3 link below for a bug in the port.
> >
> >Entering ef 00 causes an oops. This has been fixed in the i386
> >version. This may exist in 4.4 I'm not sure.
> >
> >Thanks
> >-steve
> >
> >--- old/arch/x86_64/kdb/kdbasupport.c 2004-12-15 14:00:53.000000000 +
> >0900
> >+++ new/arch/x86_64/kdb/kdbasupport.c 2004-12-15 14:02:30.000000000 +
> >0900
> >@@ -882,6 +882,11 @@
> > struct kdbregs *rlp;
> > kdb_machreg_t contents;
> >
> >+ if (!regs) {
> >+ kdb_printf("%s: pt_regs not available\n", __FUN
> >CTION__);
> >+ return KDB_BADREG;
> >+ }
> >+
> > for (i=0, rlp=kdbreglist; i<nkdbreglist; i++,rlp++) {
> > kdb_printf("%8s = ", rlp->reg_name);
> > kdba_getregcontents(rlp->reg_name, regs, &conte
> >nts);
>
> Your mailer wrapped the patch.
>
> The patch should not be necessary, anywhere in kdb that uses a
> struct pt_regs * should have a non-null value. There used to be tests
> scattered throughout kdb for 'if (regs)' but they just got in the way.
> Some time ago I made sure that all the entry paths set a valid pt_regs
> and removed all the unnecessary tests. There are a few KDB_NULL_REGS()
> calls left but they never trip and will be removed one day.
>
> The only time that there may be no registers is for reason KDB_SILENT.
> How did you get to kdba_dumpregs() with a valid set of registers?
>
> ---------------------------
> Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.
---------------------------
Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.
