| Message ID | 20170905233241.GA19231@js1304-P5Q-DELUXE (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, * Joonsoo Kim <iamjoonsoo.kim@lge.com> [170905 16:32]: > I think that I made a mistake for configuration CONFIG_HIGHMEM=y and > CONFIG_HAVE_MEMBLOCK_NODE_MAP=y. In this case, the MOVABLE_ZONE can > be *!highmem*. Could you check that your configuration have above > options? CONFIG_HIGHMEM is set yeah. > And, could you check that following patch works for you? Does not seem to help, tried against next with just 9caf25f996e8 revert and also with 9caf25f996e8. Regards, Tony > ------------>8----------------- > diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c > index 38f0fde..4c39c92 100644 > --- a/arch/arm/mm/dma-mapping.c > +++ b/arch/arm/mm/dma-mapping.c > @@ -518,7 +518,7 @@ void __init dma_contiguous_remap(void) > * considered as highmem even if it's physical address belong > * to lowmem. Therefore, re-mapping isn't required. > */ > - if (!IS_ENABLED(CONFIG_HIGHMEM)) > + if (!is_highmem_idx(ZONE_MOVABLE)) > iotable_init(&map, 1); > } > } >
On Wed, Sep 06, 2017 at 06:30:57AM -0700, Tony Lindgren wrote: > Hi, > > * Joonsoo Kim <iamjoonsoo.kim@lge.com> [170905 16:32]: > > I think that I made a mistake for configuration CONFIG_HIGHMEM=y and > > CONFIG_HAVE_MEMBLOCK_NODE_MAP=y. In this case, the MOVABLE_ZONE can > > be *!highmem*. Could you check that your configuration have above > > options? > > CONFIG_HIGHMEM is set yeah. > > > And, could you check that following patch works for you? > > Does not seem to help, tried against next with just 9caf25f996e8 > revert and also with 9caf25f996e8. Oops. I misunderstood your problem. Could you test with CONFIG_DEBUG_VIRTUAL? After commit 9caf25f996e8, user for CMA memory should use to check PageHighmem in order to get proper virtual address of the page. If someone doesn't use it, it is possible to use wrong virtual address and it then causes the use of wrong physical address. CONFIG_DEBUG_VIRTUAL would catch this case. If it doesn't help, is there a way to test n900 configuration in QEMU? Thanks.
* Joonsoo Kim <iamjoonsoo.kim@lge.com> [170907 00:30]: > On Wed, Sep 06, 2017 at 06:30:57AM -0700, Tony Lindgren wrote: > > Hi, > > > > * Joonsoo Kim <iamjoonsoo.kim@lge.com> [170905 16:32]: > > > I think that I made a mistake for configuration CONFIG_HIGHMEM=y and > > > CONFIG_HAVE_MEMBLOCK_NODE_MAP=y. In this case, the MOVABLE_ZONE can > > > be *!highmem*. Could you check that your configuration have above > > > options? > > > > CONFIG_HIGHMEM is set yeah. > > > > > And, could you check that following patch works for you? > > > > Does not seem to help, tried against next with just 9caf25f996e8 > > revert and also with 9caf25f996e8. > > Oops. I misunderstood your problem. Could you test with > CONFIG_DEBUG_VIRTUAL? Sure. > After commit 9caf25f996e8, user for CMA memory should use to check > PageHighmem in order to get proper virtual address of the page. If > someone doesn't use it, it is possible to use wrong virtual address > and it then causes the use of wrong physical address. > CONFIG_DEBUG_VIRTUAL would catch this case. OK, no extra output of current next with CONFIG_DEBUG_VIRTUAL=y. Booting of n900 hangs with just the same error: save_secure_sram() returns 0000ff02 > If it doesn't help, is there a way to test n900 configuration in QEMU? I doubt that QEMU n900 boots in secure mode but instead shows the SoC as general purpose SoC. If so, you'd have to patch the omap3_save_secure_ram_context() to attempt to save secure RAM context in all cases. If that works then debugging with any omap3 board like beagleboard in QEMU should work. Regards, Tony
On Thu, Sep 07, 2017 at 09:16:51AM -0700, Tony Lindgren wrote: > * Joonsoo Kim <iamjoonsoo.kim@lge.com> [170907 00:30]: > > On Wed, Sep 06, 2017 at 06:30:57AM -0700, Tony Lindgren wrote: > > > Hi, > > > > > > * Joonsoo Kim <iamjoonsoo.kim@lge.com> [170905 16:32]: > > > > I think that I made a mistake for configuration CONFIG_HIGHMEM=y and > > > > CONFIG_HAVE_MEMBLOCK_NODE_MAP=y. In this case, the MOVABLE_ZONE can > > > > be *!highmem*. Could you check that your configuration have above > > > > options? > > > > > > CONFIG_HIGHMEM is set yeah. > > > > > > > And, could you check that following patch works for you? > > > > > > Does not seem to help, tried against next with just 9caf25f996e8 > > > revert and also with 9caf25f996e8. > > > > Oops. I misunderstood your problem. Could you test with > > CONFIG_DEBUG_VIRTUAL? > > Sure. > > > After commit 9caf25f996e8, user for CMA memory should use to check > > PageHighmem in order to get proper virtual address of the page. If > > someone doesn't use it, it is possible to use wrong virtual address > > and it then causes the use of wrong physical address. > > CONFIG_DEBUG_VIRTUAL would catch this case. > > OK, no extra output of current next with CONFIG_DEBUG_VIRTUAL=y. > Booting of n900 hangs with just the same error: > > save_secure_sram() returns 0000ff02 > > > If it doesn't help, is there a way to test n900 configuration in QEMU? > > I doubt that QEMU n900 boots in secure mode but instead shows > the SoC as general purpose SoC. If so, you'd have to patch the > omap3_save_secure_ram_context() to attempt to save secure RAM > context in all cases. If that works then debugging with any > omap3 board like beagleboard in QEMU should work. Sorry for late response. I tried to emulate beagle board by using QEMU and now I find the way and it works. However, it doesn't call omap3_save_secure_ram_context() due to different omap_type(). And, even if I call it forcibly, the system dies with prefetch abort regardless of commit 9caf25f996e8. Could you let me know the better way to test your situation? Anyway, could you test linux-next with 'CONFIG_HIGHMEM = n'? I'd like to know if the issue is related to the change that all CMA memory is managed like as highmem. Thanks.
On Fri, Sep 15, 2017 at 03:18:18PM +0200, Pavel Machek wrote: > Hi! > > > > After commit 9caf25f996e8, user for CMA memory should use to check > > > PageHighmem in order to get proper virtual address of the page. If > > > someone doesn't use it, it is possible to use wrong virtual address > > > and it then causes the use of wrong physical address. > > > CONFIG_DEBUG_VIRTUAL would catch this case. > > > > OK, no extra output of current next with CONFIG_DEBUG_VIRTUAL=y. > > Booting of n900 hangs with just the same error: > > > > save_secure_sram() returns 0000ff02 > > > > > If it doesn't help, is there a way to test n900 configuration in QEMU? > > > > I doubt that QEMU n900 boots in secure mode but instead shows > > the SoC as general purpose SoC. If so, you'd have to patch the > > omap3_save_secure_ram_context() to attempt to save secure RAM > > context in all cases. If that works then debugging with any > > omap3 board like beagleboard in QEMU should work. > > Okay, linux-next from today still does not boot on n900. Is it > something new, or was this still not fixed in -next? Hello, Still not fixed in -next since I cannot regenerate the error. Thanks.
Hello, On Fri, Sep 15, 2017 at 03:28:44PM +0200, Pali Rohár wrote: > On Thursday 07 September 2017 16:30:38 Joonsoo Kim wrote: > > If it doesn't help, is there a way to test n900 configuration in QEMU? > > Hi Joonsoo, linaro version of QEMU has support for n900 machine. For > more information how to prepare & run kernel image see this email: > https://lists.denx.de/pipermail/u-boot/2015-January/200171.html > (instead u-boot.bin you would supply kernel's zImage) I tried to search to download required tools but cannot find a qflasher. Looks like you have qflasher and other *.bin for n900 image. Could you share them to me, please? > But QEMU does not support HS mode, so there is probably no secure ram. > IIRC smc instructions should not be used in normal GP mode. Okay. Thanks for information. I'm not sure that I can regenerate the error with n900 QEMU emulation but that would be my best so I will try. Thanks.
Hi! > > > > After commit 9caf25f996e8, user for CMA memory should use to check > > > > PageHighmem in order to get proper virtual address of the page. If > > > > someone doesn't use it, it is possible to use wrong virtual address > > > > and it then causes the use of wrong physical address. > > > > CONFIG_DEBUG_VIRTUAL would catch this case. > > > > > > OK, no extra output of current next with CONFIG_DEBUG_VIRTUAL=y. > > > Booting of n900 hangs with just the same error: > > > > > > save_secure_sram() returns 0000ff02 > > > > > > > If it doesn't help, is there a way to test n900 configuration in QEMU? > > > > > > I doubt that QEMU n900 boots in secure mode but instead shows > > > the SoC as general purpose SoC. If so, you'd have to patch the > > > omap3_save_secure_ram_context() to attempt to save secure RAM > > > context in all cases. If that works then debugging with any > > > omap3 board like beagleboard in QEMU should work. > > > > Okay, linux-next from today still does not boot on n900. Is it > > something new, or was this still not fixed in -next? > > Hello, > > Still not fixed in -next since I cannot regenerate the error. Unfortunately, rest of the world can reproduce the error, and it means linux-next is useless for us. I'd expect you to drop the relevant tree from linux-next when the error was reported. Clearly, those patches are unsuitable for 4.15, as they are broken, so they should not be in linux-next. Thanks, Pavel
Hi Pavel, On Mon, 18 Sep 2017 10:11:09 +0200 Pavel Machek <pavel@ucw.cz> wrote: > > Unfortunately, rest of the world can reproduce the error, and it means > linux-next is useless for us. > > I'd expect you to drop the relevant tree from linux-next when the > error was reported. Clearly, those patches are unsuitable for 4.15, as > they are broken, so they should not be in linux-next. Andrew has asked me to drop the patches from linux-next today and I have done so.
On Tue 2017-09-19 08:00:10, Stephen Rothwell wrote: > Hi Pavel, > > On Mon, 18 Sep 2017 10:11:09 +0200 Pavel Machek <pavel@ucw.cz> wrote: > > > > Unfortunately, rest of the world can reproduce the error, and it means > > linux-next is useless for us. > > > > I'd expect you to drop the relevant tree from linux-next when the > > error was reported. Clearly, those patches are unsuitable for 4.15, as > > they are broken, so they should not be in linux-next. > > Andrew has asked me to drop the patches from linux-next today and I > have done so. Thanks! Pavel
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c index 38f0fde..4c39c92 100644 --- a/arch/arm/mm/dma-mapping.c +++ b/arch/arm/mm/dma-mapping.c @@ -518,7 +518,7 @@ void __init dma_contiguous_remap(void) * considered as highmem even if it's physical address belong * to lowmem. Therefore, re-mapping isn't required. */ - if (!IS_ENABLED(CONFIG_HIGHMEM)) + if (!is_highmem_idx(ZONE_MOVABLE)) iotable_init(&map, 1); } }