Description of problem: I have half a dozen boxes running Linux, and I'm using esd for audio. Three of them have, after running for a day or two, gotten into a state where esd is hung. strace shows that it is in a blocking write to /dev/dsp. I am using the OSS drivers. /dev/dsp is handled by the i810_audio module. Alt-SysRq-T shows this stack trace: kernel: SysRq : Show State kernel: kernel: free sibling kernel: task PC stack pid father child younger older kernel: esd S E89FC000 0 6531 6529 (NOTLB) kernel: Call Trace: [<c011d5e5>] schedule [kernel] 0x125 (0xe89fdec0) kernel: [<c012bb35>] schedule_timeout [kernel] 0x65 (0xe89fdee0) kernel: [<c012bac0>] process_timeout [kernel] 0x0 (0xe89fdf00) kernel: [<f89b39ff>] i810_write [i810_audio] 0x2df (0xe89fdf18) kernel: [<c0153a53>] sys_write [kernel] 0xa3 (0xe89fdf94) I tracked down the source location to the schedule_timeout in i810_audio.c at line 1665 (it's the only call to schedule_timeout in i810_write()). Version-Release number of selected component (if applicable): 2.4.21-20.EL How reproducible: Occasional. (Once every 1-3 days for the boxes that seem to hit it.) Steps to Reproduce: 1. Kill off esd 2. Run an app that auto-spawns esd 3. Restart it over and over Note that the app need not actually play any sound. esd will write zeroes to /dev/dsp, which is enough to see the hang. Actual results: Our app shuts down happily, but then at some point takes a long time to shut down. It then hangs during startup. It is trying to communicate with the esd daemon, which strace shows is trying to write to /dev/dsp. Expected results: An app that happily shuts down and starts up, and an esd that doesn't hang and goes away when its last client closes. Additional info: Looking at that line of i810_write, it looks like it's waiting for a DMA transfer to finish. I don't know how to see what DMA transfers are outstanding, or logging when one is queued up to be sure there is something to wait for. Actually, I don't know anything about DMA other than it standing for either of Direct Memory Access or Dangblasted Maggot Ancestors. I have posted this question to the linux-sound mailing list too.
I have test kernels w/ a later version of i810_audio available here: http://people.redhat.com/linville/kernels/rhel3/ Please give those a try to see if you can recreate the problem with that version of the driver. Thanks!
Closed due to lack of response...please reopen if/when requested information becomes available...