<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/parisc, branch linux-4.13.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.13.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.13.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2017-10-27T08:39:09Z</updated>
<entry>
<title>parisc: Fix detection of nonsynchronous cr16 cycle counters</title>
<updated>2017-10-27T08:39:09Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2017-10-18T20:25:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d29babf5c2320f1e42fc4d343b3f369788696f23'/>
<id>urn:sha1:d29babf5c2320f1e42fc4d343b3f369788696f23</id>
<content type='text'>
commit 8642b31ba9eef8a01845146a26682d4869e62513 upstream.

For CPUs which have an unknown or invalid CPU location (physical location)
assume that their cycle counters aren't syncronized across CPUs.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Fixes: c8c3735997a3 ("parisc: Enhance detection of synchronous cr16 clocksources")
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>parisc: Fix double-word compare and exchange in LWS code on 32-bit kernels</title>
<updated>2017-10-27T08:39:09Z</updated>
<author>
<name>John David Anglin</name>
</author>
<published>2017-09-30T21:24:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f0889088d5fce357ce8ecfa3a094a94d57c545f0'/>
<id>urn:sha1:f0889088d5fce357ce8ecfa3a094a94d57c545f0</id>
<content type='text'>
commit 374b3bf8e8b519f61eb9775888074c6e46b3bf0c upstream.

As discussed on the debian-hppa list, double-wordcompare and exchange
operations fail on 32-bit kernels.  Looking at the code, I realized that
the ",ma" completer does the wrong thing in the  "ldw,ma  4(%r26), %r29"
instruction.  This increments %r26 and causes the following store to
write to the wrong location.

Note by Helge Deller:
The patch applies cleanly to stable kernel series if this upstream
commit is merged in advance:
f4125cfdb300 ("parisc: Avoid trashing sr2 and sr3 in LWS code").

Signed-off-by: John David Anglin &lt;dave.anglin@bell.net&gt;
Tested-by: Christoph Biedl &lt;debian.axhn@manchmal.in-ulm.de&gt;
Fixes: 89206491201c ("parisc: Implement new LWS CAS supporting 64 bit operations.")
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>parisc: Define CONFIG_CPU_BIG_ENDIAN</title>
<updated>2017-07-31T15:51:27Z</updated>
<author>
<name>Babu Moger</name>
</author>
<published>2017-07-06T16:34:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=74ad3d28af2104b92dd83a43add79e6a8c45d8e2'/>
<id>urn:sha1:74ad3d28af2104b92dd83a43add79e6a8c45d8e2</id>
<content type='text'>
While working on enabling queued rwlock on SPARC, found this following
code in include/asm-generic/qrwlock.h which uses CONFIG_CPU_BIG_ENDIAN
to clear a byte.

static inline u8 *__qrwlock_write_byte(struct qrwlock *lock)
 {
	return (u8 *)lock + 3 * IS_BUILTIN(CONFIG_CPU_BIG_ENDIAN);
 }

Problem is many of the fixed big endian architectures don't define
CPU_BIG_ENDIAN and clears the wrong byte.

Define CPU_BIG_ENDIAN for parisc architecture to fix it.

Signed-off-by: Babu Moger &lt;babu.moger@oracle.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
<entry>
<title>parisc: Increase thread and stack size to 32kb</title>
<updated>2017-07-31T06:41:26Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2017-07-31T06:38:27Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8f8201dfed91a43ac38c899c82f81eef3d36afd9'/>
<id>urn:sha1:8f8201dfed91a43ac38c899c82f81eef3d36afd9</id>
<content type='text'>
Since kernel 4.11 the thread and irq stacks on parisc randomly overflow
the default size of 16k. The reason why stack usage suddenly grew is yet
unknown.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Cc: stable@vger.kernel.org # 4.11+
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
<entry>
<title>parisc: Handle vma's whose context is not current in flush_cache_range</title>
<updated>2017-07-31T06:22:33Z</updated>
<author>
<name>John David Anglin</name>
</author>
<published>2017-07-30T20:20:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=13d57093c141db2036364d6be35e394fc5b64728'/>
<id>urn:sha1:13d57093c141db2036364d6be35e394fc5b64728</id>
<content type='text'>
In testing James' patch to drivers/parisc/pdc_stable.c, I hit the BUG
statement in flush_cache_range() during a system shutdown:

kernel BUG at arch/parisc/kernel/cache.c:595!
CPU: 2 PID: 6532 Comm: kworker/2:0 Not tainted 4.13.0-rc2+ #1
Workqueue: events free_ioctx

 IAOQ[0]: flush_cache_range+0x144/0x148
 IAOQ[1]: flush_cache_page+0x0/0x1a8
 RP(r2): flush_cache_range+0xec/0x148
Backtrace:
 [&lt;00000000402910ac&gt;] unmap_page_range+0x84/0x880
 [&lt;00000000402918f4&gt;] unmap_single_vma+0x4c/0x60
 [&lt;0000000040291a18&gt;] zap_page_range_single+0x110/0x160
 [&lt;0000000040291c34&gt;] unmap_mapping_range+0x174/0x1a8
 [&lt;000000004026ccd8&gt;] truncate_pagecache+0x50/0xa8
 [&lt;000000004026cd84&gt;] truncate_setsize+0x54/0x70
 [&lt;000000004033d534&gt;] put_aio_ring_file+0x44/0xb0
 [&lt;000000004033d5d8&gt;] aio_free_ring+0x38/0x140
 [&lt;000000004033d714&gt;] free_ioctx+0x34/0xa8
 [&lt;00000000401b0028&gt;] process_one_work+0x1b8/0x4d0
 [&lt;00000000401b04f4&gt;] worker_thread+0x1b4/0x648
 [&lt;00000000401b9128&gt;] kthread+0x1b0/0x208
 [&lt;0000000040150020&gt;] end_fault_vector+0x20/0x28
 [&lt;0000000040639518&gt;] nf_ip_reroute+0x50/0xa8
 [&lt;0000000040638ed0&gt;] nf_ip_route+0x10/0x78
 [&lt;0000000040638c90&gt;] xfrm4_mode_tunnel_input+0x180/0x1f8

CPU: 2 PID: 6532 Comm: kworker/2:0 Not tainted 4.13.0-rc2+ #1
Workqueue: events free_ioctx
Backtrace:
 [&lt;0000000040163bf0&gt;] show_stack+0x20/0x38
 [&lt;0000000040688480&gt;] dump_stack+0xa8/0x120
 [&lt;0000000040163dc4&gt;] die_if_kernel+0x19c/0x2b0
 [&lt;0000000040164d0c&gt;] handle_interruption+0xa24/0xa48

This patch modifies flush_cache_range() to handle non current contexts.
In as much as this occurs infrequently, the simplest approach is to
flush the entire cache when this happens.

Signed-off-by: John David Anglin &lt;dave.anglin@bell.net&gt;
Cc: stable@vger.kernel.org # 4.9+
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
<entry>
<title>parisc: Extend disabled preemption in copy_user_page</title>
<updated>2017-07-25T21:36:54Z</updated>
<author>
<name>John David Anglin</name>
</author>
<published>2017-07-25T21:23:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=56008c04ebc099940021b714da2d7779117cf6a7'/>
<id>urn:sha1:56008c04ebc099940021b714da2d7779117cf6a7</id>
<content type='text'>
It's always bothered me that we only disable preemption in
copy_user_page around the call to flush_dcache_page_asm.
This patch extends this to after the copy.

Signed-off-by: John David Anglin &lt;dave.anglin@bell.net&gt;
Cc: stable@vger.kernel.org # 4.9+
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
<entry>
<title>parisc: Prevent TLB speculation on flushed pages on CPUs that only support equivalent aliases</title>
<updated>2017-07-25T21:36:53Z</updated>
<author>
<name>John David Anglin</name>
</author>
<published>2017-07-25T21:11:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ae7a609c34b6fb12328c553b5f9aab26ae74a28e'/>
<id>urn:sha1:ae7a609c34b6fb12328c553b5f9aab26ae74a28e</id>
<content type='text'>
Helge noticed that we flush the TLB page in flush_cache_page but not in
flush_cache_range or flush_cache_mm.

For a long time, we have had random segmentation faults building
packages on machines with PA8800/8900 processors.  These machines only
support equivalent aliases.  We don't see these faults on machines that
don't require strict coherency.  So, it appears TLB speculation
sometimes leads to cache corruption on machines that require coherency.

This patch adds TLB flushes to flush_cache_range and flush_cache_mm when
coherency is required.  We only flush the TLB in flush_cache_page when
coherency is required.

The patch also optimizes flush_cache_range.  It turns out we always have
the right context to use flush_user_dcache_range_asm and
flush_user_icache_range_asm.

The patch has been tested for some time on rp3440, rp3410 and A500-44.
It's been boot tested on c8000.  No random segmentation faults were
observed during testing.

Signed-off-by: John David Anglin &lt;dave.anglin@bell.net&gt;
Cc: stable@vger.kernel.org # 4.9+
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
<entry>
<title>parisc: Suspend lockup detectors before system halt</title>
<updated>2017-07-25T19:43:38Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2017-07-25T19:41:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=56188832a50f09998cb570ba3771a1d25c193c0e'/>
<id>urn:sha1:56188832a50f09998cb570ba3771a1d25c193c0e</id>
<content type='text'>
Some machines can't power off the machine, so disable the lockup detectors to
avoid this watchdog BUG to show up every few seconds:
watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [systemd-shutdow:1]

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Cc: stable@vger.kernel.org # 4.9+
</content>
</entry>
<entry>
<title>parisc: Show DIMM slot number which holds broken memory module</title>
<updated>2017-07-25T19:43:10Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2017-07-25T18:12:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c46bafc4d2536a079455706cf31582b67192d5b7'/>
<id>urn:sha1:c46bafc4d2536a079455706cf31582b67192d5b7</id>
<content type='text'>
The Page Deallocation Table (PDT) holds the physical addresses of all broken
memory addresses. With the physical address we now are able to show which DIMM
slot (e.g. 1a, 3c) actually holds the broken memory module so that users are
able to replace it.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
<entry>
<title>parisc: Add function to return DIMM slot of physical address</title>
<updated>2017-07-25T17:28:37Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2017-07-25T17:26:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=25a9b76597fafbbf688dd4473cb910568deb2b0c'/>
<id>urn:sha1:25a9b76597fafbbf688dd4473cb910568deb2b0c</id>
<content type='text'>
Add a firmware wrapper function, which asks PDC firmware for the DIMM slot of a
physical address. This is needed to show users which DIMM module needs
replacement in case a broken DIMM was encountered.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
</feed>
