Re: [MirageOS-devel] ANN: mirage.2.3.0 released

[Dave Scott <Dave.Scott@xxxxxxxxxx>]

> On 10 Mar 2015, at 14:17, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> 
> On 10 Mar 2015, at 14:01, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>> 
>> On 10 March 2015 at 13:46, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>>> I've just released Mirage 2.3.0 to OPAM.  This is a point release
>>> with several important cleanups in the interfaces:
>>> https://github.com/mirage/mirage/releases/tag/v2.3.0
>>> 
>>> * Remove the `IO_PAGE` module type from `V1`. This has now moved
>>> into the `io-page` pacakge (#356)
>>> * Remove `DEVICE.connect` from the `V1` module types.  When a module is
>>> functorised over a `DEVICE` it should only have the ability to
>>> *use* devices it is given, not to connect to new ones. (#150)
>>> * Add `FLOW.error_message` to the `V1` module types to allow for
>>> generic handling of errors. (#346)
>>> * Add `IP.uipaddr` as a universal IP address type. (#361)
>>> * Support the `entropy` version 0.2+ interfaces. (#359)
>>> * Check that the `opam` command is at least version 1.2.0 (#355)
>>> * Don't put '-classic-display' in the generated Makefiles. (#364)
>>> 
>>> Although this is a short changelog, the main changes that matter
>>> are the IO_PAGE and Device connect changes, which required
>>> revisions across a significant number of packages.  Many thanks to
>>> Thomas Leonard who did a lot of the legwork to propagate the
>>> required changes: https://github.com/mirage/mirage/pull/350
>> 
>> Great!
>> 
>>> The full set of libraries that have changed are up at:
>>> http://openmirage.org/releases/
>> 
>> openmirage.org isn't responding for me (even to pings).
> 
> Interesting -- we've uncovered a race condition in the Xen netback
> bringup with the new release.  Putting in a very small sleep in
> the Netfront initialisation is causing the dom0 bridge to unwedge
> and then work.  I'm investigating it, although I may need your
> assistance with this one Daveâ

Uh-oh! Does the bridge device and the vif device in dom0 look ok, and
do the xenstore backend and frontend directories both have âstate = 4â?
â I assume they all look right and the bug is more of a race between
the backend and frontend init code.

If I had to guess I would try inserting a xenstore wait here:

https://github.com/mirage/mirage-net-xen/blob/6369abd80904ca98194abc07e676ecdb0a371b3c/lib/netif.ml#L300

to wait for the backend to enter âstate = 4â before writing data to the
ring and signalling the event channel. Perhaps itâs wedged because the
event was ignored. A wait loop would look like this one:

https://github.com/mirage/mirage-block-xen/blob/a64d152586c7ebc1d23c5adaa4ddd440b45a3a83/lib/blkback.ml#L388

only with the condition being âstate = Device_state.(to_string Connected)"

Of course a xenstore wait might just be a workaround by causing a delay.
Perhaps we should read the Linux netback code to see what itâs doing.

Cheers,
Dave


> 
> -anil
> 
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel