Benjamin Herrenschmidt wrote:
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
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
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 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
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
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()
On Fri, 2009-09-25 at 12:22 +0900, 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 obvi
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() call near the end of pcp
On Thu, 2009-09-24 at 18:53 +0530, Sachin Sant wrote:
> Tejun Heo wrote:
> > Sachin Sant wrote:
> >
> >> Tejun Heo wrote:
> >>
> >>> Can you please apply the attached patch and see whether anything
> >>> interesting shows up in the kernel log?
> >>>
> >>>
> >> Thanks Tejun for the
Tejun Heo wrote:
Sachin Sant wrote:
Tejun Heo wrote:
Can you please apply the attached patch and see whether anything
interesting shows up in the kernel log?
Thanks Tejun for the debug patch. Attached here are the relevant logs.
The only messages related to percpu in the logs
Sachin Sant wrote:
> Tejun Heo wrote:
>> Can you please apply the attached patch and see whether anything
>> interesting shows up in the kernel log?
>>
> Thanks Tejun for the debug patch. Attached here are the relevant logs.
> The only messages related to percpu in the logs are
>
> <6>PERCPU: E
Tejun Heo wrote:
Can you please apply the attached patch and see whether anything
interesting shows up in the kernel log?
Thanks Tejun for the debug patch. Attached here are the relevant logs.
The only messages related to percpu in the logs are
<6>PERCPU: Embedded 2 pages/cpu @c12000
Tejun Heo wrote:
>> One workaround i have found for this problem is to disable IPv6.
>> With IPv6 disabled the machine boots OK. Till a reliable solution
>> is available for this issue, i will keep IPv6 disabled in my configs.
>
> I'm think it's most likely caused by some code accessing invalid
>
Sachin Sant wrote:
> Sachin Sant wrote:
>> Sachin Sant wrote:
>>> Tejun Heo wrote:
Ah... sorry about that. Sachin, is it possible for you to build the
kernel with debug info and ask gdb where the stalling NIP is in the c
file?
>>> <6>NET: Registered protocol family 10
>>> <3
Sachin Sant wrote:
Sachin Sant wrote:
Tejun Heo wrote:
Ah... sorry about that. Sachin, is it possible for you to build the
kernel with debug info and ask gdb where the stalling NIP is in the c
file?
<6>NET: Registered protocol family 10
<3>BUG: soft lockup - CPU#2 stuck for 61s! [modprobe:
Sachin Sant wrote:
Tejun Heo wrote:
Ah... sorry about that. Sachin, is it possible for you to build the
kernel with debug info and ask gdb where the stalling NIP is in the c
file?
<6>NET: Registered protocol family 10
<3>BUG: soft lockup - CPU#2 stuck for 61s! [modprobe:1865]
<4>Modules lin
Hello,
Benjamin Herrenschmidt wrote:
> On Thu, 2009-09-17 at 16:21 +0530, Sachin Sant wrote:
>> The problem seems to have been introduced with
>> commit ada3fa15057205b7d3f727bba5cd26b5912e350f.
>>
>> Specifically this patch :
>> powerpc64: convert to dynamic percpu allocator
>>
>> If i revert th
Tejun Heo wrote:
Ah... sorry about that. Sachin, is it possible for you to build the
kernel with debug info and ask gdb where the stalling NIP is in the c
file?
<6>NET: Registered protocol family 10
<3>BUG: soft lockup - CPU#2 stuck for 61s! [modprobe:1865]
<4>Modules linked in: ipv6(+) fuse
On Thu, 2009-09-17 at 16:21 +0530, Sachin Sant wrote:
> The problem seems to have been introduced with
> commit ada3fa15057205b7d3f727bba5cd26b5912e350f.
>
> Specifically this patch :
> powerpc64: convert to dynamic percpu allocator
>
> If i revert this patch i am able to boot latest git
> on a
21 matches
Mail list logo
