On 22/07/2019 19:53, Vicente Bergas wrote:
On Monday, July 22, 2019 7:35:01 PM CEST, Robin Murphy wrote:
On 22/07/2019 18:05, Vicente Bergas wrote:
On Monday, July 22, 2019 4:54:41 PM CEST, Marc Zyngier wrote: ...
The obvious culprit would be DMA devices left running by the first
kernel scribbling over the second kernel's memory before it's had the
chance to reset them. Since boot-time memory allocation patterns tend
to be relatively repeatable for a given platform and kernel
configuration, "random" may well look a lot less random than you might
expect, and it wouldn't be unheard of for e.g. the second kernel to
mostly allocate its dentry cache from the same area the first kernel
was mostly putting a network Rx descriptor ring.
Robin.
Here is another attempted test: on the first kernel disable:
# CONFIG_ZONE_DMA32 is not set
# CONFIG_DMADEVICES is not set
# CONFIG_PL330_DMA is not set
that is, all i could disable matching CONFIG_*DMA*=y, which is not much.
Still enabled are:
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_DMA_SHARED_BUFFER=y
CONFIG_SCSI_DMA=y
CONFIG_IOMMU_DMA=y
CONFIG_HAS_DMA=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_DMA_DECLARE_COHERENT=y
CONFIG_ARCH_HAS_SETUP_DMA_OPS=y
CONFIG_ARCH_HAS_TEARDOWN_DMA_OPS=y
CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE=y
CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU=y
CONFIG_ARCH_HAS_DMA_PREP_COHERENT=y
CONFIG_ARCH_HAS_DMA_COHERENT_TO_PFN=y
CONFIG_ARCH_HAS_DMA_MMAP_PGPROT=y
CONFIG_DMA_REMAP=y
CONFIG_DMA_DIRECT_REMAP=y
Then the second kernel still fails with d_lookup errors.
Yeah, none of those configs are particularly relevant - I'm thinking
more about the drivers for ethernet, wifi, USB, PCI devices, and any
other peripherals which may be set up to make DMA accesses based on
external stimuli and don't get shut down cleanly by a kexec.
Robin.
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-rockchip
