Port-xen archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]


        hello.  I've been following this thread loosely for a while, and I
have some thoughts that might or might not be worth anything.  If I suggest
anything that you've already done, I apologize.

1.  Have you tried booting a kernel with options ACPIVERBOSE enabled?  What
I think you want to know is what event handler is registered to GpeNumber
8.  Perhaps when the system boots it can show you that, and this will tel
you where to look for the problem.

2.  The acpi code in NetBSD-5 is more capable than the acpi code in
NetBSD-4.  Thus, I think more hardware features are enabled by the software
under the new OS than under the old one.  Perhaps figuring out which new
features are enabled will help narrow the problem.  Im thinking
specifically of new ACPI devices and probably new features enabled in the
ipmi(4) driver.  In looking at the changes on the ipmi(4) driver between
4.x and 5.x, I'd say the culprit is most likely the monitoring of critical
conditions in the BMC board.  That is, because the ipmi(4) enables the
hardware to flag critical conditions, conditions which existed under
NetBSD-4 which were ignored are now monitored, and, when they fire, an
unhandlable ACPI event is triggered.  I wonder if the following hack to
sys/arch/x86/x86/ipmi.c will fix your problem, at least until the real fix
can be implemented?
        Also, note that the patch below incorporates the patches I submitted
for kern/41724, which fix critical problems with the watchdog timer for the
ipmi(4) driver.  I  hadn't realized these patches never got pulled into the
release trees.  Without them, all my ipmi(4) enabled machines are pretty
useless under NetBSD-3, 4 and 5.


Index: ipmi.c
RCS file: /cvsroot/src/sys/arch/x86/x86/ipmi.c,v
retrieving revision
diff -u -r1.21.2.7 ipmi.c
--- ipmi.c      23 Dec 2008 03:44:17 -0000
+++ ipmi.c      22 Apr 2010 16:33:52 -0000
@@ -1796,9 +1796,11 @@
                 * Monitor critical/critical-over/warning-over states
                 * in the sensors.
+#if 0
                sc->sc_sensor[i].flags |= ENVSYS_FMONCRITICAL;
                sc->sc_sensor[i].flags |= ENVSYS_FMONCRITOVER;
                sc->sc_sensor[i].flags |= ENVSYS_FMONWARNOVER;
+#endif /*0*/
                (void)strlcpy(sc->sc_sensor[i].desc, ipmi_s->i_envdesc,
                if (sysmon_envsys_sensor_attach(sc->sc_envsys,
@@ -1870,6 +1872,8 @@
                sc->sc_wdog.smw_period = smwdog->smw_period;
+       if (!cold)
+               mutex_enter(&sc->sc_lock);
        s = splsoftclock();
        /* see if we can properly task to the watchdog */
        rc = ipmi_sendcmd(sc, BMC_SA, BMC_LUN, APP_NETFN,
@@ -1878,6 +1882,8 @@
        if (rc) {
                printf("ipmi: APP_GET_WATCHDOG_TIMER returned 0x%x\n", rc);
+               if (!cold)
+                       mutex_exit(&sc->sc_lock);
                return EIO;
@@ -1896,6 +1902,8 @@
            APP_SET_WATCHDOG_TIMER, sizeof(swdog), &swdog);
        rc = ipmi_recvcmd(sc, 0, &len, NULL);
+       if (!cold)
+               mutex_exit(&sc->sc_lock);
        if (rc) {
                printf("ipmi: APP_SET_WATCHDOG_TIMER returned 0x%x\n", rc);
                return EIO;
@@ -1910,12 +1918,16 @@
        struct ipmi_softc       *sc = smwdog->smw_cookie;
        int                     s, rc, len;
+       if (!cold)
+               mutex_enter(&sc->sc_lock);
        s = splsoftclock();
        /* tickle the watchdog */
        rc = ipmi_sendcmd(sc, BMC_SA, BMC_LUN, APP_NETFN,
            APP_RESET_WATCHDOG, 0, NULL);
        rc = ipmi_recvcmd(sc, 0, &len, NULL);
+       if (!cold)
+               mutex_exit(&sc->sc_lock);
        if (rc) {
                printf("ipmi: watchdog tickle returned 0x%x\n", rc);
                return EIO;

Home | Main Index | Thread Index | Old Index