So far I have only been able to experience this issue on my model 3 B+ board
i have not had this issue happen on any of my other boards (all single core models)
* My B+ (2014 model) will not do this even with 3 test scripts running
With the latest updates to the kernel I believe the probability of this has decreased, but it can still happen most notably when there are 2 test cases running on different GPIO pins (7, 8, and/or 9 for example)
I have managed to confirm this happens with both GPIO and wiringpi python libraries
The attached scripts do nothing but setup the GPIO pins over and over and verify that they are indeed setup properly and report any failures that are found and recursively try again till it passes reporting every failure along the way
* Only the python scripts try to correct the issue, while the shell scripts just roll with it
When running 2 scripts the issue usually shows up for me in a few minutes unless you run both as shell scripts.
pi@raspberrypi:~ $ uname -r 4.14.62-v7+ pi@raspberrypi:~ $ lsb_release -a No LSB modules are available. Distributor ID: Raspbian Description: Raspbian GNU/Linux 9.4 (stretch) Release: 9.4 Codename: stretch
Here is the thread I started when I first encountered this issue:
https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=212022
I also thought this was a kernel bug, but when using only the sysfs method i was not able to reproduce it
https://github.com/raspberrypi/linux/issues/2669
This attachment up a update to the 1st attachment, this one includes test scritps for the wiringpi library