crash-utility-bounces@redhat.com wrote on 27/09/2007
15:34:47:
> Richard, the SS is "bogus" because it is NOT saved by the
processor
> unless there is a privilege level change with the exception, and in
> this case there was no privilege change. I think you'll find SS is
> valid when a fault occurs in user land, resulting in a priv change
> as we enter the kernel.
>
Yes, I know - that's what I said in my original post.
But, you will never see a ring 3 exception stack frame because a ring 3
exception will not cause a panic and will not trigger a kdump.
It would be rather more useful if meaningful information
were formatted and even better if we saved the error code. And even more
useful if during panic we saved a few of the system regs such as CR2, which
would be highly relevant to page-fault page-fault analysis.
If you want regs, why not go to the beginning of the
ring 0 stack where you'll find a complete and valid set of regs. In this
case: further down the stack we see:
f463ce54: f8b43400 f8b4304f 00200000 00000000
.4..O0.... .....
f463ce64: 00000000 f463c000 00000018 f463007b
......c.....{.c.
f463ce74: 0000007b f46300d8 ffffffff f8b43004
{.....c......0..
f463ce84: 00000060 00210286 f463cf50 00000068
`.....!.P.c.h...
f463ce94: f463cf50 c0690068 c040651f c068854e
P.c.h.i..e@.N.h.
f463cea4: 00000068 f463cf50 00000001 f463cf18
h...P.c.......c.
f463ceb4: c0691227 00000000 0000000e 0000000b
'.i.............
f463cec4: 00000000 0000f0ff f4656630 00000000
........0fe.....
f463ced4: c060310c c0691216 00000000 f463cf18
.1`...i.......c.
f463cee4: f7f713f8 f7f713c0 00200246 f463cf18
........F. ...c.
f463cef4: c0691175 00000000 0000000e 0000000b
u.i.............
f463cf04: f8b43400 00000000 c0602d0e f463c000
.4.......-`...c.
f463cf14: c060190c f8b43400 f8b4304f 00200000
..`..4..O0.... .
f463cf24: 00000000 00000000 f463c000 00000018
..........c.....
f463cf34: f463007b 0000007b f46300d8 ffffffff
{.c.{.....c.....
f463cf44: f8b43004 00000060 00210286 f8b4302b
.0..`.....!.+0..
f463cf54: f8b4304f <== base of bogus pt-regs
c0443ab6 00657061 00000002 O0...:D.ape.....
f463cf64: f531f56c 00000002 f447d800 f463cfb8
l.1.......G...c.
f463cf74: c0450dab bf910ab0 00000081 40000003
..E............@
f463cf84: f4656630 bf9132f8 00000880 f463cfb8
0fe..2........c.
f463cf94: 0063c000 f8b43400 00000880 f463cfa4
..c..4........c.
f463cfa4: 00000000 bf910ab0 00000003 bf910ab0
................
f463cfb4: c0404f70 bf910ab0 00000880 bf9132f8
pO@..........2..
f463cfc4: 00000003 bf910ab0 bf913348 ffffffda
........H3......
f463cfd4: 0000007b 0000007b c0600000 00000081
{...{.....`.....
f463cfe4: 00db5402 00000073 00200246 bf910a84
.T..s...F. .....
f463cff4: 0000007b <== base of valis pt-regs
Now this would be useful to format in bt
Here we see that r3 regs prior to entry to the kernel
were:
ss:esp 7b:bf910a84 cs:eip 73:00db5402 eflags
00200246
orig_eax: 81 (which tells me that we entered
with a call to sys_delete_module)
fs 0000 es 007b ds 007b eax ffffffda ebp bf913348
edi bf910ab0 esi 00000003
edx bf9132f8 ecx 00000880 ebx bf9100ab0
Had a few of the system regs been logged at panic
could have found the base of the r0 stack
directly from the current TSS via the TR and the GDTR
or the MSRs for SYSENTER. But even so, it's easy to find by searching.
Having got back to the r3 ss:esp we can now unwind
the r3 stack:
bf910a84: 00a90f09 00000000 08048d36 bf910ab0
........6.......
bf910a94: 00000880 bf9132f8 bf910af4 bf910af0
.....2..........
bf910aa4: 00000000 00000000 08048c63 00657061
........c...ape.
bf910ab4: 00000000 00000000 00000000 00000000
................
and using vm deduce the string of events from r3 to
r0 panic:
VMA START
END FLAGS FILE
f51bf470 9a1000 9bc000
875 /lib/ld-2.6.so
f0b3e128 9bc000 9bd000 100871
/lib/ld-2.6.so
f522ef44 9bd000 9be000 100873
/lib/ld-2.6.so
f531f56c 9c0000 b0e000
75 /lib/libc-2.6.so
f51bf3c8 b0e000 b10000 100071
/lib/libc-2.6.so
f531b0d4 b10000 b11000 100073
/lib/libc-2.6.so
f0b3e224 b11000 b14000 100073
f0b3e17c db5000 db6000 4000075
f4e2ab00 8048000 804a000 1875
/sbin/rmmod
f51bf128 804a000 804b000 101873 /sbin/rmmod
f51bf320 88b8000 88d9000 100073
f531f668 b7f8a000 b7f8c000 100073
f51bf374 bf8ff000 bf914000 100173
which was that the user ran the command rmmod ape,
etc etc.
I don't think you can deduce any thing useful from
the regs are they are currently formatted. Wouldn't you prefer your perl
scripts have access to a valid set of regs from the true pt_regs struct
at the base of the r0 stack?
Richard
> And NO.. I don't want to see a different format for priv-level-
> change vs non-priv-level change exceptions and this makes it harder
> to post process with perl, etc..
>
> As for error-code, I don't know why it would be replace with -1
>
> - jim
>
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU