[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |