rror. We need
long branch stub support in 64-bit linker.
Dave
--
John David Anglin dave.ang...@bell.net
ach snprintf
>>hppa64-linux-ld: mm/hugetlb.o(.init.text+0x728): cannot reach printk
>>hppa64-linux-ld: mm/hugetlb.o(.init.text+0x744): cannot reach printk
>>hppa64-linux-ld: mm/hugetlb.o(.init.text+0x8d4): cannot reach
>> _raw_spin_lock
>>hppa64-linux-ld: mm/hugetlb.o(.init.text+0x900): cannot reach
>> _raw_spin_unlock
>>hppa64-linux-ld: mm/hugetlb.o(.init.text+0xa40): cannot reach printk
>>hppa64-linux-ld: mm/hugetlb.o(.init.text+0xa70): cannot reach
>> kobject_create_and_add
>>hppa64-linux-ld: mm/hugetlb.o(.init.text+0xb64): cannot reach
>> kobject_create_and_add
>>hppa64-linux-ld: mm/hugetlb.o(.init.text+0xb9c): cannot reach kobject_put
>>hppa64-linux-ld: mm/hugetlb.o(.init.text+0xbb4): cannot reach printk
>>hppa64-linux-ld: mm/hugetlb.o(.init.text+0xc84): cannot reach __muldi3
>>hppa64-linux-ld: mm/hugetlb.o(.init.text+0xde8): cannot reach memparse
>>hppa64-linux-ld: mm/hugetlb.o(.init.text+0xec0): cannot reach printk
>>hppa64-linux-ld: mm/hugetlb.o(.init.text+0xef0): cannot reach unknown
>>hppa64-linux-ld: mm/hugetlb.o(.init.text+0xf94): cannot reach memparse
>>hppa64-linux-ld: mm/hugetlb.o(.init.text+0xfcc): cannot reach printk
>>hppa64-linux-ld: mm/hugetlb.o(.init.text+0xfe4): cannot reach unknown
>>hppa64-linux-ld: mm/slab.o(.text+0x490): cannot reach __udivdi3
>>hppa64-linux-ld: mm/slab.o(.text+0x4ac): cannot reach __umoddi3
>>
>> ---
>> 0-DAY CI Kernel Test Service, Intel Corporation
>> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
>
>
--
John David Anglin dave.ang...@bell.net
On 2021-01-25 4:13 p.m., Helge Deller wrote:
> On 1/25/21 10:08 PM, John David Anglin wrote:
>> I would suggest the following for this hunk:
>>
>> + ldil L%intr_restore, %r2
>> + BL preempt_schedule_irq
>> + ldo R%intr_restore(%r2), %r2
>
t n
>> +def_bool y if !MODULES || UBSAN || FTRACE
>> +bool "Enable the -mlong-calls compiler option for big kernels" if
>> MODULES && !UBSAN && !FTRACE
>> depends on PA8X00
>> help
>> If you configure the kernel to include many drivers built-in instead
>> diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S
>> index beba9816cc6c..6320f6a8397c 100644
>> --- a/arch/parisc/kernel/entry.S
>> +++ b/arch/parisc/kernel/entry.S
>> @@ -997,10 +997,19 @@ intr_do_preempt:
>> bb,<,n %r20, 31 - PSW_SM_I, intr_restore
>> nop
>>
>> -BL preempt_schedule_irq, %r2
>> -nop
>> +/* ssm PSW_SM_I done later in intr_restore */
>> +#ifdef CONFIG_MLONGCALLS
>> +ldilL%intr_restore, %r2
>> +load32 preempt_schedule_irq, %r1
>> +bv %r0(%r1)
>> +ldo R%intr_restore(%r2), %r2
>> +#else
>> +ldilL%intr_restore, %r2
>> +BL preempt_schedule_irq
>> +ldo R%intr_restore(%r2), %r2
>> +#endif
>> +
>>
>> -b,n intr_restore/* ssm PSW_SM_I done by intr_restore */
>> #endif /* CONFIG_PREEMPTION */
>>
>> /*
>>
>>
--
John David Anglin dave.ang...@bell.net
150R in c3600.
However, it is similar
to the Adaptec 1210SA which works. Maybe they differ in RAID capability.
Dave
--
John David Anglin dave.ang...@bell.net
; Testing with pattern 0x55: done
> Reading and comparing: done
> Testing with pattern 0xff: done
> Reading and comparing: done
> Testing with pattern 0x00: done
> Reading and comparing: done
> Pass completed, 0 bad blocks found.
>
> no problems found
>
--
John David Anglin dave.ang...@bell.net
Hi,
On 2018-09-25 11:21 PM, Guenter Roeck wrote:
This patch causes my parisc qemu tests to fail.
Unfortunately I don't have any useful log output; the failure
is silent. Reverting the patch fixes the problem.
Can you be more specific on how to run these tests?
Dave
--
John David Anglin
Hi,
On 2018-09-25 11:21 PM, Guenter Roeck wrote:
This patch causes my parisc qemu tests to fail.
Unfortunately I don't have any useful log output; the failure
is silent. Reverting the patch fixes the problem.
Can you be more specific on how to run these tests?
Dave
--
John David Anglin
there was another source of
text labels
that need linker relocations.
Dave
--
John David Anglin dave.ang...@bell.net
there was another source of
text labels
that need linker relocations.
Dave
--
John David Anglin dave.ang...@bell.net
unwind code doesn't help.
Personally, I prefer the implementation of current_text_addr() because:
1) The generated code is smaller, and
2) it doesn't introduce any unnecessary labels into the text.
As noted, these labels can cause issues with unwinding.
Dave
--
John David Anglin dave.ang
unwind code doesn't help.
Personally, I prefer the implementation of current_text_addr() because:
1) The generated code is smaller, and
2) it doesn't introduce any unnecessary labels into the text.
As noted, these labels can cause issues with unwinding.
Dave
--
John David Anglin dave.ang
On 2018-08-01 6:18 PM, Nick Desaulniers wrote:
What about the uses in the fs support, etc?
Sorry, I don't see it?
I mean _THIS_IP_.
Dave
--
John David Anglin dave.ang...@bell.net
On 2018-08-01 6:18 PM, Nick Desaulniers wrote:
What about the uses in the fs support, etc?
Sorry, I don't see it?
I mean _THIS_IP_.
Dave
--
John David Anglin dave.ang...@bell.net
, etc?
Dave
--
John David Anglin dave.ang...@bell.net
, etc?
Dave
--
John David Anglin dave.ang...@bell.net
On 2018-08-01 4:52 PM, Nick Desaulniers wrote:
Dave, thanks for the quick review!
On Wed, Aug 1, 2018 at 1:10 PM John David Anglin wrote:
On 2018-08-01 2:22 PM, Nick Desaulniers wrote:
As part of the effort to reduce the code duplication between _THIS_IP_
and current_text_addr(), let's
On 2018-08-01 4:52 PM, Nick Desaulniers wrote:
Dave, thanks for the quick review!
On Wed, Aug 1, 2018 at 1:10 PM John David Anglin wrote:
On 2018-08-01 2:22 PM, Nick Desaulniers wrote:
As part of the effort to reduce the code duplication between _THIS_IP_
and current_text_addr(), let's
[2] = (unsigned long) __builtin_return_address(0);
+ r.iaoq[0] = _THIS_IP_;
+ r.gr[2] = _RET_IP_;
r.gr[30] = sp;
unwind_frame_init(, current, );
Dave
--
John David Anglin dave.ang...@bell.net
[2] = (unsigned long) __builtin_return_address(0);
+ r.iaoq[0] = _THIS_IP_;
+ r.gr[2] = _RET_IP_;
r.gr[30] = sp;
unwind_frame_init(, current, );
Dave
--
John David Anglin dave.ang...@bell.net
On 2018-07-02 9:09 PM, Michael Ellerman wrote:
It's GCC 4.6.3. Are you saying that's not supported anymore?
See <https://gcc.gnu.org/> for supported releases.
Dave
--
John David Anglin dave.ang...@bell.net
On 2018-07-02 9:09 PM, Michael Ellerman wrote:
It's GCC 4.6.3. Are you saying that's not supported anymore?
See <https://gcc.gnu.org/> for supported releases.
Dave
--
John David Anglin dave.ang...@bell.net
.
The sequence point after the argument evaluation for writel prevents the
compiler from reordering
1 and 2. Accesses to I/O space are strongly ordered on PA-RISC, so 1
must occur before 2 (Page G-1
of the PA-RISC 2.0 Architecture). Thus, the current code is okay.
Dave
--
John David Anglin dave.ang
.
The sequence point after the argument evaluation for writel prevents the
compiler from reordering
1 and 2. Accesses to I/O space are strongly ordered on PA-RISC, so 1
must occur before 2 (Page G-1
of the PA-RISC 2.0 Architecture). Thus, the current code is okay.
Dave
--
John David Anglin dave.ang
for either 32 or 64 bit mode */
#define F_EXTEND(x) ((unsigned long)((x) | (0xULL)))
+#include
#include
Still lots of problems.
Dave
--
John David Anglin dave.ang...@bell.net
CC arch/parisc/kernel/asm-offsets.s
In file included from ./arch/parisc/include/asm/io.h:262:0
for either 32 or 64 bit mode */
#define F_EXTEND(x) ((unsigned long)((x) | (0xULL)))
+#include
#include
Still lots of problems.
Dave
--
John David Anglin dave.ang...@bell.net
CC arch/parisc/kernel/asm-offsets.s
In file included from ./arch/parisc/include/asm/io.h:262:0
(gc->reg_base + reg_offset);
^
cc1: some warnings being treated as errors
make[1]: *** [Kbuild:58: arch/parisc/kernel/asm-offsets.s] Error 1
Dave
--
John David Anglin dave.ang...@bell.net
(gc->reg_base + reg_offset);
^
cc1: some warnings being treated as errors
make[1]: *** [Kbuild:58: arch/parisc/kernel/asm-offsets.s] Error 1
Dave
--
John David Anglin dave.ang...@bell.net
On 2017-07-18, at 11:21 AM, Guenter Roeck wrote:
> Hi,
>
> parisc64 builds, specifically generic-64bit_defconfig, fail to build
> in mainline as follows.
It's likely this patch fixes the problem:
https://patchwork.kernel.org/patch/9832033/
Dave
--
John David Anglin dave.ang...@bell.net
On 2017-07-18, at 11:21 AM, Guenter Roeck wrote:
> Hi,
>
> parisc64 builds, specifically generic-64bit_defconfig, fail to build
> in mainline as follows.
It's likely this patch fixes the problem:
https://patchwork.kernel.org/patch/9832033/
Dave
--
John David Anglin dave.ang...@bell.net
profiling
by default?
Dave
--
John David Anglin dave.ang...@bell.net
profiling
by default?
Dave
--
John David Anglin dave.ang...@bell.net
bit Kernel has started...
>>> Kernel default page size is 4 KB. Huge pages enabled with 1 MB physical and
>>> 2 MB virtual size.
The first thing I would suspect is the enabling of huge pages.
Dave
--
John David Anglin dave.ang...@bell.net
bit Kernel has started...
>>> Kernel default page size is 4 KB. Huge pages enabled with 1 MB physical and
>>> 2 MB virtual size.
The first thing I would suspect is the enabling of huge pages.
Dave
--
John David Anglin dave.ang...@bell.net
n't
happen?
No. If you look at the TLB handler, you will see that locking is not
done for misses in
kernel space. So, this deadlock doesn't occur.
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
n't
happen?
No. If you look at the TLB handler, you will see that locking is not
done for misses in
kernel space. So, this deadlock doesn't occur.
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
actually real...
See page 10 in this document:
https://parisc.wiki.kernel.org/images-parisc/e/e9/PA-8700wp.pdf
It shows the PA-8700 L1 design. James' comments and this paper are the
basis for this change.
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from th
. This
whole discussion started when I
suggested that we needed to bump L1_CACHE_BYTES to 128 bytes on PA8800 and
PA8900 processors.
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
actually real...
See page 10 in this document:
https://parisc.wiki.kernel.org/images-parisc/e/e9/PA-8700wp.pdf
It shows the PA-8700 L1 design. James' comments and this paper are the
basis for this change.
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from th
by firmware PDC calls. This
whole discussion started when I
suggested that we needed to bump L1_CACHE_BYTES to 128 bytes on PA8800 and
PA8900 processors.
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel
Faulting instruction is:
4021a11c: 0f 38 12 d0 std r24,8(r25)
Register r25 is misaligned by 1.
Dave
On 2015-07-14, at 7:52 AM, John David Anglin wrote:
> Sadly, it appears we are not out of the woods yet:
>
> mx3210 login: Backtrace:
> [<4021c904>] free_h
rwarded Message
> Subject: Re: [PATCH] parisc: mm: Fix a memory leak related to pmd not
> attached to the pgd
> Date: Mon, 13 Jul 2015 20:52:37 +0200
> From: Helge Deller
> To: Christophe JAILLET ,
> j...@parisc-linux.org, mpato...@redhat.com, kirill.shute...@linu
Faulting instruction is:
4021a11c: 0f 38 12 d0 std r24,8(r25)
Register r25 is misaligned by 1.
Dave
On 2015-07-14, at 7:52 AM, John David Anglin wrote:
Sadly, it appears we are not out of the woods yet:
mx3210 login: Backtrace:
[4021c904] free_hot_cold_page+0x234/0x250
...@redhat.com, kirill.shute...@linux.intel.com
CC: linux-par...@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-janit...@vger.kernel.org, John David Anglin dave.ang...@bell.net,
Meelis Roos mr...@linux.ee
Hi Christophe,
On 13.07.2015 11:32, Christophe JAILLET wrote:
Commit 0e0da48dee8d
d first revdep-rebuild after nontrivial emerge compilation loop kills
> the smaller box).
I've also had problems with 4.0. I had HPMC after a few hours on rp3440.
>
> 3.19 did not seem to have this problem.
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this l
nontrivial emerge compilation loop kills
the smaller box).
I've also had problems with 4.0. I had HPMC after a few hours on rp3440.
3.19 did not seem to have this problem.
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
change.
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
change.
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
/index.php/Technical_Documentation
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
P
/index.php/Technical_Documentation
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
t;fix".
Why not just remove "FIXME: " from these comments?
The wording of the comment is not good. You can't "trick" the
compiler into not
treating a constant as DP-relative data. Whether or not a constant is
loaded as an
immediate depends on its value.
Dave
--
John
FIXME: from these comments?
The wording of the comment is not good. You can't trick the
compiler into not
treating a constant as DP-relative data. Whether or not a constant is
loaded as an
immediate depends on its value.
Dave
--
John David Anglin dave.ang...@bell.net
quot;.
Why not just remove "FIXME: " from these comments?
Dave
--
John David Anglindave.ang...@bell.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ke
FIXME: from these comments?
Dave
--
John David Anglindave.ang...@bell.net
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
cant bits are in r25
and the least significant bits in r26..
In GCC, we typically have an odd even register pair to hold 64-bit
values as register
r0 is not usable.
The rules are different for float values.
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this
bits are in r25
and the least significant bits in r26..
In GCC, we typically have an odd even register pair to hold 64-bit
values as register
r0 is not usable.
The rules are different for float values.
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list
On 6/2/2014 10:02 AM, Mikulas Patocka wrote:
On Mon, 2 Jun 2014, Mikulas Patocka wrote:
On Sun, 1 Jun 2014, John David Anglin wrote:
On 1-Jun-14, at 3:20 PM, Peter Zijlstra wrote:
If you write to some variable with ACCESS_ONCE and use cmpxchg or xchg at
the same time, you break
On 6/2/2014 10:02 AM, Mikulas Patocka wrote:
On Mon, 2 Jun 2014, Mikulas Patocka wrote:
On Sun, 1 Jun 2014, John David Anglin wrote:
On 1-Jun-14, at 3:20 PM, Peter Zijlstra wrote:
If you write to some variable with ACCESS_ONCE and use cmpxchg or xchg at
the same time, you break
that the lock
must be released with a cmpxchg operation and not a simple write on
SMP systems.
There is a race in the cache operations or instruction ordering that's
not present with
the ldcw instruction.
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send
that the lock
must be released with a cmpxchg operation and not a simple write on
SMP systems.
There is a race in the cache operations or instruction ordering that's
not present with
the ldcw instruction.
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send
...@vger.kernel.org
Cc: John David Anglin
I tested this version of the patch last night on 3.14.2. I can
confirm that an 80MB region is reserved for stack at the expected
location in virtual memory with the default config setting. GCC
and many other packages have built successfully with this setting
successfully with this setting.
Tested-by: John David Anglin dave.ang...@bell.net
---
Dave
--
John David Anglindave.ang...@bell.net
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On 30-Apr-14, at 5:26 PM, Helge Deller wrote:
+ processes when the stack grows upwards (currently only on parisc
and matag
"metag" is mispelled.
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
On 30-Apr-14, at 5:26 PM, Helge Deller wrote:
+ processes when the stack grows upwards (currently only on parisc
and matag
metag is mispelled.
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On 4-Jan-14, at 2:55 PM, Mikulas Patocka wrote:
On Sat, 4 Jan 2014, John David Anglin wrote:
On 4-Jan-14, at 12:45 PM, Mikulas Patocka wrote:
* flush_dcache_page asks for the list of userspace mappings,
however that
page->mapping field is reused by the slab subsystem for a differ
ion of
flush_dcache_page()
should return if "!mapping || mapping != page->mapping" is true. This
would
have avoided crash.
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
of
flush_dcache_page()
should return if !mapping || mapping != page-mapping is true. This
would
have avoided crash.
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
On 4-Jan-14, at 2:55 PM, Mikulas Patocka wrote:
On Sat, 4 Jan 2014, John David Anglin wrote:
On 4-Jan-14, at 12:45 PM, Mikulas Patocka wrote:
* flush_dcache_page asks for the list of userspace mappings,
however that
page-mapping field is reused by the slab subsystem for a different
want that.
2) It seems to unnecessarily call flush_kernel_dcache_page().
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
() and copy_user_page()
aren't needed.
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please re
() and copy_user_page()
aren't needed.
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
. I don't think we want that.
2) It seems to unnecessarily call flush_kernel_dcache_page().
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
On 16-Nov-13, at 5:37 PM, James Bottomley wrote:
On Sat, 2013-11-16 at 17:32 -0500, John David Anglin wrote:
On 16-Nov-13, at 5:06 PM, James Bottomley wrote:
On Sat, 2013-11-16 at 21:07 +0100, Simon Baatz wrote:
On Fri, Nov 15, 2013 at 02:42:05PM -0800, James Bottomley wrote:
On Fri, 2013
().
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
().
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 16-Nov-13, at 5:37 PM, James Bottomley wrote:
On Sat, 2013-11-16 at 17:32 -0500, John David Anglin wrote:
On 16-Nov-13, at 5:06 PM, James Bottomley wrote:
On Sat, 2013-11-16 at 21:07 +0100, Simon Baatz wrote:
On Fri, Nov 15, 2013 at 02:42:05PM -0800, James Bottomley wrote:
On Fri, 2013
fixup_exception(regs))
+ return;
fault_address = regs->ior;
fault_space = regs->isr;
break;
With this change, boot on rp3440 hangs here:
Freeing unused kernel memory: 256K (4079c000 - 407dc000)
Loading, please
t_address = regs->ior;
fault_space = regs->isr;
break;
--
To unsubscribe from this list: send the line "unsubscribe linux-
parisc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
;
fault_space = regs-isr;
break;
--
To unsubscribe from this list: send the line unsubscribe linux-
parisc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
John David Anglin dave.ang
))
+ return;
fault_address = regs-ior;
fault_space = regs-isr;
break;
With this change, boot on rp3440 hangs here:
Freeing unused kernel memory: 256K (4079c000 - 407dc000)
Loading, please wait...
Dave
--
John David Anglin
nclude/asm/cacheflush.h.
There are a bunch
of callers in mm. The interface in documented in
Documentation/cachetlb.txt. We currently
use it in copy_to_user_page and copy_from_user_page.
Dave
--
John David Anglindave.ang...@bell.net
--
To unsubscribe from this list: send the line "un
/include/asm/cacheflush.h.
There are a bunch
of callers in mm. The interface in documented in
Documentation/cachetlb.txt. We currently
use it in copy_to_user_page and copy_from_user_page.
Dave
--
John David Anglindave.ang...@bell.net
--
To unsubscribe from this list: send the line
On 6-Apr-13, at 9:22 PM, James Bottomley wrote:
John David Anglin wrote:
On 6-Apr-13, at 6:52 AM, James Bottomley wrote:
On Sat, 2013-04-06 at 15:22 +1030, Rusty Russell wrote:
The problem is our assumption that section names be unique. This
assumption is wrong. The ELF spec says
e really need is a way
to ensure we can insert ELF stubs every 128k).
There is now a config work around for this. See:
http://www.spinics.net/lists/linux-parisc/msg04521.html
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line "unsubs
is a way
to ensure we can insert ELF stubs every 128k).
There is now a config work around for this. See:
http://www.spinics.net/lists/linux-parisc/msg04521.html
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On 6-Apr-13, at 9:22 PM, James Bottomley wrote:
John David Anglin dave.ang...@bell.net wrote:
On 6-Apr-13, at 6:52 AM, James Bottomley wrote:
On Sat, 2013-04-06 at 15:22 +1030, Rusty Russell wrote:
The problem is our assumption that section names be unique. This
assumption is wrong
On 28-Sep-12, at 9:43 AM, James Bottomley wrote:
On Tue, 2012-09-25 at 19:23 -0400, John David Anglin wrote:
On 24-Sep-12, at 8:39 AM, Denys Vlasenko wrote:
Maybe it needs to be removed?
Worked for me with 3.5.4.
It's probably time to tidy up all of our asm-generic code and use
On 28-Sep-12, at 9:43 AM, James Bottomley wrote:
On Tue, 2012-09-25 at 19:23 -0400, John David Anglin wrote:
On 24-Sep-12, at 8:39 AM, Denys Vlasenko wrote:
Maybe it needs to be removed?
Worked for me with 3.5.4.
It's probably time to tidy up all of our asm-generic code and use
On 24-Sep-12, at 8:39 AM, Denys Vlasenko wrote:
Maybe it needs to be removed?
Worked for me with 3.5.4.
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.
On 24-Sep-12, at 8:39 AM, Denys Vlasenko wrote:
Maybe it needs to be removed?
Worked for me with 3.5.4.
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
();
schedule_preempt_disabled();
check_pgt_cache();
}
Builds and boots fine on parisc.
Acked-by: John David Anglin
Dave
--
John David Anglindave.ang...@bell.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
();
check_pgt_cache();
}
Builds and boots fine on parisc.
Acked-by: John David Anglindave.ang...@bell.net
Dave
--
John David Anglindave.ang...@bell.net
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
collecting Alpha
patches to send on to Linus so will include this one.
A similar change applied to 3.5.1 stable compiles successfully
on parisc.
Regards,
Dave
--
John David Anglin dave.ang...@bell.net
diff --git a/arch/parisc/include/asm/atomic.h b/arch/parisc/include/asm/atomic.h
index
compiles correctly. I'm currently collecting Alpha
patches to send on to Linus so will include this one.
A similar change applied to 3.5.1 stable compiles successfully
on parisc.
Regards,
Dave
--
John David Anglin dave.ang...@bell.net
diff --git a/arch/parisc/include/asm/atomic.h b/arch
On 8/7/2012 2:41 PM, Mikulas Patocka wrote:
Which restart patch do you mean?
http://www.spinics.net/lists/linux-parisc/msg04229.html
Dave
--
John David Anglindave.ang...@bell.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On 8/7/2012 2:41 PM, Mikulas Patocka wrote:
Which restart patch do you mean?
http://www.spinics.net/lists/linux-parisc/msg04229.html
Dave
--
John David Anglindave.ang...@bell.net
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
a constant expression.
Test case:
typedef struct { long enabled; } atomic_t;
struct static_key { atomic_t enabled; int x; };
struct static_key memalloc_socks = ((struct static_key) { .enabled =
((atomic_t) { (0) }) });
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubs
expression.
Test case:
typedef struct { long enabled; } atomic_t;
struct static_key { atomic_t enabled; int x; };
struct static_key memalloc_socks = ((struct static_key) { .enabled =
((atomic_t) { (0) }) });
Dave
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list
rnel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vg
to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
John David Anglin dave.ang...@bell.net
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
1 - 100 of 106 matches
Mail list logo
