Re: Reboot on *DOM0* while/after installing GPLPV drivers

["Mike C." <miguelmclara%gmail.com@localhost>]

On 10/23/13 12:07, Manuel Bouyer wrote:
> On Tue, Oct 22, 2013 at 01:23:45PM +0100, Mike C. wrote:
>> For the working FreeBSD guest:
>>
>>  vif = ""
>>      0 = ""
>>       backend = "/local/domain/0/backend/vif/35/0"
>>       backend-id = "0"
>>       state = "1"
>>       handle = "0"
>>       mac = "00:16:3e:04:a5:87"
>>
>> For the Windows Guest:
>>     vif = ""
>>      0 = ""
>>       backend = "/local/domain/0/backend/vif/1/0"
>>       backend-id = "0"
>>       state = "4"
>>       handle = "0"
>>       mac = "00:16:3e:52:3e:cf"
>>       tx-ring-ref = "771"
> 
> I guess it's the opposite:
(Yes you are correct, sorry)

> vif/35/0 is in state 1 "XenbusStateInitialising", while vif/1/0
> is in state 4 "XenbusStateConnected". A vif in state 1 can't be working.
> 
> The backend states are also interesting:
>      35 = ""
>       0 = ""
>        frontend = "/local/domain/35/device/vif/0"
>        frontend-id = "35"
>        online = "1"
>        state = "2"
>        script = "/etc/xen/scripts/vif-bridge"
>        mac = "00:16:3e:04:a5:87"
>        bridge = "bridge0"
>        handle = "0"
>        type = "vif_ioemu"
>        vifname = "xvif35i0"
>        feature-rx-copy = "1"
>        feature-rx-flip = "1"
>        hotplug-status = "connected"
> 
> So xenbackendd and vif script did do their job, as hotplug-status is
> "connected". But the backed is stuck to state 2 "XenbusStateInitWait".
> 
> When the backend is in XenbusStateInitWait, the frontend is supposed
> to continue setup. This includes writing to the xenstore's frontend
> area entries "tx-ring-ref", "rx-ring-ref", "event-channel" and some more
> optionnal entries, and then switch itself to "XenbusStateConnected".
> This will in turn cause the backend to look at the xenstore for
> the ring and event parameters and switch to XenbusStateConnected.
> 
> Here is appears that the frontend didn't switch to XenbusStateConnected,
> not did it publish its ring and event parameters ... the question is why,
> and I've no clues on how to debug a windows driver ...
> 

I see what you mean, interesting info about the states, and the
"workflow" of the backend/frontend.

As for windows debuging, all I know is that there are debug versions of
the drivers which should show more info.

I'm not sure where exactly but I'll try to find out more!


-- 
Melhores Cumprimentos // Best Regards
------------------------------------------------------------------------
Miguel Clara
*nix Sys Admin Freelance