-
Notifications
You must be signed in to change notification settings - Fork 15
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
kernel: Add a patch to fix an NPD when using the UART and a stuck irq #134
Conversation
This seems to solve part of the problem. The good thing is that the kernel errors seen when closing a $ dmesg -w
…
[ 68.147733] stm32-usart 4000f000.serial: Transmission is not complete
… in its place. But it gets worse when one tries to use the device again: $ dmesg -w
…
[ 78.434633] panel-mipi-dbi-spi spi2.0: SPI transfer timed out
[ 78.439387] spi_master spi2: failed to transfer one message from queue
[ 78.450284] spi_master spi2: noqueue transfer failed
[ 78.454254] panel-mipi-dbi-spi spi2.0: error -110 when sending command 0x2a
[ 78.461289] lmp92064 spi1.0: SPI transfer timed out
… followed by a watchdog induced reboot. To me this looks like e.g. lower-priority interrupts no longer being handled. |
What @hnez reports still sounds like the behavior I've observed. |
6608071
to
4385047
Compare
Closed by mistake, I think by accidentally pushing a wrong rev to my branch. Anyhow, now it should be right and fixed. |
I've tested this PR now and it looks like it fixes the issues we had. Nice to see this endeavour come to an end! Before we merge it however #136 should be merged first and this PR be rebased so that the version number consistency check does not throw errors. |
#136 has been merged. Please rebase. |
3961c07
to
5d4fc9a
Compare
I don't know what the version consistency check is about, but I rebased anyhow. |
When /dev/ttySTM1 is closed while there are still some characters pending to be sent, the kernel dereferences a null pointer which locks up the kernel. This is fixed by two patches cherry-picked from next. Another problem is that if the UART is closed while being throttled, the irq handler thinks it's still throttled after reopen which results in it not handling RX events resulting in a stuck irq starving the machine. This is fixed by two further patches. The first only improves the driver's behaviour generally on stuck irq, the second is the actual fix. Signed-off-by: Uwe Kleine-König <[email protected]>
5d4fc9a
to
bc2c396
Compare
(Pushed once more because I got the committer info wrong in the first force-push) |
It makes sure that we do not generate any images containing e.g. PS: I've accidentially pressed "Close with comment" instead of "Cancel". When I decided that I did not want to add this comment. As a result I've added the comment in a half-ready state and closed the PR, both of which I did not mean to do. Oh my. |
When /dev/ttySTM1 is closed while there are still some characters pending to be sent, the kernel dereferences a null pointer which locks up the kernel.
Fix that by picking a patch from today's linux-next.
While the commit log claims this indeed fixes the problem noticed by @SmithChart, this isn't tested yet.