Rene,
Holy crap, I've got sound! :)
You were right, that modprobe line did it. The "state=" line in the
resources file was already set to active. A couple of the resources were
different than you listed, but when I plugged the appropriate values into
the modprobe line, everything worked! The primary i/o port was 0x240 and
the second dma channel was 3, but that was it! I put the line in the
rc.local for now and it seems to be working fine. I'm working my way up to
recompiling kernels one day and I may try it the other way. In my reading
on the web I see proponents for both compiled kernel drivers and loaded
kernel modules. Are there any significant advantages or disadvantages to
one over the other?
Also, I apologize, I didn't even notice that my previous reply didn't go to
the list.
Thanks again very much!
Troy
On 8/1/07, Rene Herman <[EMAIL PROTECTED]> wrote:
>
> On 08/01/2007 02:57 AM, Troy Heidner wrote:
>
> > Thanks for the help!
>
> Sure, but please always keep existing CCs intact on these kinds of
> messages.
> Otherwise the next poor sod that googles for the same problem hits on
> these
> first few messages of a conversation, but not the solution since that was
> in
> private mail. Just always use "reply to all" when dealing with Linux
> lists.
>
> > Here's what I get when I cat those files:
>
> [ ... ]
>
> > ESS0009
> > ESS1879
> >
> > There's an ESS1879 in there, but I'm not sure what that tells me?
>
> It tells you (and me...) that indeed the problem is just that the driver
> does not know it should be driving your chip. The solution is to tell it
> this, and the attached trivial patch to the driver would do this.
>
> The ESS0009 is the chip's CTRL port but I assume from the single ESS1869
> already present there that it's okay without.
>
> If you are upto applying the attached patch and rebuilding the kernel
> please
> do so, but assuming you are not, you can work-around the driver not
> knowing
> about your chip by specifying all resources manually.
>
> Please do a:
>
> cat /sys/bus/pnp/devices/<foo>/resources
>
> where <foo> is the directory in which the "id" file says "ESS179". It
> might
> just say
>
> state = disabled
>
> If it does, do (as root):
>
> echo activate >/sys/bus/pnp/devices/<foo>/resources
>
> after which the next
>
> cat /sys/bus/pnp/devices/<foo>/resources
>
> should tell you something fairly close to:
>
> state = active
> io 0x220-0x22f
> io 0x388-0x38b
> io 0x330-0x331
> irq 5
> dma 1
> dma 0
>
> At this point, you can try loading the driver, specifying these resources:
>
> modprobe snd-es18xx isapnp=0 port=0x220 fm_port=0x388\
> mpu_port=0x330 irq=5 dma1=1 dma2=0
>
> If all is well, you now have sound (remember to unmute and up the volumes
> with a mixer such as alsamixer!).
>
> If this method works for you, you'll have to figure out how to integrate
> it
> into your bootscripts yourself as this is different with every
> distribution.
> Simply doing the enabling/loading from an "rc.local" could be easiest...
>
> If you can confirm that it works after this manual enabling (or after just
> applying and testing the patch ofcourse), I'll make sure it ends up
> upstream
> so that future drivers will work out of the box.
>
> Rene.
>
> diff --git a/sound/isa/es18xx.c b/sound/isa/es18xx.c
> index f7732bf..69b1c8a 100644
> --- a/sound/isa/es18xx.c
> +++ b/sound/isa/es18xx.c
> @@ -2042,6 +2042,7 @@ static int pnpc_registered;
>
> static struct pnp_device_id snd_audiodrive_pnpbiosids[] = {
> { .id = "ESS1869" },
> + { .id = "ESS1879" },
> { .id = "" } /* end */
> };
>
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user
