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 <rene.herman@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
