Messages in this thread | | | Date | Wed, 24 Dec 1997 09:40:41 +0200 (EET) | From | Tuomas Heino <> | Subject | Re: soundblaster problems in 2.1.74 and 2.1.75 |
| |
On Mon, 22 Dec 1997 kwrohrer@enteract.com wrote:
> And lo, Russell Coker - mailing lists account saith unto me: > > >When I try to load the sb.o module, I get the following output. > > >/lib/modules/2.1.75/misc/sb.o: init_module: Device or resource busy sound: > > >Device or resource busy > > Run "modprobe sb io=0x220 irq=7 dma=1 dma16=5" > At least gus.o is genteel enough to say you have to specify the irq etc. > on the insmod line. Note that building the Ultrasound support into the > kernel doesn't activate the gus support (forgot to check the values compiled > in?)--cat /dev/sndstat doesn't note any drivers whatsoever. > > Once I got gus.o loaded and working, players still hang; strace says > the close command isn't returning (until I control-C the player, e.g. > mpg123); top says they're in the "S" (sleeping) state. Any clues as to > this, or is it known-broken-we're-working-on-it? >
happens with OSS's 'play' too so it definitely is a bug, not a feature... [strace play...] write(3, "\v\275H\264Z\366\363\363\356\22\314"..., 2048) = 2048 read(4, "\316.\30B\312&\34739\36\304%\2\22"..., 1768) = 1768 write(3, "\316.\30B\312&\34739\36\304%\2\22"..., 1768) = 1768 ioctl(3, SNDCTL_DSP_POST, 0) = 0 close(4) = 0 ioctl(3, SNDCTL_DSP_SYNC <unfinished ...>
[strace mpg123...] write(4, "O\377\262\377V\377\312\377W\377\327"..., 16384) = 16384 read(3, "\177cu!U\220\t\310\221\221\266\233"..., 4096) = 1609 write(4, "9\377\260\377,\377\266\377=\377\315"..., 16384) = 16384 read(3, "", 4096) = 0 close(3) = 0 munmap(0x400c9000, 4096) = 0 write(2, "[0:58] Decoding of watchers.mp3 "..., 42[0:58] Decoding of watchers.mp3 finished.) = 42 write(4, "<\377\231\3772\377\224\3773\377\223"..., 15360) = 15360 close(4 <unfinished ...>
> In any case, here's what I had to do; feel free to make this complete > and/or prepend it to drivers/sound/Readme.modules; I think that's the > most sensible spot, though it deserves mention somewhere more prominent, > like Documentation/Changes... >
Hmm... good idea - for gus stuff look at the end of this message ;)
> ----------------------------------------------------------------------------- > > Using a loadable sound driver > ============================= > As of kernel 2.1.74 or so, the sound driver's behavior as a module has > changed radically. sound.o is now a common utility module, rather than > the container for all compiled sound support. To get my Gravis Ultrasound > working with 2.1.75, I had to: > > 1) Configure the kernel to build the sound driver, including the GUS support, > as a module. (I didn't try 'Y' for sound and 'M' for GUS.) For other > relevant stuff to do, see the "Building" section, below... > > 2) Specify options for your soundcard-specific driver in /etc/conf.modules > (or /etc/modules.conf if you've got one of those instead). This saves you > from having to retype them correctly every time you modprobe your sound > support. For example, I added: > > options gus io=0x220 irq=12 dma=6 > > This is what I use; those of you with different cards or different settings > will need to name the right module and specify the right settings. > > 3) For use with kerneld (a Good Thing(TM)), also add: > > alias char-major-14 sound > alias char-major-14 gus > > This will make kerneld install the gus module as well as the main sound > module; without it, kerneld just installed basic sound support, which is > useless without a specific card driver (unless you just wanted to cat > /dev/sndstat for the version number)... You might be able to get away > without the first alias, since gus.o does depend on sound.o, but it's nice > to have a working sound driver while you debug depmod problems. And again, > don't forget to change out "gus" for your sound card module of choice. > > New (and Reconditioned) Parameters > ---------------------------------- > The sound card modules, and the parameters they take, are known to include: > gus Gravis Ultrasound &c > io=0x220 irq=15 dma=6 > (I don't know the keyword for the second DMA channel; there > is only the one IRQ needed under these drivers AFAIK) > > sb true Creative Labs Sound Blaster hardware-compatibles > io=0x220 irq=7 dma=1 dma16=5 > (thanks to Russell Coker, though these values may be > non-default) > > FIXME ... > > > Questions about my experiences, and blame for this documentation, can > be attributed to Keith Rohrer (kwrohrer@enteract.com). All rights > reversed, all disclaimers made, etc... Someone else wrote the following, > which apparently nobody updated: > > ------------------------------------------------------------------------------ [snip, everything after ---'s automatically snipped... be careful with ---'s;)]
From gus_card.c:
int io = -1; int irq = -1; int dma = -1; int dma16 = -1; /* Set this for modules that need it */ int type = 0; /* 1 for PnP */ int gus16 = 0; static int db16 = 0; /* Has a Gus16 AD1848 on it */
MODULE_PARM(io, "i"); MODULE_PARM(irq, "i"); MODULE_PARM(dma, "i"); MODULE_PARM(dma16, "i"); MODULE_PARM(type, "i"); MODULE_PARM(gus16, "i"); MODULE_PARM(db16, "i");
... config.dma2 = dma16;
Meaning gus uses that funny dma16 name too... I thought gus wasn't really that sb:ish... meaning it doesn't really differentiate between 8-bit and 16-bit dma channels or does it? ;)
Also another question: When do the dma channels get used? ;) (when does the driver actually use dma2?;)
| |