linux-kernel - New P2020-based board (mpc85xx) gets "Processor 1 is stuck" on 2.6.34, not on 2.6.32

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-next>] [day] [month] [year] [list]

Date:	Thu, 24 Jun 2010 23:32:22 -0400
From:	Kyle Moffett <kyle@...fetthome.net>
To:	linux-kernel@...r.kernel.org, linuxppc-dev@...ts.linuxppc.org
Subject: New P2020-based board (mpc85xx) gets "Processor 1 is stuck" on 
	2.6.34, not on 2.6.32

Hello,

I'm working on a new board port for a P2020-based board, and I'm
having problems with my second core not starting up on 2.6.34, even
though it starts up fine on 2.6.32.

In adding various debugs to mpc85xx_kick_cpu(), it looks like the
virtual address is detected as 0x7ffff280 on both, and it seems to
ioremap it to the same address.  Furthermore, both of them get the
"ack" from the other CPU almost immediately (within 1ms).
Unfortunately, after that the second core fails to rendezvous
elsewhere in the SMP code and as a result I get "Processor 1 is
stuck".

Unfortunately I've had no luck looking through "git log
v2.6.32..v2.6.34 -- arch/powerpc/" by hand, and there are enough
mechanical merge conflicts with my patchset to make "bisection" very
painful (IE: git bisect, git cherry-pick, test, git reset --hard
HEAD^, repeat)

Any additional suggestions on where to look would be much appreciated.

Cheers,
Kyle Moffett
--
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/