Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On 12/03/15 13:11, Stas Sergeev wrote: > 12.03.2015 16:04, Russell King - ARM Linux пишет: >> On Thu, Mar 12, 2015 at 03:47:35PM +0300, Stas Sergeev wrote: >>> 12.03.2015 15:33, Peter Hurley пишет: On 03/11/2015 10:24 AM, Stas Sergeev wrote: > However, while testing, I've suddenly got another crash happened > a bit earlier than the previous one used to happen: (OOM? How??) > --- > [0.00] Booting Linux on physical CPU 0x0 > [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty > (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) > #2 SMP 5 > [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), > cr=10c5387d > [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction > cache > [0.00] Machine model: Marvell Armada XP Development Board > DB-MV784MP-GP > [0.00] Ignoring memory block 0x1 - 0x2 Once you patch your bootloader, you'll want to configure your kernel for CONFIG_ARM_LPAE=y to enable the high 4GB of memory you have, as it's being ignored in this config right now (as shown above and in the oom message below). >>> Hi Peter, thanks for this hint. >>> I actually already tried with lpae, and, except for the missing >>> 256Mb, everything works properly. :) >> How reproducable is the OOM? Have you tested LPAE as much as you did >> without LPAE? > Hi Russel, OOM is reproduceable quite fine only on old uboot > and non-lpae mode. > With lpae mode and old uboot OOM doesn't happen, but the board is not > very reliable. > With old uboot and mem=3G OOM is not reproduceable! > With new uboot and whatever lpae more, OOM does not happen. > So, after all, it still seems to be related to the problematic memory > region. Let me know if you still suspect a bug and need more testing. > Hi Stas, Recently, I've done some work on memtest kernel feature [1]. It helped to track down an issue with memory corruption on arm64 platform. I wonder if it is able to catch your case? [1] http://comments.gmane.org/gmane.linux.kernel.mm/129669 Thanks Vladimir > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
Dear Stas Sergeev, On Thu, 12 Mar 2015 16:03:07 +0300, Stas Sergeev wrote: > > No, this is expected. Your physical address space is shared between RAM > > and I/O devices. So the space 0xf000 -> 0x in the physical > > address space is where all the registers for your SoC and PCIe devices > Yeah, I realize that, but I was hoping that some work-around > exists. For example, move entire dimm above 4G? Is this really > impossible? Or maybe move overlapping region above 8G... I am not aware of any trick that would allow to do that, but I have also never looked in the deep details of the Marvell memory controller and what's possible to do with it. Moving entire DIMM above 4G is clearly not possible: devices can only do DMA on the first 32 bits of the physical address space. So if you move all the physical memory above 4G, you don't have any memory left for DMA. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
12.03.2015 16:12, Russell King - ARM Linux пишет: > On Thu, Mar 12, 2015 at 04:03:07PM +0300, Stas Sergeev wrote: >> Yeah, I realize that, but I was hoping that some work-around >> exists. For example, move entire dimm above 4G? Is this really >> impossible? Or maybe move overlapping region above 8G... > You /really/ don't want to do that. We have that situation on TI Keystone > SoCs and it's really horrible for the kernel to deal with. > > For early kernel boot, we require RAM below the 4GB boundary, so that > we are able to execute code before the MMU is enabled. No RAM below > 4GB basically means there is no way to execute any code from RAM. Then maybe it is possible to move the iomem to 1Gb and move RAM above 1Gb, so that 3Gb of RAM are still available for early boot? I mean, well, huh, giving up 256Mb of RAM so easily... :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Thu, Mar 12, 2015 at 04:03:07PM +0300, Stas Sergeev wrote: > Yeah, I realize that, but I was hoping that some work-around > exists. For example, move entire dimm above 4G? Is this really > impossible? Or maybe move overlapping region above 8G... You /really/ don't want to do that. We have that situation on TI Keystone SoCs and it's really horrible for the kernel to deal with. For early kernel boot, we require RAM below the 4GB boundary, so that we are able to execute code before the MMU is enabled. No RAM below 4GB basically means there is no way to execute any code from RAM. Keystone SoCs work around that by having an alias of RAM below 4GB, and by doing some architecturally dubious, potentially fault-inducing manipulation of the kernel page tables - so dubious that booting Linux on Keystone SoCs with this leads us to print a big warning, and immediately taint the kernel at the moment. That's on my list of things which need to be worked on, subject to commercial issues. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
12.03.2015 16:04, Russell King - ARM Linux пишет: > On Thu, Mar 12, 2015 at 03:47:35PM +0300, Stas Sergeev wrote: >> 12.03.2015 15:33, Peter Hurley пишет: >>> On 03/11/2015 10:24 AM, Stas Sergeev wrote: However, while testing, I've suddenly got another crash happened a bit earlier than the previous one used to happen: (OOM? How??) --- [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #2 SMP 5 [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Marvell Armada XP Development Board DB-MV784MP-GP [0.00] Ignoring memory block 0x1 - 0x2 >>> Once you patch your bootloader, you'll want to configure your kernel >>> for CONFIG_ARM_LPAE=y to enable the high 4GB of memory you have, as >>> it's being ignored in this config right now (as shown above and in >>> the oom message below). >> Hi Peter, thanks for this hint. >> I actually already tried with lpae, and, except for the missing >> 256Mb, everything works properly. :) > How reproducable is the OOM? Have you tested LPAE as much as you did > without LPAE? Hi Russel, OOM is reproduceable quite fine only on old uboot and non-lpae mode. With lpae mode and old uboot OOM doesn't happen, but the board is not very reliable. With old uboot and mem=3G OOM is not reproduceable! With new uboot and whatever lpae more, OOM does not happen. So, after all, it still seems to be related to the problematic memory region. Let me know if you still suspect a bug and need more testing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Wed, Mar 11, 2015 at 06:22:42PM +0300, Stas Sergeev wrote: > 11.03.2015 18:13, Gregory CLEMENT пишет: > > On 11/03/2015 16:01, Stas Sergeev wrote: > >> 11.03.2015 16:14, Russell King - ARM Linux пишет: > >>> On Wed, Mar 11, 2015 at 01:44:57PM +0100, Gregory CLEMENT wrote: > Hi Stas, > > On 10/03/2015 17:54, Stas Sergeev wrote: > > Hello, the patch below is needed for a successful boot on armada-xp. > > > I am really surprised by this patch because I used the Armada XP based > board in a daily base and I never saw this issue. > >>> Can you provide some details about your board - does it have 8GB of > >>> memory, ranging from 0-0xf000, and 4G-8G ? > >> I wonder about this 256Mb memory hole. > > This is where the SoC registers are. > OK but it seems I am loosing this region of _physical_ memory: Correct, because the kernel can't see that physical memory. If it tries to access the physical memory at those locations, it hits the SoC registers and PCI instead of memory. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
12.03.2015 15:47, Thomas Petazzoni пишет: > Dear Stas Sergeev, > > >> The only problem I now have is the lack of 256Mb of >> ram. >> >> [0.00] MEMBLOCK >> configuration: >> [0.00] memory size = 0x1f000 reserved size = >> 0x70d6e3 >> [0.00] memory.cnt = >> 0x2 >> [0.00] memory[0x0] [0x00-0x00efff], >> 0xf000 >> bytes flags: >> 0x0 >> [0.00] memory[0x1] [0x01-0x01], >> 0x1 >> bytes flags: 0x0 >> >> There is a 8Gb in a single dimm. >> Do you have any idea why 0xf000-0x range is missing? >> I suspect this is something with uboot too. > No, this is expected. Your physical address space is shared between RAM > and I/O devices. So the space 0xf000 -> 0x in the physical > address space is where all the registers for your SoC and PCIe devices Yeah, I realize that, but I was hoping that some work-around exists. For example, move entire dimm above 4G? Is this really impossible? Or maybe move overlapping region above 8G... > will be located. You are therefore indeed losing 256 MB of RAM, but > there's nothing that can be done about this. OK, that's sad. Thanks for info! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Thu, Mar 12, 2015 at 03:47:35PM +0300, Stas Sergeev wrote: > 12.03.2015 15:33, Peter Hurley пишет: > > On 03/11/2015 10:24 AM, Stas Sergeev wrote: > >> However, while testing, I've suddenly got another crash happened > >> a bit earlier than the previous one used to happen: (OOM? How??) > >> --- > >> [0.00] Booting Linux on physical CPU 0x0 > >> [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty > >> (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) > >> #2 SMP 5 > >> [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), > >> cr=10c5387d > >> [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction > >> cache > >> [0.00] Machine model: Marvell Armada XP Development Board > >> DB-MV784MP-GP > >> [0.00] Ignoring memory block 0x1 - 0x2 > > Once you patch your bootloader, you'll want to configure your kernel > > for CONFIG_ARM_LPAE=y to enable the high 4GB of memory you have, as > > it's being ignored in this config right now (as shown above and in > > the oom message below). > Hi Peter, thanks for this hint. > I actually already tried with lpae, and, except for the missing > 256Mb, everything works properly. :) How reproducable is the OOM? Have you tested LPAE as much as you did without LPAE? As I just said to Peter, I don't see adding more highmem would solve your problem - I think there's something quite bad going on here, possibly resulting in some form of memory corruption which is changing the kernels ability to properly track memory usage. I don't see how 760MB of lowmem could be gobbled up soo early in boot. Enabling LPAE and allowing an additional 4GB of highmem should mean that an additional 32MB of lowmem is consumed in the struct page array needed to track that additional 4GB of memory alone - that should increase the lowmem pressure further, and cause an OOM earlier in the boot. (32MB = 4GB / 4K * sizeof(struct page) = 4GB / 4K * 32). I think you still have problems somewhere. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Thu, Mar 12, 2015 at 08:33:40AM -0400, Peter Hurley wrote: > On 03/11/2015 10:24 AM, Stas Sergeev wrote: > > However, while testing, I've suddenly got another crash happened > > a bit earlier than the previous one used to happen: (OOM? How??) > > --- > > [0.00] Booting Linux on physical CPU 0x0 > > [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty > > (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) > > #2 SMP 5 > > [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), > > cr=10c5387d > > [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction > > cache > > [0.00] Machine model: Marvell Armada XP Development Board > > DB-MV784MP-GP > > [0.00] Ignoring memory block 0x1 - 0x2 > > Once you patch your bootloader, you'll want to configure your kernel > for CONFIG_ARM_LPAE=y to enable the high 4GB of memory you have, as > it's being ignored in this config right now (as shown above and in > the oom message below). The OOM is happening during boot. During boot, there is 760MB of lowmem free initially, along with a few gigabytes of highmem. If we look at the buddy state: [7.220815] Normal: 2*4kB (UR) 17*8kB (UR) 0*16kB 0*32kB 0*64kB 0*128kB 1*256kB (R) 0*512kB 1*1024kB (R) 1*2048kB (R) 0*4096kB = 3472kB [7.233210] HighMem: 0*4kB 1*8kB (M) 0*16kB 0*32kB 0*64kB 0*128kB 2*256kB (UM) 1*512kB (M) 1*1024kB (M) 1*2048kB (M) 767*4096kB (MR) = 3B we can see that most of lowmem is in the reserve migration type, and some is also in the unmovable type. 3MB of reserved lowmem for atomic allocations is about what I'd expect given the memory sizes. Highmem has some memory in the movable migratation type, but the bulk is in the reserve migration type - but this is irrelevant as you'll see from the next bit of information: [6.818183] swapper/0 invoked oom-killer: gfp_mask=0x2040d0, order=0, oom_score_adj=0 Let's decode that gfp_mask. ___GFP_NOTRACK | ___GFP_COMP | ___GFP_FS | ___GFP_IO | ___GFP_WAIT This does not give the allocator permission to allocate from highmem - for that, it needs ___GFP_HIGH to be in there, but it isn't. The kernel should _not_ consume 760MB of lowmem during boot, but according to the accounting, it looks like it has. If the memory allocation structures are ending up in the problem region of physical RAM, then that could be responsible for this OOM - but that won't happen, because we don't place that stuff into highmem. In short, I don't have a clue what would cause 760MB of lowmem to be gobbled up, but one thing I'm absolutely certain of is that adding more highmem won't solve this - if anything, it'll probably make things worse due to more lowmem being consumed to track the additional highmem pages. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
Dear Stas Sergeev, On Thu, 12 Mar 2015 15:44:44 +0300, Stas Sergeev wrote: > Hello Thomas, I haven't got to look into that register: > uboot is updated to v2011.12-2014_T2.0 and everything > is working! So thanks once again. Well if everything is working now, and seeing your boot log, the register 0xf1020254 will contain 0xf000. > The only problem I now have is the lack of 256Mb of > ram. > > [0.00] MEMBLOCK > configuration: > [0.00] memory size = 0x1f000 reserved size = > 0x70d6e3 > [0.00] memory.cnt = > 0x2 > [0.00] memory[0x0] [0x00-0x00efff], > 0xf000 > bytes flags: > 0x0 > [0.00] memory[0x1] [0x01-0x01], > 0x1 > bytes flags: 0x0 > > There is a 8Gb in a single dimm. > Do you have any idea why 0xf000-0x range is missing? > I suspect this is something with uboot too. No, this is expected. Your physical address space is shared between RAM and I/O devices. So the space 0xf000 -> 0x in the physical address space is where all the registers for your SoC and PCIe devices will be located. You are therefore indeed losing 256 MB of RAM, but there's nothing that can be done about this. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
12.03.2015 15:33, Peter Hurley пишет: > On 03/11/2015 10:24 AM, Stas Sergeev wrote: >> However, while testing, I've suddenly got another crash happened >> a bit earlier than the previous one used to happen: (OOM? How??) >> --- >> [0.00] Booting Linux on physical CPU 0x0 >> [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty >> (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) >> #2 SMP 5 >> [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), >> cr=10c5387d >> [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction >> cache >> [0.00] Machine model: Marvell Armada XP Development Board >> DB-MV784MP-GP >> [0.00] Ignoring memory block 0x1 - 0x2 > Once you patch your bootloader, you'll want to configure your kernel > for CONFIG_ARM_LPAE=y to enable the high 4GB of memory you have, as > it's being ignored in this config right now (as shown above and in > the oom message below). Hi Peter, thanks for this hint. I actually already tried with lpae, and, except for the missing 256Mb, everything works properly. :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 21:33, Thomas Petazzoni пишет: > Dear Stas Sergeev, > > On Wed, 11 Mar 2015 21:08:03 +0300, Stas Sergeev wrote: > >> mem=0xc000 seems to work! >> 0xd000 or 0xe000 do not. >> OK, so 3Gb instead of 8... but at least it boots! :) > What is the value of the register 0xf1020254 ? Hello Thomas, I haven't got to look into that register: uboot is updated to v2011.12-2014_T2.0 and everything is working! So thanks once again. The only problem I now have is the lack of 256Mb of ram. [0.00] MEMBLOCK configuration: [0.00] memory size = 0x1f000 reserved size = 0x70d6e3 [0.00] memory.cnt = 0x2 [0.00] memory[0x0] [0x00-0x00efff], 0xf000 bytes flags: 0x0 [0.00] memory[0x1] [0x01-0x01], 0x1 bytes flags: 0x0 There is a 8Gb in a single dimm. Do you have any idea why 0xf000-0x range is missing? I suspect this is something with uboot too. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On 03/11/2015 10:24 AM, Stas Sergeev wrote: > However, while testing, I've suddenly got another crash happened > a bit earlier than the previous one used to happen: (OOM? How??) > --- > [0.00] Booting Linux on physical CPU 0x0 > [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty > (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) > #2 SMP 5 > [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), > cr=10c5387d > [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction > cache > [0.00] Machine model: Marvell Armada XP Development Board > DB-MV784MP-GP > [0.00] Ignoring memory block 0x1 - 0x2 Once you patch your bootloader, you'll want to configure your kernel for CONFIG_ARM_LPAE=y to enable the high 4GB of memory you have, as it's being ignored in this config right now (as shown above and in the oom message below). > [7.055570] Mem-info: [...] > [7.314368] 983040 pages of RAM Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On 03/11/2015 10:24 AM, Stas Sergeev wrote: However, while testing, I've suddenly got another crash happened a bit earlier than the previous one used to happen: (OOM? How??) --- [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #2 SMP 5 [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Marvell Armada XP Development Board DB-MV784MP-GP [0.00] Ignoring memory block 0x1 - 0x2 Once you patch your bootloader, you'll want to configure your kernel for CONFIG_ARM_LPAE=y to enable the high 4GB of memory you have, as it's being ignored in this config right now (as shown above and in the oom message below). [7.055570] Mem-info: [...] [7.314368] 983040 pages of RAM Regards, Peter Hurley -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 21:33, Thomas Petazzoni пишет: Dear Stas Sergeev, On Wed, 11 Mar 2015 21:08:03 +0300, Stas Sergeev wrote: mem=0xc000 seems to work! 0xd000 or 0xe000 do not. OK, so 3Gb instead of 8... but at least it boots! :) What is the value of the register 0xf1020254 ? Hello Thomas, I haven't got to look into that register: uboot is updated to v2011.12-2014_T2.0 and everything is working! So thanks once again. The only problem I now have is the lack of 256Mb of ram. [0.00] MEMBLOCK configuration: [0.00] memory size = 0x1f000 reserved size = 0x70d6e3 [0.00] memory.cnt = 0x2 [0.00] memory[0x0] [0x00-0x00efff], 0xf000 bytes flags: 0x0 [0.00] memory[0x1] [0x01-0x01], 0x1 bytes flags: 0x0 There is a 8Gb in a single dimm. Do you have any idea why 0xf000-0x range is missing? I suspect this is something with uboot too. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
12.03.2015 15:33, Peter Hurley пишет: On 03/11/2015 10:24 AM, Stas Sergeev wrote: However, while testing, I've suddenly got another crash happened a bit earlier than the previous one used to happen: (OOM? How??) --- [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #2 SMP 5 [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Marvell Armada XP Development Board DB-MV784MP-GP [0.00] Ignoring memory block 0x1 - 0x2 Once you patch your bootloader, you'll want to configure your kernel for CONFIG_ARM_LPAE=y to enable the high 4GB of memory you have, as it's being ignored in this config right now (as shown above and in the oom message below). Hi Peter, thanks for this hint. I actually already tried with lpae, and, except for the missing 256Mb, everything works properly. :) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
Dear Stas Sergeev, On Thu, 12 Mar 2015 15:44:44 +0300, Stas Sergeev wrote: Hello Thomas, I haven't got to look into that register: uboot is updated to v2011.12-2014_T2.0 and everything is working! So thanks once again. Well if everything is working now, and seeing your boot log, the register 0xf1020254 will contain 0xf000. The only problem I now have is the lack of 256Mb of ram. [0.00] MEMBLOCK configuration: [0.00] memory size = 0x1f000 reserved size = 0x70d6e3 [0.00] memory.cnt = 0x2 [0.00] memory[0x0] [0x00-0x00efff], 0xf000 bytes flags: 0x0 [0.00] memory[0x1] [0x01-0x01], 0x1 bytes flags: 0x0 There is a 8Gb in a single dimm. Do you have any idea why 0xf000-0x range is missing? I suspect this is something with uboot too. No, this is expected. Your physical address space is shared between RAM and I/O devices. So the space 0xf000 - 0x in the physical address space is where all the registers for your SoC and PCIe devices will be located. You are therefore indeed losing 256 MB of RAM, but there's nothing that can be done about this. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
12.03.2015 16:04, Russell King - ARM Linux пишет: On Thu, Mar 12, 2015 at 03:47:35PM +0300, Stas Sergeev wrote: 12.03.2015 15:33, Peter Hurley пишет: On 03/11/2015 10:24 AM, Stas Sergeev wrote: However, while testing, I've suddenly got another crash happened a bit earlier than the previous one used to happen: (OOM? How??) --- [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #2 SMP 5 [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Marvell Armada XP Development Board DB-MV784MP-GP [0.00] Ignoring memory block 0x1 - 0x2 Once you patch your bootloader, you'll want to configure your kernel for CONFIG_ARM_LPAE=y to enable the high 4GB of memory you have, as it's being ignored in this config right now (as shown above and in the oom message below). Hi Peter, thanks for this hint. I actually already tried with lpae, and, except for the missing 256Mb, everything works properly. :) How reproducable is the OOM? Have you tested LPAE as much as you did without LPAE? Hi Russel, OOM is reproduceable quite fine only on old uboot and non-lpae mode. With lpae mode and old uboot OOM doesn't happen, but the board is not very reliable. With old uboot and mem=3G OOM is not reproduceable! With new uboot and whatever lpae more, OOM does not happen. So, after all, it still seems to be related to the problematic memory region. Let me know if you still suspect a bug and need more testing. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Thu, Mar 12, 2015 at 04:03:07PM +0300, Stas Sergeev wrote: Yeah, I realize that, but I was hoping that some work-around exists. For example, move entire dimm above 4G? Is this really impossible? Or maybe move overlapping region above 8G... You /really/ don't want to do that. We have that situation on TI Keystone SoCs and it's really horrible for the kernel to deal with. For early kernel boot, we require RAM below the 4GB boundary, so that we are able to execute code before the MMU is enabled. No RAM below 4GB basically means there is no way to execute any code from RAM. Keystone SoCs work around that by having an alias of RAM below 4GB, and by doing some architecturally dubious, potentially fault-inducing manipulation of the kernel page tables - so dubious that booting Linux on Keystone SoCs with this leads us to print a big warning, and immediately taint the kernel at the moment. That's on my list of things which need to be worked on, subject to commercial issues. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
12.03.2015 16:12, Russell King - ARM Linux пишет: On Thu, Mar 12, 2015 at 04:03:07PM +0300, Stas Sergeev wrote: Yeah, I realize that, but I was hoping that some work-around exists. For example, move entire dimm above 4G? Is this really impossible? Or maybe move overlapping region above 8G... You /really/ don't want to do that. We have that situation on TI Keystone SoCs and it's really horrible for the kernel to deal with. For early kernel boot, we require RAM below the 4GB boundary, so that we are able to execute code before the MMU is enabled. No RAM below 4GB basically means there is no way to execute any code from RAM. Then maybe it is possible to move the iomem to 1Gb and move RAM above 1Gb, so that 3Gb of RAM are still available for early boot? I mean, well, huh, giving up 256Mb of RAM so easily... :) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
Dear Stas Sergeev, On Thu, 12 Mar 2015 16:03:07 +0300, Stas Sergeev wrote: No, this is expected. Your physical address space is shared between RAM and I/O devices. So the space 0xf000 - 0x in the physical address space is where all the registers for your SoC and PCIe devices Yeah, I realize that, but I was hoping that some work-around exists. For example, move entire dimm above 4G? Is this really impossible? Or maybe move overlapping region above 8G... I am not aware of any trick that would allow to do that, but I have also never looked in the deep details of the Marvell memory controller and what's possible to do with it. Moving entire DIMM above 4G is clearly not possible: devices can only do DMA on the first 32 bits of the physical address space. So if you move all the physical memory above 4G, you don't have any memory left for DMA. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On 12/03/15 13:11, Stas Sergeev wrote: 12.03.2015 16:04, Russell King - ARM Linux пишет: On Thu, Mar 12, 2015 at 03:47:35PM +0300, Stas Sergeev wrote: 12.03.2015 15:33, Peter Hurley пишет: On 03/11/2015 10:24 AM, Stas Sergeev wrote: However, while testing, I've suddenly got another crash happened a bit earlier than the previous one used to happen: (OOM? How??) --- [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #2 SMP 5 [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Marvell Armada XP Development Board DB-MV784MP-GP [0.00] Ignoring memory block 0x1 - 0x2 Once you patch your bootloader, you'll want to configure your kernel for CONFIG_ARM_LPAE=y to enable the high 4GB of memory you have, as it's being ignored in this config right now (as shown above and in the oom message below). Hi Peter, thanks for this hint. I actually already tried with lpae, and, except for the missing 256Mb, everything works properly. :) How reproducable is the OOM? Have you tested LPAE as much as you did without LPAE? Hi Russel, OOM is reproduceable quite fine only on old uboot and non-lpae mode. With lpae mode and old uboot OOM doesn't happen, but the board is not very reliable. With old uboot and mem=3G OOM is not reproduceable! With new uboot and whatever lpae more, OOM does not happen. So, after all, it still seems to be related to the problematic memory region. Let me know if you still suspect a bug and need more testing. Hi Stas, Recently, I've done some work on memtest kernel feature [1]. It helped to track down an issue with memory corruption on arm64 platform. I wonder if it is able to catch your case? [1] http://comments.gmane.org/gmane.linux.kernel.mm/129669 Thanks Vladimir ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Thu, Mar 12, 2015 at 08:33:40AM -0400, Peter Hurley wrote: On 03/11/2015 10:24 AM, Stas Sergeev wrote: However, while testing, I've suddenly got another crash happened a bit earlier than the previous one used to happen: (OOM? How??) --- [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #2 SMP 5 [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Marvell Armada XP Development Board DB-MV784MP-GP [0.00] Ignoring memory block 0x1 - 0x2 Once you patch your bootloader, you'll want to configure your kernel for CONFIG_ARM_LPAE=y to enable the high 4GB of memory you have, as it's being ignored in this config right now (as shown above and in the oom message below). The OOM is happening during boot. During boot, there is 760MB of lowmem free initially, along with a few gigabytes of highmem. If we look at the buddy state: [7.220815] Normal: 2*4kB (UR) 17*8kB (UR) 0*16kB 0*32kB 0*64kB 0*128kB 1*256kB (R) 0*512kB 1*1024kB (R) 1*2048kB (R) 0*4096kB = 3472kB [7.233210] HighMem: 0*4kB 1*8kB (M) 0*16kB 0*32kB 0*64kB 0*128kB 2*256kB (UM) 1*512kB (M) 1*1024kB (M) 1*2048kB (M) 767*4096kB (MR) = 3B we can see that most of lowmem is in the reserve migration type, and some is also in the unmovable type. 3MB of reserved lowmem for atomic allocations is about what I'd expect given the memory sizes. Highmem has some memory in the movable migratation type, but the bulk is in the reserve migration type - but this is irrelevant as you'll see from the next bit of information: [6.818183] swapper/0 invoked oom-killer: gfp_mask=0x2040d0, order=0, oom_score_adj=0 Let's decode that gfp_mask. ___GFP_NOTRACK | ___GFP_COMP | ___GFP_FS | ___GFP_IO | ___GFP_WAIT This does not give the allocator permission to allocate from highmem - for that, it needs ___GFP_HIGH to be in there, but it isn't. The kernel should _not_ consume 760MB of lowmem during boot, but according to the accounting, it looks like it has. If the memory allocation structures are ending up in the problem region of physical RAM, then that could be responsible for this OOM - but that won't happen, because we don't place that stuff into highmem. In short, I don't have a clue what would cause 760MB of lowmem to be gobbled up, but one thing I'm absolutely certain of is that adding more highmem won't solve this - if anything, it'll probably make things worse due to more lowmem being consumed to track the additional highmem pages. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Thu, Mar 12, 2015 at 03:47:35PM +0300, Stas Sergeev wrote: 12.03.2015 15:33, Peter Hurley пишет: On 03/11/2015 10:24 AM, Stas Sergeev wrote: However, while testing, I've suddenly got another crash happened a bit earlier than the previous one used to happen: (OOM? How??) --- [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #2 SMP 5 [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Marvell Armada XP Development Board DB-MV784MP-GP [0.00] Ignoring memory block 0x1 - 0x2 Once you patch your bootloader, you'll want to configure your kernel for CONFIG_ARM_LPAE=y to enable the high 4GB of memory you have, as it's being ignored in this config right now (as shown above and in the oom message below). Hi Peter, thanks for this hint. I actually already tried with lpae, and, except for the missing 256Mb, everything works properly. :) How reproducable is the OOM? Have you tested LPAE as much as you did without LPAE? As I just said to Peter, I don't see adding more highmem would solve your problem - I think there's something quite bad going on here, possibly resulting in some form of memory corruption which is changing the kernels ability to properly track memory usage. I don't see how 760MB of lowmem could be gobbled up soo early in boot. Enabling LPAE and allowing an additional 4GB of highmem should mean that an additional 32MB of lowmem is consumed in the struct page array needed to track that additional 4GB of memory alone - that should increase the lowmem pressure further, and cause an OOM earlier in the boot. (32MB = 4GB / 4K * sizeof(struct page) = 4GB / 4K * 32). I think you still have problems somewhere. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
12.03.2015 15:47, Thomas Petazzoni пишет: Dear Stas Sergeev, The only problem I now have is the lack of 256Mb of ram. [0.00] MEMBLOCK configuration: [0.00] memory size = 0x1f000 reserved size = 0x70d6e3 [0.00] memory.cnt = 0x2 [0.00] memory[0x0] [0x00-0x00efff], 0xf000 bytes flags: 0x0 [0.00] memory[0x1] [0x01-0x01], 0x1 bytes flags: 0x0 There is a 8Gb in a single dimm. Do you have any idea why 0xf000-0x range is missing? I suspect this is something with uboot too. No, this is expected. Your physical address space is shared between RAM and I/O devices. So the space 0xf000 - 0x in the physical address space is where all the registers for your SoC and PCIe devices Yeah, I realize that, but I was hoping that some work-around exists. For example, move entire dimm above 4G? Is this really impossible? Or maybe move overlapping region above 8G... will be located. You are therefore indeed losing 256 MB of RAM, but there's nothing that can be done about this. OK, that's sad. Thanks for info! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Wed, Mar 11, 2015 at 06:22:42PM +0300, Stas Sergeev wrote: 11.03.2015 18:13, Gregory CLEMENT пишет: On 11/03/2015 16:01, Stas Sergeev wrote: 11.03.2015 16:14, Russell King - ARM Linux пишет: On Wed, Mar 11, 2015 at 01:44:57PM +0100, Gregory CLEMENT wrote: Hi Stas, On 10/03/2015 17:54, Stas Sergeev wrote: Hello, the patch below is needed for a successful boot on armada-xp. I am really surprised by this patch because I used the Armada XP based board in a daily base and I never saw this issue. Can you provide some details about your board - does it have 8GB of memory, ranging from 0-0xf000, and 4G-8G ? I wonder about this 256Mb memory hole. This is where the SoC registers are. OK but it seems I am loosing this region of _physical_ memory: Correct, because the kernel can't see that physical memory. If it tries to access the physical memory at those locations, it hits the SoC registers and PCI instead of memory. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Wed, Mar 11, 2015 at 09:38:53PM +0300, Stas Sergeev wrote:
> 11.03.2015 21:11, Thomas Petazzoni пишет:
> > Dear Stas Sergeev,
> >
> > On Wed, 11 Mar 2015 20:56:50 +0300, Stas Sergeev wrote:
> >
> >> It doesn't look like it works as intended.
> >> Got the crash below.
> >> Please note the mappings beyond 0xe000, so I wonder if
> >> the option worked as expected?
> > Are you sure you're not confusing virtual addresses and physical
> > addresses?
> OK, so I changed Russel's printk to the following way:
>
> +printk("vmalloc: mapping page %p (0x%08lx000) at 0x%08lx 0x%08zx\n",
> +page, page_to_pfn(page), addr, __pa(addr));
>
> (added __pa(addr)) and now I hope I am seeing the physical
> addresses at the last column:
No, you don't want to do that...
> [ 19.023836] vmalloc: mapping page ef7f1fa0 (0x000bfc7d000) at
| `- physical address
`-struct page address
> 0xf04a3000 0x304a3000
`- virtual address
__pa() doesn't work on addresses in the vmalloc region.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 21:11, Thomas Petazzoni пишет:
> Dear Stas Sergeev,
>
> On Wed, 11 Mar 2015 20:56:50 +0300, Stas Sergeev wrote:
>
>> It doesn't look like it works as intended.
>> Got the crash below.
>> Please note the mappings beyond 0xe000, so I wonder if
>> the option worked as expected?
> Are you sure you're not confusing virtual addresses and physical
> addresses?
OK, so I changed Russel's printk to the following way:
+printk("vmalloc: mapping page %p (0x%08lx000) at 0x%08lx 0x%08zx\n",
+page, page_to_pfn(page), addr, __pa(addr));
(added __pa(addr)) and now I hope I am seeing the physical
addresses at the last column:
[ 19.023836] vmalloc: mapping page ef7f1fa0 (0x000bfc7d000) at
0xf04a3000 0x304a3000
[ 19.031515] vmalloc: mapping page ef7f3360 (0x000bfd1b000) at
0xf04a4000 0x304a4000
[ 19.039221] vmalloc: mapping page ef7f18e0 (0x000bfc47000) at
0xf04a5000 0x304a5000
and they do not exceed mem= option.
Not sure though if this was the right thing to do though. :)
Anyway, with mem=0xc00 it seems to boot, so many
thanks to everyone!
I'll check the value of the register 0xf1020254 tomorrow and will post back.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
Dear Stas Sergeev, On Wed, 11 Mar 2015 21:08:03 +0300, Stas Sergeev wrote: > mem=0xc000 seems to work! > 0xd000 or 0xe000 do not. > OK, so 3Gb instead of 8... but at least it boots! :) What is the value of the register 0xf1020254 ? Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
Dear Stas Sergeev, On Wed, 11 Mar 2015 20:56:50 +0300, Stas Sergeev wrote: > It doesn't look like it works as intended. > Got the crash below. > Please note the mappings beyond 0xe000, so I wonder if > the option worked as expected? Are you sure you're not confusing virtual addresses and physical addresses? I'm not sure where you see mappings beyond 0xe000, except virtual addresses, which are not relevant here, as we are talking about physical addresses. > [6.122188] Unable to handle kernel NULL pointer dereference at > virtual address 02d4 > [6.130298] pgd = c0004000 > [6.133022] [02d4] *pgd= > [6.136617] Internal error: Oops: 5 [#1] SMP ARM > [6.141244] Modules linked in: > [6.144317] CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted > 4.0.0-rc2-00137-gb672c98-dirty #2 > [6.152600] Hardware name: Marvell Armada 370/XP (Device Tree) > [6.158452] Workqueue: events_unbound async_run_entry_fn > [6.163786] task: ed426c00 ti: ed452000 task.ti: ed452000 > [6.169196] PC is at 0x0 > [6.171734] LR is at 0xfafeff5c > [6.174883] pc : [<>]lr : []psr: > [6.174883] sp : ffd6d7ff ip : fp : 0200 > [6.186388] r10: ed453d90 r9 : 0001 r8 : > [6.191624] r7 : ed5857c0 r6 : r5 : ed80c60a r4 : > [6.198166] r3 : 76c06305 r2 : c200f010 r1 : r0 : > [6.204709] Flags: nzcv IRQs on FIQs on Mode USER_26 ISA ARM > Segment kernel > [6.212121] Control: 10c5387d Table: 406a DAC: 0015 > [6.217880] Process kworker/u8:0 (pid: 6, stack limit = 0xed452220) > [6.224183] ---[ end trace 93bf56ab1670c925 ]--- > [6.228824] Unable to handle kernel NULL pointer dereference at > virtual address 02d4 This looks indeed weird. What I did to work around this problem is to: 1/ Boot in appended DT mode so that the bootloader doesn't mess up with the DTB 2/ Disable CONFIG_ARM_ATAG_DTB_COMPAT so that the kernel doesn't update the /memory/reg DT node with the (bogus) ATAGS passed by the bootloader. Of course, this means you'll have to have a proper /memory/reg value in your DT, and a correct /chosen/bootargs value, since all info passed by the bootloader will essentially be ignored. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 20:46, Russell King - ARM Linux пишет: > On Wed, Mar 11, 2015 at 08:26:53PM +0300, Stas Sergeev wrote: >> Hello Thomas, thanks for that info! >> >> Is there a quick way to test that? >> I used memmap=0x2000$0xe000 but nothing changed... > Use mem=0xe000 instead. memmap= isn't supported on ARM. mem=0xc000 seems to work! 0xd000 or 0xe000 do not. OK, so 3Gb instead of 8... but at least it boots! :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 20:46, Russell King - ARM Linux пишет: > On Wed, Mar 11, 2015 at 08:26:53PM +0300, Stas Sergeev wrote: >> Hello Thomas, thanks for that info! >> >> Is there a quick way to test that? >> I used memmap=0x2000$0xe000 but nothing changed... > Use mem=0xe000 instead. memmap= isn't supported on ARM. > It doesn't look like it works as intended. Got the crash below. Please note the mappings beyond 0xe000, so I wonder if the option worked as expected? [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #2 SMP W ed Mar 11 17:03:41 MSK 2015 [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Marvell Armada XP Development Board DB-MV784MP-GP [0.00] Ignoring memory block 0x1 - 0x2 [0.00] memblock_reserve: [0x008280-0x700203] flags 0x0 arm_memblock_init+0x20/0x18c [0.00] memblock_reserve: [0x004000-0x007fff] flags 0x0 arm_memblock_init+0x124/0x18c [0.00] memblock_reserve: [0x00-0x0027ff] flags 0x0 mvebu_scan_mem+0xa4/0xec [0.00] memblock_reserve: [0x00-0x0027ff] flags 0x0 mvebu_scan_mem+0xa4/0xec [0.00] memblock_reserve: [0xa41168-0xa4535d] flags 0x0 early_init_fdt_scan_reserved_mem+0x30/0x88 [0.00] MEMBLOCK configuration: [0.00] memory size = 0xe000 reserved size = 0x70297a [0.00] memory.cnt = 0x1 [0.00] memory[0x0] [0x00-0x00dfff], 0xe000 bytes flags: 0x0 [0.00] reserved.cnt = 0x4 [0.00] reserved[0x0] [0x00-0x0027ff], 0x2800 bytes flags: 0x0 [0.00] reserved[0x1] [0x004000-0x007fff], 0x4000 bytes flags: 0x0 [0.00] reserved[0x2] [0x008280-0x700203], 0x6f7f84 bytes flags: 0x0 [0.00] reserved[0x3] [0xa41168-0xa4535d], 0x41f6 bytes flags: 0x0 [0.00] Memory policy: Data cache writealloc [0.00] memblock_reserve: [0x002f7fe000-0x002f7f] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fd000-0x002f7fdfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcfd8-0x002f7fcfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fb000-0x002f7fbfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fa000-0x002f7fafff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7f9000-0x002f7f9fff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_virt_alloc_try_nid_nopanic: 29360128 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 alloc_node_mem_map.constprop.66+0x6 0/0x90 [0.00] memblock_reserve: [0x002dbf9000-0x002f7f8fff] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 96 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 free_area_init_node+0x2fc/0x3cc [0.00] memblock_reserve: [0x002f7fcf40-0x002f7fcf9f] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 12288 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 zone_wait_table_init+0x80/0xf0 [0.00] memblock_reserve: [0x002dbf6000-0x002dbf8fff] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 356 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 free_area_init_node+0x2fc/0x3cc [0.00] memblock_reserve: [0x002f7fcdc0-0x002f7fcf23] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 49152 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 zone_wait_table_init+0x80/0xf0 [0.00] memblock_reserve: [0x002dbea000-0x002dbf5fff] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid: 28 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 setup_arch+0x4d4/0x8b0 [0.00] memblock_reserve: [0x002f7fcd80-0x002f7fcd9b] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_reserve: [0x002dbdf040-0x002dbe9fff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcfc0-0x002f7fcfd7] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcfa8-0x002f7fcfbf] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcf28-0x002f7fcf3f] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcda4-0x002f7fcdbc] flags 0x0
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Wed, Mar 11, 2015 at 08:26:53PM +0300, Stas Sergeev wrote: > Hello Thomas, thanks for that info! > > Is there a quick way to test that? > I used memmap=0x2000$0xe000 but nothing changed... Use mem=0xe000 instead. memmap= isn't supported on ARM. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 19:52, Thomas Petazzoni пишет: > Dear Stas Sergeev, > No, this is not the right fix. The right fix is to upgrade your > bootloader to a non-buggy one. > > Basically, the problem is that the memory information passed by the > bootloader to the kernel is not consistent with the MBus base address > which is the limit between RAM (below the MBus base address) and I/O > registers (above the MBus base address). > > The bootloader tells the kernel that the RAM up to 0xf000 is > usable, but sets the MBus base address to 0xe000. So whenever the > kernel accesses 0xe000 -> 0xf000, it crashes, because you're > not hitting RAM but MBus windows (and there are most likely no MBus > window mapped in this space). > > Since kmalloc() relies on the identity mapping, it happens to mainly > use pages at the beginning of the physical memory, which are OK. But > vmalloc() happens to start using pages at the end of the physical > memory (which are not part of the identity mapping), so that's why > you're seeing this on the first access to a vmalloc()ed area. > > This problem has already been reported to Marvell and they have fixed > it in their U-Boot. Please upgrade your bootloader, since there is not > much the kernel can do about this: the bootloader is simply lying to > the kernel about the amount of memory that is accessible. Hello Thomas, thanks for that info! Is there a quick way to test that? I used memmap=0x2000$0xe000 but nothing changed... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
Dear Stas Sergeev, On Tue, 10 Mar 2015 19:54:22 +0300, Stas Sergeev wrote: > Hello, the patch below is needed for a successful boot on armada-xp. > > > -=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=- > This fixes the following crash at boot: > > Unhandled fault: external abort on non-linefetch (0x808) at 0xf00ca018 > Internal error: : 808 [#1] SMP ARM > > CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc1 #3 > Hardware name: Marvell Armada 370/XP (Device Tree) > task: ed41e800 ti: ed43e000 task.ti: ed43e000 > PC is at _set_bit+0x28/0x50 > LR is at n_tty_set_termios+0x328/0x358 > pc : []lr : []psr: 4113 > sp : ed43fd00 ip : fp : > r10: 0002 r9 : r8 : ec930200 > r7 : r6 : f00ca018 r5 : f00ca000 r4 : ed69cc00 > r3 : 2000 r2 : 2000 r1 : f00ca018 r0 : > Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel > Control: 10c5387d Table: 406a DAC: 0015 > Process swapper/0 (pid: 1, stack limit = 0xed43e220) > > The offending instruction in _set_bit() is "strex r0, r2, [r1]" > For some reason the exclusive access instructions do not like the > vmalloc() space... While there may be another fix to make them > fine about vmalloc() space, it still looks like a good idea to > use kmalloc() for allocating a small (sub-page) struct. > > Signed-off-by: Stas Sergeev > --- > drivers/tty/n_tty.c |5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) No, this is not the right fix. The right fix is to upgrade your bootloader to a non-buggy one. Basically, the problem is that the memory information passed by the bootloader to the kernel is not consistent with the MBus base address which is the limit between RAM (below the MBus base address) and I/O registers (above the MBus base address). The bootloader tells the kernel that the RAM up to 0xf000 is usable, but sets the MBus base address to 0xe000. So whenever the kernel accesses 0xe000 -> 0xf000, it crashes, because you're not hitting RAM but MBus windows (and there are most likely no MBus window mapped in this space). Since kmalloc() relies on the identity mapping, it happens to mainly use pages at the beginning of the physical memory, which are OK. But vmalloc() happens to start using pages at the end of the physical memory (which are not part of the identity mapping), so that's why you're seeing this on the first access to a vmalloc()ed area. This problem has already been reported to Marvell and they have fixed it in their U-Boot. Please upgrade your bootloader, since there is not much the kernel can do about this: the bootloader is simply lying to the kernel about the amount of memory that is accessible. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 19:30, Peter Hurley пишет: > On 03/11/2015 10:24 AM, Stas Sergeev wrote: >> However, while testing, I've suddenly got another crash happened >> a bit earlier than the previous one used to happen: (OOM? How??) >> --- > Probably related to these runaway modprobes. Thanks, I'll dig into that. Anyway, the log was obscured by linewraps, so re-posting full version just in case. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #2 SMP W ed Mar 11 17:03:41 MSK 2015 [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Marvell Armada XP Development Board DB-MV784MP-GP [0.00] Ignoring memory block 0x1 - 0x2 [0.00] memblock_reserve: [0x008280-0x700203] flags 0x0 arm_memblock_init+0x20/0x18c [0.00] memblock_reserve: [0x0001100040-0x000142fad3] flags 0x0 arm_memblock_init+0x100/0x18c [0.00] memblock_reserve: [0x004000-0x007fff] flags 0x0 arm_memblock_init+0x124/0x18c [0.00] memblock_reserve: [0x00-0x0027ff] flags 0x0 mvebu_scan_mem+0xa4/0xec [0.00] memblock_reserve: [0x00-0x0027ff] flags 0x0 mvebu_scan_mem+0xa4/0xec [0.00] memblock_reserve: [0xa41168-0xa45391] flags 0x0 early_init_fdt_scan_reserved_mem+0x30/0x88 [0.00] MEMBLOCK configuration: [0.00] memory size = 0xf000 reserved size = 0xa32442 [0.00] memory.cnt = 0x1 [0.00] memory[0x0] [0x00-0x00efff], 0xf000 bytes flags: 0x0 [0.00] reserved.cnt = 0x5 [0.00] reserved[0x0] [0x00-0x0027ff], 0x2800 bytes flags: 0x0 [0.00] reserved[0x1] [0x004000-0x007fff], 0x4000 bytes flags: 0x0 [0.00] reserved[0x2] [0x008280-0x700203], 0x6f7f84 bytes flags: 0x0 [0.00] reserved[0x3] [0xa41168-0xa45391], 0x422a bytes flags: 0x0 [0.00] reserved[0x4] [0x0001100040-0x000142fad3], 0x32fa94 bytes flags: 0x0 [0.00] Memory policy: Data cache writealloc [0.00] memblock_reserve: [0x002f7fe000-0x002f7f] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fd000-0x002f7fdfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcfd8-0x002f7fcfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fb000-0x002f7fbfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fa000-0x002f7fafff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7f9000-0x002f7f9fff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_virt_alloc_try_nid_nopanic: 31457280 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 alloc_node_mem_map.constprop.66+0x6 0/0x90 [0.00] memblock_reserve: [0x002d9f9000-0x002f7f8fff] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 96 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 free_area_init_node+0x2fc/0x3cc [0.00] memblock_reserve: [0x002f7fcf40-0x002f7fcf9f] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 12288 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 zone_wait_table_init+0x80/0xf0 [0.00] memblock_reserve: [0x002d9f6000-0x002d9f8fff] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 388 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 free_area_init_node+0x2fc/0x3cc [0.00] memblock_reserve: [0x002f7fcd80-0x002f7fcf03] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 49152 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 zone_wait_table_init+0x80/0xf0 [0.00] memblock_reserve: [0x002d9ea000-0x002d9f5fff] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid: 28 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 setup_arch+0x4d4/0x8b0 [0.00] memblock_reserve: [0x002f7fcd40-0x002f7fcd5b] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_reserve: [0x002d9defd8-0x002d9e9fff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcfc0-0x002f7fcfd7] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcfa8-0x002f7fcfbf] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcf28-0x002f7fcf3f] flags 0x0
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On 03/11/2015 10:24 AM, Stas Sergeev wrote: > However, while testing, I've suddenly got another crash happened > a bit earlier than the previous one used to happen: (OOM? How??) > --- Probably related to these runaway modprobes. > [6.646259] request_module: runaway loop modprobe binfmt- > [6.653829] m25p80 spi0.0: n25q128a13 (16384 Kbytes) > [6.664246] request_module: runaway loop modprobe binfmt- Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 18:13, Gregory CLEMENT пишет: > On 11/03/2015 16:01, Stas Sergeev wrote: >> 11.03.2015 16:14, Russell King - ARM Linux пишет: >>> On Wed, Mar 11, 2015 at 01:44:57PM +0100, Gregory CLEMENT wrote: Hi Stas, On 10/03/2015 17:54, Stas Sergeev wrote: > Hello, the patch below is needed for a successful boot on armada-xp. > I am really surprised by this patch because I used the Armada XP based board in a daily base and I never saw this issue. >>> Can you provide some details about your board - does it have 8GB of >>> memory, ranging from 0-0xf000, and 4G-8G ? >> I wonder about this 256Mb memory hole. > This is where the SoC registers are. OK but it seems I am loosing this region of _physical_ memory: --- [0.00] memory size = 0x1f000 [0.00] memory.cnt = 0x2 [0.00] memory[0x0] [0x00-0x00efff], 0xf000 bytes [0.00] memory[0x1] [0x01-0x01], 0x1 bytes --- As you can see, memory size is 0x1f000 instead of 0x2000. Why 256Mb are lost? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On 11/03/2015 16:01, Stas Sergeev wrote: > 11.03.2015 16:14, Russell King - ARM Linux пишет: >> On Wed, Mar 11, 2015 at 01:44:57PM +0100, Gregory CLEMENT wrote: >>> Hi Stas, >>> >>> On 10/03/2015 17:54, Stas Sergeev wrote: Hello, the patch below is needed for a successful boot on armada-xp. >>> I am really surprised by this patch because I used the Armada XP based >>> board in a daily base and I never saw this issue. >> Can you provide some details about your board - does it have 8GB of >> memory, ranging from 0-0xf000, and 4G-8G ? > I wonder about this 256Mb memory hole. This is where the SoC registers are. > There is only one dimm for whole 8Gb. > It seems 0xf00-0x is used for PCI though: > --- > > 0xf300-0xf303 64bit] > [ 119.290027] pci :00:00.0: BAR 2: set to [mem > 0xf300-0xf303 64bit] (PCI address [0xf300-0xf303]) > [ 119.300509] pci :00:00.0: BAR 0: assigned [mem > 0xf304-0xf305 64bit] > [ 119.307883] pci :00:00.0: BAR 0: set to [mem > 0xf304-0xf305 64bit] (PCI address [0xf304-0xf305]) > [ 119.318367] pci :00:00.0: BAR 6: assigned [mem > 0xf306-0xf306 pref] > > --- > > Does this mean that the 256Mb of physical memory is > completely unaccessable on this board? > -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 16:14, Russell King - ARM Linux пишет: > On Wed, Mar 11, 2015 at 01:44:57PM +0100, Gregory CLEMENT wrote: >> Hi Stas, >> >> On 10/03/2015 17:54, Stas Sergeev wrote: >>> Hello, the patch below is needed for a successful boot on armada-xp. >>> >> I am really surprised by this patch because I used the Armada XP based >> board in a daily base and I never saw this issue. > Can you provide some details about your board - does it have 8GB of > memory, ranging from 0-0xf000, and 4G-8G ? I wonder about this 256Mb memory hole. There is only one dimm for whole 8Gb. It seems 0xf00-0x is used for PCI though: --- 0xf300-0xf303 64bit] [ 119.290027] pci :00:00.0: BAR 2: set to [mem 0xf300-0xf303 64bit] (PCI address [0xf300-0xf303]) [ 119.300509] pci :00:00.0: BAR 0: assigned [mem 0xf304-0xf305 64bit] [ 119.307883] pci :00:00.0: BAR 0: set to [mem 0xf304-0xf305 64bit] (PCI address [0xf304-0xf305]) [ 119.318367] pci :00:00.0: BAR 6: assigned [mem 0xf306-0xf306 pref] --- Does this mean that the 256Mb of physical memory is completely unaccessable on this board? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 16:14, Russell King - ARM Linux пишет: > On Wed, Mar 11, 2015 at 01:44:57PM +0100, Gregory CLEMENT wrote: >> Hi Stas, >> >> On 10/03/2015 17:54, Stas Sergeev wrote: >>> Hello, the patch below is needed for a successful boot on armada-xp. >>> >> I am really surprised by this patch because I used the Armada XP based >> board in a daily base and I never saw this issue. > Can you provide some details about your board - does it have 8GB of > memory, ranging from 0-0xf000, and 4G-8G ? Yes, there should be 8G, here's the boot log from marvell kernel that boots fine and works fine: [0.00] Booting Linux on physical CPU 0 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.2.58-1-armadaxp (root@host-010-100) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #0 SMP Thu Dec 18 124 [0.00] CPU: Marvell - PJ4Bv7 Processor [562f5842] revision 2 (ARMv7), cr=30c73c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine: Marvell Armada XP GP Board [0.00] Using UBoot passing parameters structure [0.00] bootconsole [earlycon0] enabled [0.00] Reserving training memory: base=0x (null) size=0x2800 [0.00] Reserving training memory: base=0x8000 size=0x2800 [0.00] Reserving training memory: base=0xc000 size=0x2800 [0.00] Reserving training memory: base=0xe000 size=0x2800 [0.00] MEMBLOCK configuration: [0.00] memory size = 0x1f000 [0.00] memory.cnt = 0x2 [0.00] memory[0x0] [0x00-0x00efff], 0xf000 bytes [0.00] memory[0x1] [0x01-0x01], 0x1 bytes [0.00] reserved.cnt = 0x7 [0.00] reserved[0x0] [0x00-0x0027ff], 0x2800 bytes [0.00] reserved[0x1] [0x003000-0x007fff], 0x5000 bytes [0.00] reserved[0x2] [0x0081e0-0x9ef02f], 0x9e6e50 bytes [0.00] reserved[0x3] [0x0001100040-0x000142fad3], 0x32fa94 bytes [0.00] reserved[0x4] [0x008000-0x00800027ff], 0x2800 bytes [0.00] reserved[0x5] [0x00c000-0x00c00027ff], 0x2800 bytes [0.00] reserved[0x6] [0x00e000-0x00e00027ff], 0x2800 bytes [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] SMP: init cpus [0.00] PERCPU: Embedded 7 pages/cpu @c5442000 s7104 r8192 d13376 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 2015232 [0.00] Kernel command line: console=ttyS0,115200 earlyprintk=ttyS0 root=/dev/sda2 rw pm_disable memblock=debug [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] allocated 33554432 bytes of page_cgroup [0.00] please try 'cgroup_disable=memory' option if you don't want memory cgroups [0.00] Memory: 3840MB 4096MB = 7936MB total [0.00] Memory: 8015704k/8015704k available, 110760k reserved, 7299036K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xf300 - 0xfa80 ( 120 MB) [0.00] lowmem : 0xc000 - 0xf280 ( 808 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc08b4000 (8880 kB) [0.00] .init : 0xc08b4000 - 0xc08fabc0 ( 283 kB) [0.00] .data : 0xc08fc000 - 0xc0948a20 ( 307 kB) [0.00].bss : 0xc0948a44 - 0xc09ef030 ( 666 kB) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:211 [0.00] Initializing ArmadaXP SOC Timer 0 [0.00] sched_clock: 32 bits at 25MHz, resolution 40ns, wraps every 171798ms [ 117.562527] Calibrating delay loop... 1594.16 BogoMIPS (lpj=7970816) [ 117.655298] pid_max: default: 32768 minimum: 301 [ 117.660091] Security Framework initialized [ 117.664285] AppArmor: AppArmor initialized [ 117.668578] Mount-cache hash table entries: 512 [ 117.673594] Initializing cgroup subsys cpuacct [ 117.678123] Initializing cgroup subsys memory [ 117.682584] Initializing cgroup subsys devices [ 117.687093] Initializing cgroup subsys freezer [ 117.691601] Initializing cgroup subsys net_cls [ 117.696117] Initializing cgroup subsys blkio [ 117.700528] CPU: Testing write buffer coherency: ok [ 117.705627] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [ 117.711350] SMP: prepare CPUs (4 cores) [ 117.715539] Setting Clocks for secondary CPUs [ 117.720891] SMP: CPU 0 Waking up
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 15:47, Russell King - ARM Linux пишет: >> [6.857113] vmalloc: mapping page ef7f12c0 (0x000efc16000) at 0xf00d4000 >> [6.863845] vmalloc: mapping page ef7f12a0 (0x000efc15000) at 0xf00d5000 >> [6.870567] Unhandled fault: external abort on non-linefetch (0x808) >> at 0xf00d3018 > Yet it causes this. I wonder if there's a conflict between DRAM and > some other devices causing this, or maybe a stale TLB entry. > > The thing which makes me consider a stale TLB entry is that the mapping > we're adding is for a WBWA cacheable mapping, which should cause line > fetches. The abort which is being raised is for a non-linefetch, a > type of access which a WBWA cacheable mapping should never create. > > We can check whether it's a stale TLB entry - if you add a call to > flush_tlb_all() after the call to vmalloc() in n_tty_open(). You > may need to include to make that work - can you try > that please. Seems to be the same: --- [6.872592] vmalloc: mapping page ef7f0800 (0x000efbc) at 0xf00d3000 [6.879309] vmalloc: mapping page ef7f0820 (0x000efbc1000) at 0xf00d4000 [6.886040] vmalloc: mapping page ef7f0840 (0x000efbc2000) at 0xf00d5000 [6.892762] flush_tlb_all() called here [6.896611] Unhandled fault: external abort on non-linefetch (0x808) at 0xf00d3018 [6.903717] sda: sda1 sda2 sda3 [6.907429] pgd = c0004000 [6.910141] [f00d3018] *pgd=2d404811, *pte=efbc065f, *ppte=efbc045f [6.916461] Internal error: : 808 [#1] SMP ARM --- However, while testing, I've suddenly got another crash happened a bit earlier than the previous one used to happen: (OOM? How??) --- [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #2 SMP 5 [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Marvell Armada XP Development Board DB-MV784MP-GP [0.00] Ignoring memory block 0x1 - 0x2 [0.00] memblock_reserve: [0x008280-0x700203] flags 0x0 arm_memblock_init+0x20/0x18c [0.00] memblock_reserve: [0x0001100040-0x000142fad3] flags 0x0 arm_memblock_init+0x100/0x18c [0.00] memblock_reserve: [0x004000-0x007fff] flags 0x0 arm_memblock_init+0x124/0x18c [0.00] memblock_reserve: [0x00-0x0027ff] flags 0x0 mvebu_scan_mem+0xa4/0xec [0.00] memblock_reserve: [0x00-0x0027ff] flags 0x0 mvebu_scan_mem+0xa4/0xec [0.00] memblock_reserve: [0xa41168-0xa45391] flags 0x0 early_init_fdt_scan_reserved_mem+0x30/0x88 [0.00] MEMBLOCK configuration: [0.00] memory size = 0xf000 reserved size = 0xa32442 [0.00] memory.cnt = 0x1 [0.00] memory[0x0] [0x00-0x00efff], 0xf000 bytes flags: 0x0 [0.00] reserved.cnt = 0x5 [0.00] reserved[0x0] [0x00-0x0027ff], 0x2800 bytes flags: 0x0 [0.00] reserved[0x1] [0x004000-0x007fff], 0x4000 bytes flags: 0x0 [0.00] reserved[0x2] [0x008280-0x700203], 0x6f7f84 bytes flags: 0x0 [0.00] reserved[0x3] [0xa41168-0xa45391], 0x422a bytes flags: 0x0 [0.00] reserved[0x4] [0x0001100040-0x000142fad3], 0x32fa94 bytes flags: 0x0 [0.00] Memory policy: Data cache writealloc [0.00] memblock_reserve: [0x002f7fe000-0x002f7f] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fd000-0x002f7fdfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcfd8-0x002f7fcfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fb000-0x002f7fbfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fa000-0x002f7fafff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7f9000-0x002f7f9fff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_virt_alloc_try_nid_nopanic: 31457280 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 alloc_node_mem_map.constprop.66+0x0 [0.00] memblock_reserve: [0x002d9f9000-0x002f7f8fff] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 96 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 free_area_init_node+0x2fc/0x3cc [0.00] memblock_reserve: [0x002f7fcf40-0x002f7fcf9f] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 12288 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 zone_wait_table_init+0x80/0xf0 [0.00] memblock_reserve: [0x002d9f6000-0x002d9f8fff] flags 0x0
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Wed, Mar 11, 2015 at 01:44:57PM +0100, Gregory CLEMENT wrote: > Hi Stas, > > On 10/03/2015 17:54, Stas Sergeev wrote: > > Hello, the patch below is needed for a successful boot on armada-xp. > > > > I am really surprised by this patch because I used the Armada XP based > board in a daily base and I never saw this issue. Can you provide some details about your board - does it have 8GB of memory, ranging from 0-0xf000, and 4G-8G ? Thanks. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 15:44, Gregory CLEMENT пишет: > Hi Stas, > > On 10/03/2015 17:54, Stas Sergeev wrote: >> Hello, the patch below is needed for a successful boot on armada-xp. >> > I am really surprised by this patch because I used the Armada XP based > board in a daily base and I never saw this issue. > > Could you provide your .config? > > Also could you confirm that you use the dts from arch/arm/boot/dts > wihtout any change? With defconfig, and dts without a slightest change this is still reproduceable (the logs I was posting to this thread were done with _slightly_ modified config, and unmodified DT). But... the board itself is modified. It is not a pure armada-xp-gp. I still doubt that this crash is because of the board's mods, for example please find the same crash here: http://lists.linaro.org/pipermail/kernel-build-reports/2014-June/003872.html --- Console logs for failures = arm-mvebu_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y -- armada-xp-openblocks-ax3-4: FAIL: last 40 lines of boot log: 3fe0: 0013 55048012 02109471 [] (_set_bit) from [] (n_tty_set_termios+0x234/0x348) [] (n_tty_set_termios) from [] (n_tty_open+0xec/0x114) --- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Wed, Mar 11, 2015 at 03:30:33PM +0300, Stas Sergeev wrote: > OK, here we go. > > [0.00] Booting Linux on physical CPU 0x0 > [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty > (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) > #60 SMP5 > [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), > cr=10c5387d > [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction > cache > [0.00] Machine model: Marvell Armada XP Development Board > DB-MV784MP-GP > [0.00] Ignoring memory block 0x1 - 0x2 ... > [0.00] MEMBLOCK configuration: > [0.00] memory size = 0xf000 reserved size = 0xa32442 > [0.00] memory.cnt = 0x1 > [0.00] memory[0x0] [0x00-0x00efff], > 0xf000 bytes flags: 0x0 So this says you have memory covering that entire range, and actually beyond to 8GB. > [6.772534] vmalloc: mapping page ef7f13c0 (0x000efc1e000) at 0xf00ca000 > [6.772537] vmalloc: mapping page ef7f13a0 (0x000efc1d000) at 0xf00cb000 > [6.772540] vmalloc: mapping page ef7f1380 (0x000efc1c000) at 0xf00cc000 > [6.772542] vmalloc: mapping page ef7f1360 (0x000efc1b000) at 0xf00cd000 > [6.772544] vmalloc: mapping page ef7f1340 (0x000efc1a000) at 0xf00ce000 > [6.772546] vmalloc: mapping page ef7f1320 (0x000efc19000) at 0xf00cf000 > [6.772548] vmalloc: mapping page ef7f1300 (0x000efc18000) at 0xf00d > [6.772551] vmalloc: mapping page ef7f12e0 (0x000efc17000) at 0xf00d1000 > [6.822102] ata2: SATA link down (SStatus 0 SControl F300) > [6.850381] vmalloc: mapping page ef7f0420 (0x000efba1000) at 0xf00d3000 Here, we set up the mapping, which looks fine - it's apparently in the range of physical addresses we expect for system memory. > [6.857113] vmalloc: mapping page ef7f12c0 (0x000efc16000) at 0xf00d4000 > [6.863845] vmalloc: mapping page ef7f12a0 (0x000efc15000) at 0xf00d5000 > [6.870567] Unhandled fault: external abort on non-linefetch (0x808) > at 0xf00d3018 Yet it causes this. I wonder if there's a conflict between DRAM and some other devices causing this, or maybe a stale TLB entry. The thing which makes me consider a stale TLB entry is that the mapping we're adding is for a WBWA cacheable mapping, which should cause line fetches. The abort which is being raised is for a non-linefetch, a type of access which a WBWA cacheable mapping should never create. We can check whether it's a stale TLB entry - if you add a call to flush_tlb_all() after the call to vmalloc() in n_tty_open(). You may need to include to make that work - can you try that please. Sorry it's needing soo much back-n-forth between us, I don't have any Armada platforms which approach the size you have there. :( -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
Hi Stas, On 10/03/2015 17:54, Stas Sergeev wrote: > Hello, the patch below is needed for a successful boot on armada-xp. > I am really surprised by this patch because I used the Armada XP based board in a daily base and I never saw this issue. Could you provide your .config? Also could you confirm that you use the dts from arch/arm/boot/dts wihtout any change? Thanks, Gregory > -=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=- > This fixes the following crash at boot: > > Unhandled fault: external abort on non-linefetch (0x808) at 0xf00ca018 > Internal error: : 808 [#1] SMP ARM > > CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc1 #3 > Hardware name: Marvell Armada 370/XP (Device Tree) > task: ed41e800 ti: ed43e000 task.ti: ed43e000 > PC is at _set_bit+0x28/0x50 > LR is at n_tty_set_termios+0x328/0x358 > pc : []lr : []psr: 4113 > sp : ed43fd00 ip : fp : > r10: 0002 r9 : r8 : ec930200 > r7 : r6 : f00ca018 r5 : f00ca000 r4 : ed69cc00 > r3 : 2000 r2 : 2000 r1 : f00ca018 r0 : > Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel > Control: 10c5387d Table: 406a DAC: 0015 > Process swapper/0 (pid: 1, stack limit = 0xed43e220) > > The offending instruction in _set_bit() is "strex r0, r2, [r1]" > For some reason the exclusive access instructions do not like the > vmalloc() space... While there may be another fix to make them > fine about vmalloc() space, it still looks like a good idea to > use kmalloc() for allocating a small (sub-page) struct. > > Signed-off-by: Stas Sergeev > --- > drivers/tty/n_tty.c |5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c > index cf6e0f2..e03622e 100644 > --- a/drivers/tty/n_tty.c > +++ b/drivers/tty/n_tty.c > @@ -50,7 +50,6 @@ > #include > #include > #include > -#include > > > /* number of characters left in xmit buffer before select has we have > room */ > @@ -1892,7 +1891,7 @@ static void n_tty_close(struct tty_struct *tty) > if (tty->link) > n_tty_packet_mode_flush(tty); > > -vfree(ldata); > +kfree(ldata); > tty->disc_data = NULL; > } > > @@ -1911,7 +1910,7 @@ static int n_tty_open(struct tty_struct *tty) > struct n_tty_data *ldata; > > /* Currently a malloc failure here can panic */ > -ldata = vmalloc(sizeof(*ldata)); > +ldata = kmalloc(sizeof(*ldata), GFP_KERNEL); > if (!ldata) > goto err; > > -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
Russell King - ARM Linux wrote: > Let's see whether we can get some debug from vmalloc to work out what's > going on - can you also apply the patch below. > > Also, if you could include details about how much memory your platform > has, and where it's located, that would be useful - passing > memblock=debug > should allow us to see what's going on at the memblock level. > > Also, the full kernel boot log would be useful to see. OK, here we go. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #60 SMP5 [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Marvell Armada XP Development Board DB-MV784MP-GP [0.00] Ignoring memory block 0x1 - 0x2 [0.00] memblock_reserve: [0x008280-0x700203] flags 0x0 arm_memblock_init+0x20/0x18c [0.00] memblock_reserve: [0x0001100040-0x000142fad3] flags 0x0 arm_memblock_init+0x100/0x18c [0.00] memblock_reserve: [0x004000-0x007fff] flags 0x0 arm_memblock_init+0x124/0x18c [0.00] memblock_reserve: [0x00-0x0027ff] flags 0x0 mvebu_scan_mem+0xa4/0xec [0.00] memblock_reserve: [0x00-0x0027ff] flags 0x0 mvebu_scan_mem+0xa4/0xec [0.00] memblock_reserve: [0xa41970-0xa45b99] flags 0x0 early_init_fdt_scan_reserved_mem+0x30/0x88 [0.00] MEMBLOCK configuration: [0.00] memory size = 0xf000 reserved size = 0xa32442 [0.00] memory.cnt = 0x1 [0.00] memory[0x0] [0x00-0x00efff], 0xf000 bytes flags: 0x0 [0.00] reserved.cnt = 0x5 [0.00] reserved[0x0] [0x00-0x0027ff], 0x2800 bytes flags: 0x0 [0.00] reserved[0x1] [0x004000-0x007fff], 0x4000 bytes flags: 0x0 [0.00] reserved[0x2] [0x008280-0x700203], 0x6f7f84 bytes flags: 0x0 [0.00] reserved[0x3] [0xa41970-0xa45b99], 0x422a bytes flags: 0x0 [0.00] reserved[0x4] [0x0001100040-0x000142fad3], 0x32fa94 bytes flags: 0x0 [0.00] Memory policy: Data cache writealloc [0.00] memblock_reserve: [0x002f7fe000-0x002f7f] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fd000-0x002f7fdfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcfd8-0x002f7fcfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fb000-0x002f7fbfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fa000-0x002f7fafff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7f9000-0x002f7f9fff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_virt_alloc_try_nid_nopanic: 31457280 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 alloc_node_mem_map.constprop.66+0x0 [0.00] memblock_reserve: [0x002d9f9000-0x002f7f8fff] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 96 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 free_area_init_node+0x2fc/0x3cc [0.00] memblock_reserve: [0x002f7fcf40-0x002f7fcf9f] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 12288 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 zone_wait_table_init+0x80/0xf0 [0.00] memblock_reserve: [0x002d9f6000-0x002d9f8fff] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 388 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 free_area_init_node+0x2fc/0x3cc [0.00] memblock_reserve: [0x002f7fcd80-0x002f7fcf03] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 49152 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 zone_wait_table_init+0x80/0xf0 [0.00] memblock_reserve: [0x002d9ea000-0x002d9f5fff] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid: 28 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 setup_arch+0x4d4/0x8b0 [0.00] memblock_reserve: [0x002f7fcd40-0x002f7fcd5b] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_reserve: [0x002d9defd8-0x002d9e9fff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcfc0-0x002f7fcfd7] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcfa8-0x002f7fcfbf] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcf28-0x002f7fcf3f] flags
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
Dear Stas Sergeev, On Tue, 10 Mar 2015 19:54:22 +0300, Stas Sergeev wrote: Hello, the patch below is needed for a successful boot on armada-xp. -=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=- This fixes the following crash at boot: Unhandled fault: external abort on non-linefetch (0x808) at 0xf00ca018 Internal error: : 808 [#1] SMP ARM CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc1 #3 Hardware name: Marvell Armada 370/XP (Device Tree) task: ed41e800 ti: ed43e000 task.ti: ed43e000 PC is at _set_bit+0x28/0x50 LR is at n_tty_set_termios+0x328/0x358 pc : [c01bc858]lr : [c0207314]psr: 4113 sp : ed43fd00 ip : fp : r10: 0002 r9 : r8 : ec930200 r7 : r6 : f00ca018 r5 : f00ca000 r4 : ed69cc00 r3 : 2000 r2 : 2000 r1 : f00ca018 r0 : Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 406a DAC: 0015 Process swapper/0 (pid: 1, stack limit = 0xed43e220) The offending instruction in _set_bit() is strex r0, r2, [r1] For some reason the exclusive access instructions do not like the vmalloc() space... While there may be another fix to make them fine about vmalloc() space, it still looks like a good idea to use kmalloc() for allocating a small (sub-page) struct. Signed-off-by: Stas Sergeev s...@users.sourceforge.net --- drivers/tty/n_tty.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) No, this is not the right fix. The right fix is to upgrade your bootloader to a non-buggy one. Basically, the problem is that the memory information passed by the bootloader to the kernel is not consistent with the MBus base address which is the limit between RAM (below the MBus base address) and I/O registers (above the MBus base address). The bootloader tells the kernel that the RAM up to 0xf000 is usable, but sets the MBus base address to 0xe000. So whenever the kernel accesses 0xe000 - 0xf000, it crashes, because you're not hitting RAM but MBus windows (and there are most likely no MBus window mapped in this space). Since kmalloc() relies on the identity mapping, it happens to mainly use pages at the beginning of the physical memory, which are OK. But vmalloc() happens to start using pages at the end of the physical memory (which are not part of the identity mapping), so that's why you're seeing this on the first access to a vmalloc()ed area. This problem has already been reported to Marvell and they have fixed it in their U-Boot. Please upgrade your bootloader, since there is not much the kernel can do about this: the bootloader is simply lying to the kernel about the amount of memory that is accessible. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On 11/03/2015 16:01, Stas Sergeev wrote: 11.03.2015 16:14, Russell King - ARM Linux пишет: On Wed, Mar 11, 2015 at 01:44:57PM +0100, Gregory CLEMENT wrote: Hi Stas, On 10/03/2015 17:54, Stas Sergeev wrote: Hello, the patch below is needed for a successful boot on armada-xp. I am really surprised by this patch because I used the Armada XP based board in a daily base and I never saw this issue. Can you provide some details about your board - does it have 8GB of memory, ranging from 0-0xf000, and 4G-8G ? I wonder about this 256Mb memory hole. This is where the SoC registers are. There is only one dimm for whole 8Gb. It seems 0xf00-0x is used for PCI though: --- 0xf300-0xf303 64bit] [ 119.290027] pci :00:00.0: BAR 2: set to [mem 0xf300-0xf303 64bit] (PCI address [0xf300-0xf303]) [ 119.300509] pci :00:00.0: BAR 0: assigned [mem 0xf304-0xf305 64bit] [ 119.307883] pci :00:00.0: BAR 0: set to [mem 0xf304-0xf305 64bit] (PCI address [0xf304-0xf305]) [ 119.318367] pci :00:00.0: BAR 6: assigned [mem 0xf306-0xf306 pref] --- Does this mean that the 256Mb of physical memory is completely unaccessable on this board? -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 16:14, Russell King - ARM Linux пишет: On Wed, Mar 11, 2015 at 01:44:57PM +0100, Gregory CLEMENT wrote: Hi Stas, On 10/03/2015 17:54, Stas Sergeev wrote: Hello, the patch below is needed for a successful boot on armada-xp. I am really surprised by this patch because I used the Armada XP based board in a daily base and I never saw this issue. Can you provide some details about your board - does it have 8GB of memory, ranging from 0-0xf000, and 4G-8G ? I wonder about this 256Mb memory hole. There is only one dimm for whole 8Gb. It seems 0xf00-0x is used for PCI though: --- 0xf300-0xf303 64bit] [ 119.290027] pci :00:00.0: BAR 2: set to [mem 0xf300-0xf303 64bit] (PCI address [0xf300-0xf303]) [ 119.300509] pci :00:00.0: BAR 0: assigned [mem 0xf304-0xf305 64bit] [ 119.307883] pci :00:00.0: BAR 0: set to [mem 0xf304-0xf305 64bit] (PCI address [0xf304-0xf305]) [ 119.318367] pci :00:00.0: BAR 6: assigned [mem 0xf306-0xf306 pref] --- Does this mean that the 256Mb of physical memory is completely unaccessable on this board? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On 03/11/2015 10:24 AM, Stas Sergeev wrote: However, while testing, I've suddenly got another crash happened a bit earlier than the previous one used to happen: (OOM? How??) --- Probably related to these runaway modprobes. [6.646259] request_module: runaway loop modprobe binfmt- [6.653829] m25p80 spi0.0: n25q128a13 (16384 Kbytes) [6.664246] request_module: runaway loop modprobe binfmt- Regards, Peter Hurley -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 19:30, Peter Hurley пишет: On 03/11/2015 10:24 AM, Stas Sergeev wrote: However, while testing, I've suddenly got another crash happened a bit earlier than the previous one used to happen: (OOM? How??) --- Probably related to these runaway modprobes. Thanks, I'll dig into that. Anyway, the log was obscured by linewraps, so re-posting full version just in case. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #2 SMP W ed Mar 11 17:03:41 MSK 2015 [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Marvell Armada XP Development Board DB-MV784MP-GP [0.00] Ignoring memory block 0x1 - 0x2 [0.00] memblock_reserve: [0x008280-0x700203] flags 0x0 arm_memblock_init+0x20/0x18c [0.00] memblock_reserve: [0x0001100040-0x000142fad3] flags 0x0 arm_memblock_init+0x100/0x18c [0.00] memblock_reserve: [0x004000-0x007fff] flags 0x0 arm_memblock_init+0x124/0x18c [0.00] memblock_reserve: [0x00-0x0027ff] flags 0x0 mvebu_scan_mem+0xa4/0xec [0.00] memblock_reserve: [0x00-0x0027ff] flags 0x0 mvebu_scan_mem+0xa4/0xec [0.00] memblock_reserve: [0xa41168-0xa45391] flags 0x0 early_init_fdt_scan_reserved_mem+0x30/0x88 [0.00] MEMBLOCK configuration: [0.00] memory size = 0xf000 reserved size = 0xa32442 [0.00] memory.cnt = 0x1 [0.00] memory[0x0] [0x00-0x00efff], 0xf000 bytes flags: 0x0 [0.00] reserved.cnt = 0x5 [0.00] reserved[0x0] [0x00-0x0027ff], 0x2800 bytes flags: 0x0 [0.00] reserved[0x1] [0x004000-0x007fff], 0x4000 bytes flags: 0x0 [0.00] reserved[0x2] [0x008280-0x700203], 0x6f7f84 bytes flags: 0x0 [0.00] reserved[0x3] [0xa41168-0xa45391], 0x422a bytes flags: 0x0 [0.00] reserved[0x4] [0x0001100040-0x000142fad3], 0x32fa94 bytes flags: 0x0 [0.00] Memory policy: Data cache writealloc [0.00] memblock_reserve: [0x002f7fe000-0x002f7f] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fd000-0x002f7fdfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcfd8-0x002f7fcfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fb000-0x002f7fbfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fa000-0x002f7fafff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7f9000-0x002f7f9fff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_virt_alloc_try_nid_nopanic: 31457280 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 alloc_node_mem_map.constprop.66+0x6 0/0x90 [0.00] memblock_reserve: [0x002d9f9000-0x002f7f8fff] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 96 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 free_area_init_node+0x2fc/0x3cc [0.00] memblock_reserve: [0x002f7fcf40-0x002f7fcf9f] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 12288 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 zone_wait_table_init+0x80/0xf0 [0.00] memblock_reserve: [0x002d9f6000-0x002d9f8fff] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 388 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 free_area_init_node+0x2fc/0x3cc [0.00] memblock_reserve: [0x002f7fcd80-0x002f7fcf03] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 49152 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 zone_wait_table_init+0x80/0xf0 [0.00] memblock_reserve: [0x002d9ea000-0x002d9f5fff] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid: 28 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 setup_arch+0x4d4/0x8b0 [0.00] memblock_reserve: [0x002f7fcd40-0x002f7fcd5b] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_reserve: [0x002d9defd8-0x002d9e9fff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcfc0-0x002f7fcfd7] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcfa8-0x002f7fcfbf] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcf28-0x002f7fcf3f] flags 0x0 memblock_alloc_range_nid+0x30/0x44
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 18:13, Gregory CLEMENT пишет: On 11/03/2015 16:01, Stas Sergeev wrote: 11.03.2015 16:14, Russell King - ARM Linux пишет: On Wed, Mar 11, 2015 at 01:44:57PM +0100, Gregory CLEMENT wrote: Hi Stas, On 10/03/2015 17:54, Stas Sergeev wrote: Hello, the patch below is needed for a successful boot on armada-xp. I am really surprised by this patch because I used the Armada XP based board in a daily base and I never saw this issue. Can you provide some details about your board - does it have 8GB of memory, ranging from 0-0xf000, and 4G-8G ? I wonder about this 256Mb memory hole. This is where the SoC registers are. OK but it seems I am loosing this region of _physical_ memory: --- [0.00] memory size = 0x1f000 [0.00] memory.cnt = 0x2 [0.00] memory[0x0] [0x00-0x00efff], 0xf000 bytes [0.00] memory[0x1] [0x01-0x01], 0x1 bytes --- As you can see, memory size is 0x1f000 instead of 0x2000. Why 256Mb are lost? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 19:52, Thomas Petazzoni пишет: Dear Stas Sergeev, No, this is not the right fix. The right fix is to upgrade your bootloader to a non-buggy one. Basically, the problem is that the memory information passed by the bootloader to the kernel is not consistent with the MBus base address which is the limit between RAM (below the MBus base address) and I/O registers (above the MBus base address). The bootloader tells the kernel that the RAM up to 0xf000 is usable, but sets the MBus base address to 0xe000. So whenever the kernel accesses 0xe000 - 0xf000, it crashes, because you're not hitting RAM but MBus windows (and there are most likely no MBus window mapped in this space). Since kmalloc() relies on the identity mapping, it happens to mainly use pages at the beginning of the physical memory, which are OK. But vmalloc() happens to start using pages at the end of the physical memory (which are not part of the identity mapping), so that's why you're seeing this on the first access to a vmalloc()ed area. This problem has already been reported to Marvell and they have fixed it in their U-Boot. Please upgrade your bootloader, since there is not much the kernel can do about this: the bootloader is simply lying to the kernel about the amount of memory that is accessible. Hello Thomas, thanks for that info! Is there a quick way to test that? I used memmap=0x2000$0xe000 but nothing changed... -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 20:46, Russell King - ARM Linux пишет: On Wed, Mar 11, 2015 at 08:26:53PM +0300, Stas Sergeev wrote: Hello Thomas, thanks for that info! Is there a quick way to test that? I used memmap=0x2000$0xe000 but nothing changed... Use mem=0xe000 instead. memmap= isn't supported on ARM. It doesn't look like it works as intended. Got the crash below. Please note the mappings beyond 0xe000, so I wonder if the option worked as expected? [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #2 SMP W ed Mar 11 17:03:41 MSK 2015 [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Marvell Armada XP Development Board DB-MV784MP-GP [0.00] Ignoring memory block 0x1 - 0x2 [0.00] memblock_reserve: [0x008280-0x700203] flags 0x0 arm_memblock_init+0x20/0x18c [0.00] memblock_reserve: [0x004000-0x007fff] flags 0x0 arm_memblock_init+0x124/0x18c [0.00] memblock_reserve: [0x00-0x0027ff] flags 0x0 mvebu_scan_mem+0xa4/0xec [0.00] memblock_reserve: [0x00-0x0027ff] flags 0x0 mvebu_scan_mem+0xa4/0xec [0.00] memblock_reserve: [0xa41168-0xa4535d] flags 0x0 early_init_fdt_scan_reserved_mem+0x30/0x88 [0.00] MEMBLOCK configuration: [0.00] memory size = 0xe000 reserved size = 0x70297a [0.00] memory.cnt = 0x1 [0.00] memory[0x0] [0x00-0x00dfff], 0xe000 bytes flags: 0x0 [0.00] reserved.cnt = 0x4 [0.00] reserved[0x0] [0x00-0x0027ff], 0x2800 bytes flags: 0x0 [0.00] reserved[0x1] [0x004000-0x007fff], 0x4000 bytes flags: 0x0 [0.00] reserved[0x2] [0x008280-0x700203], 0x6f7f84 bytes flags: 0x0 [0.00] reserved[0x3] [0xa41168-0xa4535d], 0x41f6 bytes flags: 0x0 [0.00] Memory policy: Data cache writealloc [0.00] memblock_reserve: [0x002f7fe000-0x002f7f] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fd000-0x002f7fdfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcfd8-0x002f7fcfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fb000-0x002f7fbfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fa000-0x002f7fafff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7f9000-0x002f7f9fff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_virt_alloc_try_nid_nopanic: 29360128 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 alloc_node_mem_map.constprop.66+0x6 0/0x90 [0.00] memblock_reserve: [0x002dbf9000-0x002f7f8fff] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 96 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 free_area_init_node+0x2fc/0x3cc [0.00] memblock_reserve: [0x002f7fcf40-0x002f7fcf9f] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 12288 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 zone_wait_table_init+0x80/0xf0 [0.00] memblock_reserve: [0x002dbf6000-0x002dbf8fff] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 356 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 free_area_init_node+0x2fc/0x3cc [0.00] memblock_reserve: [0x002f7fcdc0-0x002f7fcf23] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 49152 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 zone_wait_table_init+0x80/0xf0 [0.00] memblock_reserve: [0x002dbea000-0x002dbf5fff] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid: 28 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 setup_arch+0x4d4/0x8b0 [0.00] memblock_reserve: [0x002f7fcd80-0x002f7fcd9b] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_reserve: [0x002dbdf040-0x002dbe9fff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcfc0-0x002f7fcfd7] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcfa8-0x002f7fcfbf] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcf28-0x002f7fcf3f] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcda4-0x002f7fcdbc] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
Dear Stas Sergeev, On Wed, 11 Mar 2015 21:08:03 +0300, Stas Sergeev wrote: mem=0xc000 seems to work! 0xd000 or 0xe000 do not. OK, so 3Gb instead of 8... but at least it boots! :) What is the value of the register 0xf1020254 ? Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Wed, Mar 11, 2015 at 08:26:53PM +0300, Stas Sergeev wrote: Hello Thomas, thanks for that info! Is there a quick way to test that? I used memmap=0x2000$0xe000 but nothing changed... Use mem=0xe000 instead. memmap= isn't supported on ARM. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
Dear Stas Sergeev, On Wed, 11 Mar 2015 20:56:50 +0300, Stas Sergeev wrote: It doesn't look like it works as intended. Got the crash below. Please note the mappings beyond 0xe000, so I wonder if the option worked as expected? Are you sure you're not confusing virtual addresses and physical addresses? I'm not sure where you see mappings beyond 0xe000, except virtual addresses, which are not relevant here, as we are talking about physical addresses. [6.122188] Unable to handle kernel NULL pointer dereference at virtual address 02d4 [6.130298] pgd = c0004000 [6.133022] [02d4] *pgd= [6.136617] Internal error: Oops: 5 [#1] SMP ARM [6.141244] Modules linked in: [6.144317] CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.0.0-rc2-00137-gb672c98-dirty #2 [6.152600] Hardware name: Marvell Armada 370/XP (Device Tree) [6.158452] Workqueue: events_unbound async_run_entry_fn [6.163786] task: ed426c00 ti: ed452000 task.ti: ed452000 [6.169196] PC is at 0x0 [6.171734] LR is at 0xfafeff5c [6.174883] pc : []lr : [fafeff5c]psr: [6.174883] sp : ffd6d7ff ip : fp : 0200 [6.186388] r10: ed453d90 r9 : 0001 r8 : [6.191624] r7 : ed5857c0 r6 : r5 : ed80c60a r4 : [6.198166] r3 : 76c06305 r2 : c200f010 r1 : r0 : [6.204709] Flags: nzcv IRQs on FIQs on Mode USER_26 ISA ARM Segment kernel [6.212121] Control: 10c5387d Table: 406a DAC: 0015 [6.217880] Process kworker/u8:0 (pid: 6, stack limit = 0xed452220) [6.224183] ---[ end trace 93bf56ab1670c925 ]--- [6.228824] Unable to handle kernel NULL pointer dereference at virtual address 02d4 This looks indeed weird. What I did to work around this problem is to: 1/ Boot in appended DT mode so that the bootloader doesn't mess up with the DTB 2/ Disable CONFIG_ARM_ATAG_DTB_COMPAT so that the kernel doesn't update the /memory/reg DT node with the (bogus) ATAGS passed by the bootloader. Of course, this means you'll have to have a proper /memory/reg value in your DT, and a correct /chosen/bootargs value, since all info passed by the bootloader will essentially be ignored. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 21:11, Thomas Petazzoni пишет: Dear Stas Sergeev, On Wed, 11 Mar 2015 20:56:50 +0300, Stas Sergeev wrote: It doesn't look like it works as intended. Got the crash below. Please note the mappings beyond 0xe000, so I wonder if the option worked as expected? Are you sure you're not confusing virtual addresses and physical addresses? OK, so I changed Russel's printk to the following way: +printk(vmalloc: mapping page %p (0x%08lx000) at 0x%08lx 0x%08zx\n, +page, page_to_pfn(page), addr, __pa(addr)); (added __pa(addr)) and now I hope I am seeing the physical addresses at the last column: [ 19.023836] vmalloc: mapping page ef7f1fa0 (0x000bfc7d000) at 0xf04a3000 0x304a3000 [ 19.031515] vmalloc: mapping page ef7f3360 (0x000bfd1b000) at 0xf04a4000 0x304a4000 [ 19.039221] vmalloc: mapping page ef7f18e0 (0x000bfc47000) at 0xf04a5000 0x304a5000 and they do not exceed mem= option. Not sure though if this was the right thing to do though. :) Anyway, with mem=0xc00 it seems to boot, so many thanks to everyone! I'll check the value of the register 0xf1020254 tomorrow and will post back. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 20:46, Russell King - ARM Linux пишет: On Wed, Mar 11, 2015 at 08:26:53PM +0300, Stas Sergeev wrote: Hello Thomas, thanks for that info! Is there a quick way to test that? I used memmap=0x2000$0xe000 but nothing changed... Use mem=0xe000 instead. memmap= isn't supported on ARM. mem=0xc000 seems to work! 0xd000 or 0xe000 do not. OK, so 3Gb instead of 8... but at least it boots! :) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Wed, Mar 11, 2015 at 09:38:53PM +0300, Stas Sergeev wrote: 11.03.2015 21:11, Thomas Petazzoni пишет: Dear Stas Sergeev, On Wed, 11 Mar 2015 20:56:50 +0300, Stas Sergeev wrote: It doesn't look like it works as intended. Got the crash below. Please note the mappings beyond 0xe000, so I wonder if the option worked as expected? Are you sure you're not confusing virtual addresses and physical addresses? OK, so I changed Russel's printk to the following way: +printk(vmalloc: mapping page %p (0x%08lx000) at 0x%08lx 0x%08zx\n, +page, page_to_pfn(page), addr, __pa(addr)); (added __pa(addr)) and now I hope I am seeing the physical addresses at the last column: No, you don't want to do that... [ 19.023836] vmalloc: mapping page ef7f1fa0 (0x000bfc7d000) at | `- physical address `-struct page address 0xf04a3000 0x304a3000 `- virtual address __pa() doesn't work on addresses in the vmalloc region. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 15:44, Gregory CLEMENT пишет: Hi Stas, On 10/03/2015 17:54, Stas Sergeev wrote: Hello, the patch below is needed for a successful boot on armada-xp. I am really surprised by this patch because I used the Armada XP based board in a daily base and I never saw this issue. Could you provide your .config? Also could you confirm that you use the dts from arch/arm/boot/dts wihtout any change? With defconfig, and dts without a slightest change this is still reproduceable (the logs I was posting to this thread were done with _slightly_ modified config, and unmodified DT). But... the board itself is modified. It is not a pure armada-xp-gp. I still doubt that this crash is because of the board's mods, for example please find the same crash here: http://lists.linaro.org/pipermail/kernel-build-reports/2014-June/003872.html --- Console logs for failures = arm-mvebu_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y -- armada-xp-openblocks-ax3-4: FAIL: last 40 lines of boot log: 3fe0: 0013 55048012 02109471 [c0186b78] (_set_bit) from [c01c9ba8] (n_tty_set_termios+0x234/0x348) [c01c9ba8] (n_tty_set_termios) from [c01c9da8] (n_tty_open+0xec/0x114) --- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Wed, Mar 11, 2015 at 03:30:33PM +0300, Stas Sergeev wrote: OK, here we go. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #60 SMP5 [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Marvell Armada XP Development Board DB-MV784MP-GP [0.00] Ignoring memory block 0x1 - 0x2 ... [0.00] MEMBLOCK configuration: [0.00] memory size = 0xf000 reserved size = 0xa32442 [0.00] memory.cnt = 0x1 [0.00] memory[0x0] [0x00-0x00efff], 0xf000 bytes flags: 0x0 So this says you have memory covering that entire range, and actually beyond to 8GB. [6.772534] vmalloc: mapping page ef7f13c0 (0x000efc1e000) at 0xf00ca000 [6.772537] vmalloc: mapping page ef7f13a0 (0x000efc1d000) at 0xf00cb000 [6.772540] vmalloc: mapping page ef7f1380 (0x000efc1c000) at 0xf00cc000 [6.772542] vmalloc: mapping page ef7f1360 (0x000efc1b000) at 0xf00cd000 [6.772544] vmalloc: mapping page ef7f1340 (0x000efc1a000) at 0xf00ce000 [6.772546] vmalloc: mapping page ef7f1320 (0x000efc19000) at 0xf00cf000 [6.772548] vmalloc: mapping page ef7f1300 (0x000efc18000) at 0xf00d [6.772551] vmalloc: mapping page ef7f12e0 (0x000efc17000) at 0xf00d1000 [6.822102] ata2: SATA link down (SStatus 0 SControl F300) [6.850381] vmalloc: mapping page ef7f0420 (0x000efba1000) at 0xf00d3000 Here, we set up the mapping, which looks fine - it's apparently in the range of physical addresses we expect for system memory. [6.857113] vmalloc: mapping page ef7f12c0 (0x000efc16000) at 0xf00d4000 [6.863845] vmalloc: mapping page ef7f12a0 (0x000efc15000) at 0xf00d5000 [6.870567] Unhandled fault: external abort on non-linefetch (0x808) at 0xf00d3018 Yet it causes this. I wonder if there's a conflict between DRAM and some other devices causing this, or maybe a stale TLB entry. The thing which makes me consider a stale TLB entry is that the mapping we're adding is for a WBWA cacheable mapping, which should cause line fetches. The abort which is being raised is for a non-linefetch, a type of access which a WBWA cacheable mapping should never create. We can check whether it's a stale TLB entry - if you add a call to flush_tlb_all() after the call to vmalloc() in n_tty_open(). You may need to include asm/tlbflush.h to make that work - can you try that please. Sorry it's needing soo much back-n-forth between us, I don't have any Armada platforms which approach the size you have there. :( -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Wed, Mar 11, 2015 at 01:44:57PM +0100, Gregory CLEMENT wrote: Hi Stas, On 10/03/2015 17:54, Stas Sergeev wrote: Hello, the patch below is needed for a successful boot on armada-xp. I am really surprised by this patch because I used the Armada XP based board in a daily base and I never saw this issue. Can you provide some details about your board - does it have 8GB of memory, ranging from 0-0xf000, and 4G-8G ? Thanks. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
Russell King - ARM Linux wrote: Let's see whether we can get some debug from vmalloc to work out what's going on - can you also apply the patch below. Also, if you could include details about how much memory your platform has, and where it's located, that would be useful - passing memblock=debug should allow us to see what's going on at the memblock level. Also, the full kernel boot log would be useful to see. OK, here we go. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #60 SMP5 [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Marvell Armada XP Development Board DB-MV784MP-GP [0.00] Ignoring memory block 0x1 - 0x2 [0.00] memblock_reserve: [0x008280-0x700203] flags 0x0 arm_memblock_init+0x20/0x18c [0.00] memblock_reserve: [0x0001100040-0x000142fad3] flags 0x0 arm_memblock_init+0x100/0x18c [0.00] memblock_reserve: [0x004000-0x007fff] flags 0x0 arm_memblock_init+0x124/0x18c [0.00] memblock_reserve: [0x00-0x0027ff] flags 0x0 mvebu_scan_mem+0xa4/0xec [0.00] memblock_reserve: [0x00-0x0027ff] flags 0x0 mvebu_scan_mem+0xa4/0xec [0.00] memblock_reserve: [0xa41970-0xa45b99] flags 0x0 early_init_fdt_scan_reserved_mem+0x30/0x88 [0.00] MEMBLOCK configuration: [0.00] memory size = 0xf000 reserved size = 0xa32442 [0.00] memory.cnt = 0x1 [0.00] memory[0x0] [0x00-0x00efff], 0xf000 bytes flags: 0x0 [0.00] reserved.cnt = 0x5 [0.00] reserved[0x0] [0x00-0x0027ff], 0x2800 bytes flags: 0x0 [0.00] reserved[0x1] [0x004000-0x007fff], 0x4000 bytes flags: 0x0 [0.00] reserved[0x2] [0x008280-0x700203], 0x6f7f84 bytes flags: 0x0 [0.00] reserved[0x3] [0xa41970-0xa45b99], 0x422a bytes flags: 0x0 [0.00] reserved[0x4] [0x0001100040-0x000142fad3], 0x32fa94 bytes flags: 0x0 [0.00] Memory policy: Data cache writealloc [0.00] memblock_reserve: [0x002f7fe000-0x002f7f] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fd000-0x002f7fdfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcfd8-0x002f7fcfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fb000-0x002f7fbfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fa000-0x002f7fafff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7f9000-0x002f7f9fff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_virt_alloc_try_nid_nopanic: 31457280 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 alloc_node_mem_map.constprop.66+0x0 [0.00] memblock_reserve: [0x002d9f9000-0x002f7f8fff] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 96 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 free_area_init_node+0x2fc/0x3cc [0.00] memblock_reserve: [0x002f7fcf40-0x002f7fcf9f] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 12288 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 zone_wait_table_init+0x80/0xf0 [0.00] memblock_reserve: [0x002d9f6000-0x002d9f8fff] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 388 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 free_area_init_node+0x2fc/0x3cc [0.00] memblock_reserve: [0x002f7fcd80-0x002f7fcf03] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 49152 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 zone_wait_table_init+0x80/0xf0 [0.00] memblock_reserve: [0x002d9ea000-0x002d9f5fff] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid: 28 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 setup_arch+0x4d4/0x8b0 [0.00] memblock_reserve: [0x002f7fcd40-0x002f7fcd5b] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_reserve: [0x002d9defd8-0x002d9e9fff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcfc0-0x002f7fcfd7] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcfa8-0x002f7fcfbf] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcf28-0x002f7fcf3f] flags 0x0
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
Hi Stas, On 10/03/2015 17:54, Stas Sergeev wrote: Hello, the patch below is needed for a successful boot on armada-xp. I am really surprised by this patch because I used the Armada XP based board in a daily base and I never saw this issue. Could you provide your .config? Also could you confirm that you use the dts from arch/arm/boot/dts wihtout any change? Thanks, Gregory -=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=- This fixes the following crash at boot: Unhandled fault: external abort on non-linefetch (0x808) at 0xf00ca018 Internal error: : 808 [#1] SMP ARM CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc1 #3 Hardware name: Marvell Armada 370/XP (Device Tree) task: ed41e800 ti: ed43e000 task.ti: ed43e000 PC is at _set_bit+0x28/0x50 LR is at n_tty_set_termios+0x328/0x358 pc : [c01bc858]lr : [c0207314]psr: 4113 sp : ed43fd00 ip : fp : r10: 0002 r9 : r8 : ec930200 r7 : r6 : f00ca018 r5 : f00ca000 r4 : ed69cc00 r3 : 2000 r2 : 2000 r1 : f00ca018 r0 : Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 406a DAC: 0015 Process swapper/0 (pid: 1, stack limit = 0xed43e220) The offending instruction in _set_bit() is strex r0, r2, [r1] For some reason the exclusive access instructions do not like the vmalloc() space... While there may be another fix to make them fine about vmalloc() space, it still looks like a good idea to use kmalloc() for allocating a small (sub-page) struct. Signed-off-by: Stas Sergeev s...@users.sourceforge.net --- drivers/tty/n_tty.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c index cf6e0f2..e03622e 100644 --- a/drivers/tty/n_tty.c +++ b/drivers/tty/n_tty.c @@ -50,7 +50,6 @@ #include linux/uaccess.h #include linux/module.h #include linux/ratelimit.h -#include linux/vmalloc.h /* number of characters left in xmit buffer before select has we have room */ @@ -1892,7 +1891,7 @@ static void n_tty_close(struct tty_struct *tty) if (tty-link) n_tty_packet_mode_flush(tty); -vfree(ldata); +kfree(ldata); tty-disc_data = NULL; } @@ -1911,7 +1910,7 @@ static int n_tty_open(struct tty_struct *tty) struct n_tty_data *ldata; /* Currently a malloc failure here can panic */ -ldata = vmalloc(sizeof(*ldata)); +ldata = kmalloc(sizeof(*ldata), GFP_KERNEL); if (!ldata) goto err; -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 16:14, Russell King - ARM Linux пишет: On Wed, Mar 11, 2015 at 01:44:57PM +0100, Gregory CLEMENT wrote: Hi Stas, On 10/03/2015 17:54, Stas Sergeev wrote: Hello, the patch below is needed for a successful boot on armada-xp. I am really surprised by this patch because I used the Armada XP based board in a daily base and I never saw this issue. Can you provide some details about your board - does it have 8GB of memory, ranging from 0-0xf000, and 4G-8G ? Yes, there should be 8G, here's the boot log from marvell kernel that boots fine and works fine: [0.00] Booting Linux on physical CPU 0 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.2.58-1-armadaxp (root@host-010-100) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #0 SMP Thu Dec 18 124 [0.00] CPU: Marvell - PJ4Bv7 Processor [562f5842] revision 2 (ARMv7), cr=30c73c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine: Marvell Armada XP GP Board [0.00] Using UBoot passing parameters structure [0.00] bootconsole [earlycon0] enabled [0.00] Reserving training memory: base=0x (null) size=0x2800 [0.00] Reserving training memory: base=0x8000 size=0x2800 [0.00] Reserving training memory: base=0xc000 size=0x2800 [0.00] Reserving training memory: base=0xe000 size=0x2800 [0.00] MEMBLOCK configuration: [0.00] memory size = 0x1f000 [0.00] memory.cnt = 0x2 [0.00] memory[0x0] [0x00-0x00efff], 0xf000 bytes [0.00] memory[0x1] [0x01-0x01], 0x1 bytes [0.00] reserved.cnt = 0x7 [0.00] reserved[0x0] [0x00-0x0027ff], 0x2800 bytes [0.00] reserved[0x1] [0x003000-0x007fff], 0x5000 bytes [0.00] reserved[0x2] [0x0081e0-0x9ef02f], 0x9e6e50 bytes [0.00] reserved[0x3] [0x0001100040-0x000142fad3], 0x32fa94 bytes [0.00] reserved[0x4] [0x008000-0x00800027ff], 0x2800 bytes [0.00] reserved[0x5] [0x00c000-0x00c00027ff], 0x2800 bytes [0.00] reserved[0x6] [0x00e000-0x00e00027ff], 0x2800 bytes [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] SMP: init cpus [0.00] PERCPU: Embedded 7 pages/cpu @c5442000 s7104 r8192 d13376 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 2015232 [0.00] Kernel command line: console=ttyS0,115200 earlyprintk=ttyS0 root=/dev/sda2 rw pm_disable memblock=debug [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] allocated 33554432 bytes of page_cgroup [0.00] please try 'cgroup_disable=memory' option if you don't want memory cgroups [0.00] Memory: 3840MB 4096MB = 7936MB total [0.00] Memory: 8015704k/8015704k available, 110760k reserved, 7299036K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xf300 - 0xfa80 ( 120 MB) [0.00] lowmem : 0xc000 - 0xf280 ( 808 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc08b4000 (8880 kB) [0.00] .init : 0xc08b4000 - 0xc08fabc0 ( 283 kB) [0.00] .data : 0xc08fc000 - 0xc0948a20 ( 307 kB) [0.00].bss : 0xc0948a44 - 0xc09ef030 ( 666 kB) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:211 [0.00] Initializing ArmadaXP SOC Timer 0 [0.00] sched_clock: 32 bits at 25MHz, resolution 40ns, wraps every 171798ms [ 117.562527] Calibrating delay loop... 1594.16 BogoMIPS (lpj=7970816) [ 117.655298] pid_max: default: 32768 minimum: 301 [ 117.660091] Security Framework initialized [ 117.664285] AppArmor: AppArmor initialized [ 117.668578] Mount-cache hash table entries: 512 [ 117.673594] Initializing cgroup subsys cpuacct [ 117.678123] Initializing cgroup subsys memory [ 117.682584] Initializing cgroup subsys devices [ 117.687093] Initializing cgroup subsys freezer [ 117.691601] Initializing cgroup subsys net_cls [ 117.696117] Initializing cgroup subsys blkio [ 117.700528] CPU: Testing write buffer coherency: ok [ 117.705627] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [ 117.711350] SMP: prepare CPUs (4 cores) [ 117.715539] Setting Clocks for secondary CPUs [ 117.720891] SMP: CPU 0 Waking up CPU 1 [ 117.732639]
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
11.03.2015 15:47, Russell King - ARM Linux пишет: [6.857113] vmalloc: mapping page ef7f12c0 (0x000efc16000) at 0xf00d4000 [6.863845] vmalloc: mapping page ef7f12a0 (0x000efc15000) at 0xf00d5000 [6.870567] Unhandled fault: external abort on non-linefetch (0x808) at 0xf00d3018 Yet it causes this. I wonder if there's a conflict between DRAM and some other devices causing this, or maybe a stale TLB entry. The thing which makes me consider a stale TLB entry is that the mapping we're adding is for a WBWA cacheable mapping, which should cause line fetches. The abort which is being raised is for a non-linefetch, a type of access which a WBWA cacheable mapping should never create. We can check whether it's a stale TLB entry - if you add a call to flush_tlb_all() after the call to vmalloc() in n_tty_open(). You may need to include asm/tlbflush.h to make that work - can you try that please. Seems to be the same: --- [6.872592] vmalloc: mapping page ef7f0800 (0x000efbc) at 0xf00d3000 [6.879309] vmalloc: mapping page ef7f0820 (0x000efbc1000) at 0xf00d4000 [6.886040] vmalloc: mapping page ef7f0840 (0x000efbc2000) at 0xf00d5000 [6.892762] flush_tlb_all() called here [6.896611] Unhandled fault: external abort on non-linefetch (0x808) at 0xf00d3018 [6.903717] sda: sda1 sda2 sda3 [6.907429] pgd = c0004000 [6.910141] [f00d3018] *pgd=2d404811, *pte=efbc065f, *ppte=efbc045f [6.916461] Internal error: : 808 [#1] SMP ARM --- However, while testing, I've suddenly got another crash happened a bit earlier than the previous one used to happen: (OOM? How??) --- [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.0.0-rc2-00137-gb672c98-dirty (root@host-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #2 SMP 5 [0.00] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Marvell Armada XP Development Board DB-MV784MP-GP [0.00] Ignoring memory block 0x1 - 0x2 [0.00] memblock_reserve: [0x008280-0x700203] flags 0x0 arm_memblock_init+0x20/0x18c [0.00] memblock_reserve: [0x0001100040-0x000142fad3] flags 0x0 arm_memblock_init+0x100/0x18c [0.00] memblock_reserve: [0x004000-0x007fff] flags 0x0 arm_memblock_init+0x124/0x18c [0.00] memblock_reserve: [0x00-0x0027ff] flags 0x0 mvebu_scan_mem+0xa4/0xec [0.00] memblock_reserve: [0x00-0x0027ff] flags 0x0 mvebu_scan_mem+0xa4/0xec [0.00] memblock_reserve: [0xa41168-0xa45391] flags 0x0 early_init_fdt_scan_reserved_mem+0x30/0x88 [0.00] MEMBLOCK configuration: [0.00] memory size = 0xf000 reserved size = 0xa32442 [0.00] memory.cnt = 0x1 [0.00] memory[0x0] [0x00-0x00efff], 0xf000 bytes flags: 0x0 [0.00] reserved.cnt = 0x5 [0.00] reserved[0x0] [0x00-0x0027ff], 0x2800 bytes flags: 0x0 [0.00] reserved[0x1] [0x004000-0x007fff], 0x4000 bytes flags: 0x0 [0.00] reserved[0x2] [0x008280-0x700203], 0x6f7f84 bytes flags: 0x0 [0.00] reserved[0x3] [0xa41168-0xa45391], 0x422a bytes flags: 0x0 [0.00] reserved[0x4] [0x0001100040-0x000142fad3], 0x32fa94 bytes flags: 0x0 [0.00] Memory policy: Data cache writealloc [0.00] memblock_reserve: [0x002f7fe000-0x002f7f] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fd000-0x002f7fdfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fcfd8-0x002f7fcfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fb000-0x002f7fbfff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7fa000-0x002f7fafff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_reserve: [0x002f7f9000-0x002f7f9fff] flags 0x0 memblock_alloc_range_nid+0x30/0x44 [0.00] memblock_virt_alloc_try_nid_nopanic: 31457280 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 alloc_node_mem_map.constprop.66+0x0 [0.00] memblock_reserve: [0x002d9f9000-0x002f7f8fff] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 96 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 free_area_init_node+0x2fc/0x3cc [0.00] memblock_reserve: [0x002f7fcf40-0x002f7fcf9f] flags 0x0 memblock_virt_alloc_internal+0x104/0x154 [0.00] memblock_virt_alloc_try_nid_nopanic: 12288 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 zone_wait_table_init+0x80/0xf0 [0.00] memblock_reserve: [0x002d9f6000-0x002d9f8fff] flags 0x0
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Tue, Mar 10, 2015 at 09:31:01PM +0300, Stas Sergeev wrote:
> 10.03.2015 20:38, Russell King - ARM Linux пишет:
> > On Tue, Mar 10, 2015 at 08:27:34PM +0300, Stas Sergeev wrote:
> >> Please also find the same crash here:
> >> http://lists.linaro.org/pipermail/kernel-build-reports/2014-June/003872.html
> > Hmm, looks like from the exynos5420-arndale-octa failure in that, we
> > don't dump the page table entries. We should do. Sorry about my
> > previous mail.
> >
> > If you can reproduce this, please do so with this patch so that we
> > can get the page table entries associated with the problem. Thanks.
> >
> > arch/arm/mm/fault.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> > index a982dc3190df..6333d9c17875 100644
> > --- a/arch/arm/mm/fault.c
> > +++ b/arch/arm/mm/fault.c
> > @@ -552,6 +552,7 @@ do_DataAbort(unsigned long addr, unsigned int fsr,
> > struct pt_regs *regs)
> >
> > pr_alert("Unhandled fault: %s (0x%03x) at 0x%08lx\n",
> > inf->name, fsr, addr);
> > + show_pte(current->mm, addr);
> >
> > info.si_signo = inf->sig;
> > info.si_errno = 0;
> >
> >
Thanks.
> [5.383283] Unhandled fault: external abort on non-linefetch (0x808)
> at 0xf00d3018
> [5.390871] pgd = c0004000
> [5.393583] [f00d3018] *pgd=2d404811, *pte=efc1e65f, *ppte=efc1e45f
This is interesting.
So, the L1 page table entry is:
PMD_TYPE_TABLE
PMD_BIT4
PMD_DOMAIN(0)
Pointing at physical address 0x2f404800
L2 page table entry:
PTE_EXT_XN
PTE_BUFFERABLE
PTE_CACHEABLE
PTE_EXT_AP_UNO_SRW
PTE_EXT_TEX(1)
PTE_EXT_SHARED
Physical address 0xefc1e000
That corresponds with L_PTE_MT_WRITEALLOC, so that's a memory type mapping
with cacheable, write-back, write-allocate attributes.
The thing which has me wondering though is the difference in physical
addresses - that looks /very/ wrong - unless you have close to 4GB of
memory.
Let's see whether we can get some debug from vmalloc to work out what's
going on - can you also apply the patch below.
Also, if you could include details about how much memory your platform
has, and where it's located, that would be useful - passing memblock=debug
should allow us to see what's going on at the memblock level.
Also, the full kernel boot log would be useful to see.
Thanks.
(Patch isn't tested.)
mm/vmalloc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 35b25e1340ca..3379bcd6d280 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -129,6 +129,8 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr,
return -EBUSY;
if (WARN_ON(!page))
return -ENOMEM;
+printk("vmalloc: mapping page %p (0x%08lx000) at 0x%08lx\n",
+ page, page_to_pfn(page), addr);
set_pte_at(_mm, addr, pte, mk_pte(page, prot));
(*nr)++;
} while (pte++, addr += PAGE_SIZE, addr != end);
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On 03/10/2015 01:51 PM, Stas Sergeev wrote: > 10.03.2015 20:35, Peter Hurley пишет: >> On 03/10/2015 12:54 PM, Stas Sergeev wrote: >>> Hello, the patch below is needed for a successful boot on armada-xp. >>> >>> >>> -=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=- >>> This fixes the following crash at boot: >>> >>> Unhandled fault: external abort on non-linefetch (0x808) at 0xf00ca018 >>> Internal error: : 808 [#1] SMP ARM >>> >>> CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc1 #3 >>> Hardware name: Marvell Armada 370/XP (Device Tree) >>> task: ed41e800 ti: ed43e000 task.ti: ed43e000 >>> PC is at _set_bit+0x28/0x50 >>> LR is at n_tty_set_termios+0x328/0x358 >>> pc : []lr : []psr: 4113 >>> sp : ed43fd00 ip : fp : >>> r10: 0002 r9 : r8 : ec930200 >>> r7 : r6 : f00ca018 r5 : f00ca000 r4 : ed69cc00 >>> r3 : 2000 r2 : 2000 r1 : f00ca018 r0 : >>> Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel >>> Control: 10c5387d Table: 406a DAC: 0015 >>> Process swapper/0 (pid: 1, stack limit = 0xed43e220) >>> >>> The offending instruction in _set_bit() is "strex r0, r2, [r1]" >>> For some reason the exclusive access instructions do not like the >>> vmalloc() space... While there may be another fix to make them >>> fine about vmalloc() space, it still looks like a good idea to >>> use kmalloc() for allocating a small (sub-page) struct. >> NAK. >> >> struct n_tty_data is order 2, not sub-page. > OK, you are right, sorry. 8844 bytes. > Is this really a target for vmalloc() though? I thought kmalloc() > is preferable even for that size. It doubles as a selftest for arch page table setup :) I considered only using vmalloc() as a fallback, but problems like this make me *less* interested in doing that. At least this way the problem is unambiguous. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
10.03.2015 20:38, Russell King - ARM Linux пишет:
> On Tue, Mar 10, 2015 at 08:27:34PM +0300, Stas Sergeev wrote:
>> Please also find the same crash here:
>> http://lists.linaro.org/pipermail/kernel-build-reports/2014-June/003872.html
> Hmm, looks like from the exynos5420-arndale-octa failure in that, we
> don't dump the page table entries. We should do. Sorry about my
> previous mail.
>
> If you can reproduce this, please do so with this patch so that we
> can get the page table entries associated with the problem. Thanks.
>
> arch/arm/mm/fault.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> index a982dc3190df..6333d9c17875 100644
> --- a/arch/arm/mm/fault.c
> +++ b/arch/arm/mm/fault.c
> @@ -552,6 +552,7 @@ do_DataAbort(unsigned long addr, unsigned int fsr, struct
> pt_regs *regs)
>
> pr_alert("Unhandled fault: %s (0x%03x) at 0x%08lx\n",
> inf->name, fsr, addr);
> + show_pte(current->mm, addr);
>
> info.si_signo = inf->sig;
> info.si_errno = 0;
>
>
[5.383283] Unhandled fault: external abort on non-linefetch (0x808)
at 0xf00d3018
[5.390871] pgd = c0004000
[5.393583] [f00d3018] *pgd=2d404811, *pte=efc1e65f, *ppte=efc1e45f
[5.399901] Internal error: : 808 [#1] SMP ARM
[5.404354] Modules linked in:
[5.407427] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.0.0-rc2-00137-gb672c98-dirty #59
[5.415536] Hardware name: Marvell Armada 370/XP (Device Tree)
[5.421383] task: ed41e800 ti: ed43e000 task.ti: ed43e000
[5.426798] PC is at _set_bit+0x28/0x50
[5.430643] LR is at n_tty_set_termios+0x328/0x358
[5.435446] pc : []lr : []psr: 4113
[5.435446] sp : ed43fd00 ip : fp :
[5.446950] r10: 0002 r9 : r8 : ec975c00
[5.452186] r7 : r6 : f00d3018 r5 : f00d3000 r4 : ecd86200
[5.458728] r3 : 2000 r2 : 2000 r1 : f00d3018 r0 :
[5.465271] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment kernel
[5.472597] Control: 10c5387d Table: 406a DAC: 0015
[5.478355] Process swapper/0 (pid: 1, stack limit = 0xed43e220)
[5.484376] Stack: (0xed43fd00 to 0xed44)
[5.488745] fd00: f00d3000 ecd86200 f00d5240 ec975c00
c0207448 c02073a4 ecd86200
[5.496943] fd20: ecd8635c ec990dc0 c020b37c ecd86200
ec990dc0 ecd86200 c020bb40
[5.505142] fd40: ed6dd400 ecd86200 ec975c00
c0205a28 ed022000 0002
[5.513341] fd60: 0449 ecc89100 0001 0051 ed024590
c0205ff8 c00b81e4 ec975c00
[5.521540] fd80: ed409c00 c06f0678 c04ee370 ed024590
ecc89100 c06f37cc
[5.529739] fda0: ed022000 c06f37cc c00b89dc ed43fe7c
ed43fe38 ecc89100
[5.537938] fdc0: ed024590 ecc89108 c00b891c ed43fe7c
c00b2f40 ed43fec0
[5.546137] fde0: ed43ff44 0002 ed43fe7c
c00c0d88 ed679019 00766564
[5.554336] fe00: 0003 c00bea44 ecc89100 0026
0002
[5.562535] fe20: c004fa98 ed403f50
ed024590 ed0246d0
[5.570734] fe40: 0041 ecc89100 ed43fec0 ed43ff44 ed43fe7c
0041
[5.578932] fe60: c00c1850 ed43fe8c
817b7a1a ed403f50
[5.587131] fe80: ed022110 001a 0013 0007
ed43ff44 0001 ed679000
[5.595330] fea0: ff9c c0655588 c068f470 00ab
c00c2780 0041
[5.603529] fec0: ed403f50 ed022110 0f4756ea 0007 ed679019
ed0027f8
[5.611727] fee0: ed024590 0101 0004 001e
0002
[5.619925] ff00: ed679000 0fec 0fec 0001 0002
0002 ed679000 ff9c
[5.628124] ff20: c06d0740 ed679000 ff9c c06d0740
c00b4050
[5.636322] ff40: c05a7630 0002 0026 0100
0001 00ab c06868a4
[5.644521] ff60: 0007 c0686884 c06d0740 c0655588 00ab
c0655d68 0007 0007
[5.652720] ff80: c0655588 beefdead c04c6850
[5.660918] ffa0: c04c6858 c000e540
[5.669117] ffc0:
[5.677315] ffe0: 0013
beefdead beefdead
[5.685519] [] (_set_bit) from []
(n_tty_set_termios+0x328/0x358)
[5.693371] [] (n_tty_set_termios) from []
(n_tty_open+0xa4/0xcc)
[5.701223] [] (n_tty_open) from []
(tty_ldisc_open+0x40/0x78)
[5.708812] [] (tty_ldisc_open) from []
(tty_ldisc_setup+0x18/0x58)
[5.716838] [] (tty_ldisc_setup) from []
(tty_init_dev+0x8c/0x17c)
[5.724775] [] (tty_init_dev) from []
(tty_open+0x4e0/0x5f4)
[5.732191] [] (tty_open) from []
(chrdev_open+0xc0/0x17c)
[5.739436] [] (chrdev_open) from []
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
10.03.2015 20:35, Peter Hurley пишет: > On 03/10/2015 12:54 PM, Stas Sergeev wrote: >> Hello, the patch below is needed for a successful boot on armada-xp. >> >> >> -=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=- >> This fixes the following crash at boot: >> >> Unhandled fault: external abort on non-linefetch (0x808) at 0xf00ca018 >> Internal error: : 808 [#1] SMP ARM >> >> CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc1 #3 >> Hardware name: Marvell Armada 370/XP (Device Tree) >> task: ed41e800 ti: ed43e000 task.ti: ed43e000 >> PC is at _set_bit+0x28/0x50 >> LR is at n_tty_set_termios+0x328/0x358 >> pc : []lr : []psr: 4113 >> sp : ed43fd00 ip : fp : >> r10: 0002 r9 : r8 : ec930200 >> r7 : r6 : f00ca018 r5 : f00ca000 r4 : ed69cc00 >> r3 : 2000 r2 : 2000 r1 : f00ca018 r0 : >> Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel >> Control: 10c5387d Table: 406a DAC: 0015 >> Process swapper/0 (pid: 1, stack limit = 0xed43e220) >> >> The offending instruction in _set_bit() is "strex r0, r2, [r1]" >> For some reason the exclusive access instructions do not like the >> vmalloc() space... While there may be another fix to make them >> fine about vmalloc() space, it still looks like a good idea to >> use kmalloc() for allocating a small (sub-page) struct. > NAK. > > struct n_tty_data is order 2, not sub-page. OK, you are right, sorry. 8844 bytes. Is this really a target for vmalloc() though? I thought kmalloc() is preferable even for that size. > The abort means something else is wrong; that's what needs > tracking down and fixing. Yeah, I even mentioned that in a commit log. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
Hello, the patch below is needed for a successful boot on armada-xp. -=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=- This fixes the following crash at boot: Unhandled fault: external abort on non-linefetch (0x808) at 0xf00ca018 Internal error: : 808 [#1] SMP ARM CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc1 #3 Hardware name: Marvell Armada 370/XP (Device Tree) task: ed41e800 ti: ed43e000 task.ti: ed43e000 PC is at _set_bit+0x28/0x50 LR is at n_tty_set_termios+0x328/0x358 pc : []lr : []psr: 4113 sp : ed43fd00 ip : fp : r10: 0002 r9 : r8 : ec930200 r7 : r6 : f00ca018 r5 : f00ca000 r4 : ed69cc00 r3 : 2000 r2 : 2000 r1 : f00ca018 r0 : Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 406a DAC: 0015 Process swapper/0 (pid: 1, stack limit = 0xed43e220) The offending instruction in _set_bit() is "strex r0, r2, [r1]" For some reason the exclusive access instructions do not like the vmalloc() space... While there may be another fix to make them fine about vmalloc() space, it still looks like a good idea to use kmalloc() for allocating a small (sub-page) struct. Signed-off-by: Stas Sergeev --- drivers/tty/n_tty.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c index cf6e0f2..e03622e 100644 --- a/drivers/tty/n_tty.c +++ b/drivers/tty/n_tty.c @@ -50,7 +50,6 @@ #include #include #include -#include /* number of characters left in xmit buffer before select has we have room */ @@ -1892,7 +1891,7 @@ static void n_tty_close(struct tty_struct *tty) if (tty->link) n_tty_packet_mode_flush(tty); -vfree(ldata); +kfree(ldata); tty->disc_data = NULL; } @@ -1911,7 +1910,7 @@ static int n_tty_open(struct tty_struct *tty) struct n_tty_data *ldata; /* Currently a malloc failure here can panic */ -ldata = vmalloc(sizeof(*ldata)); +ldata = kmalloc(sizeof(*ldata), GFP_KERNEL); if (!ldata) goto err; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Tue, Mar 10, 2015 at 08:27:34PM +0300, Stas Sergeev wrote:
> Please also find the same crash here:
> http://lists.linaro.org/pipermail/kernel-build-reports/2014-June/003872.html
Hmm, looks like from the exynos5420-arndale-octa failure in that, we
don't dump the page table entries. We should do. Sorry about my
previous mail.
If you can reproduce this, please do so with this patch so that we
can get the page table entries associated with the problem. Thanks.
arch/arm/mm/fault.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index a982dc3190df..6333d9c17875 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -552,6 +552,7 @@ do_DataAbort(unsigned long addr, unsigned int fsr, struct
pt_regs *regs)
pr_alert("Unhandled fault: %s (0x%03x) at 0x%08lx\n",
inf->name, fsr, addr);
+ show_pte(current->mm, addr);
info.si_signo = inf->sig;
info.si_errno = 0;
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On 03/10/2015 12:54 PM, Stas Sergeev wrote: > Hello, the patch below is needed for a successful boot on armada-xp. > > > -=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=- > This fixes the following crash at boot: > > Unhandled fault: external abort on non-linefetch (0x808) at 0xf00ca018 > Internal error: : 808 [#1] SMP ARM > > CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc1 #3 > Hardware name: Marvell Armada 370/XP (Device Tree) > task: ed41e800 ti: ed43e000 task.ti: ed43e000 > PC is at _set_bit+0x28/0x50 > LR is at n_tty_set_termios+0x328/0x358 > pc : []lr : []psr: 4113 > sp : ed43fd00 ip : fp : > r10: 0002 r9 : r8 : ec930200 > r7 : r6 : f00ca018 r5 : f00ca000 r4 : ed69cc00 > r3 : 2000 r2 : 2000 r1 : f00ca018 r0 : > Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel > Control: 10c5387d Table: 406a DAC: 0015 > Process swapper/0 (pid: 1, stack limit = 0xed43e220) > > The offending instruction in _set_bit() is "strex r0, r2, [r1]" > For some reason the exclusive access instructions do not like the > vmalloc() space... While there may be another fix to make them > fine about vmalloc() space, it still looks like a good idea to > use kmalloc() for allocating a small (sub-page) struct. NAK. struct n_tty_data is order 2, not sub-page. The abort means something else is wrong; that's what needs tracking down and fixing. AFAIK this is not happening on any other ARM platform. Regards, Peter Hurley > Signed-off-by: Stas Sergeev > --- > drivers/tty/n_tty.c |5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c > index cf6e0f2..e03622e 100644 > --- a/drivers/tty/n_tty.c > +++ b/drivers/tty/n_tty.c > @@ -50,7 +50,6 @@ > #include > #include > #include > -#include > > > /* number of characters left in xmit buffer before select has we have > room */ > @@ -1892,7 +1891,7 @@ static void n_tty_close(struct tty_struct *tty) > if (tty->link) > n_tty_packet_mode_flush(tty); > > -vfree(ldata); > +kfree(ldata); > tty->disc_data = NULL; > } > > @@ -1911,7 +1910,7 @@ static int n_tty_open(struct tty_struct *tty) > struct n_tty_data *ldata; > > /* Currently a malloc failure here can panic */ > -ldata = vmalloc(sizeof(*ldata)); > +ldata = kmalloc(sizeof(*ldata), GFP_KERNEL); > if (!ldata) > goto err; > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Tue, Mar 10, 2015 at 07:54:22PM +0300, Stas Sergeev wrote: > Hello, the patch below is needed for a successful boot on armada-xp. > > > -=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=- > This fixes the following crash at boot: > > Unhandled fault: external abort on non-linefetch (0x808) at 0xf00ca018 > Internal error: : 808 [#1] SMP ARM > > CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc1 #3 > Hardware name: Marvell Armada 370/XP (Device Tree) > task: ed41e800 ti: ed43e000 task.ti: ed43e000 Oh ffs, stop trimming down the dumps. Knowing what the page table entries were would have been useful to see whether this is an appropriate fix. We dump information from the kernel for a reason. That reason is not so people can cut random bits that they don't think is relevant from it. NAK until we see the full dump. Thanks. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
10.03.2015 20:17, Catalin Marinas пишет: > On Tue, Mar 10, 2015 at 07:54:22PM +0300, Stas Sergeev wrote: >> Hello, the patch below is needed for a successful boot on armada-xp. >> >> -=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=- >> This fixes the following crash at boot: >> >> Unhandled fault: external abort on non-linefetch (0x808) at 0xf00ca018 >> Internal error: : 808 [#1] SMP ARM > I think you have some other problems. Likely, but IMHO the patch is still fine, there should be kmalloc() anyway. I'd like to find the roots of the problem, but I think the patch can be applied regardless. > That's an external abort, which > means that the original vmalloc'ed memory was not mapping RAM but some > empty physical address space. > > That's unless strex hits device memory and not having an exclusive > monitor causes such external abort. But vmalloc() memory is Normal > Cacheable. Some pointer could go wrong and it hits ioremap'ed memory > which is in the same range as vmalloc'ed memory. But strex is preceded by ldrex, which succeeds. I am not arm guru at all, but if we hit empty space or ioremap memory, shouldn't the ldrex also abort? It doesn't. Any hints how can I make a better diagnostic? Please also find the same crash here: http://lists.linaro.org/pipermail/kernel-build-reports/2014-June/003872.html --- Console logs for failures = arm-mvebu_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y -- armada-xp-openblocks-ax3-4: FAIL: last 40 lines of boot log: 3fe0: 0013 55048012 02109471 [] (_set_bit) from [] (n_tty_set_termios+0x234/0x348) [] (n_tty_set_termios) from [] (n_tty_open+0xec/0x114) --- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Tue, Mar 10, 2015 at 07:54:22PM +0300, Stas Sergeev wrote: > Hello, the patch below is needed for a successful boot on armada-xp. > > -=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=- > This fixes the following crash at boot: > > Unhandled fault: external abort on non-linefetch (0x808) at 0xf00ca018 > Internal error: : 808 [#1] SMP ARM I think you have some other problems. That's an external abort, which means that the original vmalloc'ed memory was not mapping RAM but some empty physical address space. That's unless strex hits device memory and not having an exclusive monitor causes such external abort. But vmalloc() memory is Normal Cacheable. Some pointer could go wrong and it hits ioremap'ed memory which is in the same range as vmalloc'ed memory. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Tue, Mar 10, 2015 at 07:54:22PM +0300, Stas Sergeev wrote: Hello, the patch below is needed for a successful boot on armada-xp. -=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=- This fixes the following crash at boot: Unhandled fault: external abort on non-linefetch (0x808) at 0xf00ca018 Internal error: : 808 [#1] SMP ARM CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc1 #3 Hardware name: Marvell Armada 370/XP (Device Tree) task: ed41e800 ti: ed43e000 task.ti: ed43e000 Oh ffs, stop trimming down the dumps. Knowing what the page table entries were would have been useful to see whether this is an appropriate fix. We dump information from the kernel for a reason. That reason is not so people can cut random bits that they don't think is relevant from it. NAK until we see the full dump. Thanks. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
10.03.2015 20:17, Catalin Marinas пишет: On Tue, Mar 10, 2015 at 07:54:22PM +0300, Stas Sergeev wrote: Hello, the patch below is needed for a successful boot on armada-xp. -=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=- This fixes the following crash at boot: Unhandled fault: external abort on non-linefetch (0x808) at 0xf00ca018 Internal error: : 808 [#1] SMP ARM I think you have some other problems. Likely, but IMHO the patch is still fine, there should be kmalloc() anyway. I'd like to find the roots of the problem, but I think the patch can be applied regardless. That's an external abort, which means that the original vmalloc'ed memory was not mapping RAM but some empty physical address space. That's unless strex hits device memory and not having an exclusive monitor causes such external abort. But vmalloc() memory is Normal Cacheable. Some pointer could go wrong and it hits ioremap'ed memory which is in the same range as vmalloc'ed memory. But strex is preceded by ldrex, which succeeds. I am not arm guru at all, but if we hit empty space or ioremap memory, shouldn't the ldrex also abort? It doesn't. Any hints how can I make a better diagnostic? Please also find the same crash here: http://lists.linaro.org/pipermail/kernel-build-reports/2014-June/003872.html --- Console logs for failures = arm-mvebu_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y -- armada-xp-openblocks-ax3-4: FAIL: last 40 lines of boot log: 3fe0: 0013 55048012 02109471 [c0186b78] (_set_bit) from [c01c9ba8] (n_tty_set_termios+0x234/0x348) [c01c9ba8] (n_tty_set_termios) from [c01c9da8] (n_tty_open+0xec/0x114) --- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On 03/10/2015 12:54 PM, Stas Sergeev wrote: Hello, the patch below is needed for a successful boot on armada-xp. -=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=- This fixes the following crash at boot: Unhandled fault: external abort on non-linefetch (0x808) at 0xf00ca018 Internal error: : 808 [#1] SMP ARM CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc1 #3 Hardware name: Marvell Armada 370/XP (Device Tree) task: ed41e800 ti: ed43e000 task.ti: ed43e000 PC is at _set_bit+0x28/0x50 LR is at n_tty_set_termios+0x328/0x358 pc : [c01bc858]lr : [c0207314]psr: 4113 sp : ed43fd00 ip : fp : r10: 0002 r9 : r8 : ec930200 r7 : r6 : f00ca018 r5 : f00ca000 r4 : ed69cc00 r3 : 2000 r2 : 2000 r1 : f00ca018 r0 : Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 406a DAC: 0015 Process swapper/0 (pid: 1, stack limit = 0xed43e220) The offending instruction in _set_bit() is strex r0, r2, [r1] For some reason the exclusive access instructions do not like the vmalloc() space... While there may be another fix to make them fine about vmalloc() space, it still looks like a good idea to use kmalloc() for allocating a small (sub-page) struct. NAK. struct n_tty_data is order 2, not sub-page. The abort means something else is wrong; that's what needs tracking down and fixing. AFAIK this is not happening on any other ARM platform. Regards, Peter Hurley Signed-off-by: Stas Sergeev s...@users.sourceforge.net --- drivers/tty/n_tty.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c index cf6e0f2..e03622e 100644 --- a/drivers/tty/n_tty.c +++ b/drivers/tty/n_tty.c @@ -50,7 +50,6 @@ #include linux/uaccess.h #include linux/module.h #include linux/ratelimit.h -#include linux/vmalloc.h /* number of characters left in xmit buffer before select has we have room */ @@ -1892,7 +1891,7 @@ static void n_tty_close(struct tty_struct *tty) if (tty-link) n_tty_packet_mode_flush(tty); -vfree(ldata); +kfree(ldata); tty-disc_data = NULL; } @@ -1911,7 +1910,7 @@ static int n_tty_open(struct tty_struct *tty) struct n_tty_data *ldata; /* Currently a malloc failure here can panic */ -ldata = vmalloc(sizeof(*ldata)); +ldata = kmalloc(sizeof(*ldata), GFP_KERNEL); if (!ldata) goto err; -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Tue, Mar 10, 2015 at 08:27:34PM +0300, Stas Sergeev wrote: Please also find the same crash here: http://lists.linaro.org/pipermail/kernel-build-reports/2014-June/003872.html Hmm, looks like from the exynos5420-arndale-octa failure in that, we don't dump the page table entries. We should do. Sorry about my previous mail. If you can reproduce this, please do so with this patch so that we can get the page table entries associated with the problem. Thanks. arch/arm/mm/fault.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c index a982dc3190df..6333d9c17875 100644 --- a/arch/arm/mm/fault.c +++ b/arch/arm/mm/fault.c @@ -552,6 +552,7 @@ do_DataAbort(unsigned long addr, unsigned int fsr, struct pt_regs *regs) pr_alert(Unhandled fault: %s (0x%03x) at 0x%08lx\n, inf-name, fsr, addr); + show_pte(current-mm, addr); info.si_signo = inf-sig; info.si_errno = 0; -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
10.03.2015 20:35, Peter Hurley пишет: On 03/10/2015 12:54 PM, Stas Sergeev wrote: Hello, the patch below is needed for a successful boot on armada-xp. -=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=- This fixes the following crash at boot: Unhandled fault: external abort on non-linefetch (0x808) at 0xf00ca018 Internal error: : 808 [#1] SMP ARM CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc1 #3 Hardware name: Marvell Armada 370/XP (Device Tree) task: ed41e800 ti: ed43e000 task.ti: ed43e000 PC is at _set_bit+0x28/0x50 LR is at n_tty_set_termios+0x328/0x358 pc : [c01bc858]lr : [c0207314]psr: 4113 sp : ed43fd00 ip : fp : r10: 0002 r9 : r8 : ec930200 r7 : r6 : f00ca018 r5 : f00ca000 r4 : ed69cc00 r3 : 2000 r2 : 2000 r1 : f00ca018 r0 : Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 406a DAC: 0015 Process swapper/0 (pid: 1, stack limit = 0xed43e220) The offending instruction in _set_bit() is strex r0, r2, [r1] For some reason the exclusive access instructions do not like the vmalloc() space... While there may be another fix to make them fine about vmalloc() space, it still looks like a good idea to use kmalloc() for allocating a small (sub-page) struct. NAK. struct n_tty_data is order 2, not sub-page. OK, you are right, sorry. 8844 bytes. Is this really a target for vmalloc() though? I thought kmalloc() is preferable even for that size. The abort means something else is wrong; that's what needs tracking down and fixing. Yeah, I even mentioned that in a commit log. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Tue, Mar 10, 2015 at 07:54:22PM +0300, Stas Sergeev wrote: Hello, the patch below is needed for a successful boot on armada-xp. -=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=- This fixes the following crash at boot: Unhandled fault: external abort on non-linefetch (0x808) at 0xf00ca018 Internal error: : 808 [#1] SMP ARM I think you have some other problems. That's an external abort, which means that the original vmalloc'ed memory was not mapping RAM but some empty physical address space. That's unless strex hits device memory and not having an exclusive monitor causes such external abort. But vmalloc() memory is Normal Cacheable. Some pointer could go wrong and it hits ioremap'ed memory which is in the same range as vmalloc'ed memory. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
Hello, the patch below is needed for a successful boot on armada-xp. -=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=- This fixes the following crash at boot: Unhandled fault: external abort on non-linefetch (0x808) at 0xf00ca018 Internal error: : 808 [#1] SMP ARM CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc1 #3 Hardware name: Marvell Armada 370/XP (Device Tree) task: ed41e800 ti: ed43e000 task.ti: ed43e000 PC is at _set_bit+0x28/0x50 LR is at n_tty_set_termios+0x328/0x358 pc : [c01bc858]lr : [c0207314]psr: 4113 sp : ed43fd00 ip : fp : r10: 0002 r9 : r8 : ec930200 r7 : r6 : f00ca018 r5 : f00ca000 r4 : ed69cc00 r3 : 2000 r2 : 2000 r1 : f00ca018 r0 : Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 406a DAC: 0015 Process swapper/0 (pid: 1, stack limit = 0xed43e220) The offending instruction in _set_bit() is strex r0, r2, [r1] For some reason the exclusive access instructions do not like the vmalloc() space... While there may be another fix to make them fine about vmalloc() space, it still looks like a good idea to use kmalloc() for allocating a small (sub-page) struct. Signed-off-by: Stas Sergeev s...@users.sourceforge.net --- drivers/tty/n_tty.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c index cf6e0f2..e03622e 100644 --- a/drivers/tty/n_tty.c +++ b/drivers/tty/n_tty.c @@ -50,7 +50,6 @@ #include linux/uaccess.h #include linux/module.h #include linux/ratelimit.h -#include linux/vmalloc.h /* number of characters left in xmit buffer before select has we have room */ @@ -1892,7 +1891,7 @@ static void n_tty_close(struct tty_struct *tty) if (tty-link) n_tty_packet_mode_flush(tty); -vfree(ldata); +kfree(ldata); tty-disc_data = NULL; } @@ -1911,7 +1910,7 @@ static int n_tty_open(struct tty_struct *tty) struct n_tty_data *ldata; /* Currently a malloc failure here can panic */ -ldata = vmalloc(sizeof(*ldata)); +ldata = kmalloc(sizeof(*ldata), GFP_KERNEL); if (!ldata) goto err; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
10.03.2015 20:38, Russell King - ARM Linux пишет: On Tue, Mar 10, 2015 at 08:27:34PM +0300, Stas Sergeev wrote: Please also find the same crash here: http://lists.linaro.org/pipermail/kernel-build-reports/2014-June/003872.html Hmm, looks like from the exynos5420-arndale-octa failure in that, we don't dump the page table entries. We should do. Sorry about my previous mail. If you can reproduce this, please do so with this patch so that we can get the page table entries associated with the problem. Thanks. arch/arm/mm/fault.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c index a982dc3190df..6333d9c17875 100644 --- a/arch/arm/mm/fault.c +++ b/arch/arm/mm/fault.c @@ -552,6 +552,7 @@ do_DataAbort(unsigned long addr, unsigned int fsr, struct pt_regs *regs) pr_alert(Unhandled fault: %s (0x%03x) at 0x%08lx\n, inf-name, fsr, addr); + show_pte(current-mm, addr); info.si_signo = inf-sig; info.si_errno = 0; [5.383283] Unhandled fault: external abort on non-linefetch (0x808) at 0xf00d3018 [5.390871] pgd = c0004000 [5.393583] [f00d3018] *pgd=2d404811, *pte=efc1e65f, *ppte=efc1e45f [5.399901] Internal error: : 808 [#1] SMP ARM [5.404354] Modules linked in: [5.407427] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc2-00137-gb672c98-dirty #59 [5.415536] Hardware name: Marvell Armada 370/XP (Device Tree) [5.421383] task: ed41e800 ti: ed43e000 task.ti: ed43e000 [5.426798] PC is at _set_bit+0x28/0x50 [5.430643] LR is at n_tty_set_termios+0x328/0x358 [5.435446] pc : [c01bc8f8]lr : [c0207374]psr: 4113 [5.435446] sp : ed43fd00 ip : fp : [5.446950] r10: 0002 r9 : r8 : ec975c00 [5.452186] r7 : r6 : f00d3018 r5 : f00d3000 r4 : ecd86200 [5.458728] r3 : 2000 r2 : 2000 r1 : f00d3018 r0 : [5.465271] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [5.472597] Control: 10c5387d Table: 406a DAC: 0015 [5.478355] Process swapper/0 (pid: 1, stack limit = 0xed43e220) [5.484376] Stack: (0xed43fd00 to 0xed44) [5.488745] fd00: f00d3000 ecd86200 f00d5240 ec975c00 c0207448 c02073a4 ecd86200 [5.496943] fd20: ecd8635c ec990dc0 c020b37c ecd86200 ec990dc0 ecd86200 c020bb40 [5.505142] fd40: ed6dd400 ecd86200 ec975c00 c0205a28 ed022000 0002 [5.513341] fd60: 0449 ecc89100 0001 0051 ed024590 c0205ff8 c00b81e4 ec975c00 [5.521540] fd80: ed409c00 c06f0678 c04ee370 ed024590 ecc89100 c06f37cc [5.529739] fda0: ed022000 c06f37cc c00b89dc ed43fe7c ed43fe38 ecc89100 [5.537938] fdc0: ed024590 ecc89108 c00b891c ed43fe7c c00b2f40 ed43fec0 [5.546137] fde0: ed43ff44 0002 ed43fe7c c00c0d88 ed679019 00766564 [5.554336] fe00: 0003 c00bea44 ecc89100 0026 0002 [5.562535] fe20: c004fa98 ed403f50 ed024590 ed0246d0 [5.570734] fe40: 0041 ecc89100 ed43fec0 ed43ff44 ed43fe7c 0041 [5.578932] fe60: c00c1850 ed43fe8c 817b7a1a ed403f50 [5.587131] fe80: ed022110 001a 0013 0007 ed43ff44 0001 ed679000 [5.595330] fea0: ff9c c0655588 c068f470 00ab c00c2780 0041 [5.603529] fec0: ed403f50 ed022110 0f4756ea 0007 ed679019 ed0027f8 [5.611727] fee0: ed024590 0101 0004 001e 0002 [5.619925] ff00: ed679000 0fec 0fec 0001 0002 0002 ed679000 ff9c [5.628124] ff20: c06d0740 ed679000 ff9c c06d0740 c00b4050 [5.636322] ff40: c05a7630 0002 0026 0100 0001 00ab c06868a4 [5.644521] ff60: 0007 c0686884 c06d0740 c0655588 00ab c0655d68 0007 0007 [5.652720] ff80: c0655588 beefdead c04c6850 [5.660918] ffa0: c04c6858 c000e540 [5.669117] ffc0: [5.677315] ffe0: 0013 beefdead beefdead [5.685519] [c01bc8f8] (_set_bit) from [c0207374] (n_tty_set_termios+0x328/0x358) [5.693371] [c0207374] (n_tty_set_termios) from [c0207448] (n_tty_open+0xa4/0xcc) [5.701223] [c0207448] (n_tty_open) from [c020b37c] (tty_ldisc_open+0x40/0x78) [5.708812] [c020b37c] (tty_ldisc_open) from [c020bb40] (tty_ldisc_setup+0x18/0x58) [5.716838] [c020bb40] (tty_ldisc_setup) from [c0205a28] (tty_init_dev+0x8c/0x17c) [5.724775] [c0205a28] (tty_init_dev) from [c0205ff8] (tty_open+0x4e0/0x5f4) [5.732191] [c0205ff8] (tty_open) from
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On 03/10/2015 01:51 PM, Stas Sergeev wrote: 10.03.2015 20:35, Peter Hurley пишет: On 03/10/2015 12:54 PM, Stas Sergeev wrote: Hello, the patch below is needed for a successful boot on armada-xp. -=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=- This fixes the following crash at boot: Unhandled fault: external abort on non-linefetch (0x808) at 0xf00ca018 Internal error: : 808 [#1] SMP ARM CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc1 #3 Hardware name: Marvell Armada 370/XP (Device Tree) task: ed41e800 ti: ed43e000 task.ti: ed43e000 PC is at _set_bit+0x28/0x50 LR is at n_tty_set_termios+0x328/0x358 pc : [c01bc858]lr : [c0207314]psr: 4113 sp : ed43fd00 ip : fp : r10: 0002 r9 : r8 : ec930200 r7 : r6 : f00ca018 r5 : f00ca000 r4 : ed69cc00 r3 : 2000 r2 : 2000 r1 : f00ca018 r0 : Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 406a DAC: 0015 Process swapper/0 (pid: 1, stack limit = 0xed43e220) The offending instruction in _set_bit() is strex r0, r2, [r1] For some reason the exclusive access instructions do not like the vmalloc() space... While there may be another fix to make them fine about vmalloc() space, it still looks like a good idea to use kmalloc() for allocating a small (sub-page) struct. NAK. struct n_tty_data is order 2, not sub-page. OK, you are right, sorry. 8844 bytes. Is this really a target for vmalloc() though? I thought kmalloc() is preferable even for that size. It doubles as a selftest for arch page table setup :) I considered only using vmalloc() as a fallback, but problems like this make me *less* interested in doing that. At least this way the problem is unambiguous. Regards, Peter Hurley -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp
On Tue, Mar 10, 2015 at 09:31:01PM +0300, Stas Sergeev wrote: 10.03.2015 20:38, Russell King - ARM Linux пишет: On Tue, Mar 10, 2015 at 08:27:34PM +0300, Stas Sergeev wrote: Please also find the same crash here: http://lists.linaro.org/pipermail/kernel-build-reports/2014-June/003872.html Hmm, looks like from the exynos5420-arndale-octa failure in that, we don't dump the page table entries. We should do. Sorry about my previous mail. If you can reproduce this, please do so with this patch so that we can get the page table entries associated with the problem. Thanks. arch/arm/mm/fault.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c index a982dc3190df..6333d9c17875 100644 --- a/arch/arm/mm/fault.c +++ b/arch/arm/mm/fault.c @@ -552,6 +552,7 @@ do_DataAbort(unsigned long addr, unsigned int fsr, struct pt_regs *regs) pr_alert(Unhandled fault: %s (0x%03x) at 0x%08lx\n, inf-name, fsr, addr); + show_pte(current-mm, addr); info.si_signo = inf-sig; info.si_errno = 0; Thanks. [5.383283] Unhandled fault: external abort on non-linefetch (0x808) at 0xf00d3018 [5.390871] pgd = c0004000 [5.393583] [f00d3018] *pgd=2d404811, *pte=efc1e65f, *ppte=efc1e45f This is interesting. So, the L1 page table entry is: PMD_TYPE_TABLE PMD_BIT4 PMD_DOMAIN(0) Pointing at physical address 0x2f404800 L2 page table entry: PTE_EXT_XN PTE_BUFFERABLE PTE_CACHEABLE PTE_EXT_AP_UNO_SRW PTE_EXT_TEX(1) PTE_EXT_SHARED Physical address 0xefc1e000 That corresponds with L_PTE_MT_WRITEALLOC, so that's a memory type mapping with cacheable, write-back, write-allocate attributes. The thing which has me wondering though is the difference in physical addresses - that looks /very/ wrong - unless you have close to 4GB of memory. Let's see whether we can get some debug from vmalloc to work out what's going on - can you also apply the patch below. Also, if you could include details about how much memory your platform has, and where it's located, that would be useful - passing memblock=debug should allow us to see what's going on at the memblock level. Also, the full kernel boot log would be useful to see. Thanks. (Patch isn't tested.) mm/vmalloc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 35b25e1340ca..3379bcd6d280 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -129,6 +129,8 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, return -EBUSY; if (WARN_ON(!page)) return -ENOMEM; +printk(vmalloc: mapping page %p (0x%08lx000) at 0x%08lx\n, + page, page_to_pfn(page), addr); set_pte_at(init_mm, addr, pte, mk_pte(page, prot)); (*nr)++; } while (pte++, addr += PAGE_SIZE, addr != end); -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
