[Crash-utility] invalid regs display in bt

Thu Sep 27 15:34:35 UTC 2007

crash-utility-bounces at 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 at .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 at ..........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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20070927/7fd38127/attachment.htm>