Re: arm-smmu 5000000.iommu: Cannot accommodate DMA offset for IOMMU page tables
On 10/15/20 12:48 AM, Christoph Hellwig wrote: > On Sun, Oct 11, 2020 at 05:53:37AM +1100, Stephen Rothwell wrote: >> Hi Naresh, >> >> Just adding Christoph and Jim to cc] > > Well, a Cc doesn't help on its own. Can you send an actual bug > report including the setup, warnings and error messages, a bisection > result and the usual suspects? I don't believe there is a DMA regression for you to look at, this was solved a long time ago thanks to Robin, here is the beginning of the thread: https://lore.kernel.org/lkml/ca+g9fyvuq58q+gswnzni0skshbubuqz-uak3tasx26v_a7y...@mail.gmail.com/ -- Florian
Re: arm-smmu 5000000.iommu: Cannot accommodate DMA offset for IOMMU page tables
On Sun, Oct 11, 2020 at 05:53:37AM +1100, Stephen Rothwell wrote: > Hi Naresh, > > Just adding Christoph and Jim to cc] Well, a Cc doesn't help on its own. Can you send an actual bug report including the setup, warnings and error messages, a bisection result and the usual suspects?
Re: arm-smmu 5000000.iommu: Cannot accommodate DMA offset for IOMMU page tables
Hello, Fabio Estevam wrote on Wed, 14 Oct 2020 09:28:49 -0300: > Hi Florian, > > On Sun, Oct 11, 2020 at 6:59 PM Florian Fainelli wrote: > > > however the NAND warning still remains. Someone else familiar with these > > NXP development boards should fix the DTS so as to provide the require > > ECC strength property. > > The ECC NAND warning looks like a regression. > > I had originally reported it for an imx27 board and now I also pointed > out that it also affects Layerscape: > https://lore.kernel.org/linux-mtd/20201013193652.0c535c7c@xps13/T/#m09fad7eacdf86aee0834bbd8863d6d5ee2e69f8c I think this thread initially reported two distinct defects, one has been solved, the second one is in my hands but I couldn't find the root cause yet. I tried to reproduce, without luck, with another NAND controller. If someone has an imx based board and a NAND controller on it, I would appreciate some help. Thanks, Miquèl
Re: arm-smmu 5000000.iommu: Cannot accommodate DMA offset for IOMMU page tables
Hi Florian, On Sun, Oct 11, 2020 at 6:59 PM Florian Fainelli wrote: > however the NAND warning still remains. Someone else familiar with these > NXP development boards should fix the DTS so as to provide the require > ECC strength property. The ECC NAND warning looks like a regression. I had originally reported it for an imx27 board and now I also pointed out that it also affects Layerscape: https://lore.kernel.org/linux-mtd/20201013193652.0c535c7c@xps13/T/#m09fad7eacdf86aee0834bbd8863d6d5ee2e69f8c Thanks, Fabio Estevam
Re: arm-smmu 5000000.iommu: Cannot accommodate DMA offset for IOMMU page tables
+Abhimanyu, Ioana, Fabio On 10/11/2020 1:36 PM, Jim Quinlan wrote: On Sat, Oct 10, 2020 at 2:53 PM Stephen Rothwell wrote: Hi Naresh, Just adding Christoph and Jim to cc] On Fri, 9 Oct 2020 19:26:24 +0530 Naresh Kamboju wrote: On Fri, 9 Oct 2020 at 19:24, Naresh Kamboju wrote: On Thu, 24 Sep 2020 at 15:26, Joerg Roedel wrote: On Thu, Sep 24, 2020 at 10:36:47AM +0100, Robin Murphy wrote: Yes, the issue was introduced by one of the changes in "dma-mapping: introduce DMA range map, supplanting dma_pfn_offset", so it only existed in the dma-mapping/for-next branch anyway. FYI, The reported problem still exists on 5.9.0-rc8-next-20201009. [1.843814] Driver must set ecc.strength when using hardware ECC [1.849847] WARNING: CPU: 4 PID: 1 at drivers/mtd/nand/raw/nand_base.c:5687 nand_scan_with_ids+0x1450/0x1470 [1.859676] Modules linked in: [1.862730] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc8-next-20201009 #1 [1.870125] Hardware name: Freescale Layerscape 2088A RDB Board (DT) [1.876478] pstate: 4005 (nZcv daif -PAN -UAO -TCO BTYPE=--) [1.882483] pc : nand_scan_with_ids+0x1450/0x1470 [1.887183] lr : nand_scan_with_ids+0x1450/0x1470 Hi, I'm having a hard time coming up with a theory regarding how a commit concerning DMA offsets can affect the operation of a NAND driver that appears not to use DMA or the dma-ranges property. Does anyone else have some ideas, or is there perhaps someone familiar with this test configuration that I can correspond with to get to the bottom of the warning? I believe you are given only a partial warning and just a glimpse of the thread here which is why understanding the connection to the dma ranges parsing is not clear. The start of the thread can be found here: https://lore.kernel.org/lkml/ca+g9fyvuq58q+gswnzni0skshbubuqz-uak3tasx26v_a7y...@mail.gmail.com/ Robin indicated that the IOMMU probe failure was fixed with: https://lore.kernel.org/linux-iommu/daedc9364a19dc07487e4d07b8768b1e5934abd4.1600700881.git.robin.mur...@arm.com/T/#u which is confirmed with the new log from Naresh: https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20201009/testrun/3284876/suite/linux-log-parser/test/check-kernel-warning-92014/log however the NAND warning still remains. Someone else familiar with these NXP development boards should fix the DTS so as to provide the require ECC strength property. -- Florian
Re: arm-smmu 5000000.iommu: Cannot accommodate DMA offset for IOMMU page tables
On Sat, Oct 10, 2020 at 2:53 PM Stephen Rothwell wrote: > > Hi Naresh, > > Just adding Christoph and Jim to cc] > > On Fri, 9 Oct 2020 19:26:24 +0530 Naresh Kamboju > wrote: > > > > On Fri, 9 Oct 2020 at 19:24, Naresh Kamboju > > wrote: > > > > > > > > > > > > On Thu, 24 Sep 2020 at 15:26, Joerg Roedel wrote: > > > > > > > > On Thu, Sep 24, 2020 at 10:36:47AM +0100, Robin Murphy wrote: > > > > > Yes, the issue was introduced by one of the changes in "dma-mapping: > > > > > introduce DMA range map, supplanting dma_pfn_offset", so it only > > > > > existed in > > > > > the dma-mapping/for-next branch anyway. > > > > > > > FYI, > > The reported problem still exists on 5.9.0-rc8-next-20201009. > > > > [1.843814] Driver must set ecc.strength when using hardware ECC > > [1.849847] WARNING: CPU: 4 PID: 1 at > > drivers/mtd/nand/raw/nand_base.c:5687 nand_scan_with_ids+0x1450/0x1470 > > [1.859676] Modules linked in: > > [1.862730] CPU: 4 PID: 1 Comm: swapper/0 Not tainted > > 5.9.0-rc8-next-20201009 #1 > > [1.870125] Hardware name: Freescale Layerscape 2088A RDB Board (DT) > > [1.876478] pstate: 4005 (nZcv daif -PAN -UAO -TCO BTYPE=--) > > [1.882483] pc : nand_scan_with_ids+0x1450/0x1470 > > [1.887183] lr : nand_scan_with_ids+0x1450/0x1470 Hi, I'm having a hard time coming up with a theory regarding how a commit concerning DMA offsets can affect the operation of a NAND driver that appears not to use DMA or the dma-ranges property. Does anyone else have some ideas, or is there perhaps someone familiar with this test configuration that I can correspond with to get to the bottom of the warning? Thanks, Jim Quinlan Broadcom STB > > > > full test log, > > https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20201009/testrun/3284876/suite/linux-log-parser/test/check-kernel-warning-92014/log > > > > > > > > > > Okay, alright then. > > > > > > > > - Naresh > > -- > Cheers, > Stephen Rothwell smime.p7s Description: S/MIME Cryptographic Signature
Re: arm-smmu 5000000.iommu: Cannot accommodate DMA offset for IOMMU page tables
Hi Naresh, Just adding Christoph and Jim to cc] On Fri, 9 Oct 2020 19:26:24 +0530 Naresh Kamboju wrote: > > On Fri, 9 Oct 2020 at 19:24, Naresh Kamboju wrote: > > > > > > > > On Thu, 24 Sep 2020 at 15:26, Joerg Roedel wrote: > > > > > > On Thu, Sep 24, 2020 at 10:36:47AM +0100, Robin Murphy wrote: > > > > Yes, the issue was introduced by one of the changes in "dma-mapping: > > > > introduce DMA range map, supplanting dma_pfn_offset", so it only > > > > existed in > > > > the dma-mapping/for-next branch anyway. > > > > FYI, > The reported problem still exists on 5.9.0-rc8-next-20201009. > > [1.843814] Driver must set ecc.strength when using hardware ECC > [1.849847] WARNING: CPU: 4 PID: 1 at > drivers/mtd/nand/raw/nand_base.c:5687 nand_scan_with_ids+0x1450/0x1470 > [1.859676] Modules linked in: > [1.862730] CPU: 4 PID: 1 Comm: swapper/0 Not tainted > 5.9.0-rc8-next-20201009 #1 > [1.870125] Hardware name: Freescale Layerscape 2088A RDB Board (DT) > [1.876478] pstate: 4005 (nZcv daif -PAN -UAO -TCO BTYPE=--) > [1.882483] pc : nand_scan_with_ids+0x1450/0x1470 > [1.887183] lr : nand_scan_with_ids+0x1450/0x1470 > > full test log, > https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20201009/testrun/3284876/suite/linux-log-parser/test/check-kernel-warning-92014/log > > > > > > > Okay, alright then. > > > > > - Naresh -- Cheers, Stephen Rothwell pgpvghNXseEPS.pgp Description: OpenPGP digital signature
Re: arm-smmu 5000000.iommu: Cannot accommodate DMA offset for IOMMU page tables
On Fri, 9 Oct 2020 at 19:24, Naresh Kamboju wrote: > > > > On Thu, 24 Sep 2020 at 15:26, Joerg Roedel wrote: > > > > On Thu, Sep 24, 2020 at 10:36:47AM +0100, Robin Murphy wrote: > > > Yes, the issue was introduced by one of the changes in "dma-mapping: > > > introduce DMA range map, supplanting dma_pfn_offset", so it only existed > > > in > > > the dma-mapping/for-next branch anyway. > FYI, The reported problem still exists on 5.9.0-rc8-next-20201009. [1.843814] Driver must set ecc.strength when using hardware ECC [1.849847] WARNING: CPU: 4 PID: 1 at drivers/mtd/nand/raw/nand_base.c:5687 nand_scan_with_ids+0x1450/0x1470 [1.859676] Modules linked in: [1.862730] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc8-next-20201009 #1 [1.870125] Hardware name: Freescale Layerscape 2088A RDB Board (DT) [1.876478] pstate: 4005 (nZcv daif -PAN -UAO -TCO BTYPE=--) [1.882483] pc : nand_scan_with_ids+0x1450/0x1470 [1.887183] lr : nand_scan_with_ids+0x1450/0x1470 full test log, https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20201009/testrun/3284876/suite/linux-log-parser/test/check-kernel-warning-92014/log > > > > Okay, alright then. > > - Naresh
Re: arm-smmu 5000000.iommu: Cannot accommodate DMA offset for IOMMU page tables
On Thu, 24 Sep 2020 at 15:26, Joerg Roedel wrote: > > On Thu, Sep 24, 2020 at 10:36:47AM +0100, Robin Murphy wrote: > > Yes, the issue was introduced by one of the changes in "dma-mapping: > > introduce DMA range map, supplanting dma_pfn_offset", so it only existed in > > the dma-mapping/for-next branch anyway. FYI, The reported problem still exists > > Okay, alright then. >
Re: arm-smmu 5000000.iommu: Cannot accommodate DMA offset for IOMMU page tables
On Thu, Sep 24, 2020 at 10:36:47AM +0100, Robin Murphy wrote: > Yes, the issue was introduced by one of the changes in "dma-mapping: > introduce DMA range map, supplanting dma_pfn_offset", so it only existed in > the dma-mapping/for-next branch anyway. Okay, alright then.
Re: arm-smmu 5000000.iommu: Cannot accommodate DMA offset for IOMMU page tables
On 2020-09-24 10:25, Joerg Roedel wrote: Hi Robin, On Thu, Sep 24, 2020 at 10:08:46AM +0100, Robin Murphy wrote: This should be fixed by https://lore.kernel.org/linux-iommu/daedc9364a19dc07487e4d07b8768b1e5934abd4.1600700881.git.robin.mur...@arm.com/T/#u (already in linux-next). Thanks! The question remains why this goes through the dma-mapping tree, was it caused by a patch there? Yes, the issue was introduced by one of the changes in "dma-mapping: introduce DMA range map, supplanting dma_pfn_offset", so it only existed in the dma-mapping/for-next branch anyway. Robin.
Re: arm-smmu 5000000.iommu: Cannot accommodate DMA offset for IOMMU page tables
Hi Robin, On Thu, Sep 24, 2020 at 10:08:46AM +0100, Robin Murphy wrote: > This should be fixed by > https://lore.kernel.org/linux-iommu/daedc9364a19dc07487e4d07b8768b1e5934abd4.1600700881.git.robin.mur...@arm.com/T/#u > (already in linux-next). Thanks! The question remains why this goes through the dma-mapping tree, was it caused by a patch there? Regards, Joerg
Re: arm-smmu 5000000.iommu: Cannot accommodate DMA offset for IOMMU page tables
Hi Joerg, On 2020-09-24 10:03, Joerg Roedel wrote: Adding Will and Robin. This should be fixed by https://lore.kernel.org/linux-iommu/daedc9364a19dc07487e4d07b8768b1e5934abd4.1600700881.git.robin.mur...@arm.com/T/#u (already in linux-next). Thanks, Robin. On Mon, Sep 21, 2020 at 06:50:40PM +0530, Naresh Kamboju wrote: arm64 Freescale Layerscape 2088A RDB Board boot failed with linux-next 5.9.0-rc5-next-20200921 kernel tag version. The kernel warning and then kernel panic happened. Reported-by: Naresh Kamboju metadata: git branch: master git repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next git commit: b10b8ad862118bf42c28a98b0f067619aadcfb23 git describe: next-20200921 make_kernelversion: 5.9.0-rc5 kernel-config: https://builds.tuxbuild.com/GxPuM0SSznSoSYYG8deYpQ/kernel.config crash log, [1.811830] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x48 [1.818202] nand: Micron MT29F16G08ABACAWP [1.822314] nand: 2048 MiB, SLC, erase size: 512 KiB, page size: 4096, OOB size: 224 [1.830078] [ cut here ] [1.834703] Driver must set ecc.strength when using hardware ECC [1.840739] WARNING: CPU: 1 PID: 1 at drivers/mtd/nand/raw/nand_base.c:5671 nand_scan_with_ids+0x110c/0x1498 [1.850568] Modules linked in: [1.853621] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc5-next-20200921 #1 [1.861015] Hardware name: Freescale Layerscape 2088A RDB Board (DT) [1.867368] pstate: 4005 (nZcv daif -PAN -UAO -TCO BTYPE=--) [1.873373] pc : nand_scan_with_ids+0x110c/0x1498 [1.878073] lr : nand_scan_with_ids+0x110c/0x1498 [1.882774] sp : 80001005ba50 [1.886083] x29: 80001005ba50 x28: [1.891395] x27: 0082edf98638 x26: 0048 [1.896706] x25: 002c x24: 0082edf98578 [1.902018] x23: 0001 x22: 0082ee6b [1.907329] x21: 0082edf98840 x20: [1.912640] x19: 0082edf98080 x18: 0010 [1.917951] x17: 0010 x16: 833b5ff2 [1.923262] x15: 0082ee6b0480 x14: [1.928572] x13: 80009005b737 x12: 80001005b73f [1.933883] x11: 80001005ba50 x10: 80001005ba50 [1.939194] x9 : dc379157bfbc x8 : 657274732e636365 [1.944504] x7 : 2074657320747375 x6 : dc37937ba000 [1.949815] x5 : dc37937baa58 x4 : 80001005b840 [1.955125] x3 : x2 : 0082ee6b [1.960436] x1 : 4732f0d38a403700 x0 : [1.965748] Call trace: [1.968189] nand_scan_with_ids+0x110c/0x1498 [1.972542] fsl_ifc_nand_probe+0x474/0x6e0 [1.976723] platform_drv_probe+0x5c/0xb0 [1.980729] really_probe+0xf0/0x4d8 [1.984300] driver_probe_device+0xfc/0x168 [1.988480] device_driver_attach+0x7c/0x88 [1.992659] __driver_attach+0xac/0x178 [1.996490] bus_for_each_dev+0x78/0xc8 [2.000321] driver_attach+0x2c/0x38 [2.003893] bus_add_driver+0x14c/0x230 [2.007724] driver_register+0x6c/0x128 [2.011555] __platform_driver_register+0x50/0x60 [2.016258] fsl_ifc_nand_driver_init+0x24/0x30 [2.020786] do_one_initcall+0x4c/0x2d0 [2.024560] ata1: SATA link down (SStatus 0 SControl 300) [2.024618] kernel_init_freeable+0x214/0x280 [2.024624] kernel_init+0x1c/0x120 [2.037849] ret_from_fork+0x10/0x30 [2.041420] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc5-next-20200921 #1 [2.048815] Hardware name: Freescale Layerscape 2088A RDB Board (DT) [2.055166] Call trace: [2.057606] dump_backtrace+0x0/0x1e0 [2.061263] show_stack+0x20/0x30 [2.064574] dump_stack+0xf8/0x168 [2.067972] __warn+0xfc/0x178 [2.071023] report_bug+0xfc/0x170 [2.074419] bug_handler+0x28/0x70 [2.077816] call_break_hook+0x70/0x88 [2.080559] ata2: SATA link down (SStatus 0 SControl 300) [2.081560] brk_handler+0x24/0x68 [2.081566] do_debug_exception+0xb8/0x130 [2.094442] el1_sync_handler+0xd8/0x120 [2.098360] el1_sync+0x80/0x100 [2.101583] nand_scan_with_ids+0x110c/0x1498 [2.105935] fsl_ifc_nand_probe+0x474/0x6e0 [2.110115] platform_drv_probe+0x5c/0xb0 [2.114120] really_probe+0xf0/0x4d8 [2.117691] driver_probe_device+0xfc/0x168 [2.121871] device_driver_attach+0x7c/0x88 [2.126050] __driver_attach+0xac/0x178 [2.129882] bus_for_each_dev+0x78/0xc8 [2.133714] driver_attach+0x2c/0x38 [2.137284] bus_add_driver+0x14c/0x230 [2.141116] driver_register+0x6c/0x128 [2.144946] __platform_driver_register+0x50/0x60 [2.149647] fsl_ifc_nand_driver_init+0x24/0x30 [2.154173] do_one_initcall+0x4c/0x2d0 [2.158004] kernel_init_freeable+0x214/0x280 [2.162358] kernel_init+0x1c/0x120 [2.165841] ret_from_fork+0x10/0x30 [2.169415] ---[ end trace d051012f465b08eb ]--- [2.174073] fsl,ifc-nand: probe of 53000.nand failed with error -22 [2.181882
Re: arm-smmu 5000000.iommu: Cannot accommodate DMA offset for IOMMU page tables
Adding Will and Robin. On Mon, Sep 21, 2020 at 06:50:40PM +0530, Naresh Kamboju wrote: > arm64 Freescale Layerscape 2088A RDB Board boot failed with linux-next > 5.9.0-rc5-next-20200921 kernel tag version. The kernel warning and then > kernel panic happened. > > Reported-by: Naresh Kamboju > > metadata: > git branch: master > git repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next > git commit: b10b8ad862118bf42c28a98b0f067619aadcfb23 > git describe: next-20200921 > make_kernelversion: 5.9.0-rc5 > kernel-config: > https://builds.tuxbuild.com/GxPuM0SSznSoSYYG8deYpQ/kernel.config > > > crash log, > > [1.811830] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x48 > [1.818202] nand: Micron MT29F16G08ABACAWP > [1.822314] nand: 2048 MiB, SLC, erase size: 512 KiB, page size: > 4096, OOB size: 224 > [1.830078] [ cut here ] > [1.834703] Driver must set ecc.strength when using hardware ECC > [1.840739] WARNING: CPU: 1 PID: 1 at > drivers/mtd/nand/raw/nand_base.c:5671 nand_scan_with_ids+0x110c/0x1498 > [1.850568] Modules linked in: > [1.853621] CPU: 1 PID: 1 Comm: swapper/0 Not tainted > 5.9.0-rc5-next-20200921 #1 > [1.861015] Hardware name: Freescale Layerscape 2088A RDB Board (DT) > [1.867368] pstate: 4005 (nZcv daif -PAN -UAO -TCO BTYPE=--) > [1.873373] pc : nand_scan_with_ids+0x110c/0x1498 > [1.878073] lr : nand_scan_with_ids+0x110c/0x1498 > [1.882774] sp : 80001005ba50 > [1.886083] x29: 80001005ba50 x28: > [1.891395] x27: 0082edf98638 x26: 0048 > [1.896706] x25: 002c x24: 0082edf98578 > [1.902018] x23: 0001 x22: 0082ee6b > [1.907329] x21: 0082edf98840 x20: > [1.912640] x19: 0082edf98080 x18: 0010 > [1.917951] x17: 0010 x16: 833b5ff2 > [1.923262] x15: 0082ee6b0480 x14: > [1.928572] x13: 80009005b737 x12: 80001005b73f > [1.933883] x11: 80001005ba50 x10: 80001005ba50 > [1.939194] x9 : dc379157bfbc x8 : 657274732e636365 > [1.944504] x7 : 2074657320747375 x6 : dc37937ba000 > [1.949815] x5 : dc37937baa58 x4 : 80001005b840 > [1.955125] x3 : x2 : 0082ee6b > [1.960436] x1 : 4732f0d38a403700 x0 : > [1.965748] Call trace: > [1.968189] nand_scan_with_ids+0x110c/0x1498 > [1.972542] fsl_ifc_nand_probe+0x474/0x6e0 > [1.976723] platform_drv_probe+0x5c/0xb0 > [1.980729] really_probe+0xf0/0x4d8 > [1.984300] driver_probe_device+0xfc/0x168 > [1.988480] device_driver_attach+0x7c/0x88 > [1.992659] __driver_attach+0xac/0x178 > [1.996490] bus_for_each_dev+0x78/0xc8 > [2.000321] driver_attach+0x2c/0x38 > [2.003893] bus_add_driver+0x14c/0x230 > [2.007724] driver_register+0x6c/0x128 > [2.011555] __platform_driver_register+0x50/0x60 > [2.016258] fsl_ifc_nand_driver_init+0x24/0x30 > [2.020786] do_one_initcall+0x4c/0x2d0 > [2.024560] ata1: SATA link down (SStatus 0 SControl 300) > [2.024618] kernel_init_freeable+0x214/0x280 > [2.024624] kernel_init+0x1c/0x120 > [2.037849] ret_from_fork+0x10/0x30 > [2.041420] CPU: 1 PID: 1 Comm: swapper/0 Not tainted > 5.9.0-rc5-next-20200921 #1 > [2.048815] Hardware name: Freescale Layerscape 2088A RDB Board (DT) > [2.055166] Call trace: > [2.057606] dump_backtrace+0x0/0x1e0 > [2.061263] show_stack+0x20/0x30 > [2.064574] dump_stack+0xf8/0x168 > [2.067972] __warn+0xfc/0x178 > [2.071023] report_bug+0xfc/0x170 > [2.074419] bug_handler+0x28/0x70 > [2.077816] call_break_hook+0x70/0x88 > [2.080559] ata2: SATA link down (SStatus 0 SControl 300) > [2.081560] brk_handler+0x24/0x68 > [2.081566] do_debug_exception+0xb8/0x130 > [2.094442] el1_sync_handler+0xd8/0x120 > [2.098360] el1_sync+0x80/0x100 > [2.101583] nand_scan_with_ids+0x110c/0x1498 > [2.105935] fsl_ifc_nand_probe+0x474/0x6e0 > [2.110115] platform_drv_probe+0x5c/0xb0 > [2.114120] really_probe+0xf0/0x4d8 > [2.117691] driver_probe_device+0xfc/0x168 > [2.121871] device_driver_attach+0x7c/0x88 > [2.126050] __driver_attach+0xac/0x178 > [2.129882] bus_for_each_dev+0x78/0xc8 > [2.133714] driver_attach+0x2c/0x38 > [2.137284] bus_add_driver+0x14c/0x230 > [2.141116] driver_register+0x6c/0x128 > [2.144946] __platform_driver_register+0x50/0x60 > [2.149647] fsl_ifc_nand_driver_init+0x24/0x30 > [2.154173] do_one_initcall+0x4c/0x2d0 > [2.158004] kernel_init_freeable+0x214/0x280 > [2.162358] kernel_init+0x1c/0x120 > [2.165841] ret_from_fork+0x10/0x30 > [2.169415] ---[ end trace d051012f465b08eb ]--- > [2.174073] fsl,ifc-nand: probe of 53000.nand failed with error -22 > [2.181882] spi-nor spi0.0: unrecognized JEDEC id by
Re: arm-smmu 5000000.iommu: Cannot accommodate DMA offset for IOMMU page tables
On 2020-09-21 14:20, Naresh Kamboju wrote: [...] [2.256403] e1000e :01:00.0: Adding to iommu group 0 [2.261733] arm-smmu 500.iommu: Cannot accommodate DMA offset for IOMMU page tables Ah, I know what's going on there - the dma_range_map stuff has overlooked a subtlety, but it's easily fixed. [2.269752] Unable to handle kernel NULL pointer dereference at virtual address ...although either way that's really not how we should subsequently handle failing to allocate a pagetable. I guess I'll take a look into what the deal is there as well :( Robin. [2.278544] Mem abort info: [2.281334] ESR = 0x9604 [2.284389] EC = 0x25: DABT (current EL), IL = 32 bits [2.289705] SET = 0, FnV = 0 [2.292759] EA = 0, S1PTW = 0 [2.295900] Data abort info: [2.298781] ISV = 0, ISS = 0x0004 [2.302618] CM = 0, WnR = 0 [2.305581] [] user address but active_mm is swapper [2.311941] Internal error: Oops: 9604 [#1] PREEMPT SMP [2.317512] Modules linked in: [2.320566] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW 5.9.0-rc5-next-20200921 #1 [2.329352] Hardware name: Freescale Layerscape 2088A RDB Board (DT) [2.335705] pstate: 6005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [2.341715] pc : arm_smmu_flush_iotlb_all+0x28/0x90 [2.346590] lr : iommu_create_device_direct_mappings.isra.0+0x1f0/0x218 [2.353203] sp : 80001005b9b0 [2.356511] x29: 80001005b9b0 x28: [2.361822] x27: dc3792e904e0 x26: 80001005ba48 [2.367134] x25: 0082ee6b x24: 0082ed88e0a8 [2.372445] x23: fff4 x22: 1000 [2.377755] x21: 80001005ba48 x20: [2.383066] x19: 0082cceeeb58 x18: 0010 [2.388377] x17: x16: 833b5ff2 [2.393688] x15: 0082ee6b0480 x14: 203a756d6d6f692e [2.398999] x13: 3030303030303520 x12: 61646f6d6d6f6363 [2.404311] x11: 6120746f6e6e6143 x10: 6f6620746573 [2.409622] x9 : dc3791d31078 x8 : 0082ed8ffd00 [2.414933] x7 : x6 : 003f [2.420244] x5 : 0040 x4 : 80001005b970 [2.425554] x3 : x2 : [2.430865] x1 : dc37927dd2f0 x0 : 0082cceeeb58 [2.436176] Call trace: [2.438618] arm_smmu_flush_iotlb_all+0x28/0x90 [2.443144] iommu_create_device_direct_mappings.isra.0+0x1f0/0x218 [2.449409] iommu_probe_device+0x6c/0x120 [2.453501] of_iommu_configure+0x134/0x218 [2.457683] of_dma_configure_id+0x110/0x2e8 [2.461950] pci_dma_configure+0x4c/0xd8 [2.465870] really_probe+0xac/0x4d8 [2.469441] driver_probe_device+0xfc/0x168 [2.473620] device_driver_attach+0x7c/0x88 [2.477799] __driver_attach+0xac/0x178 [2.481631] bus_for_each_dev+0x78/0xc8 [2.485463] driver_attach+0x2c/0x38 [2.489033] bus_add_driver+0x14c/0x230 [2.492865] driver_register+0x6c/0x128 [2.496696] __pci_register_driver+0x4c/0x58 [2.500964] e1000_init_module+0x44/0x50 [2.504882] do_one_initcall+0x4c/0x2d0 [2.508714] kernel_init_freeable+0x214/0x280 [2.513068] kernel_init+0x1c/0x120 [2.516552] ret_from_fork+0x10/0x30 [2.520124] Code: 910003fd a90153f3 aa0003f3 f85a8014 (f9400280) [2.526224] ---[ end trace d051012f465b08ec ]--- [2.530848] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b [2.538506] SMP: stopping secondary CPUs [2.542431] Kernel Offset: 0x5c378148 from 0x80001000 [2.548521] PHYS_OFFSET: 0xdb6ac000 [2.552700] CPU features: 0x0240022,21806008 [2.556965] Memory Limit: none full test log, https://lavalab.nxp.com/scheduler/job/86650#L849
