At Wed, 11 Jul 2007 09:45:29 +0800, Gao, Jonathan wrote:
Hi, I am writing a PCM driver on a Soc for 2.6.10 kernel. The test code I'm using is from alsa-lib-1.0.6rc1/test/pcm.c. The runtime log gives me like this...
open callback: hw params callback: alloc result = 1, buffer bytes = 4608
/* --------- HW params ------------- */ format = 2, rate = 44100, channels= 2, period_size = 288, periods = 4, buffer_size = 1152
prepare callback /* --------- Runtime Info ---------- */ state = 1 (SNDRV_PCM_STATE_SETUP), hw_ptr = 0, appl_ptr = 0, avail_min = 288 avail_max = 0, hw_ptr_base = 0, hw_ptr_interrupt = 0
trigger callback: START
Codec Do Copy: /* --------- Runtime Info ---------- */ state = 3 (SNDRV_PCM_STATE_RUNNING), hw_ptr = 0, appl_ptr = 1152, avail_min = 288 avail_max = 0, hw_ptr_base = 0, hw_ptr_interrupt = 0
pointer callback: hw pointer: 288 (return value of pointer callback)
Codec Do Copy: /* --------- Runtime Info ---------- */ state = 3 (SNDRV_PCM_STATE_RUNNING), hw_ptr = 288, appl_ptr = 1152, avail_min = 288 avail_max = 288, hw_ptr_base = 0, hw_ptr_interrupt = 288
pointer callback: hw pointer: 576 (return value of pointer callback)
Codec Do Copy: /* --------- Runtime Info ---------- */ state = 3 (SNDRV_PCM_STATE_RUNNING), hw_ptr = 576, appl_ptr = 1152, avail_min = 288 avail_max = 576, hw_ptr_base = 0, hw_ptr_interrupt = 576
pointer callback: hw pointer: 864 (return value of pointer callback)
Codec Do Copy: /* --------- Runtime Info ---------- */ state = 3 (SNDRV_PCM_STATE_RUNNING), hw_ptr = 864, appl_ptr = 1152, avail_min = 288 avail_max = 864, hw_ptr_base = 0, hw_ptr_interrupt = 864
pointer callback: hw pointer: 0 (return value of pointer callback)
trigger callback: STOP prepare callback /* --------- Runtime Info ---------- */ state = 4 (SNDRV_PCM_STATE_XRUN), hw_ptr = 1152, appl_ptr = 1152, avail_min = 288 avail_max = 1152, hw_ptr_base = 1152, hw_ptr_interrupt = 1152
The kernel hangs after prepare callback, from strace, I can see a endless ioctl(4, ..., ...) repeated. Does anyone have a few pointers on what is going wrong?
One good way for debugging such a blocked process is to see the output of alt+sysrq+t. Then you'll see the kernel stack traces of all processes, and check at which point the test program gets stuck.
Takashi