* FYI: imx-sdma firmware is not compatible with SLUB slab allocator
@ 2019-08-27 13:35 Jurgen Lambrecht
2019-08-27 15:04 ` Leonard Crestez
0 siblings, 1 reply; 16+ messages in thread
From: Jurgen Lambrecht @ 2019-08-27 13:35 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: linux-imx
Hi,
We are updating our kernel on our custom board with an iMX6UL from 3.14
to 4.19, and when loading linux-firmware/imx/sdma/sdma-imx6q.bin v3.5
the kernel hangs when booting, only "Starting kernel ..." is printed (by
uBoot I think).
When I remove the sdma bin (built-in the kernel via EXTRA_FIRMWARE),
then it boots.
I found that the slab allocator (menu config -> General setup -> Choose
SLAB allocator) is the culprit: when using imx_v6_v7_defconfig the
kernel boots, but not with our config (based on a tiny config I think).
And the config that makes the difference is the slab allocator: with
SLUB or SLAB the kernel (with sdma bin) boots, but not with SLOB.
I don't know how to force selecting SLUB in Kconfig when selecting
IMX_SDMA, but anyhow first this issue must be confirmed on other
processors from the iMX family.
Kind Regards,
Jürgen Lambrecht
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
2019-08-27 13:35 FYI: imx-sdma firmware is not compatible with SLUB slab allocator Jurgen Lambrecht
@ 2019-08-27 15:04 ` Leonard Crestez
2019-08-28 9:26 ` Jurgen Lambrecht
0 siblings, 1 reply; 16+ messages in thread
From: Leonard Crestez @ 2019-08-27 15:04 UTC (permalink / raw)
To: Jurgen Lambrecht; +Cc: Aisheng Dong, Robin Gong, dl-linux-imx, linux-arm-kernel
On 27.08.2019 16:35, Jurgen Lambrecht wrote:
> We are updating our kernel on our custom board with an iMX6UL from 3.14
> to 4.19, and when loading linux-firmware/imx/sdma/sdma-imx6q.bin v3.5
> the kernel hangs when booting, only "Starting kernel ..." is printed (by
> uBoot I think).
If you enable "earlycon" you should be able to see an useful error
message from crashes in early boot.
Enabling earlycon is board-specific: if you have a correct
/chosen/stdout-path reference in dts just adding "earlycon" to kernel
cmdline should work otherwise you can specify
earlycon=ec_imx6q,0x202000,115200 with the exact address depending on
which uart is console on your board.
> When I remove the sdma bin (built-in the kernel via EXTRA_FIRMWARE),
> then it boots.
>
> I found that the slab allocator (menu config -> General setup -> Choose
> SLAB allocator) is the culprit: when using imx_v6_v7_defconfig the
> kernel boots, but not with our config (based on a tiny config I think).
> And the config that makes the difference is the slab allocator: with
> SLUB or SLAB the kernel (with sdma bin) boots, but not with SLOB.
>
> I don't know how to force selecting SLUB in Kconfig when selecting
> IMX_SDMA, but anyhow first this issue must be confirmed on other
> processors from the iMX family.
If there's an incompatibility between SLOB and sdma then it's sounds
like a bug which should be fixed, not worked around via kconfig.
I tried to enable EXTRA_FIRMWARE on v4.19.68 and imx6ul-14x14-evk booted
worked fine for me with these changes:
diff --git arch/arm/configs/imx_v6_v7_defconfig
arch/arm/configs/imx_v6_v7_defconfig
index 7f524cee1357..cedd4d2e0e02 100644
--- arch/arm/configs/imx_v6_v7_defconfig
+++ arch/arm/configs/imx_v6_v7_defconfig
@@ -11,8 +11,8 @@ CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_EXPERT=y
CONFIG_PERF_EVENTS=y
-# CONFIG_SLUB_DEBUG is not set
# CONFIG_COMPAT_BRK is not set
+CONFIG_SLOB=y
CONFIG_ARCH_MULTI_V6=y
CONFIG_ARCH_MXC=y
CONFIG_MACH_MX31LILLY=y
@@ -90,6 +90,10 @@ CONFIG_RFKILL_INPUT=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_STANDALONE is not set
+CONFIG_EXTRA_FIRMWARE="imx/sdma/sdma-imx6q.bin"
+CONFIG_EXTRA_FIRMWARE_DIR="../linux-firmware"
+CONFIG_FW_LOADER_USER_HELPER=y
+CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
CONFIG_CMA_SIZE_MBYTES=64
CONFIG_IMX_WEIM=y
CONFIG_CONNECTOR=y
Please try to get a stack dump with earlycon.
--
Regards,
Leonard
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
2019-08-27 15:04 ` Leonard Crestez
@ 2019-08-28 9:26 ` Jurgen Lambrecht
2019-08-28 14:05 ` Robin Gong
0 siblings, 1 reply; 16+ messages in thread
From: Jurgen Lambrecht @ 2019-08-28 9:26 UTC (permalink / raw)
To: Leonard Crestez; +Cc: Aisheng Dong, Robin Gong, dl-linux-imx, linux-arm-kernel
On 8/27/19 5:04 PM, Leonard Crestez wrote:
> CAUTION: This Email originated from outside Televic. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> On 27.08.2019 16:35, Jurgen Lambrecht wrote:
>> We are updating our kernel on our custom board with an iMX6UL from 3.14
>> to 4.19, and when loading linux-firmware/imx/sdma/sdma-imx6q.bin v3.5
>> the kernel hangs when booting, only "Starting kernel ..." is printed (by
>> uBoot I think).
> If you enable "earlycon" you should be able to see an useful error
> message from crashes in early boot.
>
> Enabling earlycon is board-specific: if you have a correct
> /chosen/stdout-path reference in dts just adding "earlycon" to kernel
> cmdline should work otherwise you can specify
> earlycon=ec_imx6q,0x202000,115200 with the exact address depending on
> which uart is console on your board.
OK, thanks. First time I hear of earlycon.
But as I thought (because of logs with other kernel versions) the kernel
just hangs when loading the sdma driver.
Now it is v3.5, but I also tried v3.3 a few weeks ago.
This is the last kernel log (below the full log):
[ 2.312336] imx-sdma 20ec000.sdma: loaded firmware 3.5
About the DT config, I enabled sdma on all that I found: standard dtsi
only has sdma enabled for SAI. But the freescale 4.1 kernel has more: I
also enabled sdma for ecspi1 to ecspi4, uart1 to uart8.
But as a test I have also removed all sdma entries from DT, and still it
hangs.
With enabling I mean add 2 lines, e.g. for sai1 in imx6ul.dtsi:
dmas = <&sdma 35 24 0>, <&sdma 36 24 0>;
dma-names = "rx", "tx";
>
>> When I remove the sdma bin (built-in the kernel via EXTRA_FIRMWARE),
>> then it boots.
>>
>> I found that the slab allocator (menu config -> General setup -> Choose
>> SLAB allocator) is the culprit: when using imx_v6_v7_defconfig the
>> kernel boots, but not with our config (based on a tiny config I think).
>> And the config that makes the difference is the slab allocator: with
>> SLUB or SLAB the kernel (with sdma bin) boots, but not with SLOB.
>>
>> I don't know how to force selecting SLUB in Kconfig when selecting
>> IMX_SDMA, but anyhow first this issue must be confirmed on other
>> processors from the iMX family.
> If there's an incompatibility between SLOB and sdma then it's sounds
> like a bug which should be fixed, not worked around via kconfig.
I agree, but it is closed source, so nothing to do about it (except
mailing nxp).
That is why I posted this, to hope to get tips like yours.
>
> I tried to enable EXTRA_FIRMWARE on v4.19.68 and imx6ul-14x14-evk booted
> worked fine for me with these changes:
> diff --git arch/arm/configs/imx_v6_v7_defconfig
> arch/arm/configs/imx_v6_v7_defconfig
> index 7f524cee1357..cedd4d2e0e02 100644
> --- arch/arm/configs/imx_v6_v7_defconfig
> +++ arch/arm/configs/imx_v6_v7_defconfig
> @@ -11,8 +11,8 @@ CONFIG_RELAY=y
> CONFIG_BLK_DEV_INITRD=y
> CONFIG_EXPERT=y
> CONFIG_PERF_EVENTS=y
> -# CONFIG_SLUB_DEBUG is not set
> # CONFIG_COMPAT_BRK is not set
> +CONFIG_SLOB=y
> CONFIG_ARCH_MULTI_V6=y
> CONFIG_ARCH_MXC=y
> CONFIG_MACH_MX31LILLY=y
> @@ -90,6 +90,10 @@ CONFIG_RFKILL_INPUT=y
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> # CONFIG_STANDALONE is not set
> +CONFIG_EXTRA_FIRMWARE="imx/sdma/sdma-imx6q.bin"
> +CONFIG_EXTRA_FIRMWARE_DIR="../linux-firmware"
Can you please check your boot log if you see that line "imx-sdma
20ec000.sdma: loaded firmware 3.5" ? Else it is not loaded.
If you load the imx-sdma driver as a module I believe you have to put
the firmware sdma-imx6q.bin in the RFS on /lib/firmware/imx/sdma/
instead of building it into the kernel image.
> +CONFIG_FW_LOADER_USER_HELPER=y
> +CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
those are not really needed
> CONFIG_CMA_SIZE_MBYTES=64
> CONFIG_IMX_WEIM=y
> CONFIG_CONNECTOR=y
>
> Please try to get a stack dump with earlycon.
So no stack dump, it just hangs:
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.19.56-00374-gcda746ffc0d9-dirty
(lambrecht@jl-lx-tra) (gcc version 4.9.3 (GCC)) #25 Wed Aug 28 10:49:44
CEST 2019
[ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7),
cr=10c53c7d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[ 0.000000] OF: fdt: Machine model: iMX6ul 33.96.7949 (PEI-SP)
[ 0.000000] earlycon: ec_imx6q0 at MMIO 0x02020000 (options '')
[ 0.000000] bootconsole [ec_imx6q0] enabled
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] cma: Reserved 64 MiB at 0x9b400000
[ 0.000000] CPU: All CPU(s) started in SVC mode.
[ 0.000000] random: get_random_bytes called from
start_kernel+0x8c/0x47c with crng_init=0
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 130048
[ 0.000000] Kernel command line: version=DEV_33967972_1-04-01
console=ttymxc0,115200 ubi.mtd=0 root=ubi0:rootfsB rootfstype=ubifs
mtdparts=gpmi-nand:-(nandflash) earlycon
[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144
bytes)
[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072
bytes)
[ 0.000000] Memory: 434544K/524288K available (7168K kernel code,
558K rwdata, 2068K rodata, 1024K init, 7590K bss, 24208K reserved,
65536K cma-reserved, 0K highmem)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
[ 0.000000] vmalloc : 0xe0800000 - 0xff800000 ( 496 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xe0000000 ( 512 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0x(ptrval) - 0x(ptrval) (8160 kB)
[ 0.000000] .init : 0x(ptrval) - 0x(ptrval) (1024 kB)
[ 0.000000] .data : 0x(ptrval) - 0x(ptrval) ( 559 kB)
[ 0.000000] .bss : 0x(ptrval) - 0x(ptrval) (7591 kB)
[ 0.000000] Running RCU self tests
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] Switching to timer-based delay loop, resolution 41ns
[ 0.000020] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps
every 89478484971ns
[ 0.007848] clocksource: mxc_timer1: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 79635851949 ns
[ 0.019941] Console: colour dummy device 80x30
[ 0.021842] Lock dependency validator: Copyright (c) 2006 Red Hat,
Inc., Ingo Molnar
[ 0.029870] ... MAX_LOCKDEP_SUBCLASSES: 8
[ 0.033667] ... MAX_LOCK_DEPTH: 48
[ 0.037840] ... MAX_LOCKDEP_KEYS: 8191
[ 0.042288] ... CLASSHASH_SIZE: 4096
[ 0.046538] ... MAX_LOCKDEP_ENTRIES: 32768
[ 0.050975] ... MAX_LOCKDEP_CHAINS: 65536
[ 0.055500] ... CHAINHASH_SIZE: 32768
[ 0.059851] memory used by lock dependency info: 4655 kB
[ 0.065244] per task-struct memory footprint: 1536 bytes
[ 0.070822] Calibrating delay loop (skipped), value calculated using
timer frequency.. 48.00 BogoMIPS (lpj=240000)
[ 0.081099] pid_max: default: 32768 minimum: 301
[ 0.086321] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.092363] Mountpoint-cache hash table entries: 1024 (order: 0, 4096
bytes)
[ 0.104414] CPU: Testing write buffer coherency: ok
[ 0.112690] Setting up static identity map for 0x80100000 - 0x80100078
[ 0.123963] devtmpfs: initialized
[ 0.272880] VFP support v0.3: implementor 41 architecture 2 part 30
variant 7 rev 5
[ 0.281104] clocksource: jiffies: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.288416] futex hash table entries: 256 (order: 1, 11264 bytes)
[ 0.300366] pinctrl core: initialized pinctrl subsystem
[ 0.319160] NET: Registered protocol family 16
[ 0.333165] DMA: preallocated 256 KiB pool for atomic coherent
allocations
[ 0.355397] cpuidle: using governor menu
[ 0.436775] vdd3p0: supplied by regulator-dummy
[ 0.446444] cpu: supplied by regulator-dummy
[ 0.455657] vddsoc: supplied by regulator-dummy
[ 0.556952] No ATAGs?
[ 0.572146] imx6ul-pinctrl 20e0000.iomuxc: initialized IMX pinctrl driver
[ 0.908280] mxs-dma 1804000.dma-apbh: initialized
[ 0.945421] i2c i2c-2: IMX I2C adapter registered
[ 0.949403] i2c i2c-2: can't use DMA, using PIO instead.
[ 0.970338] i2c i2c-1: IMX I2C adapter registered
[ 0.972345] i2c i2c-1: can't use DMA, using PIO instead.
[ 0.991751] i2c i2c-0: IMX I2C adapter registered
[ 0.993758] i2c i2c-0: can't use DMA, using PIO instead.
[ 1.006680] i2c i2c-3: IMX I2C adapter registered
[ 1.008683] i2c i2c-3: can't use DMA, using PIO instead.
[ 1.015674] pps_core: LinuxPPS API ver. 1 registered
[ 1.018866] pps_core: Software ver. 5.3.6 - Copyright 2005-2007
Rodolfo Giometti <giometti@linux.it>
[ 1.028470] PTP clock support registered
[ 1.038288] Advanced Linux Sound Architecture Driver Initialized.
[ 1.058453] clocksource: Switched to clocksource mxc_timer1
[ 2.111494] NET: Registered protocol family 2
[ 2.120322] tcp_listen_portaddr_hash hash table entries: 256 (order:
1, 10240 bytes)
[ 2.125441] TCP established hash table entries: 4096 (order: 2, 16384
bytes)
[ 2.132796] TCP bind hash table entries: 4096 (order: 5, 147456 bytes)
[ 2.140593] TCP: Hash tables configured (established 4096 bind 4096)
[ 2.148435] UDP hash table entries: 256 (order: 2, 20480 bytes)
[ 2.152078] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[ 2.161791] NET: Registered protocol family 1
[ 2.173419] RPC: Registered named UNIX socket transport module.
[ 2.176626] RPC: Registered udp transport module.
[ 2.181521] RPC: Registered tcp transport module.
[ 2.186009] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 2.214905] workingset: timestamp_bits=30 max_order=17 bucket_order=0
[ 2.234013] NFS: Registering the id_resolver key type
[ 2.236776] Key type id_resolver registered
[ 2.240861] Key type id_legacy registered
[ 2.246822] fuse init (API version 7.27)
[ 2.289930] io scheduler noop registered (default)
[ 2.312336] imx-sdma 20ec000.sdma: loaded firmware 3.5
Kind regards,
Jürgen
>
> --
> Regards,
> Leonard
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
2019-08-28 9:26 ` Jurgen Lambrecht
@ 2019-08-28 14:05 ` Robin Gong
2019-08-29 6:23 ` Jurgen Lambrecht
0 siblings, 1 reply; 16+ messages in thread
From: Robin Gong @ 2019-08-28 14:05 UTC (permalink / raw)
To: Jurgen Lambrecht, Leonard Crestez
Cc: Aisheng Dong, dl-linux-imx, linux-arm-kernel
On 8/28/19 17:27, Jurgen Lambrecht wrote:
>
> On 8/27/19 5:04 PM, Leonard Crestez wrote:
> > CAUTION: This Email originated from outside Televic. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> >
> >
> > On 27.08.2019 16:35, Jurgen Lambrecht wrote:
> >> We are updating our kernel on our custom board with an iMX6UL from
> >> 3.14 to 4.19, and when loading linux-firmware/imx/sdma/sdma-imx6q.bin
> >> v3.5 the kernel hangs when booting, only "Starting kernel ..." is
> >> printed (by uBoot I think).
> > If you enable "earlycon" you should be able to see an useful error
> > message from crashes in early boot.
> >
> > Enabling earlycon is board-specific: if you have a correct
> > /chosen/stdout-path reference in dts just adding "earlycon" to kernel
> > cmdline should work otherwise you can specify
> > earlycon=ec_imx6q,0x202000,115200 with the exact address depending on
> > which uart is console on your board.
>
> OK, thanks. First time I hear of earlycon.
>
> But as I thought (because of logs with other kernel versions) the kernel just
> hangs when loading the sdma driver.
> Now it is v3.5, but I also tried v3.3 a few weeks ago.
>
> This is the last kernel log (below the full log):
>
> [ 2.312336] imx-sdma 20ec000.sdma: loaded firmware 3.5
>
> About the DT config, I enabled sdma on all that I found: standard dtsi only
> has sdma enabled for SAI. But the freescale 4.1 kernel has more: I also
> enabled sdma for ecspi1 to ecspi4, uart1 to uart8.
> But as a test I have also removed all sdma entries from DT, and still it hangs.
Could you help check if below commit in your side?
commit ebb853b1bd5f659b92c71dc6a9de44cfc37c78c0
Author: Lucas Stach <l.stach@pengutronix.de>
Date: Tue Nov 6 03:40:28 2018 +0000
Revert "dmaengine: imx-sdma: alloclate bd memory from dma pool"
This reverts commit fe5b85c656bc. The SDMA engine needs the descriptors to
be contiguous in memory. As the dma pool API is only able to provide a
single descriptor per alloc invocation there is no guarantee that multiple
descriptors satisfy this requirement. Also the code in question is broken
as it only allocates memory for a single descriptor, without looking at the
number of descriptors required for the transfer, leading to out-of-bounds
accesses when the descriptors are written.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
2019-08-28 14:05 ` Robin Gong
@ 2019-08-29 6:23 ` Jurgen Lambrecht
2019-09-03 5:57 ` Robin Gong
0 siblings, 1 reply; 16+ messages in thread
From: Jurgen Lambrecht @ 2019-08-29 6:23 UTC (permalink / raw)
To: Robin Gong, Leonard Crestez; +Cc: Aisheng Dong, dl-linux-imx, linux-arm-kernel
On 8/28/19 4:05 PM, Robin Gong wrote:
> Could you help check if below commit in your side?
> commit ebb853b1bd5f659b92c71dc6a9de44cfc37c78c0
> Author: Lucas Stach<l.stach@pengutronix.de>
> Date: Tue Nov 6 03:40:28 2018 +0000
yes, it's in.
Also the 2 follow-up commits of Lucas Stach:
9063f5a99ea76f85935e3e453422d15e7be89b9e and
374f384bc66f7a928f11eb20c0518f0f3fc1ffd6.
And that are the last commits on drivers/dma/imx-sdma.c for my
4.19.x+fslc branch. But I have already tried 5.1.x+fslc, and it also got
stuck.
Kind regards,
Jürgen
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
2019-08-29 6:23 ` Jurgen Lambrecht
@ 2019-09-03 5:57 ` Robin Gong
2019-09-03 14:32 ` Jurgen Lambrecht
0 siblings, 1 reply; 16+ messages in thread
From: Robin Gong @ 2019-09-03 5:57 UTC (permalink / raw)
To: Jurgen Lambrecht, Leonard Crestez
Cc: Aisheng Dong, dl-linux-imx, linux-arm-kernel
On 2019-8-29 14:24, Jurgen Lambrecht wrote:
> On 8/28/19 4:05 PM, Robin Gong wrote:
> > Could you help check if below commit in your side?
> > commit ebb853b1bd5f659b92c71dc6a9de44cfc37c78c0
> > Author: Lucas Stach<l.stach@pengutronix.de>
> > Date: Tue Nov 6 03:40:28 2018 +0000
>
> yes, it's in.
>
> Also the 2 follow-up commits of Lucas Stach:
> 9063f5a99ea76f85935e3e453422d15e7be89b9e and
> 374f384bc66f7a928f11eb20c0518f0f3fc1ffd6.
>
> And that are the last commits on drivers/dma/imx-sdma.c for my 4.19.x+fslc
> branch. But I have already tried 5.1.x+fslc, and it also got stuck.
Sorry, I can't reproduce your issue on Linux 5.3-rc6 with 'CONFIG_SLOB=y' and
SDMA firmware built in kernel, Could you have a try on our imx6ul-14x14-evk
board with Linux 5.3-rc6 directly(no any patch needed)?
root@imx6ul7d:~# dmesg | grep dma
[ 0.991928] mxs-dma 1804000.dma-apbh: initialized
[ 4.162199] imx-sdma 20ec000.sdma: loaded firmware 3.5
>
> Kind regards,
>
> Jürgen
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
2019-09-03 5:57 ` Robin Gong
@ 2019-09-03 14:32 ` Jurgen Lambrecht
2019-09-03 14:48 ` Leonard Crestez
2019-09-12 2:06 ` Robin Gong
0 siblings, 2 replies; 16+ messages in thread
From: Jurgen Lambrecht @ 2019-09-03 14:32 UTC (permalink / raw)
To: Robin Gong, Leonard Crestez; +Cc: Aisheng Dong, dl-linux-imx, linux-arm-kernel
On 9/3/19 7:57 AM, Robin Gong wrote:
> CAUTION: This Email originated from outside Televic. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> On 2019-8-29 14:24, Jurgen Lambrecht wrote:
>> On 8/28/19 4:05 PM, Robin Gong wrote:
>>> Could you help check if below commit in your side?
>>> commit ebb853b1bd5f659b92c71dc6a9de44cfc37c78c0
>>> Author: Lucas Stach<l.stach@pengutronix.de>
>>> Date: Tue Nov 6 03:40:28 2018 +0000
>> yes, it's in.
>>
>> Also the 2 follow-up commits of Lucas Stach:
>> 9063f5a99ea76f85935e3e453422d15e7be89b9e and
>> 374f384bc66f7a928f11eb20c0518f0f3fc1ffd6.
I had also already cherry picked your commit
3f5de4c7e16164a344a905649f08e8a90a68ff9f "dmaengine: imx-sdma: remove
BD_INTR for channel0".
But also then kernel hangs at loading sdma FW.
(this looked the most interesting commit)
>>
>> And that are the last commits on drivers/dma/imx-sdma.c for my 4.19.x+fslc
>> branch. But I have already tried 5.1.x+fslc, and it also got stuck.
> Sorry, I can't reproduce your issue on Linux 5.3-rc6 with 'CONFIG_SLOB=y' and
> SDMA firmware built in kernel, Could you have a try on our imx6ul-14x14-evk
> board with Linux 5.3-rc6 directly(no any patch needed)?
This works on our own board (with imx6ul)!
Thanks,
Jürgen
> root@imx6ul7d:~# dmesg | grep dma
> [ 0.991928] mxs-dma 1804000.dma-apbh: initialized
> [ 4.162199] imx-sdma 20ec000.sdma: loaded firmware 3.5
>> Kind regards,
>>
>> Jürgen
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
2019-09-03 14:32 ` Jurgen Lambrecht
@ 2019-09-03 14:48 ` Leonard Crestez
2019-09-04 14:26 ` Jurgen Lambrecht
2019-09-12 2:06 ` Robin Gong
1 sibling, 1 reply; 16+ messages in thread
From: Leonard Crestez @ 2019-09-03 14:48 UTC (permalink / raw)
To: Jurgen Lambrecht, Robin Gong
Cc: Aisheng Dong, Fabio Estevam, dl-linux-imx, linux-arm-kernel
On 03.09.2019 17:32, Jurgen Lambrecht wrote:
> On 9/3/19 7:57 AM, Robin Gong wrote:
>
>>> And that are the last commits on drivers/dma/imx-sdma.c for my 4.19.x+fslc
>>> branch. But I have already tried 5.1.x+fslc, and it also got stuck.
>> Sorry, I can't reproduce your issue on Linux 5.3-rc6 with 'CONFIG_SLOB=y' and
>> SDMA firmware built in kernel, Could you have a try on our imx6ul-14x14-evk
>> board with Linux 5.3-rc6 directly(no any patch needed)?
>
> This works on our own board (with imx6ul)!
Something seems to be wrong with the fslc tree, using 5.1.x+fslc at
latest commit cd1d083333e76e03d16f015c23f1f1b8c8637381 I can reproduce
the issue on imx6ul-14x14-evk board.
Running without SLOB and builtin firmware it's fine.
I couldn't reproduce with latest 4.19.x+fslc (currently at commit
91d5756ab9096bbec256115d1d6b85f5d7139f85), maybe some additional SDMA
patches were applied which fixed this issue?
--
Regards,
Leonard
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
2019-09-03 14:48 ` Leonard Crestez
@ 2019-09-04 14:26 ` Jurgen Lambrecht
2019-09-12 6:33 ` Uwe Kleine-König
0 siblings, 1 reply; 16+ messages in thread
From: Jurgen Lambrecht @ 2019-09-04 14:26 UTC (permalink / raw)
To: Leonard Crestez, Robin Gong
Cc: Aisheng Dong, Fabio Estevam, dl-linux-imx, linux-arm-kernel, thesven73
On 9/3/19 4:48 PM, Leonard Crestez wrote:
> CAUTION: This Email originated from outside Televic. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> On 03.09.2019 17:32, Jurgen Lambrecht wrote:
>> On 9/3/19 7:57 AM, Robin Gong wrote:
>>
>>>> And that are the last commits on drivers/dma/imx-sdma.c for my 4.19.x+fslc
>>>> branch. But I have already tried 5.1.x+fslc, and it also got stuck.
>>> Sorry, I can't reproduce your issue on Linux 5.3-rc6 with 'CONFIG_SLOB=y' and
>>> SDMA firmware built in kernel, Could you have a try on our imx6ul-14x14-evk
>>> board with Linux 5.3-rc6 directly(no any patch needed)?
>> This works on our own board (with imx6ul)!
> Something seems to be wrong with the fslc tree, using 5.1.x+fslc at
> latest commit cd1d083333e76e03d16f015c23f1f1b8c8637381 I can reproduce
> the issue on imx6ul-14x14-evk board.
>
> Running without SLOB and builtin firmware it's fine.
>
> I couldn't reproduce with latest 4.19.x+fslc (currently at commit
> 91d5756ab9096bbec256115d1d6b85f5d7139f85), maybe some additional SDMA
> patches were applied which fixed this issue?
My 4.19.x+fslc was a 4.19.56 (cda746ffc).
Now I updated to your version 4.19.66, and it does not hang anymore, but
I get a *kernel panic* (oops) (so with sdma FW and with the SLOB
allocator). Also when I remove earlycon and update the dts not to enable
sdma on the uart, it still panics. Also with our patches on top kernel
panics. To be completely sure, I compiled 4.19.66+fslc (so
91d5756ab9096bbec256115d1d6b85f5d7139f85) with imx_v6_v7_defconfig
(instead of our minimal defconfig) and then it panics half of the time
(see below).
With SLUB, it works. And with SLOB without sdma it also works!
Here the kernel panic log:
[ 0.971298] io scheduler noop registered (default)
[ 1.045927] imx-sdma 20ec000.sdma: loaded firmware 3.5
[ 1.060382] console [ttymxc0] enabled
[ 1.064199] bootconsole [ec_imx6q0] disabled
[ 1.104663] Unable to handle kernel paging request at virtual address
ffffffe8
[ 1.112035] pgd = (ptrval)
[ 1.114772] [ffffffe8] *pgd=9ffff841, *pte=00000000, *ppte=00000000
[ 1.121138] Internal error: Oops: 27 [#1] PREEMPT ARM
[ 1.126212] Modules linked in:
[ 1.129305] CPU: 0 PID: 1 Comm: swapper Not tainted
4.19.66-televic-rail-33.97.1802-00072-g39a835ebea4c #2
[ 1.138979] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
[ 1.145197] PC is at alloc_vmap_area+0x140/0x3ec
[ 1.149836] LR is at 0x1000
[ 1.152650] pc : [<c01cc150>] lr : [<00001000>] psr: 00000053
[ 1.158937] sp : df055cb0 ip : 00009000 fp : ff800000
[ 1.164183] r10: 00000001 r9 : c0a74204 r8 : 00000001
[ 1.169430] r7 : c0a74204 r6 : ffffffff r5 : 00000001 r4 : 00009000
[ 1.175980] r3 : 00000000 r2 : 00000000 r1 : c0a11df0 r0 : e0876000
[ 1.182533] Flags: nzcv IRQs on FIQs off Mode SVC_32 ISA ARM
Segment none
[ 1.189778] Control: 10c53c7d Table: 80004059 DAC: 00000051
[ 1.195546] Process swapper (pid: 1, stack limit = 0x(ptrval))
[ 1.201399] Stack: (0xdf055cb0 to 0xdf056000)
[ 1.205785] 5ca0: e0800000
00000000 e0809000 e0800000
[ 1.213993] 5cc0: 00000000 df2ed640 df2d4d80 b65d4d11 ffffffff
00009000 df2ed5c0 00000022
[ 1.222202] 5ce0: 006080c0 00000001 e0800000 c0a03048 df2d4d80
c01cc490 ffffffff 006080c0
[ 1.230412] 5d00: df2c1980 00008000 ffffffff ffffffff 006080c0
df2d4d80 00000001 c01cd870
[ 1.238621] 5d20: ff800000 ffffffff 006080c0 c0382754 c0a12028
c0382754 ffffffff 00000000
[ 1.246829] 5d40: df2c1940 df2d4d80 00000001 c01cda50 006080c0
0000024f 00000000 ffffffff
[ 1.255038] 5d60: c0382754 00000000 df2c1940 df2ed540 00000100
c01cdb1c ffffffff c0382754
[ 1.263247] 5d80: df2d4d80 c0382754 df2d4d80 df2c1940 00000000
df2d4d90 00000000 c03808d4
[ 1.271457] 5da0: df2c1940 c037f4f0 c037f514 df2ec640 00000000
c037f520 df2c1940 df2d4d80
[ 1.279666] 5dc0: c0a12030 c037d7d4 006000c0 00100000 00000013
c05ee130 00000200 df2c1940
[ 1.287875] 5de0: 00000000 00000000 df2d4d90 00000000 00000001
c0a03048 df2d4d80 c02131cc
[ 1.296082] 5e00: 00000000 c01f5640 00000000 b65d4d11 00000000
00000000 df2d4d80 c0a03048
[ 1.304290] 5e20: 00000001 00000000 df2c194c 00000001 df2d4d80
c02134a8 df2d4e70 00000001
[ 1.312498] 5e40: 00000000 b65d4d11 c09005a4 c01f4bb8 df2d4df8
c02129a4 df2c19b0 b65d4d11
[ 1.320707] 5e60: df2c1980 df2c1940 00000000 c0a03048 00000001
df2c19b0 df2c194c 00000001
[ 1.328915] 5e80: df2d4d80 c037f138 c037d7d4 c037f514 df2c1940
c0a1cd48 00100000 c05fcbcc
[ 1.337124] 5ea0: 0000000d df29f5f0 c09005a4 b65d4d11 df29d740
df2c3cc0 c0a1cd48 c0a1cd48
[ 1.345333] 5ec0: c0a1cd4c 00000000 c0a1cd4c c0a1cd48 c09005a4
c091b158 c091ac58 00000000
[ 1.353542] 5ee0: c0a2b080 00000006 c0a03048 c091b0a8 00000000
c0929830 c0929838 c0102658
[ 1.361751] 5f00: 00000000 00000084 00000084 dfbea400 00000065
c081f5e4 00000084 c013845c
[ 1.369959] 5f20: c081eba8 00000000 c09005a4 00000000 00000006
00000006 00000000 dfbea401
[ 1.378168] 5f40: 00000000 b65d4d11 00000000 b65d4d11 c0934f90
00000006 c0a2b080 00000084
[ 1.386376] 5f60: c0a2b080 c0929838 c09005a4 c0900dbc 00000006
00000006 00000000 c09005a4
[ 1.394584] 5f80: c05fd99c 00000000 c05fd99c 00000000 00000000
00000000 00000000 00000000
[ 1.402792] 5fa0: 00000000 c05fd9a4 00000000 c01010e8 00000000
00000000 00000000 00000000
[ 1.410998] 5fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 1.419205] 5fe0: 00000000 00000000 00000000 00000000 00000013
00000000 00000000 00000000
[ 1.427434] [<c01cc150>] (alloc_vmap_area) from [<c01cc490>]
(__get_vm_area_node+0x94/0x168)
[ 1.435917] [<c01cc490>] (__get_vm_area_node) from [<c01cd870>]
(__vmalloc_node_range+0x58/0x1f4)
[ 1.444825] [<c01cd870>] (__vmalloc_node_range) from [<c01cda50>]
(__vmalloc_node+0x44/0x54)
[ 1.453300] [<c01cda50>] (__vmalloc_node) from [<c01cdb1c>]
(vzalloc+0x2c/0x3c)
[ 1.460652] [<c01cdb1c>] (vzalloc) from [<c0382754>]
(check_partition+0x38/0x1d4)
[ 1.468177] [<c0382754>] (check_partition) from [<c03808d4>]
(rescan_partitions+0x78/0x440)
[ 1.476567] [<c03808d4>] (rescan_partitions) from [<c02131cc>]
(__blkdev_get+0x25c/0x414)
[ 1.484779] [<c02131cc>] (__blkdev_get) from [<c02134a8>]
(blkdev_get+0x124/0x3e8)
[ 1.492385] [<c02134a8>] (blkdev_get) from [<c037f138>]
(__device_add_disk+0x404/0x4b8)
[ 1.500432] [<c037f138>] (__device_add_disk) from [<c091b158>]
(brd_init+0xb0/0x170)
[ 1.508218] [<c091b158>] (brd_init) from [<c0102658>]
(do_one_initcall+0x48/0x1a0)
[ 1.515833] [<c0102658>] (do_one_initcall) from [<c0900dbc>]
(kernel_init_freeable+0x100/0x1c8)
[ 1.524579] [<c0900dbc>] (kernel_init_freeable) from [<c05fd9a4>]
(kernel_init+0x8/0x11c)
[ 1.532796] [<c05fd9a4>] (kernel_init) from [<c01010e8>]
(ret_from_fork+0x14/0x2c)
[ 1.540386] Exception stack(0xdf055fb0 to 0xdf055ff8)
[ 1.545463] 5fa0: 00000000
00000000 00000000 00000000
[ 1.553671] 5fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 1.561875] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 1.568522] Code: e5922018 e59f129c e1520001 0a00002f (e5121018)
[ 1.574733] ---[ end trace abfef683febb0cb6 ]---
[ 1.579384] Kernel panic - not syncing: Fatal exception
[ 1.584640] Rebooting in 180 seconds..
I checked the patches on drivers/dma/imx-sdma.c and "dmaengine:
imx-sdma: fix use-after-free on probe error path"
09593c25b975458025fd4cd15d5861cbaa33683d seems to describe the issue....
but not solving it for me. So that is why I put Sven in CC.
Also with 4.19.56 with our own patches on top, the kernel did not hang,
but panicked. It looks like a timing problem inside the sdma driver.
Because kernel did not crash always, sometimes it did boot. Also now,
but only with 4.19.66+fslc with imx_v6_v7_defconfig it booted the first
time correctly, after a reboot it panicked very late, I even got a login
console, but then it rebooted again, but again good. Here the log:
[ 49.763843] Unable to handle kernel paging request at virtual address
a72e118d
[ 49.772789] pgd = b60d9f54
[ 49.775817] [a72e118d] *pgd=00000000
[ 49.779501] Internal error: Oops: 5 [#1] SMP ARM
[ 49.784152] Modules linked in:
[ 49.787259] CPU: 0 PID: 455 Comm: ntpd Not tainted
4.19.66-00020-g91d5756ab909 #3
[ 49.794770] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
[ 49.800991] PC is at find_entry+0x5c/0xc4
[ 49.805032] LR is at find_entry+0x88/0xc4
[ 49.809073] pc : [<c03090fc>] lr : [<c0309128>] psr: a0070013
[ 49.815365] sp : d96c9d40 ip : e9cb8463 fp : d96c9d74
[ 49.820616] r10: 00000001 r9 : 00000002 r8 : d8864040
[ 49.825870] r7 : d88640bc r6 : c0e70108 r5 : d96c48fc r4 : 0000000b
[ 49.832425] r3 : 0000006e r2 : 00000009 r1 : c0e70108 r0 : ffffffff
[ 49.838982] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment none
[ 49.846146] Control: 10c5387d Table: 996cc06a DAC: 00000051
[ 49.851924] Process ntpd (pid: 455, stack limit = 0x873acf61)
[ 49.857699] Stack: (0xd96c9d40 to 0xd96ca000)
[ 49.862095] 9d40: d96c9d74 d96c9d88 c0ba1030 c1132fb4 0000000b
d8090040 d96c48c0 c1108908
[ 49.870308] 9d60: d90f44d8 00000000 d96c9dbc d96c9d78 c030a94c
c03090ac c02a2d04 d96c48fc
[ 49.878519] 9d80: 00000001 00000000 c0294844 7d9fdb21 d96c9dbc
00000000 d90f0f18 00000000
[ 49.886732] 9da0: d96c9e90 d96c9f50 d96c48c0 d96c48c0 d96c9e8c
d96c9dc0 c0294ff4 c030a8e4
[ 49.894945] 9dc0: d96c9e7c d96c9dd0 c017eb8c c017e028 d96c48c0
00000000 00000000 00000000
[ 49.903157] 9de0: d90f44d8 00000041 00000000 d96c2140 00000004
00000000 00000000 c1748cc0
[ 49.911370] 9e00: 00000000 d96ae4f0 6ca44a47 00000000 dead4ead
ffffffff ffffffff c193441c
[ 49.919581] 9e20: 00000000 00000000 c0e795c8 d96c9e2c d96c9e2c
00000000 dead4ead ffffffff
[ 49.927794] 9e40: ffffffff c193441c 00000000 00000000 c0e795c8
d96c9e2c d96c9e2c 7d9fdb21
[ 49.936006] 9e60: 00000000 00000003 d96c9f50 d96c9e90 c1108908
00000001 d96c8000 00000142
[ 49.944219] 9e80: d96c9f44 d96c9e90 c02966e4 c02942a8 d8f0ad10
d90f0f18 04ff40f7 0000000b
[ 49.952433] 9ea0: d96dd021 60070013 d8e9d3d0 d8ed0960 d90f44d8
00000101 c030ac14 0000005c
[ 49.960645] 9ec0: 00000000 00000000 00000000 d96c9ed0 d96c9ef4
d96c9ee0 c0ba1258 c0184904
[ 49.968856] 9ee0: 00000000 d96acd24 d96c9f34 d96c9ef8 c02a80d4
c0ba123c d96c9f34 00000000
[ 49.977069] 9f00: d96dd000 00000000 00000000 00000002 ffffff9c
ffffff9c d96dd000 7d9fdb21
[ 49.985282] 9f20: d96c8000 00000003 c1108908 ffffff9c d96dd000
c01011e4 d96c9f94 d96c9f48
[ 49.993493] 9f40: c0281ccc c029667c d96ae000 00000001 00000000
00000000 00000004 00000100
[ 50.001704] 9f60: 00000001 7d9fdb21 00000000 00000003 01b9da68
000003e6 00000142 c01011e4
[ 50.009917] 9f80: d96c8000 00000142 d96c9fa4 d96c9f98 c0281dd0
c0281bb4 00000000 d96c9fa8
[ 50.018130] 9fa0: c0101000 c0281dc8 00000003 01b9da68 ffffff9c
b6cd6c68 00000000 00000000
[ 50.026343] 9fc0: 00000003 01b9da68 000003e6 00000142 b6f7c900
0058ead8 bee697bc 0053b50c
[ 50.034555] 9fe0: 00000142 bee696c8 b6c930d5 b6c1a6c6 20070030
ffffff9c 00000000 00000000
[ 50.042753] Backtrace:
[ 50.045258] [<c03090a0>] (find_entry) from [<c030a94c>]
(proc_sys_lookup+0x74/0x180)
[ 50.053042] r10:00000000 r9:d90f44d8 r8:c1108908 r7:d96c48c0
r6:d8090040 r5:0000000b
[ 50.060897] r4:c1132fb4
[ 50.063472] [<c030a8d8>] (proc_sys_lookup) from [<c0294ff4>]
(path_openat+0xd58/0x108c)
[ 50.071511] r10:d96c48c0 r9:d96c48c0 r8:d96c9f50 r7:d96c9e90
r6:00000000 r5:d90f0f18
[ 50.079366] r4:00000000
[ 50.081939] [<c029429c>] (path_openat) from [<c02966e4>]
(do_filp_open+0x74/0xe4)
[ 50.089459] r10:00000142 r9:d96c8000 r8:00000001 r7:c1108908
r6:d96c9e90 r5:d96c9f50
[ 50.097311] r4:00000003
[ 50.099884] [<c0296670>] (do_filp_open) from [<c0281ccc>]
(do_sys_open+0x124/0x1ec)
[ 50.107574] r8:c01011e4 r7:d96dd000 r6:ffffff9c r5:c1108908 r4:00000003
[ 50.114311] [<c0281ba8>] (do_sys_open) from [<c0281dd0>]
(sys_openat+0x14/0x18)
[ 50.121656] r10:00000142 r9:d96c8000 r8:c01011e4 r7:00000142
r6:000003e6 r5:01b9da68
[ 50.129511] r4:00000003
[ 50.132083] [<c0281dbc>] (sys_openat) from [<c0101000>]
(ret_fast_syscall+0x0/0x28)
[ 50.139766] Exception stack(0xd96c9fa8 to 0xd96c9ff0)
[ 50.144851] 9fa0: 00000003 01b9da68 ffffff9c
b6cd6c68 00000000 00000000
[ 50.153063] 9fc0: 00000003 01b9da68 000003e6 00000142 b6f7c900
0058ead8 bee697bc 0053b50c
[ 50.161269] 9fe0: 00000142 bee696c8 b6c930d5 b6c1a6c6
[ 50.166357] Code: e598a000 e06cc007 e1a0c24c e08cc18c (e79a610c)
[ 50.172754] ---[ end trace 9e22ce3f534d2b3d ]---
Then I logged into the serial console, rebooted, and again a kernel
panic, but much sooner :
[ 3.711085] imx-sdma 20ec000.sdma: loaded firmware 3.5
[ 3.739709] console [ttymxc0] enabled
[ 3.743626] bootconsole [ec_imx6q0] disabled
[ 4.078675] brd: module loaded
[ 4.327831] loop: module loaded
[ 4.343852] at24 0-0050: 256 byte 24c02 EEPROM, writable, 8 bytes/write
[ 4.434753] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc
[ 4.441437] nand: Micron MT29F4G08ABADAH4
[ 4.445582] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048,
OOB size: 64
[ 4.466637] Bad block table not found for chip 0
[ 4.474598] Bad block table not found for chip 0
[ 4.479535] Scanning device for bad blocks
[ 7.108753] Bad block table written to 0x00001ffe0000, version 0x01
[ 7.118100] Bad block table written to 0x00001ffc0000, version 0x01
[ 7.125068] 1 cmdlinepart partitions found on MTD device gpmi-nand
[ 7.131616] Creating 1 MTD partitions on "gpmi-nand":
[ 7.137028] 0x000000000000-0x000020000000 : "nandflash"
[ 7.166797] random: crng init done
[ 8.081299] gpmi-nand 1806000.gpmi-nand: driver registered.
[ 8.089377] Unable to handle kernel NULL pointer dereference at
virtual address 00000070
[ 8.098055] pgd = a7175e07
[ 8.100896] [00000070] *pgd=00000000
[ 8.104636] Internal error: Oops: 5 [#1] SMP ARM
[ 8.109316] Modules linked in:
[ 8.112459] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.19.66-00020-g91d5756ab909 #3
[ 8.120255] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
[ 8.126506] PC is at strcmp+0x18/0x44
[ 8.130236] LR is at kset_find_obj+0x44/0x8c
[ 8.134568] pc : [<c0b9358c>] lr : [<c0b88054>] psr: 20000013
[ 8.140887] sp : d80a9e50 ip : d80a9e60 fp : d80a9e5c
[ 8.146165] r10: 00000000 r9 : c1108930 r8 : c1108908
[ 8.151444] r7 : d8139e88 r6 : c0edbd04 r5 : d8139e80 r4 : c0eba704
[ 8.158023] r3 : 00000070 r2 : 00000066 r1 : c0edbd04 r0 : 00000070
[ 8.164608] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment none
[ 8.171797] Control: 10c5387d Table: 8000406a DAC: 00000051
[ 8.177602] Process swapper/0 (pid: 1, stack limit = 0x0e667d51)
[ 8.183664] Stack: (0xd80a9e50 to 0xd80aa000)
[ 8.188084] 9e40: d80a9e7c
d80a9e60 c0b88054 c0b93580
[ 8.196328] 9e60: c117f87c c105f984 c10a7dc4 c11d7ac0 d80a9e94
d80a9e80 c0612c60 c0b8801c
[ 8.204570] 9e80: c1174e28 c117f87c d80a9eac d80a9e98 c0612cf0
c0612c50 c11d6970 c105f984
[ 8.212813] 9ea0: d80a9ebc d80a9eb0 c0613d68 c0612c88 d80a9ecc
d80a9ec0 c105f99c c0613d3c
[ 8.221056] 9ec0: d80a9f4c d80a9ed0 c01031f4 c105f990 00000000
c0f8f438 000000f7 dffffb00
[ 8.229298] 9ee0: d80a9f4c d80a9ef0 c014f5a8 c1000710 00000000
00000006 d8092000 00000000
[ 8.237542] 9f00: 60000053 c11d6970 c11dc900 c11d7ac0 d80a9f34
d80a9f20 c017bf04 7d9fdb21
[ 8.245785] 9f20: c115d3c4 00000006 c1090850 c10a7dc4 c11dc900
c11d7ac0 d80a8000 00000000
[ 8.254027] 9f40: d80a9f94 d80a9f50 c10011d4 c0103178 00000006
00000006 00000000 c1000704
[ 8.262270] 9f60: c0ba1310 000000f7 d8092000 00000000 c0b99d14
00000000 00000000 00000000
[ 8.270511] 9f80: 00000000 00000000 d80a9fac d80a9f98 c0b99d24
c1000f24 d8092000 00000000
[ 8.278753] 9fa0: 00000000 d80a9fb0 c01010b4 c0b99d20 00000000
00000000 00000000 00000000
[ 8.286993] 9fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 8.295233] 9fe0: 00000000 00000000 00000000 00000000 00000013
00000000 00000000 00000000
[ 8.303456] Backtrace:
[ 8.305993] [<c0b93574>] (strcmp) from [<c0b88054>]
(kset_find_obj+0x44/0x8c)
[ 8.313208] [<c0b88010>] (kset_find_obj) from [<c0612c60>]
(driver_find+0x1c/0x38)
[ 8.320846] r7:c11d7ac0 r6:c10a7dc4 r5:c105f984 r4:c117f87c
[ 8.326575] [<c0612c44>] (driver_find) from [<c0612cf0>]
(driver_register+0x74/0x11c)
[ 8.334465] r4:c117f87c r3:c1174e28
[ 8.338114] [<c0612c7c>] (driver_register) from [<c0613d68>]
(__platform_driver_register+0x38/0x4c)
[ 8.347215] r5:c105f984 r4:c11d6970
[ 8.350865] [<c0613d30>] (__platform_driver_register) from
[<c105f99c>] (fsl_qspi_driver_init+0x18/0x20)
[ 8.360415] [<c105f984>] (fsl_qspi_driver_init) from [<c01031f4>]
(do_one_initcall+0x88/0x31c)
[ 8.369103] [<c010316c>] (do_one_initcall) from [<c10011d4>]
(kernel_init_freeable+0x2bc/0x3e8)
[ 8.377871] r10:00000000 r9:d80a8000 r8:c11d7ac0 r7:c11dc900
r6:c10a7dc4 r5:c1090850
[ 8.385750] r4:00000006
[ 8.388356] [<c1000f18>] (kernel_init_freeable) from [<c0b99d24>]
(kernel_init+0x10/0x120)
[ 8.396688] r10:00000000 r9:00000000 r8:00000000 r7:00000000
r6:00000000 r5:c0b99d14
[ 8.404567] r4:00000000
[ 8.407169] [<c0b99d14>] (kernel_init) from [<c01010b4>]
(ret_from_fork+0x14/0x20)
[ 8.414792] Exception stack(0xd80a9fb0 to 0xd80a9ff8)
[ 8.419902] 9fa0: 00000000
00000000 00000000 00000000
[ 8.428143] 9fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 8.436379] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 8.443049] r4:00000000 r3:d8092000
[ 8.446690] Code: e24cb004 ea000001 e3530000 0a000008 (e4d03001)
[ 8.453044] ---[ end trace b6f2a017d259fade ]---
[ 8.457941] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[ 8.457941]
[ 8.467193] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x0000000b
[ 8.467193] ]---
Kind regards,
Jürgen
>
> --
> Regards,
> Leonard
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
2019-09-03 14:32 ` Jurgen Lambrecht
2019-09-03 14:48 ` Leonard Crestez
@ 2019-09-12 2:06 ` Robin Gong
2019-09-12 9:45 ` Jurgen Lambrecht
1 sibling, 1 reply; 16+ messages in thread
From: Robin Gong @ 2019-09-12 2:06 UTC (permalink / raw)
To: Jurgen Lambrecht, Leonard Crestez, Fabio Estevam
Cc: Aisheng Dong, dl-linux-imx, linux-arm-kernel
On 2019-9-3 22:32 Jurgen Lambrecht <J.Lambrecht@TELEVIC.com> wrote
> On 9/3/19 7:57 AM, Robin Gong wrote:
> > CAUTION: This Email originated from outside Televic. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> >
> >
> > On 2019-8-29 14:24, Jurgen Lambrecht wrote:
> >> On 8/28/19 4:05 PM, Robin Gong wrote:
> >>> Could you help check if below commit in your side?
> >>> commit ebb853b1bd5f659b92c71dc6a9de44cfc37c78c0
> >>> Author: Lucas Stach<l.stach@pengutronix.de>
> >>> Date: Tue Nov 6 03:40:28 2018 +0000
> >> yes, it's in.
> >>
> >> Also the 2 follow-up commits of Lucas Stach:
> >> 9063f5a99ea76f85935e3e453422d15e7be89b9e and
> >> 374f384bc66f7a928f11eb20c0518f0f3fc1ffd6.
> I had also already cherry picked your commit
> 3f5de4c7e16164a344a905649f08e8a90a68ff9f "dmaengine: imx-sdma:
> remove BD_INTR for channel0".
>
> But also then kernel hangs at loading sdma FW.
>
> (this looked the most interesting commit)
I identified this issue which caused by SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3
(41)exceed the structure sdma_script_start_addrs(40) so that illegal memory
touch, such as slob block header, thus kernel trap into while() loop forever
in slob_free(). Please see the below code piece in sdma_add_scripts().
for (i = 0; i < sdma->script_number; i++)
if (addr_arr[i] > 0)
saddr_arr[i] = addr_arr[i];
That issue was brought by commit a572460be9cf (dmaengine: imx-sdma:
Add support for version 3 firmware) because the SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3
(38->41 3 scripts added) not align with script number added in
sdma_script_start_addrs(2 scripts). Please have a try with
the below patch:
diff --git a/include/linux/platform_data/dma-imx-sdma.h b/include/linux/platform_data/dma-imx-sdma.h
index 6eaa53c..30e676b 100644
--- a/include/linux/platform_data/dma-imx-sdma.h
+++ b/include/linux/platform_data/dma-imx-sdma.h
@@ -51,7 +51,10 @@ struct sdma_script_start_addrs {
/* End of v2 array */
s32 zcanfd_2_mcu_addr;
s32 zqspi_2_mcu_addr;
+ s32 mcu_2_ecspi_addr;
/* End of v3 array */
+ s32 mcu_2_zqspi_addr;
+ /* End of v4 array */
};
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
2019-09-04 14:26 ` Jurgen Lambrecht
@ 2019-09-12 6:33 ` Uwe Kleine-König
0 siblings, 0 replies; 16+ messages in thread
From: Uwe Kleine-König @ 2019-09-12 6:33 UTC (permalink / raw)
To: Jurgen Lambrecht
Cc: Aisheng Dong, thesven73, Leonard Crestez, dl-linux-imx,
Fabio Estevam, Robin Gong, linux-arm-kernel, Lucas Stach
[adding Lucas to Cc:]
Hello,
On Wed, Sep 04, 2019 at 02:26:17PM +0000, Jurgen Lambrecht wrote:
> On 9/3/19 4:48 PM, Leonard Crestez wrote:
> > On 03.09.2019 17:32, Jurgen Lambrecht wrote:
> >> On 9/3/19 7:57 AM, Robin Gong wrote:
> >>
> >>>> And that are the last commits on drivers/dma/imx-sdma.c for my 4.19.x+fslc
> >>>> branch. But I have already tried 5.1.x+fslc, and it also got stuck.
> >>> Sorry, I can't reproduce your issue on Linux 5.3-rc6 with 'CONFIG_SLOB=y' and
> >>> SDMA firmware built in kernel, Could you have a try on our imx6ul-14x14-evk
> >>> board with Linux 5.3-rc6 directly(no any patch needed)?
> >> This works on our own board (with imx6ul)!
> > Something seems to be wrong with the fslc tree, using 5.1.x+fslc at
> > latest commit cd1d083333e76e03d16f015c23f1f1b8c8637381 I can reproduce
> > the issue on imx6ul-14x14-evk board.
> >
> > Running without SLOB and builtin firmware it's fine.
> >
> > I couldn't reproduce with latest 4.19.x+fslc (currently at commit
> > 91d5756ab9096bbec256115d1d6b85f5d7139f85), maybe some additional SDMA
> > patches were applied which fixed this issue?
>
> My 4.19.x+fslc was a 4.19.56 (cda746ffc).
>
> Now I updated to your version 4.19.66, and it does not hang anymore, but
> I get a *kernel panic* (oops) (so with sdma FW and with the SLOB
> allocator). Also when I remove earlycon and update the dts not to enable
> sdma on the uart, it still panics. Also with our patches on top kernel
> panics. To be completely sure, I compiled 4.19.66+fslc (so
> 91d5756ab9096bbec256115d1d6b85f5d7139f85) with imx_v6_v7_defconfig
> (instead of our minimal defconfig) and then it panics half of the time
> (see below).
>
> With SLUB, it works. And with SLOB without sdma it also works!
>
> Here the kernel panic log:
>
> [ 0.971298] io scheduler noop registered (default)
> [ 1.045927] imx-sdma 20ec000.sdma: loaded firmware 3.5
> [ 1.060382] console [ttymxc0] enabled
> [ 1.064199] bootconsole [ec_imx6q0] disabled
> [ 1.104663] Unable to handle kernel paging request at virtual address ffffffe8
> [ 1.112035] pgd = (ptrval)
> [ 1.114772] [ffffffe8] *pgd=9ffff841, *pte=00000000, *ppte=00000000
> [ 1.121138] Internal error: Oops: 27 [#1] PREEMPT ARM
> [ 1.126212] Modules linked in:
> [ 1.129305] CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.66-televic-rail-33.97.1802-00072-g39a835ebea4c #2
> [ 1.138979] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
> [ 1.145197] PC is at alloc_vmap_area+0x140/0x3ec
> [ 1.149836] LR is at 0x1000
> [ 1.152650] pc : [<c01cc150>] lr : [<00001000>] psr: 00000053
> [ 1.158937] sp : df055cb0 ip : 00009000 fp : ff800000
> [ 1.164183] r10: 00000001 r9 : c0a74204 r8 : 00000001
> [ 1.169430] r7 : c0a74204 r6 : ffffffff r5 : 00000001 r4 : 00009000
> [ 1.175980] r3 : 00000000 r2 : 00000000 r1 : c0a11df0 r0 : e0876000
> [ 1.182533] Flags: nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none
> [ 1.189778] Control: 10c53c7d Table: 80004059 DAC: 00000051
> [ 1.195546] Process swapper (pid: 1, stack limit = 0x(ptrval))
> [ 1.201399] Stack: (0xdf055cb0 to 0xdf056000)
> [ 1.205785] 5ca0: e0800000 00000000 e0809000 e0800000
> [ 1.213993] 5cc0: 00000000 df2ed640 df2d4d80 b65d4d11 ffffffff 00009000 df2ed5c0 00000022
> [ 1.222202] 5ce0: 006080c0 00000001 e0800000 c0a03048 df2d4d80 c01cc490 ffffffff 006080c0
> [ 1.230412] 5d00: df2c1980 00008000 ffffffff ffffffff 006080c0 df2d4d80 00000001 c01cd870
> [ 1.238621] 5d20: ff800000 ffffffff 006080c0 c0382754 c0a12028 c0382754 ffffffff 00000000
> [ 1.246829] 5d40: df2c1940 df2d4d80 00000001 c01cda50 006080c0 0000024f 00000000 ffffffff
> [ 1.255038] 5d60: c0382754 00000000 df2c1940 df2ed540 00000100 c01cdb1c ffffffff c0382754
> [ 1.263247] 5d80: df2d4d80 c0382754 df2d4d80 df2c1940 00000000 df2d4d90 00000000 c03808d4
> [ 1.271457] 5da0: df2c1940 c037f4f0 c037f514 df2ec640 00000000 c037f520 df2c1940 df2d4d80
> [ 1.279666] 5dc0: c0a12030 c037d7d4 006000c0 00100000 00000013 c05ee130 00000200 df2c1940
> [ 1.287875] 5de0: 00000000 00000000 df2d4d90 00000000 00000001 c0a03048 df2d4d80 c02131cc
> [ 1.296082] 5e00: 00000000 c01f5640 00000000 b65d4d11 00000000 00000000 df2d4d80 c0a03048
> [ 1.304290] 5e20: 00000001 00000000 df2c194c 00000001 df2d4d80 c02134a8 df2d4e70 00000001
> [ 1.312498] 5e40: 00000000 b65d4d11 c09005a4 c01f4bb8 df2d4df8 c02129a4 df2c19b0 b65d4d11
> [ 1.320707] 5e60: df2c1980 df2c1940 00000000 c0a03048 00000001 df2c19b0 df2c194c 00000001
> [ 1.328915] 5e80: df2d4d80 c037f138 c037d7d4 c037f514 df2c1940 c0a1cd48 00100000 c05fcbcc
> [ 1.337124] 5ea0: 0000000d df29f5f0 c09005a4 b65d4d11 df29d740 df2c3cc0 c0a1cd48 c0a1cd48
> [ 1.345333] 5ec0: c0a1cd4c 00000000 c0a1cd4c c0a1cd48 c09005a4 c091b158 c091ac58 00000000
> [ 1.353542] 5ee0: c0a2b080 00000006 c0a03048 c091b0a8 00000000 c0929830 c0929838 c0102658
> [ 1.361751] 5f00: 00000000 00000084 00000084 dfbea400 00000065 c081f5e4 00000084 c013845c
> [ 1.369959] 5f20: c081eba8 00000000 c09005a4 00000000 00000006 00000006 00000000 dfbea401
> [ 1.378168] 5f40: 00000000 b65d4d11 00000000 b65d4d11 c0934f90 00000006 c0a2b080 00000084
> [ 1.386376] 5f60: c0a2b080 c0929838 c09005a4 c0900dbc 00000006 00000006 00000000 c09005a4
> [ 1.394584] 5f80: c05fd99c 00000000 c05fd99c 00000000 00000000 00000000 00000000 00000000
> [ 1.402792] 5fa0: 00000000 c05fd9a4 00000000 c01010e8 00000000 00000000 00000000 00000000
> [ 1.410998] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 1.419205] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [ 1.427434] [<c01cc150>] (alloc_vmap_area) from [<c01cc490>] (__get_vm_area_node+0x94/0x168)
> [ 1.435917] [<c01cc490>] (__get_vm_area_node) from [<c01cd870>] (__vmalloc_node_range+0x58/0x1f4)
> [ 1.444825] [<c01cd870>] (__vmalloc_node_range) from [<c01cda50>] (__vmalloc_node+0x44/0x54)
> [ 1.453300] [<c01cda50>] (__vmalloc_node) from [<c01cdb1c>] (vzalloc+0x2c/0x3c)
> [ 1.460652] [<c01cdb1c>] (vzalloc) from [<c0382754>] (check_partition+0x38/0x1d4)
> [ 1.468177] [<c0382754>] (check_partition) from [<c03808d4>] (rescan_partitions+0x78/0x440)
> [ 1.476567] [<c03808d4>] (rescan_partitions) from [<c02131cc>] (__blkdev_get+0x25c/0x414)
> [ 1.484779] [<c02131cc>] (__blkdev_get) from [<c02134a8>] (blkdev_get+0x124/0x3e8)
> [ 1.492385] [<c02134a8>] (blkdev_get) from [<c037f138>] (__device_add_disk+0x404/0x4b8)
> [ 1.500432] [<c037f138>] (__device_add_disk) from [<c091b158>] (brd_init+0xb0/0x170)
> [ 1.508218] [<c091b158>] (brd_init) from [<c0102658>] (do_one_initcall+0x48/0x1a0)
> [ 1.515833] [<c0102658>] (do_one_initcall) from [<c0900dbc>] (kernel_init_freeable+0x100/0x1c8)
> [ 1.524579] [<c0900dbc>] (kernel_init_freeable) from [<c05fd9a4>] (kernel_init+0x8/0x11c)
> [ 1.532796] [<c05fd9a4>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
> [ 1.540386] Exception stack(0xdf055fb0 to 0xdf055ff8)
> [ 1.545463] 5fa0: 00000000 00000000 00000000 00000000
> [ 1.553671] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 1.561875] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [ 1.568522] Code: e5922018 e59f129c e1520001 0a00002f (e5121018)
These instructions are:
ldr r2, [r2, 0x18]
ldr r1, [pc, 0x29c]
cmp r2, r1
beq 0xd0
ldr r1, [r2, -0x18]
The last instruction tries to load from r2-0x18, but r2 is NULL.
I guess this is about inserting the new vmap area into the rbtree of
areas.
> [ 1.574733] ---[ end trace abfef683febb0cb6 ]---
> [ 1.579384] Kernel panic - not syncing: Fatal exception
> [ 1.584640] Rebooting in 180 seconds..
>
> I checked the patches on drivers/dma/imx-sdma.c and "dmaengine:
> imx-sdma: fix use-after-free on probe error path"
> 09593c25b975458025fd4cd15d5861cbaa33683d seems to describe the issue....
> but not solving it for me. So that is why I put Sven in CC.
>
> Also with 4.19.56 with our own patches on top, the kernel did not hang,
> but panicked. It looks like a timing problem inside the sdma driver.
> Because kernel did not crash always, sometimes it did boot. Also now,
> but only with 4.19.66+fslc with imx_v6_v7_defconfig it booted the first
> time correctly, after a reboot it panicked very late, I even got a login
> console, but then it rebooted again, but again good. Here the log:
>
> [ 49.763843] Unable to handle kernel paging request at virtual address
> a72e118d
> [ 49.772789] pgd = b60d9f54
> [ 49.775817] [a72e118d] *pgd=00000000
> [ 49.779501] Internal error: Oops: 5 [#1] SMP ARM
> [ 49.784152] Modules linked in:
> [ 49.787259] CPU: 0 PID: 455 Comm: ntpd Not tainted
> 4.19.66-00020-g91d5756ab909 #3
> [ 49.794770] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
> [ 49.800991] PC is at find_entry+0x5c/0xc4
> [ 49.805032] LR is at find_entry+0x88/0xc4
> [ 49.809073] pc : [<c03090fc>] lr : [<c0309128>] psr: a0070013
> [ 49.815365] sp : d96c9d40 ip : e9cb8463 fp : d96c9d74
> [ 49.820616] r10: 00000001 r9 : 00000002 r8 : d8864040
> [ 49.825870] r7 : d88640bc r6 : c0e70108 r5 : d96c48fc r4 : 0000000b
> [ 49.832425] r3 : 0000006e r2 : 00000009 r1 : c0e70108 r0 : ffffffff
> [ 49.838982] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM
> Segment none
> [ 49.846146] Control: 10c5387d Table: 996cc06a DAC: 00000051
> [ 49.851924] Process ntpd (pid: 455, stack limit = 0x873acf61)
> [ 49.857699] Stack: (0xd96c9d40 to 0xd96ca000)
> [ 49.862095] 9d40: d96c9d74 d96c9d88 c0ba1030 c1132fb4 0000000b d8090040 d96c48c0 c1108908
> [ 49.870308] 9d60: d90f44d8 00000000 d96c9dbc d96c9d78 c030a94c c03090ac c02a2d04 d96c48fc
> [ 49.878519] 9d80: 00000001 00000000 c0294844 7d9fdb21 d96c9dbc 00000000 d90f0f18 00000000
> [ 49.886732] 9da0: d96c9e90 d96c9f50 d96c48c0 d96c48c0 d96c9e8c d96c9dc0 c0294ff4 c030a8e4
> [ 49.894945] 9dc0: d96c9e7c d96c9dd0 c017eb8c c017e028 d96c48c0 00000000 00000000 00000000
> [ 49.903157] 9de0: d90f44d8 00000041 00000000 d96c2140 00000004 00000000 00000000 c1748cc0
> [ 49.911370] 9e00: 00000000 d96ae4f0 6ca44a47 00000000 dead4ead ffffffff ffffffff c193441c
> [ 49.919581] 9e20: 00000000 00000000 c0e795c8 d96c9e2c d96c9e2c 00000000 dead4ead ffffffff
> [ 49.927794] 9e40: ffffffff c193441c 00000000 00000000 c0e795c8 d96c9e2c d96c9e2c 7d9fdb21
> [ 49.936006] 9e60: 00000000 00000003 d96c9f50 d96c9e90 c1108908 00000001 d96c8000 00000142
> [ 49.944219] 9e80: d96c9f44 d96c9e90 c02966e4 c02942a8 d8f0ad10 d90f0f18 04ff40f7 0000000b
> [ 49.952433] 9ea0: d96dd021 60070013 d8e9d3d0 d8ed0960 d90f44d8 00000101 c030ac14 0000005c
> [ 49.960645] 9ec0: 00000000 00000000 00000000 d96c9ed0 d96c9ef4 d96c9ee0 c0ba1258 c0184904
> [ 49.968856] 9ee0: 00000000 d96acd24 d96c9f34 d96c9ef8 c02a80d4 c0ba123c d96c9f34 00000000
> [ 49.977069] 9f00: d96dd000 00000000 00000000 00000002 ffffff9c ffffff9c d96dd000 7d9fdb21
> [ 49.985282] 9f20: d96c8000 00000003 c1108908 ffffff9c d96dd000 c01011e4 d96c9f94 d96c9f48
> [ 49.993493] 9f40: c0281ccc c029667c d96ae000 00000001 00000000 00000000 00000004 00000100
> [ 50.001704] 9f60: 00000001 7d9fdb21 00000000 00000003 01b9da68 000003e6 00000142 c01011e4
> [ 50.009917] 9f80: d96c8000 00000142 d96c9fa4 d96c9f98 c0281dd0 c0281bb4 00000000 d96c9fa8
> [ 50.018130] 9fa0: c0101000 c0281dc8 00000003 01b9da68 ffffff9c b6cd6c68 00000000 00000000
> [ 50.026343] 9fc0: 00000003 01b9da68 000003e6 00000142 b6f7c900 0058ead8 bee697bc 0053b50c
> [ 50.034555] 9fe0: 00000142 bee696c8 b6c930d5 b6c1a6c6 20070030 ffffff9c 00000000 00000000
> [ 50.042753] Backtrace:
> [ 50.045258] [<c03090a0>] (find_entry) from [<c030a94c>] (proc_sys_lookup+0x74/0x180)
> [ 50.053042] r10:00000000 r9:d90f44d8 r8:c1108908 r7:d96c48c0 r6:d8090040 r5:0000000b
> [ 50.060897] r4:c1132fb4
> [ 50.063472] [<c030a8d8>] (proc_sys_lookup) from [<c0294ff4>] (path_openat+0xd58/0x108c)
> [ 50.071511] r10:d96c48c0 r9:d96c48c0 r8:d96c9f50 r7:d96c9e90 r6:00000000 r5:d90f0f18
> [ 50.079366] r4:00000000
> [ 50.081939] [<c029429c>] (path_openat) from [<c02966e4>] (do_filp_open+0x74/0xe4)
> [ 50.089459] r10:00000142 r9:d96c8000 r8:00000001 r7:c1108908 r6:d96c9e90 r5:d96c9f50
> [ 50.097311] r4:00000003
> [ 50.099884] [<c0296670>] (do_filp_open) from [<c0281ccc>] (do_sys_open+0x124/0x1ec)
> [ 50.107574] r8:c01011e4 r7:d96dd000 r6:ffffff9c r5:c1108908 r4:00000003
> [ 50.114311] [<c0281ba8>] (do_sys_open) from [<c0281dd0>] (sys_openat+0x14/0x18)
> [ 50.121656] r10:00000142 r9:d96c8000 r8:c01011e4 r7:00000142 r6:000003e6 r5:01b9da68
> [ 50.129511] r4:00000003
> [ 50.132083] [<c0281dbc>] (sys_openat) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
> [ 50.139766] Exception stack(0xd96c9fa8 to 0xd96c9ff0)
> [ 50.144851] 9fa0: 00000003 01b9da68 ffffff9c b6cd6c68 00000000 00000000
> [ 50.153063] 9fc0: 00000003 01b9da68 000003e6 00000142 b6f7c900 0058ead8 bee697bc 0053b50c
> [ 50.161269] 9fe0: 00000142 bee696c8 b6c930d5 b6c1a6c6
> [ 50.166357] Code: e598a000 e06cc007 e1a0c24c e08cc18c (e79a610c)
> [ 50.172754] ---[ end trace 9e22ce3f534d2b3d ]---
>
> Then I logged into the serial console, rebooted, and again a kernel
> panic, but much sooner :
>
> [ 3.711085] imx-sdma 20ec000.sdma: loaded firmware 3.5
> [ 3.739709] console [ttymxc0] enabled
> [ 3.743626] bootconsole [ec_imx6q0] disabled
> [ 4.078675] brd: module loaded
> [ 4.327831] loop: module loaded
> [ 4.343852] at24 0-0050: 256 byte 24c02 EEPROM, writable, 8 bytes/write
> [ 4.434753] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc
> [ 4.441437] nand: Micron MT29F4G08ABADAH4
> [ 4.445582] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> [ 4.466637] Bad block table not found for chip 0
> [ 4.474598] Bad block table not found for chip 0
> [ 4.479535] Scanning device for bad blocks
> [ 7.108753] Bad block table written to 0x00001ffe0000, version 0x01
> [ 7.118100] Bad block table written to 0x00001ffc0000, version 0x01
> [ 7.125068] 1 cmdlinepart partitions found on MTD device gpmi-nand
> [ 7.131616] Creating 1 MTD partitions on "gpmi-nand":
> [ 7.137028] 0x000000000000-0x000020000000 : "nandflash"
> [ 7.166797] random: crng init done
> [ 8.081299] gpmi-nand 1806000.gpmi-nand: driver registered.
> [ 8.089377] Unable to handle kernel NULL pointer dereference at virtual address 00000070
> [ 8.098055] pgd = a7175e07
> [ 8.100896] [00000070] *pgd=00000000
> [ 8.104636] Internal error: Oops: 5 [#1] SMP ARM
> [ 8.109316] Modules linked in:
> [ 8.112459] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.66-00020-g91d5756ab909 #3
> [ 8.120255] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
> [ 8.126506] PC is at strcmp+0x18/0x44
> [ 8.130236] LR is at kset_find_obj+0x44/0x8c
> [ 8.134568] pc : [<c0b9358c>] lr : [<c0b88054>] psr: 20000013
> [ 8.140887] sp : d80a9e50 ip : d80a9e60 fp : d80a9e5c
> [ 8.146165] r10: 00000000 r9 : c1108930 r8 : c1108908
> [ 8.151444] r7 : d8139e88 r6 : c0edbd04 r5 : d8139e80 r4 : c0eba704
> [ 8.158023] r3 : 00000070 r2 : 00000066 r1 : c0edbd04 r0 : 00000070
> [ 8.164608] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> [ 8.171797] Control: 10c5387d Table: 8000406a DAC: 00000051
> [ 8.177602] Process swapper/0 (pid: 1, stack limit = 0x0e667d51)
> [ 8.183664] Stack: (0xd80a9e50 to 0xd80aa000)
> [ 8.188084] 9e40: d80a9e7c d80a9e60 c0b88054 c0b93580
> [ 8.196328] 9e60: c117f87c c105f984 c10a7dc4 c11d7ac0 d80a9e94 d80a9e80 c0612c60 c0b8801c
> [ 8.204570] 9e80: c1174e28 c117f87c d80a9eac d80a9e98 c0612cf0 c0612c50 c11d6970 c105f984
> [ 8.212813] 9ea0: d80a9ebc d80a9eb0 c0613d68 c0612c88 d80a9ecc d80a9ec0 c105f99c c0613d3c
> [ 8.221056] 9ec0: d80a9f4c d80a9ed0 c01031f4 c105f990 00000000 c0f8f438 000000f7 dffffb00
> [ 8.229298] 9ee0: d80a9f4c d80a9ef0 c014f5a8 c1000710 00000000 00000006 d8092000 00000000
> [ 8.237542] 9f00: 60000053 c11d6970 c11dc900 c11d7ac0 d80a9f34 d80a9f20 c017bf04 7d9fdb21
> [ 8.245785] 9f20: c115d3c4 00000006 c1090850 c10a7dc4 c11dc900 c11d7ac0 d80a8000 00000000
> [ 8.254027] 9f40: d80a9f94 d80a9f50 c10011d4 c0103178 00000006 00000006 00000000 c1000704
> [ 8.262270] 9f60: c0ba1310 000000f7 d8092000 00000000 c0b99d14 00000000 00000000 00000000
> [ 8.270511] 9f80: 00000000 00000000 d80a9fac d80a9f98 c0b99d24 c1000f24 d8092000 00000000
> [ 8.278753] 9fa0: 00000000 d80a9fb0 c01010b4 c0b99d20 00000000 00000000 00000000 00000000
> [ 8.286993] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 8.295233] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [ 8.303456] Backtrace:
> [ 8.305993] [<c0b93574>] (strcmp) from [<c0b88054>] (kset_find_obj+0x44/0x8c)
> [ 8.313208] [<c0b88010>] (kset_find_obj) from [<c0612c60>] (driver_find+0x1c/0x38)
> [ 8.320846] r7:c11d7ac0 r6:c10a7dc4 r5:c105f984 r4:c117f87c
> [ 8.326575] [<c0612c44>] (driver_find) from [<c0612cf0>] (driver_register+0x74/0x11c)
> [ 8.334465] r4:c117f87c r3:c1174e28
> [ 8.338114] [<c0612c7c>] (driver_register) from [<c0613d68>] (__platform_driver_register+0x38/0x4c)
> [ 8.347215] r5:c105f984 r4:c11d6970
> [ 8.350865] [<c0613d30>] (__platform_driver_register) from [<c105f99c>] (fsl_qspi_driver_init+0x18/0x20)
> [ 8.360415] [<c105f984>] (fsl_qspi_driver_init) from [<c01031f4>] (do_one_initcall+0x88/0x31c)
> [ 8.369103] [<c010316c>] (do_one_initcall) from [<c10011d4>] (kernel_init_freeable+0x2bc/0x3e8)
> [ 8.377871] r10:00000000 r9:d80a8000 r8:c11d7ac0 r7:c11dc900 r6:c10a7dc4 r5:c1090850
> [ 8.385750] r4:00000006
> [ 8.388356] [<c1000f18>] (kernel_init_freeable) from [<c0b99d24>] (kernel_init+0x10/0x120)
> [ 8.396688] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0b99d14
> [ 8.404567] r4:00000000
> [ 8.407169] [<c0b99d14>] (kernel_init) from [<c01010b4>] (ret_from_fork+0x14/0x20)
> [ 8.414792] Exception stack(0xd80a9fb0 to 0xd80a9ff8)
> [ 8.419902] 9fa0: 00000000 00000000 00000000 00000000
> [ 8.428143] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 8.436379] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [ 8.443049] r4:00000000 r3:d8092000
> [ 8.446690] Code: e24cb004 ea000001 e3530000 0a000008 (e4d03001)
> [ 8.453044] ---[ end trace b6f2a017d259fade ]---
> [ 8.457941] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [ 8.457941]
> [ 8.467193] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [ 8.467193] ]---
this is something different:
sub fp, ip, 4
b 0x10
cmp r3, 0
beq 0x34
ldrb r3, [r0], 1
Maybe the sdma driver does something strage that confused SLOB but not
the other allocaters?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
2019-09-12 2:06 ` Robin Gong
@ 2019-09-12 9:45 ` Jurgen Lambrecht
2019-09-12 12:12 ` Jurgen Lambrecht
0 siblings, 1 reply; 16+ messages in thread
From: Jurgen Lambrecht @ 2019-09-12 9:45 UTC (permalink / raw)
To: Robin Gong, Leonard Crestez, Fabio Estevam
Cc: Aisheng Dong, dl-linux-imx, linux-arm-kernel, u.kleine-koenig
On 9/12/19 4:06 AM, Robin Gong wrote:
> On 2019-9-3 22:32 Jurgen Lambrecht <J.Lambrecht@TELEVIC.com> wrote
>> On 9/3/19 7:57 AM, Robin Gong wrote:
>>
>>> On 2019-8-29 14:24, Jurgen Lambrecht wrote:
>>>> On 8/28/19 4:05 PM, Robin Gong wrote:
>>>>> Could you help check if below commit in your side?
>>>>> commit ebb853b1bd5f659b92c71dc6a9de44cfc37c78c0
>>>>> Author: Lucas Stach<l.stach@pengutronix.de>
>>>>> Date: Tue Nov 6 03:40:28 2018 +0000
>>>> yes, it's in.
>>>>
>>>> Also the 2 follow-up commits of Lucas Stach:
>>>> 9063f5a99ea76f85935e3e453422d15e7be89b9e and
>>>> 374f384bc66f7a928f11eb20c0518f0f3fc1ffd6.
>> I had also already cherry picked your commit
>> 3f5de4c7e16164a344a905649f08e8a90a68ff9f "dmaengine: imx-sdma:
>> remove BD_INTR for channel0".
>>
>> But also then kernel hangs at loading sdma FW.
>>
>> (this looked the most interesting commit)
> I identified this issue which caused by SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3
> (41)exceed the structure sdma_script_start_addrs(40) so that illegal memory
> touch, such as slob block header, thus kernel trap into while() loop forever
> in slob_free(). Please see the below code piece in sdma_add_scripts().
> for (i = 0; i < sdma->script_number; i++)
> if (addr_arr[i] > 0)
> saddr_arr[i] = addr_arr[i];
> That issue was brought by commit a572460be9cf (dmaengine: imx-sdma:
> Add support for version 3 firmware) because the SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3
> (38->41 3 scripts added) not align with script number added in
> sdma_script_start_addrs(2 scripts). Please have a try with
> the below patch:
> diff --git a/include/linux/platform_data/dma-imx-sdma.h b/include/linux/platform_data/dma-imx-sdma.h
> index 6eaa53c..30e676b 100644
> --- a/include/linux/platform_data/dma-imx-sdma.h
> +++ b/include/linux/platform_data/dma-imx-sdma.h
> @@ -51,7 +51,10 @@ struct sdma_script_start_addrs {
> /* End of v2 array */
> s32 zcanfd_2_mcu_addr;
> s32 zqspi_2_mcu_addr;
> + s32 mcu_2_ecspi_addr;
> /* End of v3 array */
> + s32 mcu_2_zqspi_addr;
> + /* End of v4 array */
> };
>
Yes, this patch solves it! I can now use SLOB slab allocator. I tried
several reboots and power cycles.
I tried with different dts (without earlycon, without sdma on uart and
ecspi).
I did not try other kernels, only 4.19.66+fscl with our patches and sdma
v3.5 built-in.
Thanks and also thanks Uwe for analyzing the assembly,
Jürgen
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
2019-09-12 9:45 ` Jurgen Lambrecht
@ 2019-09-12 12:12 ` Jurgen Lambrecht
2019-09-12 14:19 ` Robin Gong
0 siblings, 1 reply; 16+ messages in thread
From: Jurgen Lambrecht @ 2019-09-12 12:12 UTC (permalink / raw)
To: Robin Gong, Leonard Crestez, Fabio Estevam
Cc: Aisheng Dong, dl-linux-imx, linux-arm-kernel, u.kleine-koenig
On 9/12/19 11:45 AM, Jurgen Lambrecht wrote:
> CAUTION: This Email originated from outside Televic. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> On 9/12/19 4:06 AM, Robin Gong wrote:
>> On 2019-9-3 22:32 Jurgen Lambrecht <J.Lambrecht@TELEVIC.com> wrote
>>> On 9/3/19 7:57 AM, Robin Gong wrote:
>>>
>>>> On 2019-8-29 14:24, Jurgen Lambrecht wrote:
>>>>> On 8/28/19 4:05 PM, Robin Gong wrote:
>>>>>> Could you help check if below commit in your side?
>>>>>> commit ebb853b1bd5f659b92c71dc6a9de44cfc37c78c0
>>>>>> Author: Lucas Stach<l.stach@pengutronix.de>
>>>>>> Date: Tue Nov 6 03:40:28 2018 +0000
>>>>> yes, it's in.
>>>>>
>>>>> Also the 2 follow-up commits of Lucas Stach:
>>>>> 9063f5a99ea76f85935e3e453422d15e7be89b9e and
>>>>> 374f384bc66f7a928f11eb20c0518f0f3fc1ffd6.
>>> I had also already cherry picked your commit
>>> 3f5de4c7e16164a344a905649f08e8a90a68ff9f "dmaengine: imx-sdma:
>>> remove BD_INTR for channel0".
>>>
>>> But also then kernel hangs at loading sdma FW.
>>>
>>> (this looked the most interesting commit)
>> I identified this issue which caused by SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3
>> (41)exceed the structure sdma_script_start_addrs(40) so that illegal memory
>> touch, such as slob block header, thus kernel trap into while() loop forever
>> in slob_free(). Please see the below code piece in sdma_add_scripts().
>> for (i = 0; i < sdma->script_number; i++)
>> if (addr_arr[i] > 0)
>> saddr_arr[i] = addr_arr[i];
>> That issue was brought by commit a572460be9cf (dmaengine: imx-sdma:
>> Add support for version 3 firmware) because the SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3
>> (38->41 3 scripts added) not align with script number added in
>> sdma_script_start_addrs(2 scripts). Please have a try with
>> the below patch:
>> diff --git a/include/linux/platform_data/dma-imx-sdma.h b/include/linux/platform_data/dma-imx-sdma.h
>> index 6eaa53c..30e676b 100644
>> --- a/include/linux/platform_data/dma-imx-sdma.h
>> +++ b/include/linux/platform_data/dma-imx-sdma.h
>> @@ -51,7 +51,10 @@ struct sdma_script_start_addrs {
>> /* End of v2 array */
>> s32 zcanfd_2_mcu_addr;
>> s32 zqspi_2_mcu_addr;
>> + s32 mcu_2_ecspi_addr;
>> /* End of v3 array */
>> + s32 mcu_2_zqspi_addr;
>> + /* End of v4 array */
>> };
>>
> Yes, this patch solves it! I can now use SLOB slab allocator. I tried
> several reboots and power cycles.
> I tried with different dts (without earlycon, without sdma on uart and
> ecspi).
> I did not try other kernels, only 4.19.66+fscl with our patches and sdma
> v3.5 built-in.
I tried again v5.3 rc6 with SLOB, but it still booted OK, then took
latest v5.3 rc8 from mainline, and it also boots OK - tried several
times also with power cycle.
Then I added your patch, and it "still" boots :-). So OK:
Linux imx6ul-33927318 5.3.0-rc8-dirty #3 PREEMPT Thu Sep 12 13:54:25
CEST 2019 armv7l GNU/Linux
> Thanks and also thanks Uwe for analyzing the assembly,
>
> Jürgen
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infradead.org%2Fmailman%2Flistinfo%2Flinux-arm-kernel&data=02%7C01%7CJ.Lambrecht%40televic.com%7C31571c624eb54b6d6dbe08d737660f66%7C68a8593ed1fc4a6ab7821bdcb0633231%7C1%7C0%7C637038783797869668&sdata=ZpzjxmupoHLuvtCF5kNBBMgXxMF6SUbnyuK7Vpq1YrM%3D&reserved=0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
2019-09-12 12:12 ` Jurgen Lambrecht
@ 2019-09-12 14:19 ` Robin Gong
2019-09-12 14:40 ` Russell King - ARM Linux admin
0 siblings, 1 reply; 16+ messages in thread
From: Robin Gong @ 2019-09-12 14:19 UTC (permalink / raw)
To: Jurgen Lambrecht, Leonard Crestez, Fabio Estevam
Cc: Aisheng Dong, dl-linux-imx, linux-arm-kernel, u.kleine-koenig
> -----Original Message-----
On 2019/9/12 20:12 Jurgen Lambrecht <J.Lambrecht@TELEVIC.com> wrote:
>
> On 9/12/19 11:45 AM, Jurgen Lambrecht wrote:
> > CAUTION: This Email originated from outside Televic. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> >
> >
> > On 9/12/19 4:06 AM, Robin Gong wrote:
> >>> (this looked the most interesting commit)
> >> I identified this issue which caused by
> >> SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3 (41)exceed the structure
> >> sdma_script_start_addrs(40) so that illegal memory touch, such as
> >> slob block header, thus kernel trap into while() loop forever in slob_free().
> Please see the below code piece in sdma_add_scripts().
> >> for (i = 0; i < sdma->script_number; i++)
> >> if (addr_arr[i] > 0)
> >> saddr_arr[i] = addr_arr[i]; That issue was
> >> brought by commit a572460be9cf (dmaengine: imx-sdma:
> >> Add support for version 3 firmware) because the
> >> SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3
> >> (38->41 3 scripts added) not align with script number added in
> >> sdma_script_start_addrs(2 scripts). Please have a try with the below
> >> patch:
> >> diff --git a/include/linux/platform_data/dma-imx-sdma.h
> >> b/include/linux/platform_data/dma-imx-sdma.h
> >> index 6eaa53c..30e676b 100644
> >> --- a/include/linux/platform_data/dma-imx-sdma.h
> >> +++ b/include/linux/platform_data/dma-imx-sdma.h
> >> @@ -51,7 +51,10 @@ struct sdma_script_start_addrs {
> >> /* End of v2 array */
> >> s32 zcanfd_2_mcu_addr;
> >> s32 zqspi_2_mcu_addr;
> >> + s32 mcu_2_ecspi_addr;
> >> /* End of v3 array */
> >> + s32 mcu_2_zqspi_addr;
> >> + /* End of v4 array */
> >> };
> >>
> > Yes, this patch solves it! I can now use SLOB slab allocator. I tried
> > several reboots and power cycles.
> > I tried with different dts (without earlycon, without sdma on uart and
> > ecspi).
> > I did not try other kernels, only 4.19.66+fscl with our patches and
> > sdma
> > v3.5 built-in.
> I tried again v5.3 rc6 with SLOB, but it still booted OK, then took latest v5.3 rc8
> from mainline, and it also boots OK - tried several times also with power cycle.
>
> Then I added your patch, and it "still" boots :-). So OK:
>
> Linux imx6ul-33927318 5.3.0-rc8-dirty #3 PREEMPT Thu Sep 12 13:54:25 CEST
> 2019 armv7l GNU/Linux
Thanks for your test on v5.3. Yes, that potential memory corrupt only happen
on one word, most time it may hid well during kernel bootup, and it's so luck
for us that your 'SLOB + firmware built in' case could expose it :).Thanks for
your report, I'll post a formal patch for review later.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
2019-09-12 14:19 ` Robin Gong
@ 2019-09-12 14:40 ` Russell King - ARM Linux admin
2019-09-12 14:47 ` Robin Gong
0 siblings, 1 reply; 16+ messages in thread
From: Russell King - ARM Linux admin @ 2019-09-12 14:40 UTC (permalink / raw)
To: Robin Gong
Cc: Aisheng Dong, Jurgen Lambrecht, dl-linux-imx, u.kleine-koenig,
Leonard Crestez, Fabio Estevam, linux-arm-kernel
On Thu, Sep 12, 2019 at 02:19:51PM +0000, Robin Gong wrote:
> > -----Original Message-----
> On 2019/9/12 20:12 Jurgen Lambrecht <J.Lambrecht@TELEVIC.com> wrote:
> >
> > On 9/12/19 11:45 AM, Jurgen Lambrecht wrote:
> > > CAUTION: This Email originated from outside Televic. Do not click links or
> > open attachments unless you recognize the sender and know the content is
> > safe.
> > >
> > >
> > > On 9/12/19 4:06 AM, Robin Gong wrote:
> > >>> (this looked the most interesting commit)
> > >> I identified this issue which caused by
> > >> SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3 (41)exceed the structure
> > >> sdma_script_start_addrs(40) so that illegal memory touch, such as
> > >> slob block header, thus kernel trap into while() loop forever in slob_free().
> > Please see the below code piece in sdma_add_scripts().
> > >> for (i = 0; i < sdma->script_number; i++)
> > >> if (addr_arr[i] > 0)
> > >> saddr_arr[i] = addr_arr[i]; That issue was
> > >> brought by commit a572460be9cf (dmaengine: imx-sdma:
> > >> Add support for version 3 firmware) because the
> > >> SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3
> > >> (38->41 3 scripts added) not align with script number added in
> > >> sdma_script_start_addrs(2 scripts). Please have a try with the below
> > >> patch:
> > >> diff --git a/include/linux/platform_data/dma-imx-sdma.h
> > >> b/include/linux/platform_data/dma-imx-sdma.h
> > >> index 6eaa53c..30e676b 100644
> > >> --- a/include/linux/platform_data/dma-imx-sdma.h
> > >> +++ b/include/linux/platform_data/dma-imx-sdma.h
> > >> @@ -51,7 +51,10 @@ struct sdma_script_start_addrs {
> > >> /* End of v2 array */
> > >> s32 zcanfd_2_mcu_addr;
> > >> s32 zqspi_2_mcu_addr;
> > >> + s32 mcu_2_ecspi_addr;
> > >> /* End of v3 array */
> > >> + s32 mcu_2_zqspi_addr;
> > >> + /* End of v4 array */
> > >> };
> > >>
> > > Yes, this patch solves it! I can now use SLOB slab allocator. I tried
> > > several reboots and power cycles.
> > > I tried with different dts (without earlycon, without sdma on uart and
> > > ecspi).
> > > I did not try other kernels, only 4.19.66+fscl with our patches and
> > > sdma
> > > v3.5 built-in.
> > I tried again v5.3 rc6 with SLOB, but it still booted OK, then took latest v5.3 rc8
> > from mainline, and it also boots OK - tried several times also with power cycle.
> >
> > Then I added your patch, and it "still" boots :-). So OK:
> >
> > Linux imx6ul-33927318 5.3.0-rc8-dirty #3 PREEMPT Thu Sep 12 13:54:25 CEST
> > 2019 armv7l GNU/Linux
> Thanks for your test on v5.3. Yes, that potential memory corrupt only happen
> on one word, most time it may hid well during kernel bootup, and it's so luck
> for us that your 'SLOB + firmware built in' case could expose it :).Thanks for
> your report, I'll post a formal patch for review later.
It sounds like this code is very fragile, and it seems like this mistake
could easily happen again in the future.
How about ensuring that sdma->script_number * sizeof(u32) <
sizeof(struct sdma_script_start_addrs), since sdma_add_scripts() has
no protection against overrunning the structure size.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
2019-09-12 14:40 ` Russell King - ARM Linux admin
@ 2019-09-12 14:47 ` Robin Gong
0 siblings, 0 replies; 16+ messages in thread
From: Robin Gong @ 2019-09-12 14:47 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Aisheng Dong, Jurgen Lambrecht, dl-linux-imx, u.kleine-koenig,
Leonard Crestez, Fabio Estevam, linux-arm-kernel
On 2019/9/12 22:40 Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> On Thu, Sep 12, 2019 at 02:19:51PM +0000, Robin Gong wrote:
> > > -----Original Message-----
> > On 2019/9/12 20:12 Jurgen Lambrecht <J.Lambrecht@TELEVIC.com> wrote:
> > >
> > > On 9/12/19 11:45 AM, Jurgen Lambrecht wrote:
> > > > CAUTION: This Email originated from outside Televic. Do not click
> > > > links or
> > > open attachments unless you recognize the sender and know the
> > > content is safe.
> > > >
> > > >
> > > > On 9/12/19 4:06 AM, Robin Gong wrote:
> > > >>> (this looked the most interesting commit)
> > > >> I identified this issue which caused by
> > > >> SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3 (41)exceed the structure
> > > >> sdma_script_start_addrs(40) so that illegal memory touch, such as
> > > >> slob block header, thus kernel trap into while() loop forever in
> slob_free().
> > > Please see the below code piece in sdma_add_scripts().
> > > >> for (i = 0; i < sdma->script_number; i++)
> > > >> if (addr_arr[i] > 0)
> > > >> saddr_arr[i] = addr_arr[i]; That issue
> > > >> was brought by commit a572460be9cf (dmaengine: imx-sdma:
> > > >> Add support for version 3 firmware) because the
> > > >> SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3
> > > >> (38->41 3 scripts added) not align with script number added in
> > > >> sdma_script_start_addrs(2 scripts). Please have a try with the
> > > >> below
> > > >> patch:
> > > >> diff --git a/include/linux/platform_data/dma-imx-sdma.h
> > > >> b/include/linux/platform_data/dma-imx-sdma.h
> > > >> index 6eaa53c..30e676b 100644
> > > >> --- a/include/linux/platform_data/dma-imx-sdma.h
> > > >> +++ b/include/linux/platform_data/dma-imx-sdma.h
> > > >> @@ -51,7 +51,10 @@ struct sdma_script_start_addrs {
> > > >> /* End of v2 array */
> > > >> s32 zcanfd_2_mcu_addr;
> > > >> s32 zqspi_2_mcu_addr;
> > > >> + s32 mcu_2_ecspi_addr;
> > > >> /* End of v3 array */
> > > >> + s32 mcu_2_zqspi_addr;
> > > >> + /* End of v4 array */
> > > >> };
> > > >>
> > > > Yes, this patch solves it! I can now use SLOB slab allocator. I
> > > > tried several reboots and power cycles.
> > > > I tried with different dts (without earlycon, without sdma on uart
> > > > and ecspi).
> > > > I did not try other kernels, only 4.19.66+fscl with our patches
> > > > and sdma
> > > > v3.5 built-in.
> > > I tried again v5.3 rc6 with SLOB, but it still booted OK, then took
> > > latest v5.3 rc8 from mainline, and it also boots OK - tried several times also
> with power cycle.
> > >
> > > Then I added your patch, and it "still" boots :-). So OK:
> > >
> > > Linux imx6ul-33927318 5.3.0-rc8-dirty #3 PREEMPT Thu Sep 12 13:54:25
> > > CEST
> > > 2019 armv7l GNU/Linux
> > Thanks for your test on v5.3. Yes, that potential memory corrupt only
> > happen on one word, most time it may hid well during kernel bootup,
> > and it's so luck for us that your 'SLOB + firmware built in' case
> > could expose it :).Thanks for your report, I'll post a formal patch for review
> later.
>
> It sounds like this code is very fragile, and it seems like this mistake could
> easily happen again in the future.
>
> How about ensuring that sdma->script_number * sizeof(u32) < sizeof(struct
> sdma_script_start_addrs), since sdma_add_scripts() has no protection against
> overrunning the structure size.
Yes, that's what my thought: add conditional checking, and warning log triggered
if sdma->script_number * sizeof(u32) > sizeof(struct sdma_script_start_addrs).
>
> --
> RMK's Patch system:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> armlinux.org.uk%2Fdeveloper%2Fpatches%2F&data=02%7C01%7Cyibin.
> gong%40nxp.com%7C45c63241e494447ce5b508d7378f28d5%7C686ea1d3bc
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C637038960316627129&sdata=d
> QRdAxrau8EL2X7etr9MlKxNccoe70jM2dsMeUM3%2BbY%3D&reserved=
> 0
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps
> up According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2019-09-12 14:48 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-27 13:35 FYI: imx-sdma firmware is not compatible with SLUB slab allocator Jurgen Lambrecht
2019-08-27 15:04 ` Leonard Crestez
2019-08-28 9:26 ` Jurgen Lambrecht
2019-08-28 14:05 ` Robin Gong
2019-08-29 6:23 ` Jurgen Lambrecht
2019-09-03 5:57 ` Robin Gong
2019-09-03 14:32 ` Jurgen Lambrecht
2019-09-03 14:48 ` Leonard Crestez
2019-09-04 14:26 ` Jurgen Lambrecht
2019-09-12 6:33 ` Uwe Kleine-König
2019-09-12 2:06 ` Robin Gong
2019-09-12 9:45 ` Jurgen Lambrecht
2019-09-12 12:12 ` Jurgen Lambrecht
2019-09-12 14:19 ` Robin Gong
2019-09-12 14:40 ` Russell King - ARM Linux admin
2019-09-12 14:47 ` Robin Gong
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).