[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] S3 crash with VTD Queue Invalidation enabled
>>> On 04.06.13 at 23:09, Ben Guthro <ben@xxxxxxxxxx> wrote: > On Tue, Jun 4, 2013 at 3:49 PM, Ben Guthro <ben@xxxxxxxxxx> wrote: >> On Tue, Jun 4, 2013 at 3:20 PM, Ben Guthro <ben@xxxxxxxxxx> wrote: >>> On Tue, Jun 4, 2013 at 10:01 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote: >>>>>>> On 04.06.13 at 14:25, Ben Guthro <ben@xxxxxxxxxx> wrote: >>>>> On Tue, Jun 4, 2013 at 4:54 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote: >>>>>> Is this perhaps having some similarity with >>>>>> http://lists.xen.org/archives/html/xen-devel/2013-04/msg00343.html? >>>>>> We're clearly running single-CPU only here and there... >>>>> >>>>> We certainly should be, as we have gone through the >>>>> disable_nonboot_cpus() by this point - and I can verify that from the >>>>> logs. >>>> >>>> I'm much more tending towards the connection here, noting that >>>> Andrew's original thread didn't really lead anywhere (i.e. we still >>>> don't know what the panic he saw was actually caused by). >>>> >>> >>> I'm starting to think you're on to something here. >> >> hmm - maybe not. >> I get the same crash with "maxcpus=1" >> >> >> >>> I've put a bunch of trace throughout the functions in qinval.c >>> >>> It seems that everything is functioning properly, up until we go >>> through the disable_nonboot_cpus() path. >>> Prior to this, I see the qinval.c functions being executed on all >>> cpus, and both drhd units >>> Afterward, it gets stuck in queue_invalidate_wait on the first drhd >>> unit.. and eventually panics. >>> >>> I'm not exactly sure what to make of this yet. > > querying status of the hardware all seems to be working correctly... > it just doesn't work with querying the QINVAL_STAT_DONE state, as far > as I can tell. > > Other register state is: > > (XEN) VER = 10 > (XEN) CAP = c0000020e60262 > (XEN) n_fault_reg = 1 > (XEN) fault_recording_offset = 200 > (XEN) fault_recording_reg_l = 0 > (XEN) fault_recording_reg_h = 0 > (XEN) ECAP = f0101a > (XEN) GCMD = 0 > (XEN) GSTS = c7000000 > (XEN) RTADDR = 137a31000 > (XEN) CCMD = 800000000000000 > (XEN) FSTS = 0 > (XEN) FECTL = 0 > (XEN) FEDATA = 4128 > (XEN) FEADDR = fee0000c > (XEN) FEUADDR = 0 > > (with code lifted from print_iommu_regs() ) > > > None of this looks suspicious to my untrained eye - but I'm including > it here in case someone else sees something I don't. Xiantao, you certainly will want to give some advice here. I won't be able to look into this more deeply right away. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |