Re: Large physical address support on e500 platform
On Jan 25, 2010, at 11:25 AM, Kumar Gala wrote: On Jan 25, 2010, at 11:06 AM, Aaron Pace wrote: Is a simple hello world module sufficient to show the issue? I'll look 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. 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Large physical address support on e500 platform
On Jan 25, 2010, at 11:25 AM, Kumar Gala wrote: On Jan 25, 2010, at 11:06 AM, Aaron Pace wrote: Is a simple hello world module sufficient to show the issue? I'll look 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. 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Large physical address support on e500 platform
On Jan 22, 2010, at 12:27 AM, Aaron Pace wrote: 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. Is a simple hello world module sufficient to show the issue? I'll look into it this week. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Large physical address support on e500 platform
Is a simple hello world module sufficient to show the issue? I'll look 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Large physical address support on e500 platform
On Jan 25, 2010, at 11:06 AM, Aaron Pace wrote: Is a simple hello world module sufficient to show the issue? I'll look 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. Ok, if there is a module or something you can post that reproduces the issue that would be extremely helpful. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Large physical address support on e500 platform
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Large physical address support on e500 platform
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. 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. 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? 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Large physical address support on e500 platform
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? 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. 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. __ See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
