From: Sam Ravnborg
Date: Fri, 24 Oct 2014 06:54:55 +0200
> A minor detail.
>
>> [PATCH] sparc64: Fix register corruption in top-most kernel stack frame
>> during boot.
>>
>> -callstart_kernel
>> +call start_early_boot
>
> Maybe add a comment about stack use - as per your nice
From: Meelis Roos
Date: Fri, 24 Oct 2014 10:49:12 +0300 (EEST)
>> > I can reproduce and I know what the problem is, fixed patch coming up
>> > shortly.
>>
>> Ok, please test this patch below.
>
> Thank you, it works fine on my V210, V440 and newly added V245.
Thanks so much for testing.
I'll
> > I can reproduce and I know what the problem is, fixed patch coming up
> > shortly.
>
> Ok, please test this patch below.
Thank you, it works fine on my V210, V440 and newly added V245.
--
Meelis Roos (mr...@linux.ee)
--
To unsubscribe from this list: send the line "unsubscribe
I can reproduce and I know what the problem is, fixed patch coming up
shortly.
Ok, please test this patch below.
Thank you, it works fine on my V210, V440 and newly added V245.
--
Meelis Roos (mr...@linux.ee)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
From: Meelis Roos mr...@linux.ee
Date: Fri, 24 Oct 2014 10:49:12 +0300 (EEST)
I can reproduce and I know what the problem is, fixed patch coming up
shortly.
Ok, please test this patch below.
Thank you, it works fine on my V210, V440 and newly added V245.
Thanks so much for testing.
From: Sam Ravnborg s...@ravnborg.org
Date: Fri, 24 Oct 2014 06:54:55 +0200
A minor detail.
[PATCH] sparc64: Fix register corruption in top-most kernel stack frame
during boot.
-callstart_kernel
+call start_early_boot
Maybe add a comment about stack use - as per your nice
A minor detail.
> [PATCH] sparc64: Fix register corruption in top-most kernel stack frame
> during boot.
>
> - callstart_kernel
> + call start_early_boot
Maybe add a comment about stack use - as per your nice patch description.
> +void __init start_early_boot(void)
This will
From: David Miller
Date: Thu, 23 Oct 2014 13:02:58 -0400 (EDT)
> From: Meelis Roos
> Date: Thu, 23 Oct 2014 02:22:36 +0300 (EEST)
>
>>> Whilst I don't have access to my reproducer machine until tomorrow in
>>> order to test this myself, I wanted to toss this patch your way so you
>>> could get
From: Meelis Roos
Date: Thu, 23 Oct 2014 02:22:36 +0300 (EEST)
>> Whilst I don't have access to my reproducer machine until tomorrow in
>> order to test this myself, I wanted to toss this patch your way so you
>> could get a head start on me.
>
> Unfortunately it fails earlier during the boot:
From: Meelis Roos mr...@linux.ee
Date: Thu, 23 Oct 2014 02:22:36 +0300 (EEST)
Whilst I don't have access to my reproducer machine until tomorrow in
order to test this myself, I wanted to toss this patch your way so you
could get a head start on me.
Unfortunately it fails earlier during the
From: David Miller da...@davemloft.net
Date: Thu, 23 Oct 2014 13:02:58 -0400 (EDT)
From: Meelis Roos mr...@linux.ee
Date: Thu, 23 Oct 2014 02:22:36 +0300 (EEST)
Whilst I don't have access to my reproducer machine until tomorrow in
order to test this myself, I wanted to toss this patch your
A minor detail.
[PATCH] sparc64: Fix register corruption in top-most kernel stack frame
during boot.
- callstart_kernel
+ call start_early_boot
Maybe add a comment about stack use - as per your nice patch description.
+void __init start_early_boot(void)
This will likely
> Whilst I don't have access to my reproducer machine until tomorrow in
> order to test this myself, I wanted to toss this patch your way so you
> could get a head start on me.
Unfortunately it fails earlier during the boot:
[ 25.232318] clocksource: mult[5355] shift[24]
[ 25.288559]
From: David Miller
Date: Mon, 20 Oct 2014 14:57:46 -0400 (EDT)
> Just an update, I have an environment where I can perfectly reproduce
> this. I have a gcc-4.9 SVN built that compiles kernels which crash
> the same way it does for you.
>
> I'll let you know when I make more progress.
Whilst I
Whilst I don't have access to my reproducer machine until tomorrow in
order to test this myself, I wanted to toss this patch your way so you
could get a head start on me.
Unfortunately it fails earlier during the boot:
[ 25.232318] clocksource: mult[5355] shift[24]
[ 25.288559]
From: David Miller da...@davemloft.net
Date: Mon, 20 Oct 2014 14:57:46 -0400 (EDT)
Just an update, I have an environment where I can perfectly reproduce
this. I have a gcc-4.9 SVN built that compiles kernels which crash
the same way it does for you.
I'll let you know when I make more
From: Meelis Roos
Date: Sun, 19 Oct 2014 10:07:03 +0300 (EEST)
>> From: Meelis Roos
>> Date: Fri, 17 Oct 2014 00:38:20 +0300 (EEST)
>>
>> > arch/sparc/kernel/setup_64.c is the only culprit.
>> >
>> > Attached are 2 versions of the object file as of v3.17-rc1-22-g480cadc
>> > that I tested.
From: Meelis Roos mr...@linux.ee
Date: Sun, 19 Oct 2014 10:07:03 +0300 (EEST)
From: Meelis Roos mr...@linux.ee
Date: Fri, 17 Oct 2014 00:38:20 +0300 (EEST)
arch/sparc/kernel/setup_64.c is the only culprit.
Attached are 2 versions of the object file as of v3.17-rc1-22-g480cadc
that I
On Sun, Oct 19, 2014 at 01:27:37PM -0400, David Miller wrote:
> From: Sam Ravnborg
> Date: Sun, 19 Oct 2014 17:32:20 +0200
>
> > This part:
> >
> >> + __attribute__ ((aligned(64)));
> >
> > Could be written as __aligned(64)
>
> I'll try to remember to sweep this up in sparc-next,
From: Sam Ravnborg
Date: Sun, 19 Oct 2014 17:32:20 +0200
> This part:
>
>> +__attribute__ ((aligned(64)));
>
> Could be written as __aligned(64)
I'll try to remember to sweep this up in sparc-next, thanks Sam.
We probably use this long-hand form in a lot of other places in
the
From: Meelis Roos
Date: Sun, 19 Oct 2014 20:12:43 +0300 (EEST)
>> > > I don't want to define the array size of the fpregs save area
>> > > explicitly and thereby placing an artificial limit there.
>> >
>> > Nevermind, it seems we have a hard limit of 7 FPU save areas anyways.
>> >
>> > Meelis,
> > > I don't want to define the array size of the fpregs save area
> > > explicitly and thereby placing an artificial limit there.
> >
> > Nevermind, it seems we have a hard limit of 7 FPU save areas anyways.
> >
> > Meelis, please try this patch:
>
> Works fine with 3.17.0-09670-g0429fbc +
On Sat, Oct 18, 2014 at 02:23:35PM -0400, David Miller wrote:
> From: David Miller
> Date: Sat, 18 Oct 2014 13:59:07 -0400 (EDT)
>
> > I don't want to define the array size of the fpregs save area
> > explicitly and thereby placing an artificial limit there.
>
> Nevermind, it seems we have a
> > I don't want to define the array size of the fpregs save area
> > explicitly and thereby placing an artificial limit there.
>
> Nevermind, it seems we have a hard limit of 7 FPU save areas anyways.
>
> Meelis, please try this patch:
Works fine with 3.17.0-09670-g0429fbc + fault patch.
Will
> From: Meelis Roos
> Date: Fri, 17 Oct 2014 00:38:20 +0300 (EEST)
>
> > arch/sparc/kernel/setup_64.c is the only culprit.
> >
> > Attached are 2 versions of the object file as of v3.17-rc1-22-g480cadc
> > that I tested.
>
> Just to confirm, a gcc-4.9 compiled kernel works if just setup_64.c
From: Meelis Roos mr...@linux.ee
Date: Fri, 17 Oct 2014 00:38:20 +0300 (EEST)
arch/sparc/kernel/setup_64.c is the only culprit.
Attached are 2 versions of the object file as of v3.17-rc1-22-g480cadc
that I tested.
Just to confirm, a gcc-4.9 compiled kernel works if just setup_64.c
I don't want to define the array size of the fpregs save area
explicitly and thereby placing an artificial limit there.
Nevermind, it seems we have a hard limit of 7 FPU save areas anyways.
Meelis, please try this patch:
Works fine with 3.17.0-09670-g0429fbc + fault patch.
Will try
On Sat, Oct 18, 2014 at 02:23:35PM -0400, David Miller wrote:
From: David Miller da...@davemloft.net
Date: Sat, 18 Oct 2014 13:59:07 -0400 (EDT)
I don't want to define the array size of the fpregs save area
explicitly and thereby placing an artificial limit there.
Nevermind, it seems we
I don't want to define the array size of the fpregs save area
explicitly and thereby placing an artificial limit there.
Nevermind, it seems we have a hard limit of 7 FPU save areas anyways.
Meelis, please try this patch:
Works fine with 3.17.0-09670-g0429fbc + fault patch.
From: Meelis Roos mr...@linux.ee
Date: Sun, 19 Oct 2014 20:12:43 +0300 (EEST)
I don't want to define the array size of the fpregs save area
explicitly and thereby placing an artificial limit there.
Nevermind, it seems we have a hard limit of 7 FPU save areas anyways.
Meelis,
From: Sam Ravnborg s...@ravnborg.org
Date: Sun, 19 Oct 2014 17:32:20 +0200
This part:
+__attribute__ ((aligned(64)));
Could be written as __aligned(64)
I'll try to remember to sweep this up in sparc-next, thanks Sam.
We probably use this long-hand form in a lot of other
On Sun, Oct 19, 2014 at 01:27:37PM -0400, David Miller wrote:
From: Sam Ravnborg s...@ravnborg.org
Date: Sun, 19 Oct 2014 17:32:20 +0200
This part:
+ __attribute__ ((aligned(64)));
Could be written as __aligned(64)
I'll try to remember to sweep this up in sparc-next,
From: Meelis Roos
Date: Fri, 17 Oct 2014 00:38:20 +0300 (EEST)
> arch/sparc/kernel/setup_64.c is the only culprit.
>
> Attached are 2 versions of the object file as of v3.17-rc1-22-g480cadc
> that I tested.
Just to confirm, a gcc-4.9 compiled kernel works if just setup_64.c
is built with
From: David Miller
Date: Sat, 18 Oct 2014 13:59:07 -0400 (EDT)
> I don't want to define the array size of the fpregs save area
> explicitly and thereby placing an artificial limit there.
Nevermind, it seems we have a hard limit of 7 FPU save areas anyways.
Meelis, please try this patch:
diff
From: Meelis Roos
Date: Fri, 17 Oct 2014 14:12:09 +0300 (EEST)
> However, on top of mainline HEAD 3.17.0-09670-g0429fbc it explodes with
> scheduler BUG - just reported to LKML + sched maintainers.
task_stack_end_corrupted() cannot work properly on sparc64.
It stores the magic value at
From: Meelis Roos mr...@linux.ee
Date: Fri, 17 Oct 2014 14:12:09 +0300 (EEST)
However, on top of mainline HEAD 3.17.0-09670-g0429fbc it explodes with
scheduler BUG - just reported to LKML + sched maintainers.
task_stack_end_corrupted() cannot work properly on sparc64.
It stores the magic
From: David Miller da...@davemloft.net
Date: Sat, 18 Oct 2014 13:59:07 -0400 (EDT)
I don't want to define the array size of the fpregs save area
explicitly and thereby placing an artificial limit there.
Nevermind, it seems we have a hard limit of 7 FPU save areas anyways.
Meelis, please try
From: Meelis Roos mr...@linux.ee
Date: Fri, 17 Oct 2014 00:38:20 +0300 (EEST)
arch/sparc/kernel/setup_64.c is the only culprit.
Attached are 2 versions of the object file as of v3.17-rc1-22-g480cadc
that I tested.
Just to confirm, a gcc-4.9 compiled kernel works if just setup_64.c
is built
> From: David Miller
> Date: Thu, 16 Oct 2014 16:20:01 -0400 (EDT)
>
> > So I'm going to audit all the code paths to make sure we don't put garbage
> > into the fault_code value.
>
> There are two code paths where we can put garbage into the fault_code
> value. And for the dtlb_prot.S case,
From: David Miller da...@redhat.com
Date: Thu, 16 Oct 2014 16:20:01 -0400 (EDT)
So I'm going to audit all the code paths to make sure we don't put garbage
into the fault_code value.
There are two code paths where we can put garbage into the fault_code
value. And for the dtlb_prot.S
From: David Miller
Date: Thu, 16 Oct 2014 16:20:01 -0400 (EDT)
> So I'm going to audit all the code paths to make sure we don't put garbage
> into the fault_code value.
There are two code paths where we can put garbage into the fault_code
value. And for the dtlb_prot.S case, the value we put
> > I just reproduced this on my Sun Blade 2500, so it can trigger on
> > UltraSPARC-IIIi
> > systems too.
>
> I looked it up - V210 and V440 are also IIIi, not plain III. So I do not
> have information about real USIII, sorry for confusion.
Brr, I just understood I confused 2 problems with
> I just reproduced this on my Sun Blade 2500, so it can trigger on
> UltraSPARC-IIIi
> systems too.
I looked it up - V210 and V440 are also IIIi, not plain III. So I do not
have information about real USIII, sorry for confusion.
--
Meelis Roos (mr...@linux.ee)
--
To unsubscribe from this
From: Meelis Roos
Date: Thu, 16 Oct 2014 23:16:44 +0300 (EEST)
>> > scripts/Makefile.build:352: recipe for target 'sound/modules.order' failed
>> > make[1]: *** [sound/modules.order] Bus error
>> > make[1]: *** Deleting file 'sound/modules.order'
>> > Makefile:929: recipe for target 'sound'
From: Meelis Roos
Date: Thu, 16 Oct 2014 23:11:49 +0300 (EEST)
>> > Hopefully, this should be a simply matter of doing a complete build
>> > with gcc-4.9, then removing the object file we want to selectively
>> > build with the older compiler and then going:
>> >
>> >make CC="gcc-4.6"
> > scripts/Makefile.build:352: recipe for target 'sound/modules.order' failed
> > make[1]: *** [sound/modules.order] Bus error
> > make[1]: *** Deleting file 'sound/modules.order'
> > Makefile:929: recipe for target 'sound' failed
>
> I just reproduced this on my Sun Blade 2500, so it can
> > Hopefully, this should be a simply matter of doing a complete build
> > with gcc-4.9, then removing the object file we want to selectively
> > build with the older compiler and then going:
> >
> > make CC="gcc-4.6" arch/sparc/mm/init_64.o
> >
> > then relinking with plain 'make'.
> >
>
From: Meelis Roos
Date: Thu, 16 Oct 2014 10:02:57 +0300 (EEST)
> scripts/Makefile.build:352: recipe for target 'sound/modules.order' failed
> make[1]: *** [sound/modules.order] Bus error
> make[1]: *** Deleting file 'sound/modules.order'
> Makefile:929: recipe for target 'sound' failed
I just
> Do you happen to have both gcc-4.9 and a previously working compiler
> on these systems? If you do, we can build a kernel with gcc-4.9 and
> then selectively compile certain failes with the older working
> compiler to narrow down what compiles into something non-working with
> gcc-4.9
Yes, I
> >> > I'd like to know that your another problem is related to commit
> >> > bf0dea23a9c0 ("mm/slab: use percpu allocator for cpu cache"). So,
> >> > if the commit is reverted, your another problem is also gone
> >> > completely?
> >>
> >> The other problem has been present forever.
> >
> >
I'd like to know that your another problem is related to commit
bf0dea23a9c0 (mm/slab: use percpu allocator for cpu cache). So,
if the commit is reverted, your another problem is also gone
completely?
The other problem has been present forever.
Umm? I am afraid I have been
Do you happen to have both gcc-4.9 and a previously working compiler
on these systems? If you do, we can build a kernel with gcc-4.9 and
then selectively compile certain failes with the older working
compiler to narrow down what compiles into something non-working with
gcc-4.9
Yes, I kept
From: Meelis Roos mr...@linux.ee
Date: Thu, 16 Oct 2014 10:02:57 +0300 (EEST)
scripts/Makefile.build:352: recipe for target 'sound/modules.order' failed
make[1]: *** [sound/modules.order] Bus error
make[1]: *** Deleting file 'sound/modules.order'
Makefile:929: recipe for target 'sound' failed
Hopefully, this should be a simply matter of doing a complete build
with gcc-4.9, then removing the object file we want to selectively
build with the older compiler and then going:
make CC=gcc-4.6 arch/sparc/mm/init_64.o
then relinking with plain 'make'.
If the build
scripts/Makefile.build:352: recipe for target 'sound/modules.order' failed
make[1]: *** [sound/modules.order] Bus error
make[1]: *** Deleting file 'sound/modules.order'
Makefile:929: recipe for target 'sound' failed
I just reproduced this on my Sun Blade 2500, so it can trigger on
From: Meelis Roos mr...@linux.ee
Date: Thu, 16 Oct 2014 23:11:49 +0300 (EEST)
Hopefully, this should be a simply matter of doing a complete build
with gcc-4.9, then removing the object file we want to selectively
build with the older compiler and then going:
make CC=gcc-4.6
From: Meelis Roos mr...@linux.ee
Date: Thu, 16 Oct 2014 23:16:44 +0300 (EEST)
scripts/Makefile.build:352: recipe for target 'sound/modules.order' failed
make[1]: *** [sound/modules.order] Bus error
make[1]: *** Deleting file 'sound/modules.order'
Makefile:929: recipe for target 'sound'
I just reproduced this on my Sun Blade 2500, so it can trigger on
UltraSPARC-IIIi
systems too.
I looked it up - V210 and V440 are also IIIi, not plain III. So I do not
have information about real USIII, sorry for confusion.
--
Meelis Roos (mr...@linux.ee)
--
To unsubscribe from this list:
I just reproduced this on my Sun Blade 2500, so it can trigger on
UltraSPARC-IIIi
systems too.
I looked it up - V210 and V440 are also IIIi, not plain III. So I do not
have information about real USIII, sorry for confusion.
Brr, I just understood I confused 2 problems with the same
From: David Miller da...@redhat.com
Date: Thu, 16 Oct 2014 16:20:01 -0400 (EDT)
So I'm going to audit all the code paths to make sure we don't put garbage
into the fault_code value.
There are two code paths where we can put garbage into the fault_code
value. And for the dtlb_prot.S case, the
From: Meelis Roos
Date: Wed, 15 Oct 2014 23:11:34 +0300 (EEST)
>> >> The gcc-4.9 case is interesting, are you saying that a gcc-4.9 compiled
>> >> kernel works fine on other systems?
>> >
>> > Yes, all USII based systems work fine with Debian gcc-4.9, as does
>> > T2000. Of USIII* systems,
> >> The gcc-4.9 case is interesting, are you saying that a gcc-4.9 compiled
> >> kernel works fine on other systems?
> >
> > Yes, all USII based systems work fine with Debian gcc-4.9, as does
> > T2000. Of USIII* systems, V210 and V440 exhibit the boot hang with
> > gcc-4.9 and V480 crashes
From: Meelis Roos
Date: Wed, 15 Oct 2014 11:04:49 +0300 (EEST)
>> > My only other current sparc64 problems that I am seeing - V210/V440 die
>> > during bootup if compiled with gcc 4.9 and V480 dies with FATAL
>> > exceptions during bootups since previous kernel release. Maybe also
>> >
> > My only other current sparc64 problems that I am seeing - V210/V440 die
> > during bootup if compiled with gcc 4.9 and V480 dies with FATAL
> > exceptions during bootups since previous kernel release. Maybe also
> > exit_mmap warning - I do not know if they have been fixed, I see them
> >
My only other current sparc64 problems that I am seeing - V210/V440 die
during bootup if compiled with gcc 4.9 and V480 dies with FATAL
exceptions during bootups since previous kernel release. Maybe also
exit_mmap warning - I do not know if they have been fixed, I see them
rarely.
From: Meelis Roos mr...@linux.ee
Date: Wed, 15 Oct 2014 11:04:49 +0300 (EEST)
My only other current sparc64 problems that I am seeing - V210/V440 die
during bootup if compiled with gcc 4.9 and V480 dies with FATAL
exceptions during bootups since previous kernel release. Maybe also
The gcc-4.9 case is interesting, are you saying that a gcc-4.9 compiled
kernel works fine on other systems?
Yes, all USII based systems work fine with Debian gcc-4.9, as does
T2000. Of USIII* systems, V210 and V440 exhibit the boot hang with
gcc-4.9 and V480 crashes wit FATAL
From: Meelis Roos mr...@linux.ee
Date: Wed, 15 Oct 2014 23:11:34 +0300 (EEST)
The gcc-4.9 case is interesting, are you saying that a gcc-4.9 compiled
kernel works fine on other systems?
Yes, all USII based systems work fine with Debian gcc-4.9, as does
T2000. Of USIII* systems, V210
From: mr...@linux.ee
Date: Wed, 15 Oct 2014 00:19:36 +0300 (EEST)
>> > I'd like to know that your another problem is related to commit
>> > bf0dea23a9c0 ("mm/slab: use percpu allocator for cpu cache"). So,
>> > if the commit is reverted, your another problem is also gone
>> > completely?
>>
>>
> > I'd like to know that your another problem is related to commit
> > bf0dea23a9c0 ("mm/slab: use percpu allocator for cpu cache"). So,
> > if the commit is reverted, your another problem is also gone
> > completely?
>
> The other problem has been present forever.
Umm? I am afraid I have been
I'd like to know that your another problem is related to commit
bf0dea23a9c0 (mm/slab: use percpu allocator for cpu cache). So,
if the commit is reverted, your another problem is also gone
completely?
The other problem has been present forever.
Umm? I am afraid I have been describing
From: mr...@linux.ee
Date: Wed, 15 Oct 2014 00:19:36 +0300 (EEST)
I'd like to know that your another problem is related to commit
bf0dea23a9c0 (mm/slab: use percpu allocator for cpu cache). So,
if the commit is reverted, your another problem is also gone
completely?
The other problem
On Mon, Oct 13, 2014 at 08:04:16PM -0400, David Miller wrote:
> From: Joonsoo Kim
> Date: Tue, 14 Oct 2014 08:52:19 +0900
>
> > I'd like to know that your another problem is related to commit
> > bf0dea23a9c0 ("mm/slab: use percpu allocator for cpu cache"). So,
> > if the commit is reverted,
From: Joonsoo Kim
Date: Tue, 14 Oct 2014 08:52:19 +0900
> I'd like to know that your another problem is related to commit
> bf0dea23a9c0 ("mm/slab: use percpu allocator for cpu cache"). So,
> if the commit is reverted, your another problem is also gone
> completely?
The other problem has been
On Mon, Oct 13, 2014 at 11:22:37PM +0300, mr...@linux.ee wrote:
> > From: David Miller
> > Date: Sat, 11 Oct 2014 22:15:10 -0400 (EDT)
> >
> > >
> > > I'm getting tons of the following on sparc64:
> > >
> > > [603965.383447] Kernel unaligned access at TPC[546b58]
> > > free_block+0x98/0x1a0
>
> From: David Miller
> Date: Sat, 11 Oct 2014 22:15:10 -0400 (EDT)
>
> >
> > I'm getting tons of the following on sparc64:
> >
> > [603965.383447] Kernel unaligned access at TPC[546b58] free_block+0x98/0x1a0
> > [603965.396987] Kernel unaligned access at TPC[546b60] free_block+0xa0/0x1a0
> >
From: David Miller da...@davemloft.net
Date: Sat, 11 Oct 2014 22:15:10 -0400 (EDT)
I'm getting tons of the following on sparc64:
[603965.383447] Kernel unaligned access at TPC[546b58] free_block+0x98/0x1a0
[603965.396987] Kernel unaligned access at TPC[546b60] free_block+0xa0/0x1a0
On Mon, Oct 13, 2014 at 11:22:37PM +0300, mr...@linux.ee wrote:
From: David Miller da...@davemloft.net
Date: Sat, 11 Oct 2014 22:15:10 -0400 (EDT)
I'm getting tons of the following on sparc64:
[603965.383447] Kernel unaligned access at TPC[546b58]
free_block+0x98/0x1a0
From: Joonsoo Kim iamjoonsoo@lge.com
Date: Tue, 14 Oct 2014 08:52:19 +0900
I'd like to know that your another problem is related to commit
bf0dea23a9c0 (mm/slab: use percpu allocator for cpu cache). So,
if the commit is reverted, your another problem is also gone
completely?
The other
On Mon, Oct 13, 2014 at 08:04:16PM -0400, David Miller wrote:
From: Joonsoo Kim iamjoonsoo@lge.com
Date: Tue, 14 Oct 2014 08:52:19 +0900
I'd like to know that your another problem is related to commit
bf0dea23a9c0 (mm/slab: use percpu allocator for cpu cache). So,
if the commit is
2014-10-13 2:30 GMT+09:00 David Miller :
> From: Joonsoo Kim
> Date: Mon, 13 Oct 2014 02:22:15 +0900
>
>> Could you test below patch?
>> If it fixes your problem, I will send it with proper description.
>
> It works, I just tested using ARCH_KMALLOC_MINALIGN which would be
> better.
Oops. resend
From: Joonsoo Kim
Date: Mon, 13 Oct 2014 02:22:15 +0900
> Could you test below patch?
> If it fixes your problem, I will send it with proper description.
It works, I just tested using ARCH_KMALLOC_MINALIGN which would be
better.
--
To unsubscribe from this list: send the line "unsubscribe
2014-10-12 11:15 GMT+09:00 David Miller :
>
> I'm getting tons of the following on sparc64:
>
> [603965.383447] Kernel unaligned access at TPC[546b58] free_block+0x98/0x1a0
> [603965.396987] Kernel unaligned access at TPC[546b60] free_block+0xa0/0x1a0
> [603965.410523] Kernel unaligned access at
From: David Miller
Date: Sat, 11 Oct 2014 22:15:10 -0400 (EDT)
>
> I'm getting tons of the following on sparc64:
>
> [603965.383447] Kernel unaligned access at TPC[546b58] free_block+0x98/0x1a0
> [603965.396987] Kernel unaligned access at TPC[546b60] free_block+0xa0/0x1a0
> [603965.410523]
From: David Miller da...@davemloft.net
Date: Sat, 11 Oct 2014 22:15:10 -0400 (EDT)
I'm getting tons of the following on sparc64:
[603965.383447] Kernel unaligned access at TPC[546b58] free_block+0x98/0x1a0
[603965.396987] Kernel unaligned access at TPC[546b60] free_block+0xa0/0x1a0
2014-10-12 11:15 GMT+09:00 David Miller da...@davemloft.net:
I'm getting tons of the following on sparc64:
[603965.383447] Kernel unaligned access at TPC[546b58] free_block+0x98/0x1a0
[603965.396987] Kernel unaligned access at TPC[546b60] free_block+0xa0/0x1a0
[603965.410523] Kernel
From: Joonsoo Kim js1...@gmail.com
Date: Mon, 13 Oct 2014 02:22:15 +0900
Could you test below patch?
If it fixes your problem, I will send it with proper description.
It works, I just tested using ARCH_KMALLOC_MINALIGN which would be
better.
--
To unsubscribe from this list: send the line
2014-10-13 2:30 GMT+09:00 David Miller da...@davemloft.net:
From: Joonsoo Kim js1...@gmail.com
Date: Mon, 13 Oct 2014 02:22:15 +0900
Could you test below patch?
If it fixes your problem, I will send it with proper description.
It works, I just tested using ARCH_KMALLOC_MINALIGN which would
I'm getting tons of the following on sparc64:
[603965.383447] Kernel unaligned access at TPC[546b58] free_block+0x98/0x1a0
[603965.396987] Kernel unaligned access at TPC[546b60] free_block+0xa0/0x1a0
[603965.410523] Kernel unaligned access at TPC[546b58] free_block+0x98/0x1a0
[603965.424061]
I'm getting tons of the following on sparc64:
[603965.383447] Kernel unaligned access at TPC[546b58] free_block+0x98/0x1a0
[603965.396987] Kernel unaligned access at TPC[546b60] free_block+0xa0/0x1a0
[603965.410523] Kernel unaligned access at TPC[546b58] free_block+0x98/0x1a0
[603965.424061]
90 matches
Mail list logo
