Re: Large physical address support on e500 platform

Re: Large physical address support on e500 platform

[Aaron Pace]

> >
> > Its possible that we've broken module/vmalloc support with
> > "Large physical addressing".? Its not something I've
> > tried in a while.? What kernel/git SHA are you using.
> >

>I'm just pulling in from the main kernel tree git.
>My current version is 2.6.33-rc4-00193-gd1e4922-dirty,
>but it had not changed since 2.6.33-rc2
>
>I started from 2.6.32, but I don't remember if I had a large PA
>support enabled there.

Just to second this issue, the following commit is what broke this:

[76acc2c1a7a9a8c2cae7e9cf8d0a8b374a48aa94]

I didn't have time to delve into the whys & hows, but this commit
caused the same issue on an 8572 platform.
Reverting this one change allows everything (including 36-bit memory
access) to work correctly, as before.

-Aaron Pace

Re: Large physical address support on e500 platform

[Kumar Gala]

On Jan 22, 2010, at 12:27 AM, Aaron Pace wrote:

>>>=20
>>> Its possible that we've broken module/vmalloc support with
>>> "Large physical addressing".? Its not something I've
>>> tried in a while.? What kernel/git SHA are you using.
>>>=20
>=20
>> I'm just pulling in from the main kernel tree git.
>> My current version is 2.6.33-rc4-00193-gd1e4922-dirty,
>> but it had not changed since 2.6.33-rc2
>>=20
>> I started from 2.6.32, but I don't remember if I had a large PA
>> support enabled there.
>=20
> Just to second this issue, the following commit is what broke this:
>=20
> [76acc2c1a7a9a8c2cae7e9cf8d0a8b374a48aa94]
>=20
> I didn't have time to delve into the whys & hows, but this commit
> caused the same issue on an 8572 platform.
> Reverting this one change allows everything (including 36-bit memory
> access) to work correctly, as before.

Is a simple "hello world" module sufficient to show the issue?  I'll =
look into it this week.

- k=

Re: Large physical address support on e500 platform

[Aaron Pace]

>
> Is a simple "hello world" module sufficient to show the issue? =A0I'll lo=
ok into it this week.
>
> - k

It wasn't in my situation, unfortunately.  To duplicate this, I had
one relatively large kernel module, and then one simple 'hello world'
module that did nothing more than call an exported function from the
first module as part of its init.

-Aaron

Re: Large physical address support on e500 platform

[Kumar Gala]

On Jan 25, 2010, at 11:06 AM, Aaron Pace wrote:

>>=20
>> Is a simple "hello world" module sufficient to show the issue?  I'll =
look into it this week.
>>=20
>> - k
>=20
> It wasn't in my situation, unfortunately.  To duplicate this, I had
> one relatively large kernel module, and then one simple 'hello world'
> module that did nothing more than call an exported function from the
> first module as part of its init.

Ok, if there is a module or something you can post that reproduces the =
issue that would be extremely helpful.

- k=

Re: Large physical address support on e500 platform

[Kumar Gala]

On Jan 25, 2010, at 11:25 AM, Kumar Gala wrote:

>=20
> On Jan 25, 2010, at 11:06 AM, Aaron Pace wrote:
>=20
>>>=20
>>> Is a simple "hello world" module sufficient to show the issue?  I'll =
look into it this week.
>>>=20
>>> - k
>>=20
>> It wasn't in my situation, unfortunately.  To duplicate this, I had
>> one relatively large kernel module, and then one simple 'hello world'
>> module that did nothing more than call an exported function from the
>> first module as part of its init.
>=20
> Ok, if there is a module or something you can post that reproduces the =
issue that would be extremely helpful.

I think we may now have figured this out.

- k=

Re: Large physical address support on e500 platform

[Kumar Gala]

On Jan 25, 2010, at 11:25 AM, Kumar Gala wrote:

>=20
> On Jan 25, 2010, at 11:06 AM, Aaron Pace wrote:
>=20
>>>=20
>>> Is a simple "hello world" module sufficient to show the issue?  I'll =
look into it this week.
>>>=20
>>> - k
>>=20
>> It wasn't in my situation, unfortunately.  To duplicate this, I had
>> one relatively large kernel module, and then one simple 'hello world'
>> module that did nothing more than call an exported function from the
>> first module as part of its init.
>=20
> Ok, if there is a module or something you can post that reproduces the =
issue that would be extremely helpful.

I think we may now have figured this out.

- k=

Re: Large physical address support on e500 platform

[Alex Dubov]

> =0A> > So, the obvious question is, what is the current=0A> status of lar=
ge physical=0A> > address support on e500? Is it a problem in current=0A> g=
it version or is it=0A> > not ready yet?=0A> > =0A> > Thanks.=0A> =0A> Its =
possible that we've broken module/vmalloc support with=0A> "Large physical =
addressing".=A0 Its not something I've=0A> tried in a while.=A0 What kernel=
/git SHA are you using.=0A> =0A=0AI'm just pulling in from the main kernel =
tree git.=0AMy current version is 2.6.33-rc4-00193-gd1e4922-dirty,=0Abut it=
 had not changed since 2.6.33-rc2=0A=0AI started from 2.6.32, but I don't r=
emember if I had a large PA=0Asupport enabled there.=0A=0A=0A=0A=0A      __=
___________________________________________________________________________=
_____=0ASee what's on at the movies in your area. Find out now: http://au.m=
ovies.yahoo.com/session-times/

Re: Large physical address support on e500 platform

[Kumar Gala]

On Jan 19, 2010, at 12:54 AM, Alex Dubov wrote:

> I'm working on an mpc8548 based board and recently I've encountered a
> problem, whereupon kernel crashed each time module loading is =
attempted. I
> traced the problem to the fact, that vmalloc_exec was setting =
incorrect
> page attributes on allocated pages. This, in turn, happened because I
> specified "Large physical address support" in the Kconfig, leading to
> CONFIG_PHYS_64BIT and friends being set.
>=20
> It appears that having this option set on e500 pulls in incorrect =
headers
> and otherwise not working. CPU, however, has support for 36b physical
> addressing, which qualifies as "Large physical address".
>=20
> So, the obvious question is, what is the current status of large =
physical
> address support on e500? Is it a problem in current git version or is =
it
> not ready yet?
>=20
> Thanks.

Its possible that we've broken module/vmalloc support with "Large =
physical addressing".  Its not something I've tried in a while.  What =
kernel/git SHA are you using.

- k=

Large physical address support on e500 platform

[Alex Dubov]

I'm working on an mpc8548 based board and recently I've encountered a=0Apro=
blem, whereupon kernel crashed each time module loading is attempted. I=0At=
raced the problem to the fact, that vmalloc_exec was setting incorrect=0Apa=
ge attributes on allocated pages. This, in turn, happened because I=0Aspeci=
fied "Large physical address support" in the Kconfig, leading to=0ACONFIG_P=
HYS_64BIT and friends being set.=0A=0AIt appears that having this option se=
t on e500 pulls in incorrect headers=0Aand otherwise not working. CPU, howe=
ver, has support for 36b physical=0Aaddressing, which qualifies as "Large p=
hysical address".=0A=0ASo, the obvious question is, what is the current sta=
tus of large physical=0Aaddress support on e500? Is it a problem in current=
 git version or is it=0Anot ready yet?=0A=0AThanks.=0A=0A=0A=0A=0A=0A=0A=0A=
      _____________________________________________________________________=
_____________=0ASee what's on at the movies in your area. Find out now: htt=
p://au.movies.yahoo.com/session-times/