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

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

Thanks for your continued work on this.
I hope to be able to spend some time on this over the upcoming Christmas break.

Let me know ASAP when the new GPLPV drivers are available and I can put them up 
on win-7, win-xp.

johnh...
________________________________________
From: Mike C. [miguelmclara%gmail.com@localhost]
Sent: Thursday, December 12, 2013 12:07 PM
To: John Hayward; Manuel Bouyer
Cc: port-xen%netbsd.org@localhost
Subject: Re: Reboot on *DOM0* while/after installing GPLPV drivers

I've been working with James Harper (the gplpv drivers dev) on this, or
better... he's been doing all the work!

We are still testing but It seems that he pretty much solved the problem!

Quoting his words:
"Looking in the backend source, netbsd definitely doesn't know about or
advertise support for gso, so it's a bug in my drivers that it is
enabled when the "feature-gso-tcpv4" doesn't even exist. Should be easy
to fix."

I found a similar problem with FreeBSD-10 Domu's, seems that the PV
drivers also expect TSO/GSO features are there, but they might not be,
depending on the Dom0 support.

I wonder though, and sorry if I'm about to say something ridiculous...
but could NetBSD Xen backhend be modified to advertise this? IIRC NetBSD
supports TSO right?
I'm also not sure if this would really mean any advantage?

Anyway back to the fix in GPLPV, I guess James will put the installers
online has soon as possible.

NOTE: he also fixed the xl core-dump problem, that I reported some time
ago too, if you have any interest in that please see:
http://mail-index.netbsd.org/port-xen/2013/12/10/msg008171.html
or
http://lists.xen.org/archives/html/xen-devel/2013-12/msg01414.html


Thanks

On 10/27/13 01:19, Mike C. wrote:
>
> On 10/25/13 15:47, John Hayward wrote:
>> 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.
>
> The version was 372 signed and I also trying some newer unsigned, this
> was around May/June and I don't see any newer builds except for XP, all
> worked on Debian and 372 signed is still working fine.
>
>>
>> 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
>>
>>
>
> --
> Melhores Cumprimentos // Best Regards
> ------------------------------------------------------------------------
> Miguel Clara
> *nix Sys Admin Freelance
>
>
>
> http://www.linkedin.com/in/miguelmclara/
> Mike_C_PT <https://twitter.com/Mike_C_PT>
> http://about.me/miguelmclara
> ------------------------------------------------------------------------

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



http://www.linkedin.com/in/miguelmclara/
Mike_C_PT <https://twitter.com/Mike_C_PT>
http://about.me/miguelmclara
------------------------------------------------------------------------