Re: i386 kernel w/options PAE fails

[jean-Yves Migeon <jym%NetBSD.org@localhost>]

On Thu, 29 Jul 2010 14:06:24 -0500 (CDT), "John D. Baker"
<jdbaker%mylinuxisp.com@localhost> wrote:
> I've tried a GENERIC kernel that only has "options PAE" added.  It
> panics in a similar fashion to my custom kernel:
> 
>    http://bobdbob.com/~jdbaker/dmesg-GENERIC_pae_up-nbsd5_99_38.txt
>    http://bobdbob.com/~jdbaker/dmesg-GENERIC_pae-nbsd5_99_38.txt
> 
> When I was still running 5.1_RCx, I would occasionally boot Xen 3.3.2.
> Since the Xen kernel found PAE support, a netbsd-XEN3PAE_DOM0 kernel
> was required and ran just fine.
>
> I'll have to try it again with -current

Please do.

Note that someone reported regression with a.out not running any more and
NX bit feature, if that matters.

FWIW, I suspect NX to be the culprit. Your dmesg shows:

Jul 28 16:42:20 shadow amd[250]/warn:  getnetbyaddr failed on 0xc0a8fb00,
succeeded on 0xc0a8fb
Creating a.out runtime link edituvm_fault(0xd06e2e18, 0, 1) -> 0xe
fatal page fault in supervisor mode                               
trap type 6 code 0 eip c03cf20b cs 8 eflags 10296 cr2 62 ilevel 0
panic: trap                                                      
cpu0: Begin traceback...
uvm_fault(0xd06e2e18, 0, 1) -> 0xe

If I get it right, it fault on address 0x62 (as pointed by cr2), and CS is
8 (GEXTBIOSDATA_SEL) used to trap BIOS refs to EBDA.

I had similar crashes when low memory code was mapped with incorrect
rights, like bioscall trampoline.

Can you please try booting with the following patch applied:


--- sys/arch/i386/include/pte.h.orig    2010-07-30 11:26:29.000000000 +0200
+++ sys/arch/i386/include/pte.h 2010-07-30 11:26:37.000000000 +0200
@@ -298,7 +298,7 @@ typedef uint32_t pt_entry_t;                /* PTE */
 #define        PG_KW           0x00000002      /* kernel read-write */
 
 #ifdef PAE
-#define        PG_NX           0x8000000000000000ULL /* No-execute */
+#define        PG_NX           0
 #else
 #define        PG_NX           0               /* dummy */
 #endif



Also, of interest, a disassembly (gdb + disass 0xc03cf20b on the kernel
binary) would be helpful, just to know in what context the trap happens.

> (The message to which I'm replying just arrived, taking nearly 24 hours
> to get from "me-wanadoo.fr" to my ISP's inbound MTA...)

Greylisting somewhere, I suppose...

-- 
Jean-Yves Migeon
jym%NetBSD.org@localhost