From owner-freebsd-multimedia@FreeBSD.ORG Fri Jul 1 02:32:54 2005 Return-Path: X-Original-To: freebsd-multimedia@freebsd.org Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98EA516A41C for ; Fri, 1 Jul 2005 02:32:54 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45BA443D49 for ; Fri, 1 Jul 2005 02:32:54 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by wproxy.gmail.com with SMTP id i25so213245wra for ; Thu, 30 Jun 2005 19:32:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:from; b=FlO/KzLFhjDgQ5WokSEz0WSxCq7pUDLV8KTCSGc01u4ajyNX+zKh52dS68LMMlQbZK5+Wudxo8eRoL1k5MYQhoo6Bwgm0OZ4UL4foJXGZxvTYnOZURFm9XeWANicXDBfHa2JiwFXFID2wKgQkikGd+BBtOeClnJp1kxKA7aqupk= Received: by 10.54.16.28 with SMTP id 28mr962051wrp; Thu, 30 Jun 2005 19:32:53 -0700 (PDT) Received: from michelle.rndsoft.co.kr ([211.32.202.209]) by mx.gmail.com with ESMTP id 65sm168894wra.2005.06.30.19.32.51; Thu, 30 Jun 2005 19:32:53 -0700 (PDT) Received: from michelle.rndsoft.co.kr (localhost.rndsoft.co.kr [127.0.0.1]) by michelle.rndsoft.co.kr (8.13.1/8.13.1) with ESMTP id j612X7Jp017986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jul 2005 11:33:07 +0900 (KST) (envelope-from yongari@rndsoft.co.kr) Received: (from yongari@localhost) by michelle.rndsoft.co.kr (8.13.1/8.13.1/Submit) id j612X7f5017985; Fri, 1 Jul 2005 11:33:07 +0900 (KST) (envelope-from yongari@rndsoft.co.kr) Date: Fri, 1 Jul 2005 11:33:07 +0900 To: Scott Long Message-ID: <20050701023307.GF17609@rndsoft.co.kr> References: <8eb2b81050628200659d338ab@mail.gmail.com> <20050629043027.GB8832@rndsoft.co.kr> <42C2B94F.2010708@samsco.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: <42C2B94F.2010708@samsco.org> User-Agent: Mutt/1.4.2.1i From: Pyun YongHyeon Cc: freebsd-multimedia@freebsd.org, Muzaffar Ariff Subject: Re: ESS Maestro3 no sound X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2005 02:32:54 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jun 29, 2005 at 09:07:59AM -0600, Scott Long wrote: [...] > > It looks like yet more decay in the driver. When I wrote it, I was lazy > and didn't want to figure out which chip versions preferred IOPORT > mapping and which ones preferred MEMIO, so I just had it try MEMIO first > (since that is a better choice) and then fail back to IOPORT. The > resource manager seemed to tolerate this back then, but apparently it > doesn't now. My guess is that the first call to bus_alloc_resource > returns success but actually fails, and in the process it leaks the > resource out of the resource manager. Then when you unload and load > again, the resource is unavailable (since it was leaked) so the first > call to fails, prompting it to go to the second call which succeeds > fully. This would mean that there are now a number of bugs in the > resource manager which need to be fixed. > > Based on what I've seen over the years, it might be safe to assume that > BAR0 on both the meastro3 and allegro1 is IOPORT and that BAR1 on the > maestro3 is MEMIO. Thus, the easiest change might be to just remove > the first bus_alloc_resource call and force the driver to always use > IOPORT. I'd still like to use this as a test case for fixing the deeper > bugs in the resource manager, though. > Thanks for detailed explanation. :-) Here is patch. Muzaffar, does the patch change your situation? Btw, I encountered dreasful message "play interrupt timeout, channel dead" again. Unloading the driver and then reloading the driver fixed it. Since I see "pci_link2: Unable to choose an IRQ" during driver load I can't sure it's fault of maestro3(4) driver. > Scott PS. Due to mail server issues I sent again. -- Regards, Pyun YongHyeon --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="maestro3.resource.diff" --- maestro3.c.orig Mon May 23 15:27:07 2005 +++ maestro3.c Thu Jun 30 14:55:02 2005 @@ -1203,19 +1203,21 @@ } } + pci_enable_busmaster(dev); data = pci_read_config(dev, PCIR_COMMAND, 2); - data |= (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN | PCIM_CMD_BUSMASTEREN); + data |= (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN); pci_write_config(dev, PCIR_COMMAND, data, 2); sc->regid = PCIR_BAR(0); - sc->regtype = SYS_RES_MEMORY; + data = pci_read_config(dev, PCIR_COMMAND, 2); + device_printf(dev,"PCIR_COMMAND = 0x%x\n", data); + sc->regtype = SYS_RES_IOPORT; + if ((data & PCIM_CMD_PORTEN) == 0) { + sc->regtype = SYS_RES_MEMORY; + device_printf(dev,"using memory mapped I/O\n"); + } sc->reg = bus_alloc_resource_any(dev, sc->regtype, &sc->regid, RF_ACTIVE); - if (!sc->reg) { - sc->regtype = SYS_RES_IOPORT; - sc->reg = bus_alloc_resource_any(dev, sc->regtype, &sc->regid, - RF_ACTIVE); - } if (!sc->reg) { device_printf(dev, "unable to allocate register space\n"); goto bad; --FL5UXtIhxfXey3p5--