13:59 <tomeu> lynxeye: I think the splits might just increase the probability of hitting some race

14:00 <tomeu> and regarding why it happens only when the parallel processes are starting up, could it be related to the powering on or the setting up of the MMU for each of these processes?

14:01 <tomeu> I'm going now through the logs and trying to find any commonalities between the runs that triggered the fault

14:01 <tomeu> btw, sometimes it's a "slave not present" fault, sometimes it's a "page not found" fault

14:05 <tomeu> of 61 runs that triggered this, I get this distribution among fault type and address:

14:05 <tomeu> 46 (page not present) addr 0xfae50000

14:05 <tomeu> 15 (slave not present) addr 0xfa3a7000

14:16 <lynxeye> tomeu: Are those valid addresses? I.e. are there buffers mapped at this location?

14:38 <tomeu> lynxeye: not starting at that location, but 0xfae4e000 is allocated, as well as 0xfae53000

14:39 <tomeu> guess I should check what is allocated there and with what sizes

14:40 <lynxeye> tomeu: if you capture a devcoredump of one of those failing runs, the BO map contained in the dump should tell you which BOs are currently mapped and their size

14:47 <tomeu> hmm, it's an output tensor in a NN job

14:57 <tomeu> that's 0xfae4e000-0xfae504c0

14:57 <tomeu> wonder if it can be significant that it seems to fault on a page boundary

14:57 <tomeu> 0xfae50000

14:58 <tomeu> that BO is allocated from 0xfae4e000 to 0xfae53000

15:33 <tomeu> I don't see anything wrong with the lifecycle of these BOs, so I will go back to checking for a race

15:43 <lynxeye> Hard to tell if this is simply just the first location in the output tensor that is touched by the NPU.