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

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



On 21 Jul 2014, at 13:31, Dave Scott <Dave.Scott@xxxxxxxxxx> wrote:

> Perhaps to see whether “xen_mb” is working you could add a delay (via busy 
> loop?) in the ‘memory_barrier’ function (or thereabouts) in 
> shared-memory-ring. Assuming the writes are committed eventually (is that a 
> valid assumption?) then the busy loop would “fix it”. That would be fairly 
> good evidence that barriers are broken.

These memory barriers are effectively noops on x86 due to its memory model (but 
not on ARM), so I could believe that there's a bug here.  But it's odd that 
it's happening so often, as such a concurrency race should be much more 
sporadic.

It would be quite handy to have a low-level ring/grant unit test to rule out 
these sorts of bugs. Vchan doesn't quite count for this I guess, since there's 
no granting happening.  Does the same bug happen with blkfront?  That shares 
the same logic with netfront, so it'll at least isolate the checksumming code 
vs the Ring code.

-anil (unable to do any actual low-level debugging while on the road, so will 
stick to wise thought experiments)
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel


 


Rackspace

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