[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [win-pv-devel] Windows 10 domU hang on boot after pv drivers install if dom0 have old kernel (or specific 3.2 problem)
> -----Original Message----- > From: Fabio Fantoni [mailto:fabio.fantoni@xxxxxxx] > Sent: 09 November 2015 16:15 > To: Paul Durrant; win-pv-devel@xxxxxxxxxxxxxxxxxxxx > Subject: Re: Windows 10 domU hang on boot after pv drivers install if dom0 > have old kernel (or specific 3.2 problem) > > > > Il 09/11/2015 16:15, Fabio Fantoni ha scritto: > > Il 09/11/2015 15:42, Paul Durrant ha scritto: > >>> -----Original Message----- > >> [snip] > >>>>> I know since long time ago that winpv require xen>=4.5.0 and > upstream > >>>>> qemu>=1.6.1 > >>>>> Probably also backports of these xen patches are needed if xen<4.6 > >>>>> (based on critical problems had long time ago): > >>>>> - x86/hvm: add per-vcpu evtchn upcalls > >>>> There was a bug in XENBUS which would cause a boot-time hang if you > >>> were not running a Xen with this patch, but that was fixed by: > >>>> commit 021d1f91ff9c1c10fa59e6d4200628b9d0d37eab > >>>> Author: Paul Durrant <paul.durrant@xxxxxxxxxx> > >>>> Date: Thu Jul 2 10:23:26 2015 +0100 > >>>> > >>>> Fix fall-back to two-level EVTCHN ABI > >>>> > >>>> When the EVTCHN code attempts to acquire the FIFO ABI it may > >>>> fail to > >>> do > >>>> so because the version of Xen may not support it. In this > >>>> case the code > >>>> was issuing an EventChannelReset() which has the unfortunate > >>>> side > >>> effect of > >>>> killing any toolstack-created channels, such as the xenstored > >>>> channel. > >>>> > >>>> This patch moves the existent EvtchnFifoReset function into > >>>> the base > >>>> evtchn source module (since it's not ABI specific) and uses > >>>> that function > >>>> as the only mechanism of issuing an EventChannelReset() since it > >>> contains > >>>> code to preserve event channel bindings. (Prior to the move > >>>> it only > >>>> preserved the xenstore channel but this patch adds code to > >>>> preserve > >>> the > >>>> console event channel too, if it exists). > >>>> > >>>> Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx> > >>>> > >>>> ...which is in the staging-8.1 branch and hence will be in the 8.1 > >>>> release. > >>>> > >>>>> - x86/hvm: extend HVM cpuid leaf with vcpu id > >>>>> > >>>> This is not relied upon so you should be ok without it. > >>>> > >>>> Paul > >>> Thanks for your reply. > >>> Based on your reply with recent winpv builds don't require backport of > >>> these xen patches but only require xen>=4.5.0 and upstream > qemu>=1.6.1. > >>> > >>> About the problem reported in this mail that seems related to the > >>> kernel > >>> (the only different thing comparing with test server), what can you > >>> tell > >>> me about? > >>> > >> The other thing that comes to mind is this fix in xen-netback: > >> > >> commit 279f438e36c0a70b23b86d2090aeec50155034a9 > >> Author: Paul Durrant <Paul.Durrant@xxxxxxxxxx> > >> Date: Tue Sep 17 17:46:08 2013 +0100 > >> > >> xen-netback: Don't destroy the netdev until the vif is shut down > >> > >> Without this patch, if a frontend cycles through states Closing > >> and Closed (which Windows frontends need to do) then the netdev > >> will be destroyed and requires re-invocation of hotplug scripts > >> to restore state before the frontend can move to Connected. Thus > >> when udev is not in use the backend gets stuck in InitWait. > >> > >> With this patch, the netdev is left alone whilst the backend is > >> still online and is only de-registered and freed just prior to > >> destroying the vif (which is also nicely symmetrical with the > >> netdev allocation and registration being done during probe) so > >> no re-invocation of hotplug scripts is required. > >> > >> Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx> > >> Cc: David Vrabel <david.vrabel@xxxxxxxxxx> > >> Cc: Wei Liu <wei.liu2@xxxxxxxxxx> > >> Cc: Ian Campbell <ian.campbell@xxxxxxxxxx> > >> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> > >> Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx> > >> > >> As you can see, it's pretty old, but wheezy is older. > >> > >> Paul > > > > Big thanks for the reply. > > This patch is missed in 3.2 upstream and also in debian patches. > > I'll try rebuild with it ASAP for see if it solve the problem and > > backport request is needed (as 3.2 is an LTS) > > I tried to apply it to latest wheezy (3.2) but fails to apply and there > are fails in drivers/net/xen-netback/interface.c hunk #2, #3 and #4 for > parts missed or too different, same with latest upsteam (3.2.72). > I not understand how to adapt it safely :( Probably best just to use a newer kernel then. Paul > > Thanks for any reply and sorry for my bad english. _______________________________________________ win-pv-devel mailing list win-pv-devel@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |