Pi 5 UARTs broken in 6.6.44 build of rpi-6.6.y. #6365
Comments
|
The current list of suspect commits is: I'll try and create a PR from the 6.6.44 build head (2806f39) but with those commits reverted. |
|
#6366 is the PR that will create the trial builds. After each update to it, wait about 45 minutes for the builds to complete then run |
|
Do you want to reconsider any of the above patches, @P33M? |
|
|
|
This might be the same bug - long TX bursts appear to drop data on Pi 5 - https://forums.raspberrypi.com/viewtopic.php?t=376532 |
|
With f3cb675 I see data loss at the end of transmission: (where 931a is the last byte, and everything before 9300 matches) I've updated #6366 to be top-of-tree rpi-6.6.y but with f3cb675 reverted. As before, wait about 45 minutes then run |
This reverts commit f3cb675. Data loss has been observed on the Pi's PL011 UARTs since f3cb675 was merged. The loss appears to be on reception, not transmission. Revert the commit as a workaroud and potential fix. Link: raspberrypi#6365 Link: raspberrypi#6144 (comment) Link: https://forums.raspberrypi.com/viewtopic.php?t=376532 Signed-off-by: Phil Elwell <[email protected]>
|
ran received the error "Invalid artifact specified. Response: 404." pi@cumulusmxkitchen:~ $ sudo rpi-update pulls/6366 gzip: stdin: unexpected end of file |
|
I thought this might happen. I updated the PR to include a merge-ready commit message, and you came online and tried to update in the interval while it was being rebuilt. It should be good now. |
|
ran the meteopi is not working! the command pi@cumulusmxkitchen:~ $ uname -a |
|
Did you reboot after the install? Yes - I can see that you did. There's another build with more reversions available via |
|
I ran The meteopi is now working! I would like to allow the meteopi to run overnight and check for any errors from the meteopi. Thank You! output from the command pi@cumulusmxkitchen:~ $ uname -a |
|
I just noticed when I ran the command [ 11.585942] pl011-axi 1f00030000.serial: unable to pause DMA transfer |
Some recent DMA changes have led to data loss in UART0 on Pi 5. It also seems that even prior to these changes there was a problem with aborted transfers. As this is the only RP1 UART configured for DMA, it is better to remove the DMA usage until it is shown to be reliable. Link: raspberrypi#6365 Signed-off-by: Phil Elwell <[email protected]>
Some recent DMA changes have led to data loss in UART0 on Pi 5. It also seems that even prior to these changes there was a problem with aborted transfers. As this is the only RP1 UART configured for DMA, it is better to remove the DMA usage until it is shown to be reliable. Link: #6365 Signed-off-by: Phil Elwell <[email protected]>
|
|
|
I let the meteopi run overnight, there were no errors! Its working as expected! Thank you again for your help! I will try Thanks, |
|
I ran the command The meteopi is working fine and the error "pl011-axi 1f00030000.serial: unable to pause DMA transfer" no longer appears in the output from pi@cumulusmxkitchen:~ $ uname -a Thank you again for your help! |
|
Thank you for reporting it - shipping that kernel in an image would have been embarrassing. |
In order to avoid losing residue bytes when a receive is terminated early, set the destination width to single bytes. Link: raspberrypi#6365 Signed-off-by: Phil Elwell <[email protected]>
Describe the bug
As detailed by @lgeitner in the thread starting at #6144 (comment), the MeteoPi application which requires UART access seems to be broken in the 6.6.44 build of rpi-6.6.y. It has also been shown to have worked in the 6.6.42 build. The corresponding source commits for those two builds are:
"kernel: Bump to 6.6.42" (1969fd7): bfbd468
"kernel: Bump to 6.6.44" (44a287f): 2806f39
Steps to reproduce the behaviour
Run MeteoPi. Other test cases have yet to be determined.
Device (s)
Raspberry Pi 5
System
Linux 6.6.44-v8-16k+ #1789 SMP PREEMPT Mon Aug 5 15:24:18 BST 2024 aarch64 GNU/LinuxLogs
N/A
Additional context
No response
The text was updated successfully, but these errors were encountered: