-
Notifications
You must be signed in to change notification settings - Fork 5.2k
sc16is7xx transmit errors (tty buffer?) and spi (tpm-slb9670) issue on all versions with kernel above 5.4.83-v7+ #4711
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
ping |
I'm also having this. But I have another detail to add: My trial is perfectly working on RPi1 (CM):
And it never works on RPi3 (CM):
As you can see, I do have a 5.10.y kernel on RPi1 which works perfectly. So it might be kernel related, and it might be also related to architecture, or might be a 32/64-bit issue. |
ping |
UART drivers are meant to use the port spinlock within certain methods, to protect against reentrancy. The sc16is7xx driver does very little locking, presumably because when added it triggers "scheduling while atomic" errors. This is due to the use of mutexes within the regmap abstraction layer, and the mutex implementation's habit of sleeping the current thread while waiting for access. Unfortunately this lack of interlocking can lead to corruption of outbound data, which occurs when the buffer used for I2C transmission is used simultaneously by two threads - a work queue thread running sc16is7xx_tx_proc, and an IRQ thread in sc16is7xx_port_irq, both of which can call sc16is7xx_handle_tx. An earlier patch added efr_lock, a mutex that controls access to the EFR register. This mutex is already claimed in the IRQ handler, and all that is required is to claim the same mutex in sc16is7xx_tx_proc. See: #4885 Signed-off-by: Phil Elwell <[email protected]>
After Running the test
4711.log Thank you @pelwell ! |
Uh oh!
There was an error while loading. Please reload this page.
Describe the bug
Serial communication using sc16is7xx randomly fail to send data. Receiving doesn’t seems to be affected.
Issue appears with one port or more ports used in parallel but it does not seems related to the loading or amount of data transmitted.
Last working kernel version was
5.4.83-v7+
-Raspberry Pi reference 2021-06-15 -Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, bf8c9f53833016e1b9410d2eb3ed0149390975a7
.Rebuilding kernel
5.10.17-v7+
with sc16is7xx driver from5.4.83-v7+
commit5da6b1c079e6804a81e63ab8337224cbd2148c91
didn't solve the problem.In our program (not the linux-serial-test) we got randomly 4096 bytes in buffer and this was the reason to link the issue to the kernel tty.
Versions above
5.4.83-v7+
also have the #4228 issue.To reproduce
Raspberry Pi 3 Model B+
SD image: 2021-10-30-raspios-bullseye-armhf-lite.zip
Custom board witn 2 x SC16IS752 and tpm-slb9670 (@pelwell has one)
Set /boot/config.txt:
Set /boot/cmdline.txt:
Update system, enable I2C, SPI and autologin to console:
List serial ports available to check that sc16is752 is loaded:
ls /dev/ttyS*
Clone and build linux-serial-test:
Expected behaviour
All data sent (Tx) should be received (Rx) using a loopback cable or just conecting Rx to Tx of same port.
Actual behaviour


Some date is not transmitted so not received.
Using an ttyUSB0 is OK:

System
cat /etc/rpi-issue
)?vcgencmd version
)?uname -a
)?Linux raspberrypi 5.10.63-v7+ #1459 SMP Wed Oct 6 16:41:10 BST 2021 armv7l GNU/Linux
Additional context
Add any other relevant context for the problem.
sc16is752-i2c-01-02.zip
The text was updated successfully, but these errors were encountered: