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