|
xen-ia64-devel
RE: [Xen-ia64-devel] RFC: Switch to xlilo now? Or post-3.0?
FYI, I have booted xen-ia64-unstable tip (7738) successfully
on my RHEL3 box, so perhaps this problem only occurs when
using xlilo? (I'm guessing you are booting debian?)
>From the error messages, I'd guess that some machine page
is being used by domain0 but then being xalloc'ed and
overwritten by Xen.
BTW, I think it is OK to allow old syntax (image=xen,
initrd=xenlinux) with elilo but require new syntax
(vmm=xen, image=xenlinux, initrd=initrd) with xlilo,
but I am open to discussion if others disagree.
> -----Original Message-----
> From: Williamson, Alex (Linux Kernel Dev)
> Sent: Thursday, November 17, 2005 4:32 PM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: takebe_akio@xxxxxxxxxxxxxx; xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-ia64-devel] RFC: Switch to xlilo now? Or post-3.0?
>
> On Thu, 2005-11-17 at 10:08 -0800, Magenheimer, Dan (HP Labs Fort
> Collins) wrote:
>
> > But then (from Xen):
> >
> > handle_op: can't handle privop at 0xa000000000010670
> (op=0) slot 0 (type=5)
> >
> > (note, NOT 0xa000000100010670)
> >
> > and
> >
> > udevstart[1047]: General Exception: IA-64 Privileged
> Operation fault 16 [1]
> > Modules linked in:
> >
> > and then a a long string of kernel core dumps, the first of which
> > is comm=udevstart.
>
> I'm having similar problems w/o even trying to use an
> initrd. I did
> a fresh clone of xen-ia64-unstable.hg (newer xlilo patch already
> included) and ran make. Previously I was using xlilo.efi as
> if it were
> elilo.efi (ie. image=xen initrd=xenlinux). Yes, this is now broken.
> Switched to image=xenlinux and vmm=xen.gz and it works, until...
>
> Cleaning /tmp....
> Cleaning /var/run ....
> Cleaning /var/lock ....
> Detecting hardware...(XEN) handle_op: can't handle privop at
> 0xa000000000010650 (op=0x0000000008000000) slot 0 (type=1),
> ipsr=0000101208026038
> (XEN) priv_emulate: priv_handle_op fails, isr=0000000000000010
> discover[1158]: General Exception: IA-64 Privileged Operation
> fault 16 [1]
>
> discover is the one that starts the string of core dumps for
> me and it claims:
>
> ip is at __kernel_syscall_via_epc+0x10/0xc0
>
> Looks like something is busted in the tree. Thanks,
>
> Alex
>
>
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
|
|
Home