On Fri, Sep 09, 2016 at 06:17:13AM -0700, Sagar Borikar wrote: > Thanks James. > > On Fri, Sep 9, 2016 at 5:36 AM, James Hogan <james.hogan@xxxxxxxxxx> wrote: > > Hi Sagar, > > > > On Thu, Sep 08, 2016 at 08:33:57PM -0700, Sagar Borikar wrote: > >> Hello, > >> > >> I am upgrading kernel for a MIPS Interaptive CPU from 3.10.60 to > >> 3.14.10 (stable) from: > >> https://www.linux-mips.org/wiki/Malta_Linux_Repository > > > > Unfortunately that wiki page needs updating. > > > > If you're upgrading anyway, I think we'd recommend switching all the way > > to a recent mainline kernel release / stable branch, e.g. 4.4 (LTS) or > > 4.7 (and maybe update to 4.9 (LTS) when it is released or when 4.7 goes > > EOL). I think all the stuff you'll need for interAptiv should be in > > mainline now anyway. > > I see. We generally upgrade to malta repo as its maintained by mips > (imgtec). I presume you are referring to kernel.org. I think linux-mti > is having 4.1.7 as stable, right? Yeh I was referring to kernel.org. 3.14 was the last linux-mti branch. A lot of stuff in mti-3.10 got upstreamed (with a lot of changes and clean ups made along the way), and I think as a result mti-3.14 was mostly backported patches from mainline. That may explain this regression. We're now trying to focus a lot more on mainline (although we have engineering branches in that same linux-mti repository, which are more for supporting new architecture features & new cores before they've found their way into mainline). > >> The platform has non-contiguous low memory and high memory. After the > >> upgrade, highmem is not getting enabled due to max_low_pfn and > >> highend_pfn not being the same. > >> > >> The commit cce335ae47e231398269fb05fa48e0e9cbf289e0 introduced the > >> change apparently for sibyte platform. That change doesn't hold good > >> for all platforms where the high memory and low memory is sparsed. > >> > >> If I comment out only following change in arch/mips/mm/init.c, highmem > >> gets initialized properly. > >> > >> 296 if (cpu_has_dc_aliases && max_low_pfn != highend_pfn) { > >> 297 printk(KERN_WARNING "This processor doesn't support highmem." > >> 298 " %ldk highmem ignored\n", > >> 299 (highend_pfn - max_low_pfn) << (PAGE_SHIFT - 10)); > >> 300 max_zone_pfns[ZONE_HIGHMEM] = max_low_pfn; > >> 301 lastpfn = max_low_pfn; > >> 302 } > > > > I don't think we ever supported DCache aliasing + highmem in > > combination. > > Interesting. We are currently running 3.10.60 and apparently it seems > to work. Are you saying it may cause any issues? So far we haven't > seen any problems. What kind of issues it might end up into? Sorry, I was thinking of mainline. Mti-3.10 seems to have had changes which didn't make it upstream which would have made this possible, from which commit 15de36a4c3cf ("mm/highmem: make kmap cache coloring aware") was derived (which was merged for v3.17, in August 2014). There were attempts to add the MIPS support after this, but none of them made it upstream: https://patchwork.linux-mips.org/project/linux-mips/list/?state=*&q=fixes+for+cache+aliasing > > > > > If you want to use that memory your options are probably: > > - increase the page size to avoid dcache aliasing. > > Ok thanks. I would need to experiment with this but I am bit baffled > how its working in 3.10.60. > Generally, is there any reference platforms based on interaptiv which > uses highmem and dcache aliasing? I might have missed but couldn't > find any platform which comes close in both trees. Its probably possible to configure malta in such a way (4k pages, big cache, alias removal disabled in hardware, highmem). > > > - OR use EVA to increase the size of lowmem, which at the moment is a > > bit more involved. How much RAM do you have, and what does your > > physical memory map look like? > > Total memory is 2GB. memory map looks like this: > > low mem(~66MB) : > > * 0x04300000 +-----------------+ > * | Linux | > * 0x00043000 +-----------------+ > > high mem (128MB): > > * 0x28000000 +-----------------+ > * | linuxhi | > * 0x20000000 +-----------------+ > > Rest of the blocks are reserved. It should be possible to use EVA to expand lowmem to cover these two regions. Fitting in the whole 2GB would probably be a little trickier depending on other stuff (how much IO memory is needed, IOCU in use, etc). Cheers James
Attachment:
signature.asc
Description: Digital signature
