<tt>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. > </tt> <tt>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. </tt> <tt>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. </tt> <tt>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:</tt> <tt>f463ce54: f8b43400 f8b4304f 00200000 00000000 .4..O0.... .....</tt> <tt>f463ce64: 00000000 f463c000 00000018 f463007b ......c.....{.c.</tt> <tt>f463ce74: 0000007b f46300d8 ffffffff f8b43004 {.....c......0..</tt> <tt>f463ce84: 00000060 00210286 f463cf50 00000068 `.....!.P.c.h...</tt> <tt>f463ce94: f463cf50 c0690068 c040651f c068854e P.c.h.i..e@.N.h.</tt> <tt>f463cea4: 00000068 f463cf50 00000001 f463cf18 h...P.c.......c.</tt> <tt>f463ceb4: c0691227 00000000 0000000e 0000000b '.i.............</tt> <tt>f463cec4: 00000000 0000f0ff f4656630 00000000 ........0fe.....</tt> <tt>f463ced4: c060310c c0691216 00000000 f463cf18 .1`...i.......c.</tt> <tt>f463cee4: f7f713f8 f7f713c0 00200246 f463cf18 ........F. ...c.</tt> <tt>f463cef4: c0691175 00000000 0000000e 0000000b u.i.............</tt> <tt>f463cf04: f8b43400 00000000 c0602d0e f463c000 .4.......-`...c.</tt> <tt>f463cf14: c060190c f8b43400 f8b4304f 00200000 ..`..4..O0.... .</tt> <tt>f463cf24: 00000000 00000000 f463c000 00000018 ..........c.....</tt> <tt>f463cf34: f463007b 0000007b f46300d8 ffffffff {.c.{.....c.....</tt> <tt>f463cf44: f8b43004 00000060 00210286 f8b4302b .0..`.....!.+0..</tt> <tt>f463cf54: f8b4304f <== base of bogus pt-regs</tt> <tt> c0443ab6 00657061 00000002 O0...:D.ape.....</tt> <tt>f463cf64: f531f56c 00000002 f447d800 f463cfb8 l.1.......G...c.</tt> <tt>f463cf74: c0450dab bf910ab0 00000081 40000003 ..E............@</tt> <tt>f463cf84: f4656630 bf9132f8 00000880 f463cfb8 0fe..2........c.</tt> <tt>f463cf94: 0063c000 f8b43400 00000880 f463cfa4 ..c..4........c.</tt> <tt>f463cfa4: 00000000 bf910ab0 00000003 bf910ab0 ................</tt> <tt>f463cfb4: c0404f70 bf910ab0 00000880 bf9132f8 pO@..........2..</tt> <tt>f463cfc4: 00000003 bf910ab0 bf913348 ffffffda ........H3......</tt> <tt>f463cfd4: 0000007b 0000007b c0600000 00000081 {...{.....`.....</tt> <tt>f463cfe4: 00db5402 00000073 00200246 bf910a84 .T..s...F. .....</tt> <tt>f463cff4: 0000007b <== base of valis pt-regs</tt> <tt>Now this would be useful to format in bt</tt> <tt>Here we see that r3 regs prior to entry to the kernel were:</tt> <tt>ss:esp 7b:bf910a84 cs:eip 73:00db5402 eflags 00200246</tt> <tt>orig_eax: 81 (which tells me that we entered with a call to sys_delete_module)</tt> <tt>fs 0000 es 007b ds 007b eax ffffffda ebp bf913348 edi bf910ab0 esi 00000003</tt> <tt>edx bf9132f8 ecx 00000880 ebx bf9100ab0</tt> <tt>Had a few of the system regs been logged at panic could have found the base of the r0 stack</tt> <tt>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.</tt> <tt>Having got back to the r3 ss:esp we can now unwind the r3 stack:</tt> <tt>bf910a84: 00a90f09 00000000 08048d36 bf910ab0 ........6.......</tt> <tt>bf910a94: 00000880 bf9132f8 bf910af4 bf910af0 .....2..........</tt> <tt>bf910aa4: 00000000 00000000 08048c63 00657061 ........c...ape.</tt> <tt>bf910ab4: 00000000 00000000 00000000 00000000 ................</tt> <tt>and using vm deduce the string of events from r3 to r0 panic:</tt> <tt> VMA START END FLAGS FILE</tt> <tt>f51bf470 9a1000 9bc000 875 /lib/ld-2.6.so</tt> <tt>f0b3e128 9bc000 9bd000 100871 /lib/ld-2.6.so</tt> <tt>f522ef44 9bd000 9be000 100873 /lib/ld-2.6.so</tt> <tt>f531f56c 9c0000 b0e000 75 /lib/libc-2.6.so</tt> <tt>f51bf3c8 b0e000 b10000 100071 /lib/libc-2.6.so</tt> <tt>f531b0d4 b10000 b11000 100073 /lib/libc-2.6.so</tt> <tt>f0b3e224 b11000 b14000 100073 </tt> <tt>f0b3e17c db5000 db6000 4000075 </tt> <tt>f4e2ab00 8048000 804a000 1875 /sbin/rmmod</tt> <tt>f51bf128 804a000 804b000 101873 /sbin/rmmod</tt> <tt>f51bf320 88b8000 88d9000 100073 </tt> <tt>f531f668 b7f8a000 b7f8c000 100073 </tt> <tt>f51bf374 bf8ff000 bf914000 100173 </tt> <tt>which was that the user ran the command rmmod ape, etc etc.</tt> <tt>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?</tt> <tt>Richard</tt> <tt> > 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 > </tt> <hr> 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