From owner-freebsd-acpi@FreeBSD.ORG Fri Aug 10 18:56:12 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 0F66516A417 for ; Fri, 10 Aug 2007 18:56:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id C5DBC13C459 for ; Fri, 10 Aug 2007 18:56:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 202546366 for multiple; Fri, 10 Aug 2007 15:05:39 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l7AItr05085101; Fri, 10 Aug 2007 14:55:54 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Fri, 10 Aug 2007 14:55:44 -0400 User-Agent: KMail/1.9.6 References: <46337B06.9080102@ybb.ne.jp> <200708081750.l78HoaUY047803@lava.sentex.ca> <86vebn7ipx.fsf@ds4.des.no> In-Reply-To: <86vebn7ipx.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708101455.44492.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 10 Aug 2007 14:55:54 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3909/Fri Aug 10 11:10:24 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?= , 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 18:56:12 -0000 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 w= ork > > > > > 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 bars= =20 just like the vgapci(4) device) and use that single BAR resource for I/O. = =20 However, just fixing the end address to be appropriate should fix the drive= r=20 for now. =2D-=20 John Baldwin