lkml.org 
[lkml]   [1997]   [Dec]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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?;)

\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.060 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site