RE: [Xen-ia64-devel] RFC: Switch to xlilo now? Or post-3.0?

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

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