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 <phil@raspberrypi.com>
|
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 <phil@raspberrypi.com>
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 <phil@raspberrypi.com>
|
|
|
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 <phil@raspberrypi.com>
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 <phil@raspberrypi.com>
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 <phil@raspberrypi.com>
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 <phil@raspberrypi.com>
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 <phil@raspberrypi.com>
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 <phil@raspberrypi.com>
|
Thank You for the above information I was able to upgrade the Kernel to Version 6.6.75 using the command: I was looking at the commits from https://github.com/raspberrypi/firmware/commits, instead of the commits from https://github.com/raspberrypi/rpi-firmware/commits/master Over the next couple of days, I will upgrade the Kernel one version at a time. I will post the results here. Thank You, |
In order to avoid losing residue bytes when a receive is terminated early, set the destination width to single bytes. Link: #6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
In order to avoid losing residue bytes when a receive is terminated early, set the destination width to single bytes. Link: #6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
In order to avoid losing residue bytes when a receive is terminated early, set the destination width to single bytes. Link: #6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
In order to avoid losing residue bytes when a receive is terminated early, set the destination width to single bytes. Link: #6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
In order to avoid losing residue bytes when a receive is terminated early, set the destination width to single bytes. Link: #6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
|
Results of Testing Kernel one version at a time. Kernel 6.6.75 MeteoPI has no errors! I found the solution to prevent any errors from occurring with the MeteoPI was to remove the following line from /boot/firmware/config.txt dtparam=uart0_nodma then I no longer have any errors with the MeteoPI on the 6.12.20 Kernel! Thank You, |
i.e. You reverted
Yay, pleased to hear that! |
|
I Updated my Raspberry PI 5 using the following commands: The MeteoPI started producing errors again!
the command dma0 (1000010000.dma): number of channels: 5 dma1 (1000010600.dma): number of channels: 5 dma2 (1f00188000.dma): number of channels: 8 I ran the following command to switch to the 6.12.21 Kernel Version
Linux cumulusmxkitchen 6.12.21-v8-16k+ #1868 SMP PREEMPT Mon Mar 31 17:10:57 BST 2025 aarch64 GNU/Linux the command dma0 (1000010000.dma): number of channels: 5 dma1 (1000010600.dma): number of channels: 5 dma2 (1f00188000.dma): number of channels: 8 Below is the output for the Kernel Version 6.12.20 that works!
dma0 (1000010000.dma): number of channels: 5 dma1 (1000010600.dma): number of channels: 5 dma2 (1f00188000.dma): number of channels: 8
[ 0.000000] Kernel command line: reboot=w coherent_pool=1M 8250.nr_uarts=1 pci=pcie_bus_safe cgroup_disable=memory numa_policy=interleave numa=fake=8 system_heap.max_order=0 smsc95xx.macaddr=D8:3A:DD:BC:F2:62 vc_mem.mem_base=0x3fc00000 vc_mem.mem_size=0x40000000 root=PARTUUID=6f803e6a-02 rootfstype=ext4 fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles How do I re-enable DMA on the Kernel for Kernel Version 6.12.21 or later? |
It seems that some applications don't work with UART DMA enabled, while others don't work without it. No DMA seems to be the safer default choice, but add a dtparam - uart0_dma - to re-enable it. See: raspberrypi#6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
It seems that some applications don't work with UART DMA enabled, while others don't work without it. No DMA seems to be the safer default choice, but add a dtparam - uart0_dma - to re-enable it. See: raspberrypi#6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
|
There's a new PR giving the Pi 5 family a |
In order to avoid losing residue bytes when a receive is terminated early, set the destination width to single bytes. Link: #6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
In order to avoid losing residue bytes when a receive is terminated early, set the destination width to single bytes. Link: #6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
|
added then ran
Linux cumulusmxkitchen 6.12.25-v8-16k+ #1 SMP PREEMPT Tue May 6 13:42:48 UTC 2025 aarch64 GNU/Linux
dma0 (1000010000.dma): number of channels: 5 dma1 (1000010600.dma): number of channels: 5 dma2 (1f00188000.dma): number of channels: 8 There are no errors anymore with the MeteoPI ! Thank You, |
|
I'll get that merged, and it will become a standard feature. |
It seems that some applications don't work with UART DMA enabled, while others don't work without it. No DMA seems to be the safer default choice, but add a dtparam - uart0_dma - to re-enable it. See: #6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
It seems that some applications don't work with UART DMA enabled, while others don't work without it. No DMA seems to be the safer default choice, but add a dtparam - uart0_dma - to re-enable it. See: #6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
It seems that some applications don't work with UART DMA enabled, while others don't work without it. No DMA seems to be the safer default choice, but add a dtparam - uart0_dma - to re-enable it. See: #6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
|
I'm not sure if this issue will resolve the DMA problem that I've been facing.
|
|
There's a good chance that updating to the current kernel (6.12.25 or later) will get it working again. |
In order to avoid losing residue bytes when a receive is terminated early, set the destination width to single bytes. Link: #6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
It seems that some applications don't work with UART DMA enabled, while others don't work without it. No DMA seems to be the safer default choice, but add a dtparam - uart0_dma - to re-enable it. See: #6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
In order to avoid losing residue bytes when a receive is terminated early, set the destination width to single bytes. Link: #6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
It seems that some applications don't work with UART DMA enabled, while others don't work without it. No DMA seems to be the safer default choice, but add a dtparam - uart0_dma - to re-enable it. See: #6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
In order to avoid losing residue bytes when a receive is terminated early, set the destination width to single bytes. Link: #6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
It seems that some applications don't work with UART DMA enabled, while others don't work without it. No DMA seems to be the safer default choice, but add a dtparam - uart0_dma - to re-enable it. See: #6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
In order to avoid losing residue bytes when a receive is terminated early, set the destination width to single bytes. Link: #6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
It seems that some applications don't work with UART DMA enabled, while others don't work without it. No DMA seems to be the safer default choice, but add a dtparam - uart0_dma - to re-enable it. See: #6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
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: