Re: Large physical address support on e500 platform

quoted

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

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

quoted

quoted

=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

quoted

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=

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

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

quoted

=20
Is a simple "hello world" module sufficient to show the issue?  I'll =

look into it this week.

quoted

=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=

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

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

quoted

quoted

=20
Is a simple "hello world" module sufficient to show the issue?  I'll =

look into it this week.

quoted

quoted

=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=

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

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

quoted

quoted

=20
Is a simple "hello world" module sufficient to show the issue?  I'll =

look into it this week.

quoted

quoted

=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=