stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	stable@vger.kernel.org, Helge Deller <deller@gmx.de>,
	John David Anglin <dave.anglin@bell.net>
Subject: [PATCH 3.4 13/26] parisc: Do not crash 64bit SMP kernels on machines with >= 4GB RAM
Date: Fri,  8 Nov 2013 22:51:42 -0800	[thread overview]
Message-ID: <20131109065051.142853176@linuxfoundation.org> (raw)
In-Reply-To: <20131109065050.089866597@linuxfoundation.org>

3.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Helge Deller <deller@gmx.de>

commit 54e181e073fc1415e41917d725ebdbd7de956455 upstream.

Since the beginning of the parisc-linux port, sometimes 64bit SMP kernels were
not able to bring up other CPUs than the monarch CPU and instead crashed the
kernel.  The reason was unclear, esp. since it involved various machines (e.g.
J5600, J6750 and SuperDome). Testing showed, that those crashes didn't happened
when less than 4GB were installed, or if a 32bit Linux kernel was booted.

In the end, the fix for those SMP problems is trivial:
During the early phase of the initialization of the CPUs, including the monarch
CPU, the PDC_PSW firmware function to enable WIDE (=64bit) mode is called.
It's documented that this firmware function may clobber various registers, and
one one of those possibly clobbered registers is %cr30 which holds the task
thread info pointer.

Now, if %cr30 would always have been clobbered, then this bug would have been
detected much earlier. But lots of testing finally showed, that - at least for
%cr30 - on some machines only the upper 32bits of the 64bit register suddenly
turned zero after the firmware call.

So, after finding the root cause, the explanation for the various crashes
became clear:
- On 32bit SMP Linux kernels all upper 32bit were zero, so we didn't faced this
  problem.
- Monarch CPUs in 64bit mode always booted sucessfully, because the inital task
  thread info pointer was below 4GB.
- Secondary CPUs booted sucessfully on machines with less than 4GB RAM because
  the upper 32bit were zero anyay.
- Secondary CPus failed to boot if we had more than 4GB RAM and the task thread
  info pointer was located above the 4GB boundary.

Finally, the patch to fix this problem is trivial by saving the %cr30 register
before the firmware call and restoring it afterwards.

Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/parisc/kernel/head.S |    4 ++++
 1 file changed, 4 insertions(+)

--- a/arch/parisc/kernel/head.S
+++ b/arch/parisc/kernel/head.S
@@ -195,6 +195,8 @@ common_stext:
 	ldw             MEM_PDC_HI(%r0),%r6
 	depd            %r6, 31, 32, %r3        /* move to upper word */
 
+	mfctl		%cr30,%r6		/* PCX-W2 firmware bug */
+
 	ldo             PDC_PSW(%r0),%arg0              /* 21 */
 	ldo             PDC_PSW_SET_DEFAULTS(%r0),%arg1 /* 2 */
 	ldo             PDC_PSW_WIDE_BIT(%r0),%arg2     /* 2 */
@@ -203,6 +205,8 @@ common_stext:
 	copy            %r0,%arg3
 
 stext_pdc_ret:
+	mtctl		%r6,%cr30		/* restore task thread info */
+
 	/* restore rfi target address*/
 	ldd             TI_TASK-THREAD_SZ_ALGN(%sp), %r10
 	tophys_r1       %r10



  parent reply	other threads:[~2013-11-09  6:51 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-09  6:51 [PATCH 3.4 00/26] 3.4.69-stable review Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 01/26] USB: support new huawei devices in option.c Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 02/26] USB: quirks.c: add one device that cannot deal with suspension Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 03/26] USB: quirks: add touchscreen that is dazzeled by remote wakeup Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 04/26] USB: serial: ftdi_sio: add id for Z3X Box device Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 05/26] mac80211: correctly close cancelled scans Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 06/26] mac80211: update sta->last_rx on acked tx frames Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 07/26] rtlwifi: rtl8192cu: Fix error in pointer arithmetic Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 08/26] jfs: fix error path in ialloc Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 09/26] can: flexcan: flexcan_chip_start: fix regression, mark one MB for TX and abort pending TX Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 10/26] libata: make ata_eh_qc_retry() bump scmd->allowed on bogus failures Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 11/26] md: Fix skipping recovery for read-only arrays Greg Kroah-Hartman
2013-11-17  4:11   ` Ben Hutchings
2013-11-17  7:20     ` NeilBrown
2013-11-09  6:51 ` [PATCH 3.4 12/26] clockevents: Sanitize ticks to nsec conversion Greg Kroah-Hartman
2013-11-09  6:51 ` Greg Kroah-Hartman [this message]
2013-11-09  6:51 ` [PATCH 3.4 14/26] ALSA: hda - Add a fixup for ASUS N76VZ Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 15/26] ALSA: fix oops in snd_pcm_info() caused by ASoC DPCM Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 16/26] ASoC: wm_hubs: Add missing break in hp_supply_event() Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 17/26] ASoC: dapm: Fix source list debugfs outputs Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 18/26] staging: ozwpan: prevent overflow in oz_cdev_write() Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 19/26] Staging: bcm: info leak in ioctl Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 20/26] uml: check length in exitcode_proc_write() Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 21/26] xtensa: dont use alternate signal stack on threads Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 22/26] lib/scatterlist.c: dont flush_kernel_dcache_page on slab page Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 23/26] aacraid: missing capable() check in compat ioctl Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 24/26] mm: fix aio performance regression for database caused by THP Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 25/26] drm: Prevent overwriting from userspace underallocating core ioctl structs Greg Kroah-Hartman
2013-11-09  6:51 ` [PATCH 3.4 26/26] drm/radeon/atom: workaround vbios bug in transmitter table on rs780 Greg Kroah-Hartman
2013-11-09 14:24 ` [PATCH 3.4 00/26] 3.4.69-stable review Satoru Takeuchi
2013-11-09 16:19   ` Greg Kroah-Hartman
2013-11-09 16:58 ` Guenter Roeck
2013-11-09 17:12   ` Greg Kroah-Hartman
2013-11-11 17:58 ` Shuah Khan
2013-11-11 22:51   ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131109065051.142853176@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=dave.anglin@bell.net \
    --cc=deller@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).