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

[John Hayward <john.hayward%wheaton.edu@localhost>]

Hi - I'm also trying to get the debug drivers installed 
Mike, you indicated that for debian dom0 did not crash on the block devices - 
do you have data on the windows drivers for windows-7 on debian?  This might 
help to identify if the problem is with the windows driver or with NetBSD dom0.

johnh...
________________________________________
From: port-xen-owner%NetBSD.org@localhost [port-xen-owner%NetBSD.org@localhost] 
on behalf of Mike C. [miguelmclara%gmail.com@localhost]
Sent: Thursday, October 24, 2013 7:04 AM
To: Manuel Bouyer
Cc: port-xen%netbsd.org@localhost
Subject: Re: Reboot on *DOM0* while/after installing GPLPV drivers

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