From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262787AbTKVXgh (ORCPT ); Sat, 22 Nov 2003 18:36:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262960AbTKVXgh (ORCPT ); Sat, 22 Nov 2003 18:36:37 -0500 Received: from walfield.org ([209.113.206.50]:7058 "EHLO wilde") by vger.kernel.org with ESMTP id S262787AbTKVXgf (ORCPT ); Sat, 22 Nov 2003 18:36:35 -0500 Date: Sat, 22 Nov 2003 18:22:42 -0500 Message-ID: <8765hcaszh.wl@wilde.walfield.org> From: "Neal H. Walfield" To: zab@zabbo.net cc: linux-kernel@vger.kernel.org Subject: maestro3.c bug using SNDCTL_DSP_SYNC ioctl in 2.4.22 User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org I recently acquired a Dell Latitude CPx 650 with a maestro3 chip. With the 2.4.22 verion of the linux kernel (specifically 2.4.22-1-686 as distributed by Debian), I encountered some problems with the SNDCTL_DSP_SYNC ioctl which is used, for example, by madplay [1]. On startup, madplay calls the SNDCTL_DSP_SYNC ioctl. This causes no problems until I interrupt madplay using control-C. If the next operation is the SNDCTL ioctl (e.g. by starting madplay) then the caller will hang waiting for the ioctl to return (this is easily seen using strace). As far as I can tell, the driver hangs in drain_dac()'s for loop waiting for s->dma_dac.count to drop to zero which it never does. I can use control-C to interrupt it and madplay will exit. Subsequent runs of madplay exhibit the same problem. On the other hand, if I use another audio program such as gnome-vlc (which strace indicates does not call the ioctl in question), it is able to use the audio successfully. After exiting from gnome-vlc, madplay will again work (however, hitting control-C and attempting to start madplay again will cause it to exhibit the same hang). The following work around allows me to use madplay successfully: --- maestro3.c.orig Sat Aug 30 02:01:42 2003 +++ maestro3.c Sat Nov 22 15:52:16 2003 @@ -1291,7 +1291,7 @@ static int drain_dac(struct m3_state *s, int count; signed long tmo; - if (s->dma_dac.mapped || !s->dma_dac.ready) + if (s->dma_dac.mapped || !s->dma_dac.ready || !(s->enable & DAC_RUNNING)) return 0; set_current_state(TASK_INTERRUPTIBLE); add_wait_queue(&s->dma_dac.wait, &wait); If drain_dac ought to work even if the card is not enabled, then maybe this patch is better: --- maestro3.c.orig Sat Nov 22 15:52:16 2003 +++ maestro3.c Sat Nov 22 18:13:25 2003 @@ -1594,7 +1594,7 @@ static int m3_ioctl(struct inode *inode, return put_user(SOUND_VERSION, (int *)arg); case SNDCTL_DSP_SYNC: - if (file->f_mode & FMODE_WRITE) + if ((file->f_mode & FMODE_WRITE) && !(s->enable & DAC_RUNNING)) return drain_dac(s, file->f_flags & O_NONBLOCK); return 0; I have no idea if either of these are correct fix. There may, for instance, be unaccounted dma packets that need cleaning up; I haven't looked that deeply into the code to be able to tell. Thanks. [1] http://www.underbit.com/products/mad/