[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM0PR02MB4436C535FDD72EFE422D8B10BCB39@AM0PR02MB4436.eurprd02.prod.outlook.com>
Date: Tue, 21 Jun 2022 10:46:25 +0000
From: Peter Rosin <peda@...ntia.se>
To: "Tudor.Ambarus@...rochip.com" <Tudor.Ambarus@...rochip.com>,
"regressions@...mhuis.info" <regressions@...mhuis.info>,
"Nicolas.Ferre@...rochip.com" <Nicolas.Ferre@...rochip.com>,
"alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>
CC: Daniels Umanovskis <du@...ntia.se>,
"Patrice.Vilchez@...rochip.com" <Patrice.Vilchez@...rochip.com>,
"Cristian.Birsan@...rochip.com" <Cristian.Birsan@...rochip.com>,
"Ludovic.Desroches@...rochip.com" <Ludovic.Desroches@...rochip.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"saravanak@...gle.com" <saravanak@...gle.com>
Subject: RE: Regression: memory corruption on Atmel SAMA5D31
2022-06-20 at 16:22, Tudor.Ambarus@...rochip.com wrote:
>
>>
>> git@...hub.com:ambarus/linux-0day.git, branch dma-regression-hdmac-v5.18-rc7-4th-attempt
>>
>
> Hi, Peter,
>
> I've just forced pushed on this branch, I had a typo somewhere and with that fixed I could
> no longer reproduce the bug. Tested for ~20 minutes. Would you please test last 3 patches
> and tell me if you can still reproduce the bug?
Hi!
I rebased your patches onto my current branch which is v5.18.2 plus a few unrelated
changes (at least they are unrelated after removing the previous workaround to disable
nand-dma entirely).
The unrelated patches are two backports so that drivers recognize new compatibles [1][2],
which should be completely harmless, plus a couple of proposed fixes that happens to fix
eeprom issues with the at91 I2C driver from Codrin Ciubotariu [3].
On that kernel, I can still reproduce. It seems a bit harder to reproduce the problem now
though. If the system is otherwise idle, the sha256sum test did not reproduce in a run of
150+ attempts, but if I let the "real" application run while I do the test, I get a failure rate
of about 10%, see below. The real application burns some CPU (but not all of it) and
communicates with HW using I2C, native UARTs and two of the four USB-serial ports
(FTDI, with the latency set to 1ms as mentioned earlier), so I guess there is more DMA
pressure or something? There is a 100mbps network connection, but it was left "idle"
during this test.
Cheers,
Peter
$ dd if=/dev/urandom of=testfile bs=1024 count=40000
40000+0 records in
40000+0 records out
40960000 bytes (41 MB, 39 MiB) copied, 80.0485 s, 512 kB/s
$ while :; do cat testfile | sha256sum; done
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
a4850c1bb0226f14659035cdf1461c7df03d50bff8af560e3bd204942556b73f -
43c1941e15bd7e048e9d5f1d41ce67517cb6e59dae1d3af256d1507168100fcb -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
4a35af384455853a24b943ef94353663e8c22a9aa29d2e275194fd544d0b194a -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
f6710849b36e6954c26ff62cd974ecb082b93fa6e53ecf0aea7e0c93acc0a445 -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
2c2f4ac91f435439d2d640c34ee89b4d1ebf3adb8438efbf064a4139247241c5 -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
b93e0c56cfba75cb9e2b35ff6769abdb6c1a5d17cadc28cec1979188e044cf3d -
^C
[1] https://lore.kernel.org/linux-kernel/42db911c-5eba-0511-3e8c-8011a2a5b44a@axentia.se/
[2] https://lore.kernel.org/linux-kernel/ea4cd16b-4a04-8857-d08a-53be58b00d28@axentia.se/
[3] https://lore.kernel.org/linux-kernel/20220614101347.16910-1-codrin.ciubotariu@microchip.com/
Powered by blists - more mailing lists