[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] Trouble booting FreeBSD i386 PV DomU
On 26/03/13 11:14, Colin Percival wrote: > On 03/26/13 03:10, Roger Pau Monné wrote: >> On 26/03/13 10:38, Colin Percival wrote: >>> On 03/26/13 02:31, Roger Pau Monné wrote: >>>> Is Xen i386 PV broken? >>> >>> Not completely broken, but it's certainly not in a good state. I believe >>> it's broken with SMP, for example -- if the "crashed on cpu#7" in your >>> output means cpu#7 from the guest, it would certainly explain things. >> >> My guest only has one vcpu (vcpu#0): > > Ok, I wasn't sure how to parse that output. > >>> HVM is the way to go with FreeBSD/Xen. >> >> Yes, I'm already working on that, and got vector callbacks working on >> both i386 and amd64 HVM guests, thanks to Justin T. Gibbs patch. Now I >> was trying to boot a PV guest to see how much breakage this change >> introduced to PV, but I'm not able to make it work, even without my patches. >> >> I've replied to this xen-users thread because the author seem to have a >> working FreeBSD DomU PV guest, and I was wondering how he did it. From >> my POV it seems like PV guests hasn't been working for a long time, >> since Xen 3.3 dropped support for non-PAE guests, and the FreeBSD kernel >> is detected as non-PAE. > > I had FreeBSD 8.2-RELEASE and a 9.0-CURRENT @ January 2011 running with PV > in EC2 (http://www.daemonology.net/freebsd-on-ec2/, look for "t1.micro > instances only") and that used PAE. But it's entirely likely that something > got broken in the past two years and nobody noticed because nobody ever uses > PV... I've checked and 9.1 is working OK (at least boots and seems to be functional). I've also found the reason why HEAD doesn't work, and it's probably caused by the switch to clang, which seems to have problems with the ELFNOTE macro, here is a patch that makes i386 PV boot again: --- diff --git a/sys/i386/include/asmacros.h b/sys/i386/include/asmacros.h index c1c3f64..474dfe1 100644 --- a/sys/i386/include/asmacros.h +++ b/sys/i386/include/asmacros.h @@ -211,7 +211,7 @@ #ifdef __STDC__ #define ELFNOTE(name, type, desctype, descdata...) \ -.pushsection .note.name ; \ +.pushsection .note.name,"",@note ; \ .align 4 ; \ .long 2f - 1f /* namesz */ ; \ .long 4f - 3f /* descsz */ ; \ @@ -223,7 +223,7 @@ .popsection #else /* !__STDC__, i.e. -traditional */ #define ELFNOTE(name, type, desctype, descdata) \ -.pushsection .note.name ; \ +.pushsection .note.name,"",@note ; \ .align 4 ; \ .long 2f - 1f /* namesz */ ; \ .long 4f - 3f /* descsz */ ; \ --- But there's even more problems... rtc0: [XEN] xen_rtc_gettime rtc0: [XEN] xen_rtc_gettime: wallclock 1364233979 sec; 999999989 nsec rtc0: [XEN] xen_rtc_gettime: uptime 76890 sec; 166126554 nsec rtc0: [XEN] xen_rtc_gettime: TOD 1364310870 sec; 166126543 nsec start_init: trying /sbin/init pid 26 (sh), uid 0: exited on signal 4 panic: removing pages from non-current pmap cpuid = 0 KDB: enter: panic [ thread pid 26 tid 100037 ] Stopped at kdb_enter+0x3d: movl $0,kdb_why db> bt Tracing pid 26 tid 100037 td 0xc25e4900 kdb_enter(c03f8ad8,c03f8ad8,c04321de,ccf7699c,c04321de,...) at kdb_enter+0x3d/frame 0xccf76930 kassert_panic(c047c478,100,c04321de,ccf7699c,ccf7699c,...) at kassert_panic+0x232/frame 0xccf7696c kassert_panic(c04321de,c0431504,e0a,7bc,c044fe94,...) at kassert_panic+0xea/frame 0xccf76990 pmap_remove_pages(c2427638,c064bd74,8,c2427638,c248c8b8,...) at pmap_remove_pages+0xb3/frame 0xccf76a00 vmspace_exit(c25e4900,0,c03f2588,140,4,...) at vmspace_exit+0xb1/frame 0xccf76a28 exit1(c25e4900,4,1a,c248cacc,0,...) at exit1+0x654/frame 0xccf76a88 sigexit(c25e4900,4,c03f8b70,b0a,c0153a4f,...) at sigexit+0xc7f/frame 0xccf76c20 postsig(4,0,c03fee92,10d,0,...) at postsig+0x3b2/frame 0xccf76cdc ast(ccf76d18) at ast+0x388/frame 0xccf76d0c vm86_biosret() at vm86_biosret+0x9c/frame 0xbf7fcba8 Attachment:
0001-xen-fix-ELFNOTE-macro.patch _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxx http://lists.xen.org/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |