Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: i386 kernel w/options PAE fails

On Thu, 29 Jul 2010 14:06:24 -0500 (CDT), "John D. Baker"
<> wrote:
> I've tried a GENERIC kernel that only has "options PAE" added.  It
> panics in a similar fashion to my custom kernel:
> 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
 #define        PG_NX           0               /* dummy */

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 "" to my ISP's inbound MTA...)

Greylisting somewhere, I suppose...

Jean-Yves Migeon

Home | Main Index | Thread Index | Old Index