<feed xmlns='http://www.w3.org/2005/Atom'>
<title>talos-skiboot/core/stack.c, branch master</title>
<subtitle>Talos™ II skiboot sources</subtitle>
<id>https://git.raptorcs.com/git/talos-skiboot/atom?h=master</id>
<link rel='self' href='https://git.raptorcs.com/git/talos-skiboot/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-skiboot/'/>
<updated>2018-04-19T01:23:07+00:00</updated>
<entry>
<title>core/opal: Emergency stack for re-entry</title>
<updated>2018-04-19T01:23:07+00:00</updated>
<author>
<name>Nicholas Piggin</name>
<email>npiggin@gmail.com</email>
</author>
<published>2018-04-08T06:49:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-skiboot/commit/?id=3fdd2629516dd8be2b52a3a13e7ef5713411c7bf'/>
<id>urn:sha1:3fdd2629516dd8be2b52a3a13e7ef5713411c7bf</id>
<content type='text'>
This detects OPAL being re-entered by the OS, and switches to an
emergency stack if it was. This protects the firmware's main stack
from re-entrancy and allows the OS to use NMI facilities for crash
/ debug functionality.

Further nested re-entry will destroy the previous emergency stack
and prevent returning, but those should be rare cases.

This stack is sized at 16kB, which doubles the size of CPU stacks,
so as not to introduce a regression in primary stack size. The 16kB
stack originally had a 4kB machine check stack at the top, which was
removed by 80eee1946 ("opal: Remove machine check interrupt patching
in OPAL."). So it is possible the size could be tightened again, but
that would require further analysis.

Signed-off-by: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Signed-off-by: Stewart Smith &lt;stewart@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>core/stack: backtrace unwind basic OPAL call details</title>
<updated>2018-04-19T01:23:07+00:00</updated>
<author>
<name>Nicholas Piggin</name>
<email>npiggin@gmail.com</email>
</author>
<published>2018-04-08T06:49:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-skiboot/commit/?id=ad0941960bd045644f6834d6e711bedbde3c29c8'/>
<id>urn:sha1:ad0941960bd045644f6834d6e711bedbde3c29c8</id>
<content type='text'>
Put OPAL callers' r1 into the stack back chain, and then use that to
unwind back to the OPAL entry frame (as opposed to boot entry, which
has a 0 back chain).

&gt;From there, dump the OPAL call token and the caller's r1. A backtrace
looks like this:

  CPU 0000 Backtrace:
   S: 0000000031c03ba0 R: 000000003001a548   ._abort+0x4c
   S: 0000000031c03c20 R: 000000003001baac   .opal_run_pollers+0x3c
   S: 0000000031c03ca0 R: 000000003001bcbc   .opal_poll_events+0xc4
   S: 0000000031c03d20 R: 00000000300051dc   opal_entry+0x12c
   --- OPAL call entry token: 0xa caller R1: 0xc0000000006d3b90 ---

This is pretty basic for the moment, but it does give you the bottom
of the Linux stack. It will allow some interesting improvements in
future.

First, with the eframe, all the call's parameters can be printed out
as well.  The ___backtrace / ___print_backtrace API needs to be
reworked in order to support this, but it's otherwise very simple
(see opal_trace_entry()).

Second, it will allow Linux's stack to be passed back to Linux via
a debugging opal call. This will allow Linux's BUG() or xmon to
also print the Linux back trace in case of a NMI or MCE or watchdog
lockup that hits in OPAL.

Signed-off-by: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Signed-off-by: Stewart Smith &lt;stewart@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>core/utils: add snprintf_symbol</title>
<updated>2018-02-09T00:21:42+00:00</updated>
<author>
<name>Nicholas Piggin</name>
<email>npiggin@gmail.com</email>
</author>
<published>2018-02-02T05:34:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-skiboot/commit/?id=3a7422851bc345971773c4d22881199b7911da33'/>
<id>urn:sha1:3a7422851bc345971773c4d22881199b7911da33</id>
<content type='text'>
get_symbol is difficult to use. Add snprintf_symbol helper which
prints a symbol into a buffer with length, and returns the number
of bytes used, similarly to snprintf. Use this in the stack dumping
code rather than open-coding it.

Signed-off-by: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Signed-off-by: Stewart Smith &lt;stewart@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>lock: Add additional lock auditing code</title>
<updated>2017-12-21T04:15:36+00:00</updated>
<author>
<name>Benjamin Herrenschmidt</name>
<email>benh@kernel.crashing.org</email>
</author>
<published>2017-12-20T02:16:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-skiboot/commit/?id=76d9bcdca58936d761458f8f05960239c4dd8dec'/>
<id>urn:sha1:76d9bcdca58936d761458f8f05960239c4dd8dec</id>
<content type='text'>
Keep track of lock owner name and replace lock_depth counter
with a per-cpu list of locks held by the cpu.

This allows us to print the actual locks held in case we hit
the (in)famous message about opal_pollers being run with a
lock held.

It also allows us to warn (and drop them) if locks are still
held when returning to the OS or completing a scheduled job.

Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Reviewed-by: Nicholas Piggin &lt;npiggin@gmail.com&gt;
[stewart: fix unit tests]
Signed-off-by: Stewart Smith &lt;stewart@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>core/backtrace: Serialise printing backtraces</title>
<updated>2017-07-25T05:05:07+00:00</updated>
<author>
<name>Oliver O'Halloran</name>
<email>oohall@gmail.com</email>
</author>
<published>2017-07-25T02:05:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-skiboot/commit/?id=024bbfd036bed080a21e30f5a62d287c7e3a42c2'/>
<id>urn:sha1:024bbfd036bed080a21e30f5a62d287c7e3a42c2</id>
<content type='text'>
Add a lock so that only one thread can print a backtrace at a time.
This should prevent multiple threads from garbaling each other's
backtraces.

Signed-off-by: Oliver O'Halloran &lt;oohall@gmail.com&gt;
Signed-off-by: Stewart Smith &lt;stewart@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>stack: Don't recurse into __stack_chk_fail</title>
<updated>2016-12-22T02:17:28+00:00</updated>
<author>
<name>Benjamin Herrenschmidt</name>
<email>benh@kernel.crashing.org</email>
</author>
<published>2016-12-21T07:25:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-skiboot/commit/?id=d7ffce9096d5a23ee4ff309910983d823e953bd2'/>
<id>urn:sha1:d7ffce9096d5a23ee4ff309910983d823e953bd2</id>
<content type='text'>
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Signed-off-by: Stewart Smith &lt;stewart@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>core: Fix backtrace for gcc 6</title>
<updated>2016-03-30T07:15:39+00:00</updated>
<author>
<name>Joel Stanley</name>
<email>joel@jms.id.au</email>
</author>
<published>2016-02-29T00:51:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-skiboot/commit/?id=793f6f5b32c96f2774bd955b6062c74a672317ca'/>
<id>urn:sha1:793f6f5b32c96f2774bd955b6062c74a672317ca</id>
<content type='text'>
GCC 6 warns when we look at any stack frame other than our own, ie any
argument to __builtin_frame_address other than zero.

Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
Signed-off-by: Stewart Smith &lt;stewart@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>Fix early backtraces</title>
<updated>2016-03-04T05:06:51+00:00</updated>
<author>
<name>Ryan Grimm</name>
<email>grimm@linux.vnet.ibm.com</email>
</author>
<published>2016-03-03T20:58:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-skiboot/commit/?id=fbf1bb983af879cfa7c7d5283cd17d5c254753ae'/>
<id>urn:sha1:fbf1bb983af879cfa7c7d5283cd17d5c254753ae</id>
<content type='text'>
If we fail an assert() before we add a mem region, such as missing chip-id in a
dt xscom node, we don't get a backtrace:

[836883,0] Assert fail: core/device.c:870:id != 0xffffffff
[848859,0] Aborting!
CPU 0000 Backtrace:

This patch adjusts the top_of_ram value compared to the fp stack frame to
assume one stack early on so we get a backtrace:

[440546,0] Assert fail: core/device.c:822:id != 0xffffffff
[452522,0] Aborting!
CPU 0000 Backtrace:
 S: 0000000031c03b70 R: 00000000300135d0   .backtrace+0x24
 S: 0000000031c03bf0 R: 0000000030017f38   ._abort+0x4c
 S: 0000000031c03c70 R: 0000000030017fb4   .assert_fail+0x34
 S: 0000000031c03cf0 R: 0000000030021830   .dt_get_chip_id+0x24
 S: 0000000031c03d60 R: 00000000300143cc   .init_chips+0x23c
 S: 0000000031c03e30 R: 0000000030013ab8   .main_cpu_entry+0x110
 S: 0000000031c03f00 R: 000000003000254c   boot_entry+0x19c

Signed-off-by: Ryan Grimm &lt;grimm@linux.vnet.ibm.com&gt;
Signed-off-by: Stewart Smith &lt;stewart@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>Don't try to print symbol when we didn't find one</title>
<updated>2015-08-11T06:33:32+00:00</updated>
<author>
<name>Stewart Smith</name>
<email>stewart@linux.vnet.ibm.com</email>
</author>
<published>2015-08-11T06:33:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-skiboot/commit/?id=3428deb9b97ee9e16e20f85442d555ca168a6839'/>
<id>urn:sha1:3428deb9b97ee9e16e20f85442d555ca168a6839</id>
<content type='text'>
Signed-off-by: Stewart Smith &lt;stewart@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>Add symbolic backtraces and expose skiboot map to Linux</title>
<updated>2014-11-18T08:33:51+00:00</updated>
<author>
<name>Benjamin Herrenschmidt</name>
<email>benh@kernel.crashing.org</email>
</author>
<published>2014-11-18T08:33:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-skiboot/commit/?id=c38c2e8d08e03e905b72334747a9f8795f3526c2'/>
<id>urn:sha1:c38c2e8d08e03e905b72334747a9f8795f3526c2</id>
<content type='text'>
We use a double link technique, doing a first pass with a .o containing
a dummy symbol map, then re-linking with a new .o

Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</content>
</entry>
</feed>
