And thanks again, again.
That's the below patch. It looks pretty innocuous. I'd be assuming that
there's something in the shutdown sequence which needs 8259 functionality
after the thing has been turned off.
This could well depend upon .config contents and linkage order.
Eric, maybe we need to turn it off by hand at the right time rather than
relying on driver model shutdown ordering?
arch/i386/kernel/i8259.c | 11 +++++++++++
1 files changed, 11 insertions(+)
diff -puN arch/i386/kernel/i8259.c~i8259-shutdown arch/i386/kernel/i8259.c
--- 25/arch/i386/kernel/i8259.c~i8259-shutdown 2003-05-11 18:48:58.000000000 -0700
+++ 25-akpm/arch/i386/kernel/i8259.c 2003-05-11 18:48:58.000000000 -0700
@@ -245,10 +245,21 @@ static int i8259A_resume(struct device *
return 0;
}
+static void i8259A_shutdown(struct device *dev)
+{
+ /* Put the i8259A into a quiescent state that
+ * the kernel initialization code can get it
+ * out of.
+ */
+ outb(0xff, 0x21); /* mask all of 8259A-1 */
+ outb(0xff, 0xA1); /* mask all of 8259A-1 */
+}
+
static struct device_driver i8259A_driver = {
.name = "pic",
.bus = &system_bus_type,
.resume = i8259A_resume,
+ .shutdown = i8259A_shutdown,
};
static struct sys_device device_i8259A = {
_
-
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/