[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Anil Madhavapeddy <anil@xxxxxxxxxx>
  • From: Dave Scott <Dave.Scott@xxxxxxxxxx>
  • Date: Tue, 10 Mar 2015 14:41:51 +0000
  • Accept-language: en-GB, en-US
  • Cc: mirageos-devel <mirageos-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 10 Mar 2015 14:42:02 +0000
  • List-id: Developer list for MirageOS <mirageos-devel.lists.xenproject.org>
  • Thread-index: AQHQWzi3ChBS8cIP+EOt/hU2T+qBfJ0VrhsAgAAEq4CAAAazgA==
  • Thread-topic: [MirageOS-devel] ANN: mirage.2.3.0 released

> 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:


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:


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.


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

MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.