From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 21:19:39 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4A18B16A421 for ; Wed, 11 Jul 2007 21:19:39 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from bavaria.utcluj.ro (bavaria.utcluj.ro [193.226.5.35]) by mx1.freebsd.org (Postfix) with ESMTP id E569013C458 for ; Wed, 11 Jul 2007 21:19:38 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from localhost (localhost [127.0.0.1]) by bavaria.utcluj.ro (Postfix) with ESMTP id C5CF850853 for ; Thu, 12 Jul 2007 00:19:34 +0300 (EEST) X-Virus-Scanned: by the daemon playing with your mail on bavaria.utcluj.ro Received: from bavaria.utcluj.ro ([127.0.0.1]) by localhost (bavaria.utcluj.ro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzMl8a3MqT-V for ; Thu, 12 Jul 2007 00:19:30 +0300 (EEST) Received: from hades.local (c7.campus.utcluj.ro [193.226.6.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bavaria.utcluj.ro (Postfix) with ESMTP id 7539750842 for ; Thu, 12 Jul 2007 00:19:30 +0300 (EEST) Message-ID: <4695495A.8080009@net.utcluj.ro> Date: Thu, 12 Jul 2007 00:19:22 +0300 From: Cristian KLEIN User-Agent: Thunderbird 2.0.0.4 (X11/20070711) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [patch] suspend problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 21:19:39 -0000 Hi everybody, I have buildworld/kernel yesterday. When I try to suspend using the ACPI sleep button, the following errors occur. After several suspend / resume cycles, the system repeatedly prints this error message: fwohci0: device physically ejected? On my system fwohci seems to use poll (tested using a printf), so the message is printed so often that the system becomes unusable. My solution rate-limits this message, however I don't think that the firewire device is resumed correctly. --- cut here --- diff -ur sys.orig/dev/firewire/fwohci.c sys/dev/firewire/fwohci.c --- sys.orig/dev/firewire/fwohci.c 2007-06-08 12:04:30.000000000 +0300 +++ sys/dev/firewire/fwohci.c 2007-07-11 17:31:10.898954755 +0300 @@ -2064,8 +2064,13 @@ stat = OREAD(sc, FWOHCI_INTSTAT); if (stat == 0xffffffff) { - device_printf(sc->fc.dev, - "device physically ejected?\n"); + /* Rate limit this message */ + static int verbose = 10; + if (verbose != 0) { + device_printf(sc->fc.dev, + "device physically ejected?\n"); + verbose--; + } return (FILTER_STRAY); } if (stat) --- and here --- After solving this problem, during resume, the kernel panics with something like "recursing on non-recursive mutex ". The problem seems to be in ACPI vendor code, which assumes that the OS supplied lock functions allow recursion. The following patch modifies the OS layer to match ACPI vendor code's assumption: --- cut here --- diff -ur sys.orig/dev/acpica/Osd/OsdSynch.c sys/dev/acpica/Osd/OsdSynch.c --- sys.orig/dev/acpica/Osd/OsdSynch.c 2007-03-27 02:04:02.000000000 +0300 +++ sys/dev/acpica/Osd/OsdSynch.c 2007-07-11 17:29:47.497655148 +0300 @@ -346,7 +346,7 @@ snprintf(h->name, sizeof(h->name), "acpi subsystem HW lock"); else snprintf(h->name, sizeof(h->name), "acpi subsys %p", OutHandle); - mtx_init(&h->lock, h->name, NULL, MTX_DEF); + mtx_init(&h->lock, h->name, NULL, MTX_DEF | MTX_RECURSE); *OutHandle = (ACPI_SPINLOCK)h; return (AE_OK); } --- and here --- E.g. * AcpiEvGpeDetect() calls AcpiOsAcquireLock(AcpiGbl_GpeLock) in contrib/dev/acpica/evgpe.c:511, then calls AcpiEvGpeDispatch() * AcpiEvGpeDispatch() calls AcpiHwDisableAllGpes() in evgpe.c:762 * AcpiHwDisableAllGpes() calls AcpiEvWalkGpeList in hwgpe.c:487 * AcpiEvWalkGpeList() calls AcpiOsAcquireLock(AcpiGbl_GpeLock) aaagain in evgpeblk.c:237 Thanks.