> James Bottomley wrote:
> > On Mon, 2008-02-11 at 17:23 +0100, Roel Kluin wrote:
> >> duplicate pa11_dma_alloc_consistent; more appropriate appears
> >> pa11_dma_alloc_noncoherent here.
> >>
> >> Not tested, please confirm that this fix is correct
> >
> > No, it looks completely incorrect to me.
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.
))
+ return;
fault_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 majordom
if (!user_mode(regs) && 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 (0000
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
e's something else we could do (all we 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
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
_idle_exit();
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&qu
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
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/parisc/include/asm/atom
bscribe 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...@bell.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
s in 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
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 us
> The 32bit and 64bit PARISC Linux kernels suffers from the problem, that the
> gettimeofday() call sometimes returns non-monotonic times.
This certainly needs to be fixed. I see stuff like this from ping:
64 bytes from 132.246.100.193: icmp_seq=19 ttl=255 time=0.4 ms
64 bytes from 132.246.100.
> The parisc point intentionally switched to "extern inline" at one
> point and unless what jda wrote is now incorrect, I'm not inclined
> to change it.
The handling of "extern inline" is changing in GCC 4.3 to the C99 specified
behavior. The attribute gnu_inline on an inline declaration results
current_text_addr() to the parisc 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 unw
ized there was another source of
text labels
that need linker relocations.
Dave
--
John David Anglin dave.ang...@bell.net
;
- r.gr[2] = (unsigned long) __builtin_return_address(0);
+ r.iaoq[0] = _THIS_IP_;
+ r.gr[2] = _RET_IP_;
r.gr[30] = sp;
unwind_frame_init(&info, current, &r);
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&#
fs support, etc?
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
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 A
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
/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
; (and 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 f
on
error. We need
long branch stub support in 64-bit linker.
Dave
--
John David Anglin dave.ang...@bell.net
ot reach 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
default 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
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
>
;fix".
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.k
e later on.
There is nothing you could try to "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
loade
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
ux-me...@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 se
gnificant 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
recently 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
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 it
's as we do in in flush_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 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
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
Plea
be deferred. 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...
ation 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
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
gh that this can'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 linu
x27;t have a working 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/
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" in
the body of a messa
t; but if it is 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
aring: done
> 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
SD-SATA150R 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
or=implicit-function-declaration]
return readl(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
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
.
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 dav
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
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_h
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
56 matches
Mail list logo
