[PATCH] arm64: cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES)

Mark Rutland mark.rutland at arm.com
Fri Jun 4 03:01:14 PDT 2021


Hi Marek,

On Wed, Jun 02, 2021 at 04:09:19PM +0200, Marek Szyprowski wrote:
> On 02.06.2021 15:51, Mark Rutland wrote:
> > On Wed, Jun 02, 2021 at 03:25:41PM +0200, Marek Szyprowski wrote:
> >> On 27.05.2021 14:43, Will Deacon wrote:
> >> This patch landed in todays linux-next as commit 65688d2a05de ("arm64:
> >> cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES)"). It causes an
> >> issue on Raspberry Pi 3b board. System boots to userspace fine, but then
> >> it hangs somewhere during the init scripts after loading the modules. I
> >> didn't manage to track where it hangs yet though.
> > Ouch!
> >
> > I have a 3b in a drawer that I might be able to reproduce the issue
> > with; can you tell me how you're booting that kernel? e.g. which FW and
> > DT you're using?
> 
> I'm booting the kernel with the mainline dtb 
> (arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dtb) from the u-boot, 
> which downloads it via TFTP. I don't remember which firmware version is 
> there, but without raspberry specific tools (which I don't have deployed 
> there) it is hard to check that now.

Thanks, this was enough info to get started.

For comparison, I have a 3Bv1.2 board.

I grabbed the latest RPI firmware, built myself a v2021.07-rc3
rpi_3_defconfig u-boot, and got a kernel booting (off the SD card rather
than over the network).

For the kernel I'm testing commit 65688d2a05de; defconfig with DRM and
VC4 built-in, since passing modules around is painful in my setup.

> The rootfs is on SD card, the system is some older Debian release.

For comparison, I built myself a buildroot 2021.02.2 filesystem.

So far, booting up an running I'm not seeeing issues (and no complaints
from KASAN or similar), but I don't have a good way to stress the VC4
GPU, so I might not be triggering whatever's going wrong.

>From the log below I see the last message is about X sockets -- is the
lockup happening when the display manager starts?

Thanks,
Mark.

> Here is the last part of the boot 
> log if it helps:
> 
> [    7.906329] Freeing unused kernel memory: 8512K
> [    7.911793] Run /sbin/init as init process
> INIT: version 2.88 booting
> [info] Using makefile-style concurrent boot in runlevel S.
> ERROR: could not open /proc/stat: No such file or directory
> [....] Starting the hotplug events dispatcher: systemd-udevdstarting 
> version 236
> . ok
> [....] Synthesizing the initial hotplug events...[   13.641287] 
> bcm2835-rng 3f104000.rng: hwrng registered
> [   13.896575] i2c-bcm2835 3f805000.i2c: Could not read clock-frequency 
> property
> done.
> [   13.938691] debugfs: Directory '3f902000.hdmi' with parent 'vc4-hdmi' 
> already present!
> [   13.983716] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops)
> [   13.991816] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops)
> [   14.000945] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops)
> [   14.009644] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops)
> [   14.017547] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops)
> [   14.025780] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops)
> [   14.033995] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops)
> [   14.042196] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops)
> [....] Waiting for /dev to be fully populated...[   14.112812] [drm] 
> Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
> done.
> [ ok ] Activating swap...done.
> [....] Checking file systems...fsck from util-linux 2.29.2
> done.
> [ ok ] Cleaning up temporary files... /tmp.
> [ ok ] Mounting local filesystems...done.
> [ ok ] Activating swapfile swap...done.
> [ ok ] Cleaning up temporary files....
> [ ok ] Setting kernel variables...done.
> [ ok ] Configuring network interfaces...done.
> [ ok ] Starting RPC port mapper daemon: rpcbind.
> [ ok ] Cleaning up temporary files....
> [ ok ] Setting up ALSA...done.
> [ ok ] Setting up X socket directories... /tmp/.X11-unix /tmp/.ICE-unix.
> 
> Best regards
> 
> -- 
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
> 



More information about the linux-arm-kernel mailing list