On Sat, Sep 26, 2009 at 07:57:32AM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2009-09-25 at 21:45 +0200, Sam Ravnborg wrote:
> > On Thu, Sep 24, 2009 at 03:28:11PM +0400, Yuri Frolov wrote:
> > > Hello,
> > >
> > > here is a corresponding bug:
> > > http://bugzilla.kernel.org/show_bug.cgi?id=
On Fri, 2009-09-25 at 21:45 +0200, Sam Ravnborg wrote:
> On Thu, Sep 24, 2009 at 03:28:11PM +0400, Yuri Frolov wrote:
> > Hello,
> >
> > here is a corresponding bug:
> > http://bugzilla.kernel.org/show_bug.cgi?id=11143
> > This patch should correctly export crtsavres.o in order to make O= option
Thus spake Benjamin Herrenschmidt (b...@kernel.crashing.org):
>
> > I think there's more finishyness to 8xx than we thought. IE. That
> > tlbil_va might have more reasons to be there than what the comment
> > seems to advertize. Can you try to move it even higher up ? IE.
> > Unconditionally at t
On Fri, 2009-09-25 at 16:48 +0200, Peter Zijlstra wrote:
> On Thu, 2009-09-24 at 10:51 +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2009-09-15 at 14:11 +0200, Peter Zijlstra wrote:
> > > I still think its a layering violation... its the hypervisor manager
> > > that should be bothered in what s
Anybody else getting these? They just started popping up with the
recent changes for 2.6.32.
ppc_4xxFP-ld: .tmp_vmlinux1: warning: allocated section `.data_nosave'
not in segment KSYM.tmp_kallsyms1.S
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
ppc_4xxFP-ld: .tmp_vmlinux2: warning: all
Ben/all,
I have had some luck reserving some memory (via in this autoscan
(which reserves the resources)) which in this hack code - I reserve
an appropriate amount of resources for the bridge (by detecting
this special type of port).
The problem comes later on - when the Hotplug event comes - an
On Thu, Sep 24, 2009 at 03:28:11PM +0400, Yuri Frolov wrote:
> Hello,
>
> here is a corresponding bug: http://bugzilla.kernel.org/show_bug.cgi?id=11143
> This patch should correctly export crtsavres.o in order to make O= option
> working.
> Please, consider to apply.
Hi Yuri.
I like the way you
* Arun R Bharadwaj [2009-09-22 16:55:27]:
Hi,
I have done the following experiments and have posted the results
below.
Average of 5 iterations:
--
On Sep 25, 2009, at 4:07 AM, Fortini Matteo wrote:
I was trying to insert an optimized strlen() function using the
following code taken from the ibm site on an MPC5121, but it crashes
the kernel.
Is it because it's an unsupported op, or because I'm missing some
needed steps?
Thank you,
M
On Thu, 2009-09-24 at 10:51 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2009-09-15 at 14:11 +0200, Peter Zijlstra wrote:
> > I still think its a layering violation... its the hypervisor manager
> > that should be bothered in what state an off-lined cpu is in.
> >
> That's not how our hyperviso
Hi Stephen,
next-20090925 randconfig build breaks on hvcs driver on powerpc,
with HVC_CONSOLE=n.
ERROR: ".hvc_put_chars" [drivers/char/hvcs.ko] undefined!
ERROR: ".hvc_get_chars" [drivers/char/hvcs.ko] undefined!
adding the dependency of HVC_CONSOLE helped
Sig
On Thu, Sep 24, 2009 at 10:41 AM, Asier Llano Palacios
wrote:
> Hi Grant,
>
> We've been working with a lite5200b for a while, we have been working
> with the ppc platform in linux 2.6.x for 5 years and it worked properly
> until 2.6.25 included. We want to switch to the powerpc platform but it
>
I was trying to insert an optimized strlen() function using the
following code taken from the ibm site on an MPC5121, but it crashes the
kernel.
Is it because it's an unsupported op, or because I'm missing some needed
steps?
Thank you,
Matteo
_GLOBAL(strlen)
addi r4,0,8// Load byte c
Benjamin Herrenschmidt wrote on 25/09/2009 11:47:34:
>
> On Fri, 2009-09-25 at 10:31 +0200, Joakim Tjernlund wrote:
> >
> > The main problem with 8xx it does not update the DAR register in
> > the TLB Miss/Fault handlers for cache instructions :( It on old bug
> > that was found only some years ag
Joakim Tjernlund wrote:
> The driver always ends a read with a STOP condition which
> breaks subsequent I2C reads/writes in the same transaction as
> these expect to do a repeated START(ReSTART).
>
> This will also help I2C multimaster as the bus will not be released
> after the first read, but wh
On Fri, 2009-09-25 at 18:01 +0900, Tejun Heo wrote:
> > With this patch applied the machine boots OK :-)
>
> Ah... so, the problem really is too high address. If you've got some
> time, it might be interesting to find out how far high is safe.
>
Might give me a clue about what the problem is but
On Fri, 2009-09-25 at 10:31 +0200, Joakim Tjernlund wrote:
>
> The main problem with 8xx it does not update the DAR register in
> the TLB Miss/Fault handlers for cache instructions :( It on old bug
> that was found only some years ago.
>
> I think the old comment is correct though, as I recall it
On 09/25/2009 08:39 AM, Sam Ravnborg wrote:
> On Fri, Sep 25, 2009 at 11:12:21AM +1000, Benjamin Herrenschmidt wrote:
>> On Thu, 2009-09-24 at 15:28 +0400, Yuri Frolov wrote:
>>> Hello,
>>>
>>> here is a corresponding bug:
>>> http://bugzilla.kernel.org/show_bug.cgi?id=11143
>>> This patch should
On Fri, 25 Sep 2009 10:54:24 +0200
Peter Zijlstra wrote:
> On Fri, 2009-09-25 at 12:36 +0530, Vaidyanathan Srinivasan wrote:
> > * Arjan van de Ven [2009-09-24 14:22:28]:
> >
> > > On Thu, 24 Sep 2009 10:42:41 +0530
> > > Arun R Bharadwaj wrote:
> > >
> > > > * Arun R Bharadwaj [2009-09-22
>
Sachin Sant wrote:
> With this patch applied the machine boots OK :-)
Ah... so, the problem really is too high address. If you've got some
time, it might be interesting to find out how far high is safe.
Thanks.
--
tejun
___
Linuxppc-dev mailing list
On Fri, 2009-09-25 at 12:36 +0530, Vaidyanathan Srinivasan wrote:
> * Arjan van de Ven [2009-09-24 14:22:28]:
>
> > On Thu, 24 Sep 2009 10:42:41 +0530
> > Arun R Bharadwaj wrote:
> >
> > > * Arun R Bharadwaj [2009-09-22 16:55:27]:
> > >
> > > Hi Len, (or other acpi folks),
> > >
> > > I had
>
>
> > I think there's more finishyness to 8xx than we thought. IE. That
> > tlbil_va might have more reasons to be there than what the comment
> > seems to advertize. Can you try to move it even higher up ? IE.
> > Unconditionally at the beginning of set_pte_filter ?
> >
> > Also, if that doesn't
On Fri, 2009-09-25 at 16:39 +0900, Tejun Heo wrote:
> Hello,
>
> Sachin Sant wrote:
> > <4>PERCPU: chunk 1 relocating -1 -> 18 c000db70fb00
> >
> > <4>PERCPU: relocated
> > <4>PERCPU: chunk 1 relocating 18 -> 16 c000db70fb00
> >
> > <4>PERCPU: relocated
> > <4>PERCPU: chunk 1, alloc pa
Tejun Heo wrote:
Tejun Heo wrote:
Hello,
Sachin Sant wrote:
<4>PERCPU: chunk 1 relocating -1 -> 18 c000db70fb00
<4>PERCPU: relocated
<4>PERCPU: chunk 1 relocating 18 -> 16 c000db70fb00
<4>PERCPU: relocated
<4>PERCPU: chunk 1, alloc pages [0,1)
<4>PERCPU: chunk 1, map pages
Tejun Heo wrote:
> Hello,
>
> Sachin Sant wrote:
>> <4>PERCPU: chunk 1 relocating -1 -> 18 c000db70fb00
>>
>> <4>PERCPU: relocated
>> <4>PERCPU: chunk 1 relocating 18 -> 16 c000db70fb00
>>
>> <4>PERCPU: relocated
>> <4>PERCPU: chunk 1, alloc pages [0,1)
>> <4>PERCPU: chunk 1, map pages
On Fri, 25 Sep 2009 12:55:49 +0530
Vaidyanathan Srinivasan wrote:
> > I obviously can't speak for p-series cpus, just wanted to point out
> > that there is no universal truth about "offlining saves power".
>
> Hi Arjan,
>
> As you have said, on some cpus the extra effort of offlining does not
>
Hello,
Sachin Sant wrote:
> <4>PERCPU: chunk 1 relocating -1 -> 18 c000db70fb00
>
> <4>PERCPU: relocated
> <4>PERCPU: chunk 1 relocating 18 -> 16 c000db70fb00
>
> <4>PERCPU: relocated
> <4>PERCPU: chunk 1, alloc pages [0,1)
> <4>PERCPU: chunk 1, map pages [0,1)
> <4>PERCPU: map 0xd
* Arjan van de Ven [2009-09-24 13:41:23]:
> On Thu, 24 Sep 2009 13:33:07 +0200
> Peter Zijlstra wrote:
>
> > On Thu, 2009-09-24 at 18:38 +1000, Benjamin Herrenschmidt wrote:
> > > On Thu, 2009-09-24 at 09:51 +0200, Peter Zijlstra wrote:
> > > > > I don't quite follow your logic here. This is us
On Thu, Sep 24, 2009 at 5:52 PM, Arjan van de Ven wrote:
> On Thu, 24 Sep 2009 10:42:41 +0530
> Arun R Bharadwaj wrote:
>
>> * Arun R Bharadwaj [2009-09-22 16:55:27]:
>>
>> Hi Len, (or other acpi folks),
>>
>> I had a question regarding ACPI-cpuidle interaction in the current
>> implementation.
Tejun Heo wrote:
Benjamin Herrenschmidt wrote:
--- Exception: 301 at .memset+0x60/0xfc
LR = .pcpu_alloc+0x718/0x8fc
So it's memsetting something that causes it to hash_page(), ie, faulting
in pages (vmalloc space ?) so far nothing obviously wrong
It's probably memset()
* Arjan van de Ven [2009-09-24 14:22:28]:
> On Thu, 24 Sep 2009 10:42:41 +0530
> Arun R Bharadwaj wrote:
>
> > * Arun R Bharadwaj [2009-09-22 16:55:27]:
> >
> > Hi Len, (or other acpi folks),
> >
> > I had a question regarding ACPI-cpuidle interaction in the current
> > implementation.
> >
31 matches
Mail list logo
