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 15:06:03 -0500 Message-ID: <43063BAB.1060302@us.ibm.com> References: <7F740D512C7C1046AB53446D3720017304ED13FD@scsmsx402.amr.corp.intel.com> <43063352.8000205@us.ibm.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: <43063352.8000205@us.ibm.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Cc: Ian Pratt , Ryan Harper , xen-devel@lists.xensource.com, "Nakajima, Jun" List-Id: xen-devel@lists.xenproject.org OK. More info on the x86_64 build on SLES 9 SP2. It built and booted=20 fine; however, when I can't create a domU. When attempting to create domU, it gives me the VFS: Unable to mount=20 root fs on unknown-block (0,0) message. This configurations have routinely worked before, so it is not a setup=20 issue. From console: bl2-1 login: (XEN) (file=3Dtraps.c, line=3D878) Non-priv domain attempted= =20 RDMSR(0000 0000c0000080,00020000,00020000). (XEN) (file=3Dtraps.c, line=3D870) Non-priv domain attempted=20 WRMSR(00000000c0000100, 00000000,00000000). (XEN) (file=3Dtraps.c, line=3D870) Non-priv domain attempted=20 WRMSR(00000000c0000102, 00000000,00000000). (XEN) (file=3Dtraps.c, line=3D878) Non-priv domain attempted=20 RDMSR(00000000c0000080, 00000000,00000000). stop_this_cpu disable_local_APIC (XEN) (file=3Dgrant_table.c, line=3D523) Bad handle (0). (XEN) (file=3Dgrant_table.c, line=3D1086) Grant unref rd(1) ld(0) frm(3f4= 85)=20 flgs(0) =2E (XEN) (file=3Dtraps.c, line=3D878) Non-priv domain attempted=20 RDMSR(00000000c0000080, 00020000,00020000). (XEN) (file=3Dtraps.c, line=3D870) Non-priv domain attempted=20 WRMSR(00000000c0000100, 00000000,00000000). (XEN) (file=3Dtraps.c, line=3D870) Non-priv domain attempted=20 WRMSR(00000000c0000102, 00000000,00000000). (XEN) (file=3Dtraps.c, line=3D878) Non-priv domain attempted=20 RDMSR(00000000c0000080, 00000000,00000000). stop_this_cpu disable_local_APIC David F Barrera wrote: > It seems that the x86_64 build still broken on FC4. It built on SLES=20 > 9, but I got the following error on FC4: > > > gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing=20 > -iwithprefix 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=20 > signedness > 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 >>>> >>>> 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 a= nd >> 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. >> Jun >> --- >> Intel Open Source Technology Center >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> >> =20 >> > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >