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

[takebe_akio@xxxxxxxxxxxxxx]

Hi All,

Sorry, I'm back my office now.

I had similar problem, but I resolved it.

It is nessecerry to do "mv /lib/tls /lib/tls.disabled".
I'm sorry. I missed my boot way. 

I write again the Dom0 boot way on RHEL4 with xlilo.efi. :)
-------------
1. get new source
  # hg clone http://xenbits.xensource.com/ext/xen-ia64-unstable.hg
2. do patches
  # patch -p1 </root/vmx_vioapic.patch    <----gcc34buildv2.patch
  # patch -p1 </root/tools_build_for_gcc34.patch    
  # patch -p1 </root/tristan_build.patch  <---Tristan's compilefix.diff

3. make & install
  # make world
  # make install-tools
  # cp xen/xen.gz /boot/efi/efi/xen/
  # cp linux-2.6.12-xen0/vmlinux /boot/efi/efi/xen/vmlinux-2.6.12-xen0
  # cd linux-2.6.12-xen0
  # make modules_install
  # mkinitrd -f /boot/efi/efi/xen/initrd-2.6.12-xen0.img 2.6.12.6-xen0
4. vi /boot/efi/efi/xen/elilo.conf
>       image=vmlinux-2.6.12-xen0
>               label=xen
>               vmm=xen.gz
>               initrd=initrd-2.6.12-xen0.img
>               read-only
>               append="com2=115200,8n1 console=com2 sched=bvt maxcpus=1 
>-- nomca nosmp console=tty0 console=ttyS1,115200,8n1 rhgb root=/dev/sda2"
5. mv /lib/tls /lib/tls.disabled
6. reboot

Best Regards,

Akio Takebe

>>From: Matt Chapman
>>Sent: 2005ト\xF31ヤツ18ネユ 15:36
>>
>>N.B. Dan: this is in the fast system call path, so I don't
>>expect you'll see it with RHEL3, since the libc is too old
>>to support fast system calls.
>>
>>Matt
>
>Absolutely agree. ;-)
>
>Thanks,
>Kevin
>>
>>
>>On Thu, Nov 17, 2005 at 04:32:02PM -0700, Alex Williamson wrote:
>>> 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
>>
>>_______________________________________________
>>Xen-ia64-devel mailing list
>>Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>>http://lists.xensource.com/xen-ia64-devel
>
>_______________________________________________
>Xen-ia64-devel mailing list
>Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-ia64-devel

Attachment: tools_build_for_gcc34.patch
Description: Binary data

Attachment: gcc34buildv2.patch
Description: Binary data

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel