<br><tt><font size=2>I've been puzzling over why the regs formatted with
a backtrace on an IA32 dump are invalid. Here's what I mean:</font></tt>
<br>
<br><tt><font size=2>PID: 2692   TASK: f4656630  CPU: 0  
COMMAND: "rmmod"</font></tt>
<br><tt><font size=2> #0 [f463ce54] crash_kexec at c044a1f7</font></tt>
<br><tt><font size=2> #1 [f463ce9c] die at c040651a</font></tt>
<br><tt><font size=2> #2 [f463ced4] do_page_fault at c0603107</font></tt>
<br><tt><font size=2> #3 [f463cf14] error_code (via page_fault) at
c060190a</font></tt>
<br><tt><font size=2>    EAX: 00000018  EBX: f8b43400  ECX:
f8b4304f  EDX: 00200000 </font></tt>
<br><tt><font size=2>    DS:  007b      ESI:
00000000  ES:  007b      EDI: 00000000</font></tt>
<br><tt><font size=2>    SS:  304f      ESP:
f8b4302b  EBP: f463c000</font></tt>
<br><tt><font size=2>    CS:  0060      EIP:
f8b43004  ERR: ffffffff  EFLAGS: 00210286 </font></tt>
<br>
<br>
<br><tt><font size=2>They are supposed to represent a valid set of regs
that are presented to do_page_fault, which I presume are meant to be valid
at the time the exception occurred.</font></tt>
<br><tt><font size=2>Of they can never be a set of valid regs for the simple
reason that the CPL is 0 (CS=60) and the RPL of SS is 3, which is an automatic
GPF.</font></tt>
<br><tt><font size=2>Since I manufactured the exception that caused this
dump, by causing an unrecoverable page fault in ring 0, I known the CS
is correct but SS is bogus. </font></tt>
<br><tt><font size=2>Furthermore the the error code (ERR), which is stored
by the processor as part of the exception stack frame uses only bits 0-2
for page faults and at most bits 0-15 for other exceptions, the unused
bit positions are zero. So ERR is also bogus.</font></tt>
<br>
<br><tt><font size=2>On looking at the code in entry.S at page_fault and
the other exception entry points I see no attempt to save regs to create
a pt_regs struct. The fact that do_page_fault takes pt_regs as the first
arg is a hack to get at CS:EIP and SS:ESP at the time of exception. Furthermore
error_code loads the exception error code into edx then wipes it out from
the stack by storing -1 into this location. I can't actually see a good
reason for wiping out the error code. By convention exceptions and interrupts
have a -ve integer stored at the error-code location to distinguish them
from system calls, but I don't think this is used. signal.c seems to be
the only place to look for an error code >=0 but I don't see an exception
affects signal.c </font></tt>
<br>
<br><tt><font size=2>Can anyone confirm whether setting the error code
to -1 is essential. If it isn't then I think we should consider leaving
it in place.</font></tt>
<br>
<br>
<br><tt><font size=2>The long and short of it is: the only thing that has
any meaning is CS, EIP and EFLAGS. All of which are saved by the processor.
 SS and ESP are only saved when the exception occurred at a privilege
level >0 but these can never generate a panic. </font></tt>
<br>
<br><tt><font size=2>I'd recommend that we change the bt output to format
only the three valid regs (possibly SS and ESP, if CPL at time of exception
>0). Is there any reason why this shouldn't be changed?</font></tt>
<br>
<br><tt><font size=2>Richard</font></tt>
<br>
<br><font size=3 face="sans-serif"><br>
</font>
<br><font size=3 face="sans-serif"><br>
</font>
<hr><font size=2 face="sans-serif"><br>
<i><br>
</i></font>
<p><font size=2 face="sans-serif"><i>Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU</i></font>
<p><font size=2 face="sans-serif"><br>
</font><font size=3 face="sans-serif"><br>
</font>
<br>
<br><font size=3 face="sans-serif"><br>
</font>