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

[Matt Chapman <matthewc@xxxxxxxxxxxxxxx>]

Moving /lib/tls has the side-effect of turning off fast system
calls... my guess is that with my latest patches, moving /lib/tls
is no longer necessary.

Matt


On Fri, Nov 18, 2005 at 09:33:17AM -0800, Magenheimer, Dan (HP Labs Fort 
Collins) wrote:
> I did not have to move /lib/tls to successfully boot.
> 
> Although this may be required on Xen/x86, I am not
> aware of anything in /lib/tls that would break
> Xen/ia64.
> 
> Does anybody know about potential probleems with
> /lib/tls on ia64?
> 
> Dan 
> 
> > -----Original Message-----
> > From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> > [mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf 
> > Of takebe_akio@xxxxxxxxxxxxxx
> > Sent: Friday, November 18, 2005 2:12 AM
> > To: Tian, Kevin; Chapman, Matthew (HP Labs); Williamson, Alex 
> > (Linux Kernel Dev)
> > Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [Xen-ia64-devel] RFC: Switch to xlilo now? Or post-3.0?
> > 
> > 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ãã1ãã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
> > 
> > 

> _______________________________________________
> 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