At Tue, 19 Dec 2006 10:12:54 -0500, David Cullen wrote: > In alsa-driver-1.0.13/acore/memalloc.c there is this section of code > > /* > * Hacks > */ > > #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0) > #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 5) > > I am using a patched 2.6.13 kernel. Should I change that last line > to be KERNEL_VERSION(2, 6, 13)? That part is a workaround only for the old 2.6 kernels which cause Oops when NULL is passed to device pointer. So, it should be irrelevant. > Also, could you give me some pointers regarding my previous e-mails > regarding this issue: > > Takashi Iwai wrote: > > At Mon, 27 Nov 2006 17:01:52 -0500, > > David Cullen wrote: > >> > >> I am trying to get ALSA version 1.0.13 working on an AMCC PowerPC > >> PPC405EP Taihu board with a Sound Blaster Live! 24-bit 7.1 PCI > >> card. I am using a patched 2.6.13 kernel that comes with the > >> board. I built the kernel with the sound core built in and I > >> used the cross-compiler tools to build the ALSA driver, library, > >> and utils. When I run "speaker-test", it crashes in the ALSA > >> library. The problem is that the call to mmap in > >> > >> alsa-lib-1.0.13/src/pcm/pcm_mmap.c line 367 > >> > >> which looks like > >> > >> ptr = mmap(NULL, size, PROT_READ|PROT_WRITE, > >> MAP_FILE|MAP_SHARED, i->u.mmap.fd, i->u.mmap.offset); > >> > >> returns a pointer that appears to be valid (0x3001E000) but > >> causes a kernel OOPS when accessed. > >> > >> Previous calls to mmap in pcm_hw.c on lines 822 and 854 both > >> succeed, and the pointers returned can be successfully accessed, > >> but they use the status and control offsets as parameters to > >> mmap. > >> > >> I haved traced the problem on the target into the ALSA library > >> using gdb and into the kernel using kgdb and everything looks > >> like it works properly. If I disable the semaphore acquisition > >> in do_mmap2, I can print the contents of the address in kgdb > >> using > >> > >> (gdb) print ((char *)vma->vm_start)[0] > >> > >> after the call to vm_link in do_mmap_pgoff. However, the board > >> locks up after the print command. > >> > >> Anyone have any experience with this type of problem on PowerPC > >> systems? > > > > Possibly a memory coherency problem. The memory allocated via > > dma_alloc_coherent() isn't simply mmappable. > > > > An essential fix would be to add dma_mmap_coherent() to all > > architectures and use it for ALSA mmap. I made some patches quite > > ago, but left it rotten for the time being... > > > > How do I "add dma_mmap_coherent() to all architectures and use it > for ALSA mmap"? Well, for that, we need to patch the kernel itself and add dma_mmap_coherent() call. The problem is that the memory returned from dma_alloc_coherent() isn't the address of the really allocated pages in your case. Since the ALSA mmap mode obtains the page via virt_to_page(), this doesn't work. Thus, a new function, dma_mmap_coherent() is required to calculate the real page address and do the rest of low-level mmap jobs. A simple solution would be simply disable mmap. In pci/ca0106/ca0106_main.c, remove SNDRV_PCM_INFO_MMAP and SNDRV_PCM_INFO_MMAP_VALID from snd_ca0106_playback_hw and snd_ca0106_capture_hw structs. Also, disable #if defined(CONFIG_PPC) around snd_pcm_mmap_status_*() in core/pcm_native.c. This will reduce the sound system functionality (e.g. no dmix is available), though. BTW, any chance to try a newer version of kernel? I don't want to debug the issues of old kernels but rather fix the latest kernel... Takashi ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
