From owner-freebsd-acpi@FreeBSD.ORG Fri Aug 10 11:25:16 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EF7916A418 for ; Fri, 10 Aug 2007 11:25:16 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id CCEC313C45D for ; Fri, 10 Aug 2007 11:25:15 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id F347620B0; Fri, 10 Aug 2007 13:05:30 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id D6619208A; Fri, 10 Aug 2007 13:05:30 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id AA2D58447F; Fri, 10 Aug 2007 13:05:30 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Tancsa References: <46337B06.9080102@ybb.ne.jp> <46338C0F.9000608@ybb.ne.jp> <4633932A.8080602@ybb.ne.jp> <86tzuxni1b.fsf@dwp.des.no> <200707061723.l66HNYSe037055@lava.sentex.ca> <86ir86hqhc.fsf@ds4.des.no> <200707262035.l6QKZtnd067391@lava.sentex.ca> <86abtihk6h.fsf@ds4.des.no> <200707262338.l6QNcL1T068284@lava.sentex.ca> <86hcnq900e.fsf@ds4.des.no> <200707270038.l6R0cLNV068524@lava.sentex.ca> <8664462p1b.fsf@ds4.des.no> <200707271037.l6RAbc2Q071412@lava.sentex.ca> <86fy2v2x9e.fsf@ds4.des.no> <200708071529.l77FTpsO040934@lava.sentex.ca> <86y7gmkolf.fsf@ds4.des.no> <200708081750.l78HoaUY047803@lava.sentex.ca> Date: Fri, 10 Aug 2007 13:05:30 +0200 In-Reply-To: <200708081750.l78HoaUY047803@lava.sentex.ca> (Mike Tancsa's message of "Wed\, 08 Aug 2007 13\:50\:53 -0400") Message-ID: <86vebn7ipx.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-acpi@freebsd.org Subject: Re: ichwd for ICH8 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2007 11:25:16 -0000 Mike Tancsa writes: > At 11:55 AM 8/8/2007, Dag-Erling Sm=C3=83=C2=B8rgrav wrote: > > Mike Tancsa writes: > > > Dag-Erling Sm=C3=83=C2=B8rgrav writes: > > > > I've tested the driver under -CURRENT on a couple more machines, wi= th > > > > the same result everywhere: it probes and attaches and seems to work > > > > fine, but the box does not reboot. > > > kldload ichwd, watchdogd -t 20;killall -9 watchdogd and nada ? > > > > Precisely. > > > > > I can boot one of my working RELENG_6 boxes on current and test if you > > > think it is some version issue. > > > > That would be great! > > Very strange indeed. My RELENG_6 box reboots just fine with your > version and the version from the PR. However, the box fails to reboot > running with a CURRENT kernel on either version of the watchdog. > > On a chance, I tried a trick I used to have to do ages ago in order to > get the driver to work. I added > > debug.acpi.disabled=3D"sysresource" > > to /boot/loader.conf > > and then it worked on the CURRENT kernel. i.e. kldload > /tmp/ichwd.ko,watchdogd -t 20;killall -9=20 > watchdogd.... ~20 sec later, the box reboots running a CURRENT. > Without that in loader.conf, the box does not reboot. > > I _dont_ have to add debug.acpi.disabled=3D"sysresource" on RELENG_6 on > the same box for the ichwd to work as expected. > > dmesg.txt attached the for same machine-- running CURRENT, one from RELEN= G_6 Let's ask the ACPI folks if they know what's up... To summarize, the ichwd driver (both the in-tree version and the new version available from http://people.freebsd.org/~des/software/) works fine in RELENG_6 but fails silently (i.e. attaches and seems to work, but the machine does not reboot) in HEAD. There is one thing I think might be related. To quote my own comments from the code: * The WDT is programmed through I/O registers in the ACPI I/O space. * Intel swears it's always at offset 0x60, so we use that. But perhaps it isn't? Or perhaps access to the TCO registers silently fails due to the ACPI sysresource code? Perhaps the ichwd driver should access them through ACPI, instead of doing direct I/O? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no