Skip to Content.
Sympa Menu

baslinux - Re: [BL] Can I make my own scsi kernel?

baslinux AT lists.ibiblio.org

Subject: Baslinux mailing list

List archive

Chronological Thread  
  • From: sindi keesan <keesan AT sdf.lonestar.org>
  • To: baslinux AT lists.ibiblio.org
  • Subject: Re: [BL] Can I make my own scsi kernel?
  • Date: Mon, 21 Feb 2005 03:23:20 +0000 (UTC)

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




Archive powered by MHonArc 2.6.24.

Top of Page