summaryrefslogtreecommitdiffstats
path: root/drivers/misc/sgi-gru
diff options
context:
space:
mode:
authorRobin Holt <holt@sgi.com>2008-09-13 02:33:22 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2008-09-13 14:41:52 -0700
commit8275d102f8dbaa4f437f6b03b00d85bfb4e16025 (patch)
tree039189a824d81d8968143e166c77f88ee31593ad /drivers/misc/sgi-gru
parentecc9a04de66e7b2d40d539cc39d5798bc46553e9 (diff)
downloadtalos-op-linux-8275d102f8dbaa4f437f6b03b00d85bfb4e16025.tar.gz
talos-op-linux-8275d102f8dbaa4f437f6b03b00d85bfb4e16025.zip
ia64: fix panic during `modprobe -r xpc'
If you are on ia64 and you modprobe xpc then modprobe -r xpc, you immediately get a panic. xpc depends on xp which depends on gru for a symbol. That symbol is only used when we are running on UV hardware. Currently, the GRU driver detects we are not on UV hardware and does no initializing. It does not do the same check when unloading. As a result, the gru driver attempts to tear down stuff that was not setup. This is a simple two-line workaround to get us through this release. Once 2.6.28 is opened, we need to rework the symbols that xp is depending on from gru so the gru driver can properly fail to load when hardware is not available. Signed-off-by: Robin Holt <holt@sgi.com> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/misc/sgi-gru')
-rw-r--r--drivers/misc/sgi-gru/grufile.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/drivers/misc/sgi-gru/grufile.c b/drivers/misc/sgi-gru/grufile.c
index 23c91f5f6b61..d61cee796efd 100644
--- a/drivers/misc/sgi-gru/grufile.c
+++ b/drivers/misc/sgi-gru/grufile.c
@@ -445,6 +445,9 @@ static void __exit gru_exit(void)
int order = get_order(sizeof(struct gru_state) *
GRU_CHIPLETS_PER_BLADE);
+ if (!IS_UV())
+ return;
+
for (i = 0; i < GRU_CHIPLETS_PER_BLADE; i++)
free_irq(IRQ_GRU + i, NULL);
OpenPOWER on IntegriCloud