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 ha
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 ha
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 'he
>
> 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 f
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.
>> M
> >
> > 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
>
> > 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 n
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 alloc
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 "L
