Baslinux mailing list

[sindi keesan <keesan AT sdf.lonestar.org>]

On Sun, 20 Feb 2005, David Moberg wrote:

> ----- Original Message -----
> From: "sindi keesan" <keesan AT sdf.lonestar.org>
>
> > It is not at all clear what is being recommended since sometimes
> > when configuring you see N/y/m but the help file recommends Y. This
> > time I erred on the safe side and included most things they
> > recommended.
>
> The default does not always agree with what is recommended.

Okay.  I will go with recommended unless I can figure out what it all 
means.

> > How do I tell what rate the SB16 files were sampled at?
>
> Try the file command to get a description of the files. Please
> post the output here if it doesn't produce a sampling rate.


The .wav file from SB16 packages is 8 bit mono, 11025Hz.
The ripped .wav file (not handled by my two ASUS boards in linux) is 16 
bit stereo, 44100 Hz.  (It gives some IRQ/DRQ error message).
Interesting, thanks.

> > > > What exactly happens to the kernel when you tell it, for
> > > > instance, to let you use the sound.o module?
> > >
> > > When you insmod? Or when you select =m from configuration and then make?
> > When you configure and make, having told it to use a module later.

> Mkdep and gcc combine to process the configuration file. If something like
> sound.o is set to M, then mkdep looks up all the dependencies and makes sure
> that they're either in the kernel or among the modules to be built. When you
> run make, gcc compiles everything and puts it in the kernel.
>
> > Another major victory for me - I could not have done it without the
> > support.  I will try this kernel with the scsi scanner and zip
> > drive next. (Or maybe redo my scrambled DOS drive).
>
> That's great to hear. I was going to answer the thread about vfat, but it 
> looks
> like Steven's already covered it. I'm getting more confused about vfat 
> myself, as
> I always thought that it was FAT32, and not just long filenames. Oh well.


I had a kernel that worked with scsi and sound but then I was unable to 
mount my floppy disk (it mounted /hda1 okay) without getting a message 
about kernel not supporting vfat.  Apparently MSDOS 7.1, even if you
format the hard drive partitions to plain DOS (short file names), formats 
the floppy disks so that you need vfat to mount them without having to 
specify -t msdos.

So I attempted to modify the configuration to add vfat=y, which fixed that 
problem, but I must have made some other changes at the same time (one of 
these being I think unsetting RZ1000 and another unsetting PC_QUIRKS - I 
cannot figure out if I need these or not, or if they will just cause 
problems).  Anyway, since then sound.o won't insmod.  I had sound working 
perfectly.  I tried various changes (not yet PC_QUIRKS) and after a while 
I started to get error messages about the compiler.  I would make clean 
and make dep and use the same .config and next time it would compile okay.
So I installed kernel source code and bin86.tgz (needed for kernel 
compilation, it says) onto my slower computer, which is indeed compiling a 
bit more slowly, and I am still trying to compile for sound again.

On the 300MHz computer I was using as much as 99% cpu time, usually about 
20-40$ and about 90MB memory.  On the 233MHz I am using as much as 99% cpu 
time, but more of the time, and about 80MB memory.  So this is definitely 
cpu intensive, and it seems to be going slower on this slower cpu.  I have 
not run into any need for more than 96MB RAM yet in linux.  When I am 
compiling I don't try to do much else that is cpu intensive or RAM 
intensive.

Two leads on fixing the sound problem, which consists in my trying to 
insmod sound.o and getting a message 'insmod:  Unresolved symbol 
isa_dma_bridge_buggy'.  I ran into two suggestions for a fix:

Someone said there was a problem building a 2nd kernel after building the 
first if PCI_QUIRKS option was changed.  I changed that option and can try 
changing it back again from N to Y.

Another cure for this problem (which affects all sound cards that use 
sound.o - which includes sb) is to add to /linux/drivers/sound/dmabuf.c 
the line

#include <asm/dma.h>

which I did after the other include line.  I have recompiled for at least 
the 15th time and will try this new kernel and then if needed change 
PCI_QUIRKS back to Y.  I should only change one thing at a time, but it 
was a real pain having to compile on the flaky computer where I could not 
also boot linux except from floppy disk.

The problem  with sound.o showed up around kernel 2.2.12 apparently. 
People were still commenting on it in kernel 2.3.x.  Does anyone have the 
kernel source for 2.0 (Slackware 3.5) handy to see if dmabuf.c contains 
this presumed missing line?  (I have it but in a big .tgz file).

Maybe I need to compile my kernel on a computer while using a kernel that 
was already compiled with PC_QUIRKS=y?  THings are certainly acting 
quirky.  I should have saved my partial successes.

> David
> --
> _______________________________________________
> Find what you are looking for with the Lycos Yellow Pages
> http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10
>
> _______________________________________________
> BasLinux mailing list
> BasLinux AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/baslinux

keesan AT sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org