Has the parity check got beyond the size of the biggest data drive?
Did you use the parity swap procedure to upgrade the parity drive?
If so it seems that the space beyond the largest drive is not always correctly zeroed on the new parity drive and you need to run a correcting check once to fix this - after that future checks should be error free. However I do not think that is your problem here
It looks as if there may be some other problem that needs looking at first as in your syslog there are continual
Sep 12 14:46:15 Excelsior kernel: sd 1:0:2:0: attempting task abort!scmd(0x000000001e0cffe4), outstanding for 30528 ms & timeout 30000 ms
Sep 12 14:46:15 Excelsior kernel: sd 1:0:2:0: [sdi] tag#2226 CDB: opcode=0x88 88 00 00 00 00 00 9c b9 b4 40 00 00 00 08 00 00
Sep 12 14:46:15 Excelsior kernel: scsi target1:0:2: handle(0x000b), sas_address(0x5000cca23c0d2c39), phy(2)
Sep 12 14:46:15 Excelsior kernel: scsi target1:0:2: enclosure logical id(0x500605b0098b8100), slot(3)
Sep 12 14:46:15 Excelsior kernel: sd 1:0:2:0: task abort: SUCCESS scmd(0x000000001e0cffe4)
type messages in the syslog (sdi appears to be disk5). These seem to have started on Sep 8 - did you do anything to the system then? Is there any indication in the GUI of possible problems with disk5?
I would suggest you
Cancel the current check as no point proceeding if there are underlying hardware issues.
Do NOT at this point attempt to run a correcting check as if you have a hardware issue you are more likely to end up corrupting parity
Carefully check all connections (power and SATA) to disk5). Perhaps when changing drives you slightly disturbed an existing connection or did not quite perfectly seat one.
Not sure if at that point you should retry the non-correcting check or do something else such as an extended test on disk5
You may want to wait to see if anyone else (in particular @JorgeB has any other suggestions.