[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SoundBlaster Live (emu10k1) on PWS433



On Thu, 2002-07-18 at 18:53, Jay Estabrook wrote:
> On Thu, Jul 18, 2002 at 02:55:58PM +0200, Dannis 't Hart wrote:
> > Has anyone got a Soundblaster live (emu10k1) working succesfully on
> > alpha?
> >
> > ......
> > /proc/pci says:
> > 
> > Bus  1, device   9, function  0:
> >  Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 8).
> >  IRQ 40.
> >  Master Capable.  Latency=32.  Min Gnt=2.Max Lat=20.
> >  I/O at 0x9400 [0x941f].
> >  
> > Bus  1, device   9, function  1:
> >  Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 8).
> >  IRQ 40.
> >  Master Capable.  Latency=32.  
> >  I/O at 0x9420 [0x9427].
> > 
> > While 'tail /var/log/messages' appears to indicate some hardware
> > trouble???
> >
> >....... 
> > Jul 18 14:51:29 tachyon kernel: pci_map_single: no HW sg
> 
> Given that message, there must have been some earlier messages
> that should have warned you that something was amiss on your
> machine, concluding with something like:
> 
> 	"pci: disabling sg translation window\n"

I'm not sure where I would be able to find such a message, but dmesg
does tell me:

POSIX conformance testing by UNIFIX
pci: passed tb register update test
pci: passed sg loopback i/o read test
pci: passed pte write cache snoop test
pci: failed valid tag invalid pte reload test (mcheck; workaround
available)
pci: passed pci machine check test
pci: tbia workaround enabled
pci: pyxis 8K boundary dma bug - sg dma disabled
Linux NET4.0 for Linux 2.4

I suppose this means the same sort of thing as what you meant :-(
No good news.
> 
> Why the setup code should fail to be able to use hardware
> scatter/gather on your MIATA is unknown by me; since it's a 433, it
> may be an early one with PYXIS pass1, which may have such a problem.

Yes, I'm affraid so; dmesg says:
pci: cia revision 1 (pyxis)
So, it's the old Miata with the buggy chipset.

> All the code is in arch/alpha/kernel/core_cia.c if you are curious.

Well, I am curious, and I did look. But I'm not a programmer and this
stuff is beyond me, unfortunately.
> 
> But the real question is why it should fail to be able to direct-map
> the address, given that you probably have less than 2GB of memory in
> your machine (right?).
Correct. It has 576 MB. I started out with 64 MB when I bought it. Later
figured it would probably benefit much from more mem, so bought an
additional 512 MB. This is physically 2 modules of 32 MB and 2 modules
of 256 MB.

> 
> Well, the direct-map window for PCI DMA on MIATA is set up to start at
> 2GB (0x80000000); but if we look in the EMU10K1 code, we see that the
> device itself is incapable of issuing addresses larger than 512MB-1,
> as evidenced by:
> 
> #define EMU10K1_DMA_MASK 0x1fffffff /* DMA buffer mask for pci_alloc_consist */
> 
> What this means is that the device can't issue an address onto the PCI
> bus that will fall into the range of addresses detected by the PYXIS
> core logic as being part of the direct-map window.
Aha! I had no clue whatsoever.

> Given the failure of your MIATA hardware to support scatter/gather
> operation, and the EMU10K1 failure to generate enough address bits,
> one hope is the following workaround:
> 
> 1. if you have 256MB of memory or less, and
> 2. if you don't have any PCI devices that take large chunks of
>    PCI address space (graphics are the prime suspects here, and
>    there may be additional workaround needed if so)
> 
> Then, replace the following two lines in arch/alpha/kernel/core_cia.c:
> 
>         __direct_map_base = 0x80000000;
>         __direct_map_size = 0x80000000;
> 
> with the following two lines:
> 
>         __direct_map_base = 0x10000000;
>         __direct_map_size = 0x10000000;
> 
> rebuild your kernel, and pray... :-)

Ok. I tried this, and it actually works. I didn't do much intensive
testing, but appearantly nothing seemed to break. The sad point is, as
you stated in condition 1., 256 MB or less. I pulled out the modules
which make up 512 MB, and was left with 64 MB, but your workaround DID
work! Putting back the 512 MB gave a lot of errors during boot ending in
a kernel-panic.

So, changing that core_cia.c back to its original values, I looked into
the emu10k1 source, and decided to try another thing.
/usr/src/linux/drivers/sound/emu10k1/main.c states in its revision
history:

 *     0.17 Fix for mixer SOUND_MIXER_INFO ioctl.
 *          Fix for HIGHMEM machines (emu10k1 can only do 31 bit bus
master)
 *          midi poll initial implementation.
 *          Small mixer fixes/cleanups.
 *          Improved support for 5.1 cards.
 *     0.18 Fix for possible leak in pci_alloc_consistent()
 *          Cleaned up poll() functions (audio and midi). Don't start
input.
 *          Restrict DMA pages used to 512Mib range.
 *          New AC97_BOOST mixer ioctl.
 *     0.19 Real fix for kernel with highmem support (cast dma_handle to
u32)
 *          Fix recording buffering parameters calculation
 *          Use unsigned long for variables in bit ops.

Well, currently (kernel 2.4.19-rc2) the source of emu10k1 is at version
0.19, and, as you stated it says:
#define EMU10K1_DMA_MASK 0x1fffffff /* DMA buffer mask for
pci_alloc_consist */
So, that's 29 bits, right?
But, in version 0.17 of the emu10k1 source, as above, it says it can do
31 bits. So, I decided to try and change the EMU10K1_DMA_MASK to
0x7ffffff, and rebuild the kernel.
Unfortunately, it didn't help. Got the same errors on trying to modprobe
emu10k1. Well, on second thought, this seems logical; it runs into the
same problem you already described, because 0x7fffffff < 0x80000000.

Now, looking further back at even older source of emu10k1, I decided to
try:
#define EMU10K1_DMA_MASK 0xffffffff
to allow it 32 bits, as it was upto version 0.16 of the driver. After
all, the line above the #define in the 0.19 source was:
/* the emu10k1 _seems_ to only supports 29 bit (512MiB) bit bus master
*/

_seems_ it says, so I figured the author wasn't altogether sure...

And guess what happened? With the 32 bits, the modprobe emu10k1 worked
just fine, no errors reported, and module nicely loaded.
BUT, although now I could load TkMixer and XMMS without problems, NO
sound came out of the speakers :-(
Guess now I know why the author said _seems_ !

That's not even all, read on for another surprise!
I decided to compile a 2.2.21 kernel. It has a much older source of
emu10k1, namely version 0.7. It also has #define EMU10K1_DMA_MASK
0xffffffff.
Also, core_cia.c and related seemed a lot different from 2.4.x
kernels...
Now guess what? Compiling 2.2.21 went fine, booting it went fine and
even modprobe emu10k1 went fine! Moreover, I now have working sound with
the emu10k1 on my Miata, albeit a 2.2 kernel!

So, I was wondering, might this be some sort of proof that the emu10k1
can use a 32-bit DMA_MASK? Or would this be a wrong conclusion
considering a completely (?) different method of setting up DMA on 2.2
kernels?
> 
> Let us know what happens, as you may not be the only one to encounter
> this problem. Thanks!

Well, up until now it seems I can't get all of these combined working
harmoniously:
1) emu10k1
2) the full 576 MB of memory
3) a 2.4.x kernel
Still, I hope it can be solved. I'm open to suggestions! 
BTW, the built-in sb (an ESS1888) works with both 2.2.x and 2.4.x, but
doesn't have nice sound, nor features.
Furthermore, I'd like to use a 2.4 kernel; I got a 3Dfx Voodoo3 3000 in
my Miata, so I'd like to use the DRM.

Jay, thanks! You inspired the above experiments. I hope you have more
suggestions.

Dannis.
 



-- 
To UNSUBSCRIBE, email to debian-alpha-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: