[opensuse-arm] Upgrade of RPi3 to latest Tumbleweed shows a number of errors

older
[opensuse-arm] Raspberry Pi1 is...

Freek de Kruijf

3 Oct 2017 3 Oct '17

21:52

I used the image: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2017.09.09-Build3.11.raw.xz to initialize the SD card. After that, with some fiddling, I upgraded the system to Tumbleweed 20170920, including the kernel to 4.13.2-1. After the reboot I see the following error messages: sep 14 18:32:58 rpi3tum kernel: kvm [1]: Invalid trigger for IRQ4, assuming level low sep 14 18:32:58 rpi3tum kernel: OF: /soc/usb@7e980000: could not get #phy- cells for /phy and quite a lot of messages like: okt 03 23:42:29 rpi3tum kernel: bcm2835-dma 3f007000.dma: swiotlb buffer is full (sz: 221172 bytes) okt 03 23:42:29 rpi3tum kernel: bcm2835-dma 3f007000.dma: DMA: Out of SW-IOMMU space for 221172 bytes okt 03 23:42:29 rpi3tum kernel: mmcblk0: error -22 transferring data, sector 3465216, nr 1024, cmd response 0x900, card status 0xb00 okt 03 23:42:29 rpi3tum kernel: bcm2835-dma 3f007000.dma: swiotlb buffer is full (sz: 221172 bytes) -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Show replies by date

Alexander Graf

4 Oct 4 Oct

10:47

On 03.10.17 23:52, Freek de Kruijf wrote:

...

I used the image: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2017.09.09-Build3.11.raw.xz to initialize the SD card.

After that, with some fiddling, I upgraded the system to Tumbleweed 20170920, including the kernel to 4.13.2-1.

After the reboot I see the following error messages: sep 14 18:32:58 rpi3tum kernel: kvm [1]: Invalid trigger for IRQ4, assuming level low sep 14 18:32:58 rpi3tum kernel: OF: /soc/usb@7e980000: could not get #phy- cells for /phy

and quite a lot of messages like: okt 03 23:42:29 rpi3tum kernel: bcm2835-dma 3f007000.dma: swiotlb buffer is full (sz: 221172 bytes) okt 03 23:42:29 rpi3tum kernel: bcm2835-dma 3f007000.dma: DMA: Out of SW-IOMMU space for 221172 bytes okt 03 23:42:29 rpi3tum kernel: mmcblk0: error -22 transferring data, sector 3465216, nr 1024, cmd response 0x900, card status 0xb00 okt 03 23:42:29 rpi3tum kernel: bcm2835-dma 3f007000.dma: swiotlb buffer is full (sz: 221172 bytes)

Sounds like you're running out of swiotlb space during SD card DMA operations. I wonder what spills it? Maybe vc4? Can you try to allocate proper amounts of CMA memory with the cma= kernel command line parameter? Or maybe blacklist the vc4 kernel module? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Freek de Kruijf

13:37

Op woensdag 4 oktober 2017 12:47:35 CEST schreef Alexander Graf:

...

On 03.10.17 23:52, Freek de Kruijf wrote:

...
and quite a lot of messages like: okt 03 23:42:29 rpi3tum kernel: bcm2835-dma 3f007000.dma: swiotlb buffer is full (sz: 221172 bytes) okt 03 23:42:29 rpi3tum kernel: bcm2835-dma 3f007000.dma: DMA: Out of SW-IOMMU space for 221172 bytes okt 03 23:42:29 rpi3tum kernel: mmcblk0: error -22 transferring data, sector 3465216, nr 1024, cmd response 0x900, card status 0xb00 okt 03 23:42:29 rpi3tum kernel: bcm2835-dma 3f007000.dma: swiotlb buffer is full (sz: 221172 bytes)

Sounds like you're running out of swiotlb space during SD card DMA operations. I wonder what spills it? Maybe vc4?

Can you try to allocate proper amounts of CMA memory with the cma= kernel command line parameter? Or maybe blacklist the vc4 kernel module?

I can't find a module vc4 using: # lsmod | grep vc4 -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Freek de Kruijf

16:01

Op woensdag 4 oktober 2017 12:47:35 CEST schreef Alexander Graf:

...

Can you try to allocate proper amounts of CMA memory with the cma= kernel command line parameter?

In /boot/grub2/grub.cfg I see: linux /boot/Image-4.13.2-1-default root=UUID=d578a86e-c033-4290-8f9f- e9ddd2489659 root=/dev/disk/by-id/mmc-SD16G_ 0xda58f009-part2 disk=/dev/disk/by-id/mmc-SD16G_0xda58f009 resume=/dev/disk/ by-id/mmc-SD16G_0xda58f009-part3 quiet splash=silent ply mouth.enable=0 swiotlb=512,force cma=384M console=tty0 console=ttyS0,115200n8 quiet Should swiotbl=512 be larger? cma=384M seems large enough. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Alexander Graf

16:12

...

Am 04.10.2017 um 18:01 schrieb Freek de Kruijf :

Op woensdag 4 oktober 2017 12:47:35 CEST schreef Alexander Graf:

...
Can you try to allocate proper amounts of CMA memory with the cma= kernel command line parameter?

In /boot/grub2/grub.cfg I see:

linux /boot/Image-4.13.2-1-default root=UUID=d578a86e-c033-4290-8f9f- e9ddd2489659 root=/dev/disk/by-id/mmc-SD16G_ 0xda58f009-part2 disk=/dev/disk/by-id/mmc-SD16G_0xda58f009 resume=/dev/disk/ by-id/mmc-SD16G_0xda58f009-part3 quiet splash=silent ply mouth.enable=0 swiotlb=512,force cma=384M console=tty0 console=ttyS0,115200n8 quiet

Should swiotbl=512 be larger? cma=384M seems large enough.

Yeah, give that a try. swiotlb sizing is odd - it‘s in some multiple that I can never remember. 1k or so? Alex

...

-- fr.gr.

member openSUSE Freek de Kruijf

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Freek de Kruijf

21:14

Op woensdag 4 oktober 2017 18:12:53 CEST schreef Alexander Graf:

...

...
Am 04.10.2017 um 18:01 schrieb Freek de Kruijf :

Op woensdag 4 oktober 2017 12:47:35 CEST schreef Alexander Graf:

...
Can you try to allocate proper amounts of CMA memory with the cma= kernel command line parameter?

In /boot/grub2/grub.cfg I see:

linux /boot/Image-4.13.2-1-default root=UUID=d578a86e-c033-4290-8f9f- e9ddd2489659 root=/dev/disk/by-id/mmc-SD16G_ 0xda58f009-part2 disk=/dev/disk/by-id/mmc-SD16G_0xda58f009 resume=/dev/disk/ by-id/mmc-SD16G_0xda58f009-part3 quiet splash=silent ply mouth.enable=0 swiotlb=512,force cma=384M console=tty0 console=ttyS0,115200n8 quiet

Should swiotbl=512 be larger? cma=384M seems large enough.

Yeah, give that a try. swiotlb sizing is odd - it‘s in some multiple that I can never remember. 1k or so?

Alex

I found swiotbl=512 means 512 slabs of 128K memory, so this takes 64M, which is mentioned as the default value. I will try 768. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Freek de Kruijf

22:07

Op woensdag 4 oktober 2017 23:14:43 CEST schreef Freek de Kruijf:

...

Op woensdag 4 oktober 2017 18:12:53 CEST schreef Alexander Graf:

...
...
Am 04.10.2017 um 18:01 schrieb Freek de Kruijf :

Op woensdag 4 oktober 2017 12:47:35 CEST schreef Alexander Graf:

...
Can you try to allocate proper amounts of CMA memory with the cma= kernel command line parameter?

In /boot/grub2/grub.cfg I see:

linux /boot/Image-4.13.2-1-default root=UUID=d578a86e-c033-4290-8f9f- e9ddd2489659 root=/dev/disk/by-id/mmc-SD16G_ 0xda58f009-part2 disk=/dev/disk/by-id/mmc-SD16G_0xda58f009 resume=/dev/disk/ by-id/mmc-SD16G_0xda58f009-part3 quiet splash=silent ply mouth.enable=0 swiotlb=512,force cma=384M console=tty0 console=ttyS0,115200n8 quiet

Should swiotbl=512 be larger? cma=384M seems large enough.

Yeah, give that a try. swiotlb sizing is odd - it‘s in some multiple that I can never remember. 1k or so?

Alex

I found swiotbl=512 means 512 slabs of 128K memory, so this takes 64M, which is mentioned as the default value. I will try 768.

Did not help. Also changed cma=384M in cma=512M, did not help either. -- fr.gr. Freek de Kruijf member openSUSE -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

2457

Age (days ago)

2458

Last active (days ago)

List overview

Download

6 comments

2 participants

participants (2)

Alexander Graf
Freek de Kruijf