Re: n900 in next-20170901

2017-11-14 Thread Tony Lindgren
* Joonsoo Kim [171115 02:44]: > On Tue, Nov 14, 2017 at 06:04:00PM -0800, Tony Lindgren wrote: > > * Joonsoo Kim [171115 00:48]: > > > On Tue, Nov 14, 2017 at 09:37:19AM -0800, Tony Lindgren wrote: > > > > * Joonsoo Kim [171114 06:34]: > > > > > On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lin

Re: n900 in next-20170901

2017-11-14 Thread Joonsoo Kim
On Tue, Nov 14, 2017 at 06:04:00PM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171115 00:48]: > > On Tue, Nov 14, 2017 at 09:37:19AM -0800, Tony Lindgren wrote: > > > * Joonsoo Kim [171114 06:34]: > > > > On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote: > > > > > * Joonsoo Kim [17

Re: n900 in next-20170901

2017-11-14 Thread Tony Lindgren
* Joonsoo Kim [171115 00:48]: > On Tue, Nov 14, 2017 at 09:37:19AM -0800, Tony Lindgren wrote: > > * Joonsoo Kim [171114 06:34]: > > > On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote: > > > > * Joonsoo Kim [171110 06:34]: > > > > > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lin

Re: n900 in next-20170901

2017-11-14 Thread Joonsoo Kim
On Tue, Nov 14, 2017 at 09:37:19AM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171114 06:34]: > > On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote: > > > * Joonsoo Kim [171110 06:34]: > > > > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > > > > +#define OMAP34XX_

Re: n900 in next-20170901

2017-11-14 Thread Tony Lindgren
* Tero Kristo [171114 20:03]: > On 14/11/17 21:44, Tony Lindgren wrote: > > * Tero Kristo [171114 19:34]: > > > I guess you could just use rx51_secure_dispatcher and ditch the > > > save_secure_ram_context call completely (and most of the other related > > > code)? That one would handle the cache

Re: n900 in next-20170901

2017-11-14 Thread Tero Kristo
On 14/11/17 21:44, Tony Lindgren wrote: * Tero Kristo [171114 19:34]: I guess you could just use rx51_secure_dispatcher and ditch the save_secure_ram_context call completely (and most of the other related code)? That one would handle the cache also in a clean manner. Something like: rx51_secu

Re: n900 in next-20170901

2017-11-14 Thread Tony Lindgren
* Tero Kristo [171114 19:34]: > I guess you could just use rx51_secure_dispatcher and ditch the > save_secure_ram_context call completely (and most of the other related > code)? That one would handle the cache also in a clean manner. > > Something like: > > rx51_secure_dispatcher(25, 0, FLAG_STA

Re: n900 in next-20170901

2017-11-14 Thread Tero Kristo
On 14/11/17 19:37, Tony Lindgren wrote: * Joonsoo Kim [171114 06:34]: On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote: * Joonsoo Kim [171110 06:34]: On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: +#define OMAP34XX_SRAM_PHYS 0x4020 +#define OMAP34XX_SRAM

Re: n900 in next-20170901

2017-11-14 Thread Tony Lindgren
* Joonsoo Kim [171114 06:34]: > On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote: > > * Joonsoo Kim [171110 06:34]: > > > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > > > +#define OMAP34XX_SRAM_PHYS 0x4020 > > > > +#define OMAP34XX_SRAM_VIRT 0xd00100

Re: n900 in next-20170901

2017-11-13 Thread Joonsoo Kim
On Mon, Nov 13, 2017 at 01:15:30PM -0800, Tony Lindgren wrote: > * Tony Lindgren [171110 07:36]: > > * Joonsoo Kim [171110 06:34]: > > > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > > > +#define OMAP34XX_SRAM_PHYS 0x4020 > > > > +#define OMAP34XX_SRAM_VIRT 0xd001

Re: n900 in next-20170901

2017-11-13 Thread Joonsoo Kim
On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171110 06:34]: > > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > > +#define OMAP34XX_SRAM_PHYS 0x4020 > > > +#define OMAP34XX_SRAM_VIRT 0xd001 > > > +#define OMAP34XX_SRAM_SIZE

Re: n900 in next-20170901

2017-11-13 Thread Tony Lindgren
* Tony Lindgren [171110 07:36]: > * Joonsoo Kim [171110 06:34]: > > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > > +#define OMAP34XX_SRAM_PHYS 0x4020 > > > +#define OMAP34XX_SRAM_VIRT 0xd001 > > > +#define OMAP34XX_SRAM_SIZE 0x1 > > > > For my

Re: n900 in next-20170901

2017-11-10 Thread Tony Lindgren
* Joonsoo Kim [171110 06:43]: > On Thu, Nov 09, 2017 at 10:23:40PM -0800, Tony Lindgren wrote: > > * Tony Lindgren [171109 22:19]: > > > * Tony Lindgren [171110 03:28]: > > > > Then I'll follow up on cleaning up save_secure_ram_context later. > > > > > > Here's a better version, the static mapp

Re: n900 in next-20170901

2017-11-10 Thread Tony Lindgren
* Joonsoo Kim [171110 06:34]: > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > +#define OMAP34XX_SRAM_PHYS 0x4020 > > +#define OMAP34XX_SRAM_VIRT 0xd001 > > +#define OMAP34XX_SRAM_SIZE 0x1 > > For my testing environment, vmalloc address space is started at > roughl

Re: n900 in next-20170901

2017-11-09 Thread Joonsoo Kim
On Thu, Nov 09, 2017 at 10:23:40PM -0800, Tony Lindgren wrote: > * Tony Lindgren [171109 22:19]: > > * Tony Lindgren [171110 03:28]: > > > Then I'll follow up on cleaning up save_secure_ram_context later. > > > > Here's a better version, the static mapping did not get used.. It > > just moved th

Re: n900 in next-20170901

2017-11-09 Thread Joonsoo Kim
On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171110 00:10]: > > On Thu, Nov 09, 2017 at 07:08:54AM -0800, Tony Lindgren wrote: > > > Hmm OK. Does your first patch above now have the initcall issue too? > > > It boots if I make that also subsys_initcall and then I

Re: n900 in next-20170901

2017-11-09 Thread Tony Lindgren
* Tony Lindgren [171109 22:19]: > * Tony Lindgren [171110 03:28]: > > Then I'll follow up on cleaning up save_secure_ram_context later. > > Here's a better version, the static mapping did not get used.. It > just moved the area so it happened to work. It needs to be set > up as MT_MEMORY_RWX_NON

Re: n900 in next-20170901

2017-11-09 Thread Tony Lindgren
* Tony Lindgren [171110 03:28]: > * Joonsoo Kim [171110 00:10]: > > On Thu, Nov 09, 2017 at 07:08:54AM -0800, Tony Lindgren wrote: > > > Hmm OK. Does your first patch above now have the initcall issue too? > > > It boots if I make that also subsys_initcall and then I get: > > > > > [2.078094

Re: n900 in next-20170901

2017-11-09 Thread Tony Lindgren
* Joonsoo Kim [171110 00:10]: > On Thu, Nov 09, 2017 at 07:08:54AM -0800, Tony Lindgren wrote: > > Hmm OK. Does your first patch above now have the initcall issue too? > > It boots if I make that also subsys_initcall and then I get: > > > [2.078094] vmalloc_pool_init: DMA: get vmalloc area: d

Re: n900 in next-20170901

2017-11-09 Thread Joonsoo Kim
On Thu, Nov 09, 2017 at 07:08:54AM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171109 03:47]: > > Could you test following two commits on my updated branch? > > > > "arm/dma: vmalloc area allocation" > > Won't boot at this commit: > > [6.747283] save_secure_sram() returns ff02 > [6

Re: n900 in next-20170901

2017-11-09 Thread Tony Lindgren
* Joonsoo Kim [171109 03:47]: > Could you test following two commits on my updated branch? > > "arm/dma: vmalloc area allocation" Won't boot at this commit: [6.747283] save_secure_sram() returns ff02 [6.751983] save_secure_sram()'s param: 0: 0x4 [6.756561] save_secure_sram()'s p

Re: n900 in next-20170901

2017-11-08 Thread Joonsoo Kim
On Thu, Nov 09, 2017 at 09:36:39AM +0900, Joonsoo Kim wrote: > On Wed, Nov 08, 2017 at 04:11:13PM -0800, Tony Lindgren wrote: > > * Joonsoo Kim [171109 00:05]: > > > On Wed, Nov 08, 2017 at 08:34:13AM -0800, Tony Lindgren wrote: > > > > * Joonsoo Kim [171108 07:43]: > > > > > On Tue, Nov 07, 2017

Re: n900 in next-20170901

2017-11-08 Thread Joonsoo Kim
On Wed, Nov 08, 2017 at 04:11:13PM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171109 00:05]: > > On Wed, Nov 08, 2017 at 08:34:13AM -0800, Tony Lindgren wrote: > > > * Joonsoo Kim [171108 07:43]: > > > > On Tue, Nov 07, 2017 at 07:48:42AM -0800, Tony Lindgren wrote: > > > > > So it seems the is

Re: n900 in next-20170901

2017-11-08 Thread Tony Lindgren
* Joonsoo Kim [171109 00:05]: > On Wed, Nov 08, 2017 at 08:34:13AM -0800, Tony Lindgren wrote: > > * Joonsoo Kim [171108 07:43]: > > > On Tue, Nov 07, 2017 at 07:48:42AM -0800, Tony Lindgren wrote: > > > > So it seems the issue is currently at the atomic_pool_init() > > > > related code? > > > >

Re: n900 in next-20170901

2017-11-08 Thread Joonsoo Kim
On Wed, Nov 08, 2017 at 08:34:13AM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171108 07:43]: > > On Tue, Nov 07, 2017 at 07:48:42AM -0800, Tony Lindgren wrote: > > > So it seems the issue is currently at the atomic_pool_init() > > > related code? > > > > Yes, your test showed it although I can'

Re: n900 in next-20170901

2017-11-08 Thread Tony Lindgren
* Joonsoo Kim [171108 07:43]: > On Tue, Nov 07, 2017 at 07:48:42AM -0800, Tony Lindgren wrote: > > So it seems the issue is currently at the atomic_pool_init() > > related code? > > Yes, your test showed it although I can't find any clue in > atomic_pool_init(). > > Could you test updated branch

Re: n900 in next-20170901

2017-11-07 Thread Joonsoo Kim
On Tue, Nov 07, 2017 at 07:48:42AM -0800, Tony Lindgren wrote: > Hi, > > * Joonsoo Kim [171107 05:30]: > > Could you test follwing updated branch? > > > > https://github.com/JoonsooKim/linux/tree/cma-debug4-next-20180901 > > > > It has three relevant commits on top and enables CMA memory use. >

Re: n900 in next-20170901

2017-11-07 Thread Tony Lindgren
Hi, * Joonsoo Kim [171107 05:30]: > Could you test follwing updated branch? > > https://github.com/JoonsooKim/linux/tree/cma-debug4-next-20180901 > > It has three relevant commits on top and enables CMA memory use. Okie dokie. > "arm/dma: remove i-cache flush" Your branch at the above commit

Re: n900 in next-20170901

2017-11-06 Thread Joonsoo Kim
Hello, Sorry for dealy. I was on vacation during last week. On Thu, Oct 26, 2017 at 07:16:27AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [171025 21:45]: > > On Wed, Oct 25, 2017 at 10:31:38AM -0700, Tony Lindgren wrote: > > > Great, this branch boots on n900! Early parts of the dmesg attached

Re: n900 in next-20170901

2017-10-26 Thread Tony Lindgren
* Joonsoo Kim [171025 21:45]: > On Wed, Oct 25, 2017 at 10:31:38AM -0700, Tony Lindgren wrote: > > Great, this branch boots on n900! Early parts of the dmesg attached > > below. > > Sound good. Perhaps, problem is due to the cache management. With my > patchset, direct mapping for CMA area is cle

Re: n900 in next-20170901

2017-10-25 Thread Joonsoo Kim
On Wed, Oct 25, 2017 at 10:31:38AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [171022 21:51]: > > On Fri, Oct 20, 2017 at 10:31:47AM -0700, Tony Lindgren wrote: > > > * Joonsoo Kim [171019 18:53]: > > > > Oops... I made a mistak. Could you test with reverting commit > > > > c977ee2803787363187d6

Re: n900 in next-20170901

2017-10-25 Thread Tony Lindgren
* Joonsoo Kim [171022 21:51]: > On Fri, Oct 20, 2017 at 10:31:47AM -0700, Tony Lindgren wrote: > > * Joonsoo Kim [171019 18:53]: > > > Oops... I made a mistak. Could you test with reverting commit > > > c977ee2803787363187d6aca9cebdabc793c6531 ("omap: forcibly call > > > save_secure_ram_context()

Re: n900 in next-20170901

2017-10-22 Thread Joonsoo Kim
On Fri, Oct 20, 2017 at 10:31:47AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [171019 18:53]: > > Oops... I made a mistak. Could you test with reverting commit > > c977ee2803787363187d6aca9cebdabc793c6531 ("omap: forcibly call > > save_secure_ram_context() for test") in that branch? > > Without r

Re: n900 in next-20170901

2017-10-20 Thread Tony Lindgren
* Joonsoo Kim [171019 18:53]: > Oops... I made a mistak. Could you test with reverting commit > c977ee2803787363187d6aca9cebdabc793c6531 ("omap: forcibly call > save_secure_ram_context() for test") in that branch? > Without reverting it, it doesn't call 'smc' so it always cause a > hang. Oops I s

Re: n900 in next-20170901

2017-10-19 Thread Joonsoo Kim
On Thu, Oct 19, 2017 at 11:30:34AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [171018 01:27]: > > On Mon, Sep 25, 2017 at 07:54:37AM -0700, Tony Lindgren wrote: > > > * Joonsoo Kim [170925 01:06]: > > > > On Thu, Sep 21, 2017 at 10:28:11AM -0700, Tony Lindgren wrote: > > > > > * Joonsoo Kim [17

Re: n900 in next-20170901

2017-10-19 Thread Tony Lindgren
* Joonsoo Kim [171018 01:27]: > On Mon, Sep 25, 2017 at 07:54:37AM -0700, Tony Lindgren wrote: > > * Joonsoo Kim [170925 01:06]: > > > On Thu, Sep 21, 2017 at 10:28:11AM -0700, Tony Lindgren wrote: > > > > * Joonsoo Kim [170914 23:55]: > > > > > On Wed, Sep 13, 2017 at 09:31:27AM -0700, Tony Lin

Re: n900 in next-20170901

2017-10-18 Thread Joonsoo Kim
On Mon, Sep 25, 2017 at 07:54:37AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [170925 01:06]: > > On Thu, Sep 21, 2017 at 10:28:11AM -0700, Tony Lindgren wrote: > > > * Joonsoo Kim [170914 23:55]: > > > > On Wed, Sep 13, 2017 at 09:31:27AM -0700, Tony Lindgren wrote: > > > > > Yes I disabled CON

Re: n900 in next-20170901

2017-09-25 Thread Tony Lindgren
* Joonsoo Kim [170925 01:06]: > On Thu, Sep 21, 2017 at 10:28:11AM -0700, Tony Lindgren wrote: > > * Joonsoo Kim [170914 23:55]: > > > On Wed, Sep 13, 2017 at 09:31:27AM -0700, Tony Lindgren wrote: > > > > Yes I disabled CONFIG_HIGHMEM and n900 boots. To disable it, > > > > you need to remove it

Re: n900 in next-20170901

2017-09-25 Thread Joonsoo Kim
On Thu, Sep 21, 2017 at 10:28:11AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [170914 23:55]: > > On Wed, Sep 13, 2017 at 09:31:27AM -0700, Tony Lindgren wrote: > > > Yes I disabled CONFIG_HIGHMEM and n900 boots. To disable it, > > > you need to remove it from arch/arm/mach-omap2/Kconfig that > >

Re: n900 in next-20170901

2017-09-21 Thread Tony Lindgren
* Joonsoo Kim [170914 23:55]: > On Wed, Sep 13, 2017 at 09:31:27AM -0700, Tony Lindgren wrote: > > Yes I disabled CONFIG_HIGHMEM and n900 boots. To disable it, > > you need to remove it from arch/arm/mach-omap2/Kconfig that > > selects it if ARCH_OMAP2PLUS_TYPICAL is selected. > > Okay. Problem w

Re: Linux-next broken for 2 weeks was Re: n900 in next-20170901

2017-09-18 Thread Pavel Machek
On Tue 2017-09-19 08:00:10, Stephen Rothwell wrote: > Hi Pavel, > > On Mon, 18 Sep 2017 10:11:09 +0200 Pavel Machek 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-

Re: Linux-next broken for 2 weeks was Re: n900 in next-20170901

2017-09-18 Thread Stephen Rothwell
Hi Pavel, On Mon, 18 Sep 2017 10:11:09 +0200 Pavel Machek 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 unsui

Linux-next broken for 2 weeks was Re: n900 in next-20170901

2017-09-18 Thread Pavel Machek
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. > > >

Re: n900 in next-20170901

2017-09-17 Thread Joonsoo Kim
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

Re: n900 in next-20170901

2017-09-17 Thread Joonsoo Kim
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 > > > an

Re: n900 in next-20170901

2017-09-15 Thread Pali Rohár
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

Re: n900 in next-20170901

2017-09-15 Thread Pavel Machek
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_VIRTU

Re: n900 in next-20170901

2017-09-14 Thread Joonsoo Kim
On Wed, Sep 13, 2017 at 09:31:27AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [170913 00:54]: > > On Thu, Sep 07, 2017 at 09:16:51AM -0700, Tony Lindgren wrote: > > > 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

Re: n900 in next-20170901

2017-09-13 Thread Tony Lindgren
* Joonsoo Kim [170913 00:54]: > On Thu, Sep 07, 2017 at 09:16:51AM -0700, Tony Lindgren wrote: > > 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 > >

Re: n900 in next-20170901

2017-09-13 Thread Joonsoo Kim
On Thu, Sep 07, 2017 at 09:16:51AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [170907 00:30]: > > On Wed, Sep 06, 2017 at 06:30:57AM -0700, Tony Lindgren wrote: > > > Hi, > > > > > > * Joonsoo Kim [170905 16:32]: > > > > I think that I made a mistake for configuration CONFIG_HIGHMEM=y and > > >

Re: n900 in next-20170901

2017-09-08 Thread Pavel Machek
Hi! > > It compiles ok, but it hangs on boot; black screen, so sometime before > > display is initialized. > > Thanks for reporting it. Based on git bisect, the regression causing > commit is 9caf25f996e8 ("mm/cma: manage the memory of the CMA area > by using the ZONE_MOVABLE"). With this path ap

Re: n900 in next-20170901

2017-09-07 Thread Tony Lindgren
* Joonsoo Kim [170907 00:30]: > On Wed, Sep 06, 2017 at 06:30:57AM -0700, Tony Lindgren wrote: > > Hi, > > > > * Joonsoo Kim [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 > > >

Re: n900 in next-20170901

2017-09-07 Thread Joonsoo Kim
On Wed, Sep 06, 2017 at 06:30:57AM -0700, Tony Lindgren wrote: > Hi, > > * Joonsoo Kim [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 conf

Re: n900 in next-20170901

2017-09-06 Thread Tony Lindgren
Hi, * Joonsoo Kim [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

Re: n900 in next-20170901

2017-09-05 Thread Joonsoo Kim
On Tue, Sep 05, 2017 at 01:13:15PM -0700, Tony Lindgren wrote: > * Pavel Machek [170903 13:38]: > > Hi! > > > > It compiles ok, but it hangs on boot; black screen, so sometime before > > display is initialized. > > Thanks for reporting it. Based on git bisect, the regression causing > commit is 9

Re: n900 in next-20170901

2017-09-05 Thread Tony Lindgren
* Vlastimil Babka [170905 13:29]: > On 09/05/2017 10:13 PM, Tony Lindgren wrote: > > * Pavel Machek [170903 13:38]: > >> Hi! > >> > >> It compiles ok, but it hangs on boot; black screen, so sometime before > >> display is initialized. > > > > Thanks for reporting it. Based on git bisect, the reg

Re: n900 in next-20170901

2017-09-05 Thread Vlastimil Babka
On 09/05/2017 10:13 PM, Tony Lindgren wrote: > * Pavel Machek [170903 13:38]: >> Hi! >> >> It compiles ok, but it hangs on boot; black screen, so sometime before >> display is initialized. > > Thanks for reporting it. Based on git bisect, the regression causing > commit is 9caf25f996e8 ("mm/cma:

Re: n900 in next-20170901

2017-09-05 Thread Tony Lindgren
* Pavel Machek [170903 13:38]: > Hi! > > It compiles ok, but it hangs on boot; black screen, so sometime before > display is initialized. Thanks for reporting it. Based on git bisect, the regression causing commit is 9caf25f996e8 ("mm/cma: manage the memory of the CMA area by using the ZONE_MOVAB

n900 in next-20170901

2017-09-03 Thread Pavel Machek
Hi! It compiles ok, but it hangs on boot; black screen, so sometime before display is initialized. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/h