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

Re: Better work-around: Re: SoundBlaster Live (emu10k1) on PWS433



On Fri, 2002-07-19 at 23:24, Jay Estabrook wrote:
> On Fri, Jul 19, 2002 at 10:17:50PM +0200, Dannis 't Hart wrote:
> > On Fri, 2002-07-19 at 18:15, Jay Estabrook wrote:
> > > 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
> > > 
> > Well, yes indeed, this sounds reasonable, doesn't it?
> > I tried it, and it works!!!! It's actually all that's required, as far
> > as I can see, for now.
> 
> Yes, and I feel much better about this solution than allowing the
> scatter/gather DMA to be used.
> 
> I think that the scatter/gather DMA will actually work without problems
> when used across the PCI-PCI bridge (ie to one of the 32-bit slots),
> because the transfers get broken up by the HW so that the 8K boundary
> crossing is never done. But I'd rather avoid it completely by making
> direct-map usable by all your devices, even the broken ones... ;-}
> 
> OBTW, I think you should be able to put the Voodoo3 3000 in one of the
> 64-bit slots (better performance when not going through the bridge),
> if you tell SRM:
> 
> 	>>> set pci_device_override -1
> 
> But do the above *before* you try moving the card... ;-}
> 
You are correct. Untill yesterday I did have the Voodoo3 in a 64-bit PCI-slot.
And I did have pci_device_override set to -1 (0xffffffff). Since I had
the case opened anyway to get the memory-modules out, I also wanted to
be conservative with regard to the 32/64-bit PCI slots. I had to set
pci_device_override [DEVICE_ID][VENDOR_ID] to get it to work, though...
Anyway, I'll change it on the next reboot. I'm now building a kernel
with framebuffer support, because the documentation of mplayer seems to
indicate that that may give a considerable performance boost. It also
says I'd have to use XFree >= 4.2, though. That may prove another
challenge, we'll see :-)
So far, mplayer is now playing 'The Mummy', eating approx. 20% cpu,
according to top. I can live with that, but I'll see what's possible...

Thanx,

Dannis.
 



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



Reply to: