On Sat, Jul 29, 2017 at 04:37:40PM +0200, Tobias Nygren wrote:I found that for the network cards, the problem goes away if I sprinkle a memory barrier before bus_dmamap_load. (See attached patch.)This should happen in the bus_dmamap_sync() function. If a driver does not call that properly, the driver is buggy.Yes, and it does, but for some reason it is not sufficient. It's not an MI problem. It seems like tsunami core logic is the common denominator here.
Some additional information:The reported issues happen on both the DS20L machines and on the DS25 machine I have, which are very different machines. The processors aren't all that different, though - EV68AL in the DS20L and EV68CB in the DS25.
Since lots of issues seem to be related to heavy disk and network usage, I did some additional tests.
It seems that I can't find a pattern for when a boot will succeed or when it'll fail, but I'll deal with that issue separately.
Time is wildly off sometimes, by as much as 25%. Sometimes it's fine. Just like not knowing a pattern for whether the system boots properly, I don't know why this happens sometimes and not others.
I installed a PCI Intel gigabit card and use that for networking. When I do, the system runs without crashing, without network oddities and, apparently, without corrupting the disk. It also runs with both processors enabled.
My DS25 is a few thousand miles away and doesn't have a PCI ethernet card, so I won't get to test that soon, but for starters it looks as if the network issue is real.
Thanks! John