From owner-freebsd-acpi@FreeBSD.ORG Fri Aug 10 19:35:11 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 11EB216A421 for ; Fri, 10 Aug 2007 19:35:11 +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 8418B13C4B6 for ; Fri, 10 Aug 2007 19:35:10 +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 6399620B0; Fri, 10 Aug 2007 21:35:06 +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 C566B208A; Fri, 10 Aug 2007 21:35:05 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id ADC5D84486; Fri, 10 Aug 2007 21:35:05 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: John Baldwin References: <46337B06.9080102@ybb.ne.jp> <200708081750.l78HoaUY047803@lava.sentex.ca> <86vebn7ipx.fsf@ds4.des.no> <200708101455.44492.jhb@freebsd.org> Date: Fri, 10 Aug 2007 21:35:05 +0200 In-Reply-To: <200708101455.44492.jhb@freebsd.org> (John Baldwin's message of "Fri\, 10 Aug 2007 14\:55\:44 -0400") Message-ID: <86ir7nnpxy.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, Mike Tancsa 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 19:35:11 -0000 John Baldwin writes: > On Friday 10 August 2007 07:05:30 am Dag-Erling Sm=C3=B8rgrav wrote: >> 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,= =20 > with >> > > > > 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=20 > RELENG_6 >>=20 >> 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. >>=20 >> There is one thing I think might be related. To quote my own comments >> from the code: >>=20 >> * 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. >>=20 >> 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? > > Don't use ~0ul for the end address, but use the real one. However, the=20 > resource management in this driver is all wrong. What it should be doing= , is=20 > to identify as a child of 'isab' and create a child device of 'isab'. It= =20 > should then allocate the appropriate BAR from the 'isab' device (the isab= =20 > driver can "proxy" alloc_resource requests from direct children to its ba= rs=20 > just like the vgapci(4) device) and use that single BAR resource for I/O.= =20=20 > However, just fixing the end address to be appropriate should fix the dri= ver=20 > for now. So basically, the quick fix is this? sc->tco_res =3D bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->tco_ri= d, pmbase + TCO_BASE, pmbase + TCO_BASE + TCO_LEN, TCO_LEN, RF_ACTIVE | RF_SHAREABLE); The man page isn't entirely clear on whether end is the last address in the range or the first address beyond the range. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no