NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/40488: Unable to reboot Dell PE 2970
Christos Zoulas wrote:
> On Jan 26, 11:08pm, ad%netbsd.org@localhost (Andrew Doran) wrote:
> -- Subject: Re: kern/40488: Unable to reboot Dell PE 2970
>
> | On Mon, Jan 26, 2009 at 11:05:04PM +0000, Andrew Doran wrote:
> | > The following reply was made to PR kern/40488; it has been noted by GNATS.
> | >
> | > From: Andrew Doran <ad%netbsd.org@localhost>
> | > To: gnats-bugs%NetBSD.org@localhost
> | > Cc: port-i386%netbsd.org@localhost, port-amd64%netbsd.org@localhost
> | > Subject: Re: kern/40488: Unable to reboot Dell PE 2970
> | > Date: Mon, 26 Jan 2009 23:03:16 +0000
> | >
> | > On Mon, Jan 26, 2009 at 10:45:00PM +0000, mbowie%buzmo.com@localhost
> wrote:
> | >
> | > > Running a fresh install of either 4.0.1 or 5.0_BETA (from 20090125) on
> a Dell PowerEdge 2970 (BIOS 3.0.3). Issuing a reboot or "shutdown -r now"
> results in the machine hanging indefinitely after unmounting the local
> filesystems. A test installation of FreeBSD on the same system reboots
> successfully. Testing with both ACPI and ACPI / SMP disabled yields the same
> results. There are no ACPI tunables in the BIOS.
> | >
> | > We could try port 0x92 and the PCI reset vector before the triple fault.
> | > Anyone interested in taking a look?
> |
> | FreeBSD at seems to try the port 92 method but not the PCI method.
> |
> | http://fxr.watson.org/fxr/source/i386/i386/vm_machdep.c#L652
> |
>
> And here's a patch that does that...
>
> christos
>
> Index: machdep.c
> ===================================================================
> RCS file: /cvsroot/src/sys/arch/i386/i386/machdep.c,v
> retrieving revision 1.654
> diff -u -u -r1.654 machdep.c
> --- machdep.c 15 Dec 2008 22:20:52 -0000 1.654
> +++ machdep.c 26 Jan 2009 23:16:29 -0000
> @@ -1680,6 +1680,35 @@
> delay(100000);
>
> /*
> + * Attempt to force a reset via the Reset Control register at
> + * I/O port 0xcf9. Bit 2 forces a system reset when it
> + * transitions from 0 to 1. Bit 1 selects the type of reset
> + * to attempt: 0 selects a "soft" reset, and 1 selects a
> + * "hard" reset. We try a "hard" reset. The first write sets
> + * bit 1 to select a "hard" reset and clears bit 2. The
> + * second write forces a 0 -> 1 transition in bit 2 to trigger
> + * a reset.
> + */
> + outb(0xcf9, 0x2);
> + outb(0xcf9, 0x6);
> + DELAY(500000); /* wait 0.5 sec to see if that did it */
> +
> + /*
> + * Attempt to force a reset via the Fast A20 and Init register
> + * at I/O port 0x92. Bit 1 serves as an alternate A20 gate.
> + * Bit 0 asserts INIT# when set to 1. We are careful to only
> + * preserve bit 1 while setting bit 0. We also must clear bit
> + * 0 before setting it if it isn't already clear.
> + */
> + b = inb(0x92);
> + if (b != 0xff) {
> + if ((b & 0x1) != 0)
> + outb(0x92, b & 0xfe);
> + outb(0x92, b | 0x1);
> + DELAY(500000); /* wait 0.5 sec to see if that did it */
> + }
> +
> + /*
> * Try to cause a triple fault and watchdog reset by making the IDT
> * invalid and causing a fault.
> */
Patching the machdep.c for amd64 with the first half of Christos's
patch yields a successful reboot.
Thanks to all for the extremely fast responses!
Cheers,
Mike.
--- sys/arch/amd64/amd64/machdep.c.orig 2009-01-27 18:28:43.000000000 +0000
+++ sys/arch/amd64/amd64/machdep.c 2009-01-27 18:29:24.000000000 +0000
@@ -1555,6 +1555,20 @@
outb(IO_KBD + KBCMDP, KBC_PULSE0);
delay(100000);
+ /*
+ * Attempt to force a reset via the Reset Control register at
+ * I/O port 0xcf9. Bit 2 forces a system reset when it
+ * transitions from 0 to 1. Bit 1 selects the type of reset
+ * to attempt: 0 selects a "soft" reset, and 1 selects a
+ * "hard" reset. We try a "hard" reset. The first write sets
+ * bit 1 to select a "hard" reset and clears bit 2. The
+ * second write forces a 0 -> 1 transition in bit 2 to trigger
+ * a reset.
+ */
+ outb(0xcf9, 0x2);
+ outb(0xcf9, 0x6);
+ DELAY(500000); /* wait 0.5 sec to see if that did it */
+
/*
* Try to cause a triple fault and watchdog reset by making the IDT
* invalid and causing a fault.
Home |
Main Index |
Thread Index |
Old Index