From: Jack Steiner If the GRU malfunctions, print a message instead of panicing the system. This simplifies debugging since some of the debug tools can be used on a live system. Flush the cache on instruction timeouts in case the malfunction is related to a coherency issue (never seen this but I'm paranoid). Signed-off-by: Jack Steiner --- drivers/misc/sgi-gru/gruhandles.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Index: linux/drivers/misc/sgi-gru/gruhandles.c =================================================================== --- linux.orig/drivers/misc/sgi-gru/gruhandles.c 2010-06-09 08:11:43.724081727 -0500 +++ linux/drivers/misc/sgi-gru/gruhandles.c 2010-06-09 08:11:46.697237522 -0500 @@ -71,7 +71,7 @@ static void report_instruction_timeout(v else if (TYPE_IS(TFH, goff)) id = "TFH"; - panic(KERN_ALERT "GRU %p (%s) is malfunctioning\n", h, id); + printk(KERN_ALERT "GRU:%d %p (%s) is malfunctioning\n", smp_processor_id(), h, id); } static int wait_instruction_complete(void *h, enum mcs_op opc) @@ -85,6 +85,7 @@ static int wait_instruction_complete(voi if (status != CCHSTATUS_ACTIVE) break; if (GRU_OPERATION_TIMEOUT < (get_cycles() - start_time)) { + gru_flush_cache(h); report_instruction_timeout(h); start_time = get_cycles(); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/