Re: [MirageOS-devel] wireshark capture of failed download from mirage-www on ARM

[David Scott <scott.dj@xxxxxxxxx>]

I think for the earlier bug of a non-aligned buffer, we should make this a fatal error and stop the program:

https://github.com/mirage/mirage-net-xen/issues/10

Maybe we can do something fancy with types later?

Regarding a feature flag: it's a bit tricky if the feature is a bug fix since the buggy netbacks don't advertise the fact that they're buggy. To be reliable you'd have to assume the worst: if there's no feature flag (i.e. on all current kernels) take the slow path and wait for the 'feature-has-bugfix' in a recent kernel to filter down into distributions :(

On Tue, Jul 22, 2014 at 1:17 PM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:

On 22 Jul 2014, at 02:01, Thomas Leonard <talex5@xxxxxxxxx> wrote:

> On 22 July 2014 09:14, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>> On 22 Jul 2014, at 01:10, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>>>
>>> I noticed I'm getting a lot of these in the dom0 log (dmsg):
>>>
>>> Jul 22 08:09:05 cubietruck kernel: [11892.128241]
>>> xen_add_phys_to_mach_entry: cannot add pfn=0x00079abe ->
>>> mfn=0x000bed87: pfn=0x000799a6 -> mfn=0x000bed87 already exists
>>> Jul 22 08:09:05 cubietruck kernel: [11892.128727]
>>> xen_add_mach_to_phys_entry: cannot add pfn=0x00079bcb ->
>>> mfn=0x000bed87: pfn=0x000799a6 -> mfn=0x000bed87 already exists
>>> Jul 22 08:09:05 cubietruck kernel: [11892.133264]
>>> xen_add_phys_to_mach_entry: cannot add pfn=0x00079b70 ->
>>> mfn=0x000bed87: pfn=0x00079bd7 -> mfn=0x000bed87 already exists
>>> Jul 22 08:09:09 cubietruck kernel: [11896.041106]
>>> xen_add_phys_to_mach_entry: cannot add pfn=0x0007999a ->
>>> mfn=0x000bed87: pfn=0x00079b2b -> mfn=0x000bed87 already exists
>>
>> That looks like this bug in Xen/ARM/netback:
>> http://lists.xenproject.org/archives/html/xen-users/2014-07/msg00067.html
>
> Aha! This seems to fix it (I can browse mirage-www without huge delays):
>
> diff --git a/lib/netif.ml b/lib/netif.ml
> index 4e02e5e..3cc7760 100644
> --- a/lib/netif.ml
> +++ b/lib/netif.ml
> @@ -455,7 +455,7 @@ let writev nf pages =
> Â Â Â Â Âlwt rest_th = xmit other_pages in
> Â Â Â Â Â(* All fragments are now written, we can now notify the backend *)
> Â Â Â Â ÂLwt_ring.Front.push nf.t.tx_client (notify nf.t);
> - Â Â Â Â return ()
> + Â Â Â Â join rest_th
> Â Â )
>
> let wait_for_plug nf =
>
> Not very efficient, but at least it works! Looks like the Xen people
> will fix it at some point.

That's going to serialize requests on the TX ring, isn't it? ÂMight
be worth making conditional via a feature flag if it's going to take
x86 transmit performance down.

-anil

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

--
Dave Scott

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