[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [xen-unstable test] 64494: regressions - FAIL
On 20/11/15 15:41, Andrew Cooper wrote: > On 20/11/15 15:34, Wei Liu wrote: >> On Fri, Nov 20, 2015 at 04:29:04PM +0100, Juergen Gross wrote: >>> On 20/11/15 16:14, Jan Beulich wrote: >>>>>>> On 19.11.15 at 12:47, <JGross@xxxxxxxx> wrote: >>>>> On 19/11/15 11:30, Ian Campbell wrote: >>>>>> On Thu, 2015-11-19 at 11:24 +0100, Juergen Gross wrote: >>>>>>> On 18/11/15 15:49, Wei Liu wrote: >>>>>>>> Hi Juergen >>>>>>>> >>>>>>>> Looks like there is something we missed after all. >>>>>>>> >>>>>>>> On Wed, Nov 18, 2015 at 02:31:57PM +0000, osstest service owner wrote: >>>>>>>>> flight 64494 xen-unstable real [real] >>>>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/64494/ >>>>>>>>> >>>>>>>>> Regressions :-( >>>>>>>>> >>>>>>>>> Tests which did not succeed and are blocking, >>>>>>>>> including tests which could not be run: >>>>>>>>> test-amd64-amd64-i386-pvgrub 10 guest-start fail REGR. >>>>>>>>> vs. 64035 >>>>>>>> Nov 18 05:11:19.753014 (d2) Bootstrapping... >>>>>>>> Nov 18 05:11:19.769108 (d2) Xen Minimal OS! >>>>>>>> Nov 18 05:11:19.769134 (d2) start_info: 0xa13000(VA) >>>>>>>> Nov 18 05:11:19.769158 (d2) nr_pages: 0x20000 >>>>>>>> Nov 18 05:11:19.777046 (d2) shared_inf: 0xca1fc000(MA) >>>>>>>> Nov 18 05:11:19.777072 (d2) pt_base: 0xa16000(VA) >>>>>>>> Nov 18 05:11:19.785042 (d2) nr_pt_frames: 0xb >>>>>>>> Nov 18 05:11:19.785077 (d2) mfn_list: 0x993000(VA) >>>>>>>> Nov 18 05:11:19.785108 (d2) mod_start: 0x0(VA) >>>>>>>> Nov 18 05:11:19.785135 (d2) mod_len: 0 >>>>>>>> Nov 18 05:11:19.793047 (d2) flags: 0x0 >>>>>>>> Nov 18 05:11:19.793077 (d2) cmd_line: (hd0,0)/boot/grub/menu.lst >>>>>>>> Nov 18 05:11:19.793108 (d2) stack: 0x972580-0x992580 >>>>>>>> Nov 18 05:11:19.801150 (d2) MM: Init >>>>>>>> Nov 18 05:11:19.801181 (d2) _text: 0x0(VA) >>>>>>>> Nov 18 05:11:19.801197 (d2) _etext: 0x7b22d(VA) >>>>>>>> Nov 18 05:11:19.809104 (d2) _erodata: 0xa4000(VA) >>>>>>>> Nov 18 05:11:19.809123 (d2) _edata: 0xa81a8(VA) >>>>>>>> Nov 18 05:11:19.809138 (d2) stack start: 0x972580(VA) >>>>>>>> Nov 18 05:11:19.817062 (d2) _end: 0x992b30(VA) >>>>>>>> Nov 18 05:11:19.817099 (d2) start_pfn: a24 >>>>>>>> Nov 18 05:11:19.817125 (d2) max_pfn: 20000 >>>>>>>> Nov 18 05:11:19.825037 (d2) Mapping memory range 0x1000000 - 0x20000000 >>>>>>>> Nov 18 05:11:19.825071 (d2) setting 0x0-0xa4000 readonly >>>>>>>> Nov 18 05:11:19.825100 (d2) skipped 1000 >>>>>>>> Nov 18 05:11:19.833049 (d2) MM: Initialise page allocator for >>>>>>>> b1c000(b1c000)-20000000(20000000) >>>>>>>> Nov 18 05:11:19.833089 (d2) Page fault at linear address c00008, eip >>>>>>>> 5fc70, regs 0x98ff28, sp b1c000, our_sp 0x98fefc, code 2 >>>>>>>> Nov 18 05:11:19.849044 (d2) Page fault in pagetable walk (access to >>>>>>>> invalid memory?). >>>>>>>> >>>>>>>> The pvgrub in used is 32 bit. 64 bit (which I myself tested) seemed to >>>>>>>> be working fine. >>>>>>> Okay, I'm hitting this issue, too. I'll investigate further. >>>>>> Do we want to revert $something in the meantime? If so, what... >>>>>> >>>>> The problem is really located in pvgrub: >>>> One question I have here: Even if this gets fixed in pvgrub (or >>>> mini-os, as it now seems), can we tolerate all existing mini-os >>>> clones now being broken on -unstable (and hence then also >>>> eventually on 4.7)? >>> It would be rather inconvenient if not. The problem is mini-os is >>> relying on an interface which was never meant to be this way. grub-xen >>> is already breaking this interface today, and I think this is okay. >>> >>> Is mini-os shipped independent of Xen in any other product or stand >>> alone? >> Rump kernel has quite a bit of code based on mini-os. I will take care >> of that. That's the only "real" thing based on mini-os that I'm aware >> of. >> >> Given that we split mini-os out just last release, I don't expect there >> are many clones in the wild. > Mirage microkernels use a mini-os base as well. > > Having said that, I don't think we should not block this change because > mini-os has been broken in a dumb way for ages. > > People using mini-os based things will have to take a "stable update" of > their mini-os to run on Xen 4.7 when it is release. Linux is treated > exactly the same with bugs like this. Apologies - too many negatives. "I don't think we should block this change". ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |