Re: SoundBlaster Live (emu10k1) on PWS433
On Fri, Jul 19, 2002 at 02:02:09PM +0200, Dannis 't Hart wrote:
>
> 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.
That's it, in a nutshell...
> Yes, I'm affraid so; dmesg says:
> pci: cia revision 1 (pyxis)
> So, it's the old Miata with the buggy chipset.
Yup.
> 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.
As we might have expected, due to the nature of the problem...
> 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.
Exactly.
>
> 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_ !
Well, the sound would probably be the first actual DMA that was tried,
and that's when the failure would occur.
> 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?
Well, not necessarily 32-bits, but perhaps 31... ;-}
On LX with 2.2.x kernels, the direct-map windows are set up starting
at 1GB, so a 31-bit address is all that's needed.
Which suggests that for a 2.4.19 kernel, you might try changing those
lines in arch/alpha/kernel/core_cia.c to:
__direct_map_base = 0x40000000;
__direct_map_size = 0x40000000;
and change the mask to:
#define EMU10K1_DMA_MASK 0x7fffffff
If that doesn't work, pull out the 2 32MB memory modules, and do:
__direct_map_base = 0x20000000;
__direct_map_size = 0x20000000;
and change the mask to:
#define EMU10K1_DMA_MASK 0x3fffffff
to see if a 30-bit address/mask will work.
> 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.
Oh, yeah, Voodoo3 3000 works very nicely on MIATA... :-) :-)
Good luck, keep us posted...
--Jay++
-----------------------------------------------------------------------------
Jay A Estabrook HPTC - LINUX support
Hewlett-Packard Company - MRO1-2/K15 (508) 467-2080
200 Forest Street, Marlboro MA 01752 Jay.Estabrook@hp.com
-----------------------------------------------------------------------------
--
To UNSUBSCRIBE, email to debian-alpha-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: