Date: Fri, 1 Jul 2005 22:48:12 +0800 From: Muzaffar Ariff <mus.bsd@gmail.com> To: pyunyh@gmail.com Cc: freebsd-multimedia@freebsd.org Subject: Re: ESS Maestro3 no sound Message-ID: <8eb2b81050701074853656129@mail.gmail.com> In-Reply-To: <20050701023307.GF17609@rndsoft.co.kr> References: <8eb2b81050628200659d338ab@mail.gmail.com> <20050629043027.GB8832@rndsoft.co.kr> <42C2B94F.2010708@samsco.org> <20050701023307.GF17609@rndsoft.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
I'll give it a try first thing tomorrow. Had a busy week (hence no reply) :) I personally don't have a clue on how to load the patch but i think i can figure it out. I'll keep you guys posted next week. -m- On 7/1/05, Pyun YongHyeon <pyunyh@gmail.com> wrote: > On Wed, Jun 29, 2005 at 09:07:59AM -0600, Scott Long wrote: >=20 > [...] >=20 > > > > It looks like yet more decay in the driver. When I wrote it, I was la= zy > > 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 fir= st > > (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 tha= t > > 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 deep= er > > bugs in the resource manager, though. > > >=20 > Thanks for detailed explanation. :-) > Here is patch. Muzaffar, does the patch change your situation? >=20 > 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. >=20 > > Scott >=20 > PS. Due to mail server issues I sent again. > -- > Regards, > Pyun YongHyeon >=20 >=20 >=20 --=20 Muzaffar Ariff mus.bsd@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8eb2b81050701074853656129>