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 patc
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 linux-kernel"
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 likel
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:
>
> 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] cloc
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
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.
>>
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, than
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 spa
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 + fau
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 har
> > 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
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 gcc-4
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 "task_t
> 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
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 in
> > 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
> 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
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' faile
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" arch/s
> > 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
> > 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 re
> 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 ke
> >> > 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
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, V210
> >> 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
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
>> > exit_mm
> > 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
> > r
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?
>>
>> T
> > 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
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, you
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 p
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
> > [6
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 linux-
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 TP
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] Kern
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] Kern
45 matches
Mail list logo
