lwn.git/arch/powerpc/platforms/pseries/ras.c, branch v3.10.63

powerpc/pseries: Cut down on enthusiastic use of defines in RAS code

2012-03-28T00:32:01+00:00

So many defines for such a little file. Most of them can go. Also remove the single entry changelog, we have git for that. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt

powerpc/pseries: Clean up ras_error_interrupt code

2012-03-28T00:32:00+00:00

The RAS error interrupt is no longer used but we may as well mirror the changes we made to the EPOW interrupt. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt

powerpc/pseries: Remove RTAS_POWERMGM_EVENTS

2012-03-28T00:32:00+00:00

IBM bit 2 in the rtas event-scan and check-exception calls is marked reserved in the PAPR, so remove it from our RAS code. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt

powerpc/pseries: Use rtas_get_sensor in RAS code

2012-03-28T00:31:59+00:00

We have rtas_get_sensor so we may as well use it. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt

powerpc/pseries: Parse and handle EPOW interrupts

2012-03-28T00:31:59+00:00

We have code to take environmental and power warning (EPOW) interrupts but it simply prints a terse error message: EPOW <0x6240040000000b8 0x0 0x0> which tells us nothing about what happened. Even worse, if we don't correctly respond to the interrupt we may get terminated by firmware. Add code to printk some useful information when we get EPOW events. We want to make it clear that we have an error, that it was reported by firmware and that the RTAS error log will have more detailed information. eg: Ambient temperature too high reported by firmware. Check RTAS error log for details Depending on the error encountered, we now issue an immediate or an orderly power down. Move initialization of the EPOW interrupt earlier in boot since we want to respond to them as early as possible. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt

powerpc/pseries: Print corrupt r3 in FWNMI code

2011-05-19T04:30:43+00:00

I have a report of an FWNMI with an r3 value that we think is corrupt, but since we don't print r3 we have no idea what was wrong with it. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt

powerpc/irq: Stop exporting irq_map

2011-05-04T05:02:15+00:00

First step in eliminating irq_map[] table entirely Signed-off-by: Benjamin Herrenschmidt

powerpc: Fix corruption when grabbing FWNMI data

2011-01-21T03:08:38+00:00

The FWNMI code uses a global buffer without any locks to read the RTAS error information. If two CPUs take a machine check at once then we will corrupt this buffer. Since most FWNMI rtas messages are not of the extended type, we can create a 64bit percpu buffer and use it where possible. If we do receive an extended RTAS log then we fall back to the old behaviour of using the global buffer. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt

powerpc: Rework pseries machine check handler

2011-01-21T03:08:38+00:00

Rework pseries machine check handler: - If MSR_RI isn't set, we cannot recover even if the machine check was fully recovered - Rename nonfatal to recovered - Handle RTAS_DISP_LIMITED_RECOVERY - Use BUS_MCEERR_AR instead of BUS_ADRERR - Don't check all the RTAS error log fields when receiving a synchronous machine check. Recent versions of the pseries firmware do not fill them in during a machine check and instead send a follow up error log with the detailed information. If we see a synchronous machine check, and we came from userspace then kill the task. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt

powerpc: Never halt RTAS error logging after receiving an unrecoverable machine check

2011-01-21T03:08:37+00:00

Newer versions of the System p firwmare send a partial RTAS error log in the machine check handler with a more detailed response appearing sometime later via check event. This means at machine check time we do not have enough information to ascertain exactly what went on. Furthermore, I have found the RTAS error logs in the machine check handler contain no useful information, so halting on them makes little sense. If we want to halt it would make more sense to do it following the error log received sometime later via check event. In light of this, never halt the error log in the pseries machine check handler. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt