lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 09 Jun 2015 08:43:28 -0700
From:	Kevin Hilman <khilman@...nel.org>
To:	Peter Griffin <peter.griffin@...aro.org>
Cc:	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	srinivas.kandagatla@...il.com, patrice.chotard@...com,
	maxime.coquelin@...com, arnd@...db.de, olof@...om.net,
	lee.jones@...aro.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 0/3] Add code to release secondary cores from holding pen.

Peter Griffin <peter.griffin@...aro.org> writes:

> Hi Maxime, Patrice, Srini, Kevin, Olof & Arnd,
>
> This patchset adds in the necessary code to manage the holding pen for STi
> platforms.
>
> Due to all the STi upstream devs using JTAG to boot the STi boards, there
> is currently a SMP bug when booting upstream kernels via u-boot where
> only the primary core is brought up.
>
> This hasn't been noticed until now because when booting via JTAG the
> stlinux_arm_boot script sets the PC of the secondary cores directly.
>
> With these patches applied booting via u-boot now works correctly.
>
> [    0.045456] CPU: Testing write buffer coherency: ok
> [    0.045597] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> [    0.045734] Setting up static identity map for 0x40209000 - 0x40209098
> [    0.065047] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
> [    0.065081] Brought up 2 CPUs
> [    0.065089] SMP: Total of 2 processors activated (5983.43 BogoMIPS).
> [    0.065092] CPU: All CPU(s) started in SVC mode.
>
> Kevin / Olof / Arnd - Can you put this fix into the next ARM SoC fixes pull
> request (if there is one)?

At this stage of the cycle (we're already at -rc7) we limit things to
strictly regression fixes, and seems this has been broken for some time,
so I think this will have to wait for v4.2.

After addresing the comments, Maxime should queue this up for arm-soc so
we can get it in early in the v4.2-rc cycle.

Kevin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ