From mboxrd@z Thu Jan 1 00:00:00 1970 From: David F Barrera Subject: Re: x86_64 SLES 9 SP2 build break Date: Fri, 19 Aug 2005 14:30:26 -0500 Message-ID: <43063352.8000205@us.ibm.com> References: <7F740D512C7C1046AB53446D3720017304ED13FD@scsmsx402.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <7F740D512C7C1046AB53446D3720017304ED13FD@scsmsx402.amr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Nakajima, Jun" Cc: Ian Pratt , Ryan Harper , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org It seems that the x86_64 build still broken on FC4. It built on SLES 9,=20 but I got the following error on FC4: gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix=20 include -Wall -Werror -Wno-pointer-arith -pipe=20 -I/tmp/xen-unstable.hg/xen/include=20 -I/tmp/xen-unstable.hg/xen/include/asm-x86/mach-generic=20 -I/tmp/xen-unstable.hg/xen/include/asm-x86/mach-default -O3=20 -fomit-frame-pointer -msoft-float -m64 -mno-red-zone -fpic=20 -fno-reorder-blocks -fno-asynchronous-unwind-tables -DNDEBUG -DVERBOSE=20 -c physdev.c -o physdev.o cc1: warnings being treated as errors physdev.c: In function =E2do_physdev_op=E2: physdev.c:109: warning: pointer targets in assignment differ in signednes= s make[3]: *** [physdev.o] Error 1 make[3]: Leaving directory `/tmp/xen-unstable.hg/xen/arch/x86' make[2]: *** [/tmp/xen-unstable.hg/xen/xen] Error 2 make[2]: Leaving directory `/tmp/xen-unstable.hg/xen' make[1]: *** [xen] Error 2 make[1]: Leaving directory `/tmp/xen-unstable.hg' make: *** [world] Error 2 Nakajima, Jun wrote: >Ryan Harper wrote: > =20 > >>>>You need x86_64 to run ASAP, not HOTPLUG_CPU for x86_64 smp, >>>>correct?=20 >>>> =20 >>>> >>>No, we _do_ need HOTPLUG_CPU for x86_64 smp. The build problem is >>>not a big deal. >>> =20 >>> >>Ah. OK. I don't think it will be a problem for Xen, but currently in >>plain linux-2.6.13-rc6 (which has x86_64 HOTPLUG_CPU support), >>support is non-functional, at least on my two-way Opteron box. I can >>remove a cpu (echo 0 > /sys/devices/system/cpu/cpu1/online) fine, but >>when I try to restore (echo 1), the processor fails to come back.=20 >>Part of this is that they are integrating the physical hotplug >>support which requires a full reboot of the processor (a second run >>through do_boot_cpu()) since it would have been physically removed. =20 >>I really wanted to see HOTPLUG_CPU work on plain Linux before >>bringing the code into XenLinux, but the issues may be tied up in >>code that Xen doesn't need. The hypervisor will have to support >>physical hotplug before XenLinux will need it. >> =20 >> > >That's right. As long as we handle VCPU, that should be Xen-specific and >common between x86 and x86_64 (although smp.c & smpboot.c are slightly >different there at this point). > > =20 > >>There are some other subtle differences in HOTPLUG_CPU in the newer >>2.6.13 series for x86_64 compared to the level of HOTPLUG_CPU we have >>patched into the 2.6.12 tree. >> >>I'll go ahead and work up a patch that brings in HOTPLUG_CPU for >>x86_64 and share that so we both can work on getting it working. >> =20 >> > >Great.=20 > >Jun >--- >Intel Open Source Technology Center > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel > > =20 >