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.
Regards,
Vicenç.
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-rockchip
