Re: Dom0 PAE panic when starting xend

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

On Tuesday 10 March 2009 21:06:43 Manuel Bouyer wrote:
> On Tue, Mar 10, 2009 at 08:34:00PM +0100, Christoph Egger wrote:
> > > > Yes, even after a << PAGE_SHIFT
> > > >
> > > > x86_round_page(), x86_trunc_page() and x86_ptob() also need to be
> > > > changed from (unsigned long) to paddr_t. The other x86_* macros in
> > > > the same block are safe (only used on virtual addresses).
> >
> > I just tested this change in local tree. Changing x86_round_page() and
> > x86_trunc_page() as said, lets the init process die with SIGSEGV on boot.
> >
> > So if you are sure, this is the way to go, then we have to fix other
> > bugs, too.
>
> Probably. There was also an overvlow in xpmap_mtop(). Can you try with
> the changes I just commited ? it works fine on my system ...

Yes, the machine boots and I can start xend.
Now when I want to start a 32bit PAE PV guest, python crashes
before xend evaluates the guest config file.
A ktrace is this:

   370      8 python2.5 CALL  mlock(0xb9bfc000,0x1000)
   370      8 python2.5 RET   mlock 0
   370      8 python2.5 CALL  ioctl(0x17,_IOWR('P',0,0x1c),0xb9bfc760)
   370      8 python2.5 GIO   fd 23 wrote 28 bytes
       "#\0\0\0\M-T\M-F\M-?\M-9\M-@u\M-g\M-:,\M-%G\M-:\M^E\^Rr\M-;`\M-/|\M-;
\0\0\0\0"
   370      8 python2.5 GIO   fd 23 read 28 bytes
       "#\0\0\0\M-T\M-F\M-?\M-9\M-@u\M-g\M-:,\M-%G\M-:\M^E\^Rr\M-;`\M-/|\M-;
\0\0\0\0"
   370      8 python2.5 RET   ioctl 0
   370      8 python2.5 CALL  munlock(0xb9bfc000,0x1000)
   370      8 python2.5 RET   munlock 0
   370      8 python2.5 CALL  mlock(0xb9bfc000,0x1000)
   370      8 python2.5 RET   mlock 0
   370      8 python2.5 CALL  ioctl(0x17,_IOWR('P',0,0x1c),0xb9bfc6b8)
   370      8 python2.5 GIO   fd 23 wrote 28 bytes
       "#\0\0\0\M-|\M-F\M-?\M-9\0\M-p\M-$\M-:\^B\0\0\0\M-D\M-aE\M-:
\^P\0\0\0\M-X\^Ai\M-;"
   370      8 python2.5 GIO   fd 23 read 28 bytes
       "#\0\0\0\M-|\M-F\M-?\M-9\0\M-p\M-$\M-:\^B\0\0\0\M-D\M-aE\M-:
\^P\0\0\0\0\0\0\0"
   370      8 python2.5 RET   ioctl 0
   370      8 python2.5 CALL  munlock(0xb9bfc000,0x1000)
   370      8 python2.5 RET   munlock 0
   370      8 python2.5 PSIG  SIGSEGV SIG_DFL: code=SEGV_MAPERR, addr=0x55, 
trap=6)
   370      7 python2.5 RET   accept -1 errno 4 Interrupted system call
   370      6 python2.5 RET   accept -1 errno 4 Interrupted system call
   370      5 python2.5 RET   read -1 errno 4 Interrupted system call
   370      3 python2.5 RET   __select50 -1 errno 4 Interrupted system call
   370      2 python2.5 RET   accept -1 errno 4 Interrupted system call
   370      1 python2.5 RET   __select50 -1 errno 4 Interrupted system call
   370      4 python2.5 RET   ___lwp_park50 -1 errno 4 Interrupted system call

I also traced the python execution path and it looks like something
during a process fork(2) goes wrong. Sounds like there are some
PAE bugs in our pmap.

Christoph