[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] possible I/O emulation state machine issue
>>> On 23.03.18 at 11:43, <Paul.Durrant@xxxxxxxxxx> wrote: >> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf >> Of Jan Beulich >> Sent: 23 March 2018 07:30 >> >> >>> On 22.03.18 at 16:29, <andrew.cooper3@xxxxxxxxxx> wrote: >> > On 22/03/18 15:12, Jan Beulich wrote: >> >> our PV driver person has found a reproducible crash with ws2k8, >> >> triggered by one of the WHQL tests. The guest get crashed because >> >> the re-issue check of an ioreq close to the top of hvmemul_do_io() >> >> fails. I've handed him a first debugging patch, output of which >> >> suggests that we're dealing with a completely new request, which >> >> in turn would mean that we've run into stale STATE_IORESP_READY >> >> state: >> >> >> >> (XEN) d2v3: t=0/1 a=3c4/fed000f0 s=2/4 c=1/1 d=0/1 f=0/0 p=0/0 >> > v=100/ffff831873f27a30 >> >> (XEN) ----[ Xen-4.10.0_15-0 x86_64 debug=n Tainted: C ]---- >> > >> > Irrespective of the issue at hand, can testing be tried with a debug >> > build to see if any of the assertions are hit? >> >> Nothing, unfortunately. But at least the stack trace can be relied >> upon this way. > > I'm assuming the debug line above is indicating the former emulation > before the '/' and the latter after? Yes (to clarify this is why I had included the patch as well). > In which case it looks like an MMIO to > the HPET (I think that's what's at 0xfed000f0) clashing with a port IO to the > graphics device. That's what I had concluded too. > So, why is the HPET emulation making it to QEMU? Are you > trying to run Windows with Xen's HPET emulation turned on? DYM "off"? In any event I don't think he's having any special settings in place, but I'll double check. Yet if there really was "hpet=0" in the guest config file, things should still work, shouldn't they? I'd rather take this as a hint that hpet_range() suddenly isn't reached anymore, perhaps because of some other address range getting inserted which supersedes the HPET one. In that context it may become relevant to mention that this happens when, in the course of the test, the LAN driver gets unloaded and then reloaded (i.e. it's the reload which triggers the issue). He's calling the test "AddressChange test", and now I start wondering whether this isn't a change of the NIC address, but a change of addresses within the MMIO window. I've asked for clarification of that as well. Supposedly all was fine with 4.9, but I'll also ask to make sure it really is. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |