* PAE40 without HIGHMEM [not found] <1493973869.3200.26.camel@synopsys.com> @ 2017-05-05 19:31 ` Vineet Gupta 2017-05-05 19:42 ` Alexey Brodkin 0 siblings, 1 reply; 3+ messages in thread From: Vineet Gupta @ 2017-05-05 19:31 UTC (permalink / raw) To: linux-snps-arc +CC arcml Hi Alexey, On 05/05/2017 01:44 AM, Alexey Brodkin wrote: > Hi Vineet, > > Playing with PAE40 on axs103 v1.2-rc2 (where PAE really seems to work quite well) > Eugeniy bumped into the fact that PAE could be enabled without HIGHMEM. > > Personally I din't face that trouble because I used to enable HIGHMEM manually before > even thinking of PAE. > > So we were surprised why there's no dependency which I was pretty sure was there > back in the day. And to no surprise I found you removed such a dependency in > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7cab91b87dd8eeee5911ec34be8bb0288ebba18b > "ARCv2: Allow enabling PAE40 w/o HIGHMEM". > > Now what we have another [and this time real HW] platform with PAE support > and DDR mapped above 4Gb do you think we may revert this change and > put dependency on HIGHMEM for PAE? > > If you like I may send a patch to that effect. I understand your point, and PAE40 when really exercising > 32 bits certainly needs HIGHMEM. However in a setup where we only had 32 bit paddr, we can technically still build a PAE40 enabled kernel - which uses PAE40 enabled MMU cmds etc (with upper words always happening to be 0) and should in theory work as well. Agreed it is not a production config, still it is a useful "test" config or a "developer" config. The next question is why was Euginey seeing the errors - because he had DT setup memory > 1_0000_0000 and CONFIG_HIGHMEM was not enabled ? That certainly is broken and needs to be prevented at config or early run time. -Vineet ^ permalink raw reply [flat|nested] 3+ messages in thread
* PAE40 without HIGHMEM 2017-05-05 19:31 ` PAE40 without HIGHMEM Vineet Gupta @ 2017-05-05 19:42 ` Alexey Brodkin 2017-05-05 19:57 ` Vineet Gupta 0 siblings, 1 reply; 3+ messages in thread From: Alexey Brodkin @ 2017-05-05 19:42 UTC (permalink / raw) To: linux-snps-arc Hi Vineet, On Fri, 2017-05-05@12:31 -0700, Vineet Gupta wrote: > +CC arcml > > Hi Alexey, > > On 05/05/2017 01:44 AM, Alexey Brodkin wrote: > > > > Hi Vineet, > > > > Playing with PAE40 on axs103 v1.2-rc2 (where PAE really seems to work quite well) > > Eugeniy bumped into the fact that PAE could be enabled without HIGHMEM. > > > > Personally I din't face that trouble because I used to enable HIGHMEM manually before > > even thinking of PAE. > > > > So we were surprised why there's no dependency which I was pretty sure was there > > back in the day. And to no surprise I found you removed such a dependency in > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7cab91b87dd8eeee5911ec34be8bb0288ebba18b > > "ARCv2: Allow enabling PAE40 w/o HIGHMEM". > > > > Now what we have another [and this time real HW] platform with PAE support > > and DDR mapped above 4Gb do you think we may revert this change and > > put dependency on HIGHMEM for PAE? > > > > If you like I may send a patch to that effect. > > I understand your point, and PAE40 when really exercising > 32 bits certainly > needs HIGHMEM. > > However in a setup where we only had 32 bit paddr, we can technically still build > a PAE40 enabled kernel - which uses PAE40 enabled MMU cmds etc (with upper words > always happening to be 0) and should in theory work as well. Agreed it is not a > production config, still it is a useful "test" config or a "developer" config. > > The next question is why was Euginey seeing the errors - because he had DT setup > memory > 1_0000_0000 and CONFIG_HIGHMEM was not enabled ? That certainly is broken > and needs to be prevented at config or early run time. Actually it was not an error that Eugeniy saw but absence of any differences after: 1) Adding the second memory region "0x1 0xa000_0000" in axc003_idu.dtsi 2) Enabling PAE40 in menuconfig We had roughly the same situation as with PAE disabled and pristine DTS. Well the only difference was mention of PAE40 being in use... but still only 256Mb (read the same lowmem) was available. I'd say for "tests" we may manually overcome HIGHMEM dependency (with local arch/arc/Kconfig mod) but keep the dependency in place so users who really want to access memory above 4Gb are not misleaded. -Alexey ^ permalink raw reply [flat|nested] 3+ messages in thread
* PAE40 without HIGHMEM 2017-05-05 19:42 ` Alexey Brodkin @ 2017-05-05 19:57 ` Vineet Gupta 0 siblings, 0 replies; 3+ messages in thread From: Vineet Gupta @ 2017-05-05 19:57 UTC (permalink / raw) To: linux-snps-arc On 05/05/2017 12:42 PM, Alexey Brodkin wrote: > Hi Vineet, > > On Fri, 2017-05-05@12:31 -0700, Vineet Gupta wrote: >> +CC arcml >> >> Hi Alexey, >> >> On 05/05/2017 01:44 AM, Alexey Brodkin wrote: >>> >>> Hi Vineet, >>> >>> Playing with PAE40 on axs103 v1.2-rc2 (where PAE really seems to work quite well) >>> Eugeniy bumped into the fact that PAE could be enabled without HIGHMEM. >>> >>> Personally I din't face that trouble because I used to enable HIGHMEM manually before >>> even thinking of PAE. >>> >>> So we were surprised why there's no dependency which I was pretty sure was there >>> back in the day. And to no surprise I found you removed such a dependency in >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7cab91b87dd8eeee5911ec34be8bb0288ebba18b >>> "ARCv2: Allow enabling PAE40 w/o HIGHMEM". >>> >>> Now what we have another [and this time real HW] platform with PAE support >>> and DDR mapped above 4Gb do you think we may revert this change and >>> put dependency on HIGHMEM for PAE? >>> >>> If you like I may send a patch to that effect. >> >> I understand your point, and PAE40 when really exercising > 32 bits certainly >> needs HIGHMEM. >> >> However in a setup where we only had 32 bit paddr, we can technically still build >> a PAE40 enabled kernel - which uses PAE40 enabled MMU cmds etc (with upper words >> always happening to be 0) and should in theory work as well. Agreed it is not a >> production config, still it is a useful "test" config or a "developer" config. >> >> The next question is why was Euginey seeing the errors - because he had DT setup >> memory > 1_0000_0000 and CONFIG_HIGHMEM was not enabled ? That certainly is broken >> and needs to be prevented at config or early run time. > > Actually it was not an error that Eugeniy saw but absence of any differences after: > 1) Adding the second memory region "0x1 0xa000_0000" in axc003_idu.dtsi > 2) Enabling PAE40 in menuconfig > > We had roughly the same situation as with PAE disabled and pristine DTS. > Well the only difference was mention of PAE40 being in use... but still only > 256Mb (read the same lowmem) was available. So you mean PAE40 + !HIGHMEM behaved as !PAE40 and it didn't crash or tell the user that it was not being in user ! I'd say this is good and cool ;-) > I'd say for "tests" we may manually overcome HIGHMEM dependency (with local arch/arc/Kconfig mod) > but keep the dependency in place so users who really want to access memory above 4Gb are not > misleaded. Fair enough, please send the revert of my orig patch to enforce the dependency: as you rightly say now we have a PAE40 enabled platform to actually test the real deal and not made up stuff ! -Vineet ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-05-05 19:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1493973869.3200.26.camel@synopsys.com>
2017-05-05 19:31 ` PAE40 without HIGHMEM Vineet Gupta
2017-05-05 19:42 ` Alexey Brodkin
2017-05-05 19:57 ` Vineet Gupta
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.