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

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

> On 10 Mar 2015, at 14:41, Dave Scott <Dave.Scott@xxxxxxxxxx> wrote:
> 
> 
>> 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.
> 

Indeed, Dave tracked this one down to the mirage-net-xen driver not
waiting for the backend to be fully ready.  I've merged and released
the fix in https://github.com/ocaml/opam-repository/pull/3709.

The live site is now running this, so please do let us know if anyone
sees any start-of-day packet loss with this version of the driver.

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