From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend Date: Fri, 06 Jul 2007 18:19:35 +0200 Message-ID: References: <468E63BC.6070401@leemhuis.info> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id EDC8B103819 for ; Fri, 6 Jul 2007 18:19:43 +0200 (CEST) In-Reply-To: <468E63BC.6070401@leemhuis.info> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Thorsten Leemhuis Cc: alsa-devel@alsa-project.org, Matt Mullins List-Id: alsa-devel@alsa-project.org At Fri, 06 Jul 2007 17:46:04 +0200, Thorsten Leemhuis wrote: > > Hi! > > FYI, I own the same laptop-model as Matt and have similar (identical?) > problems. > > On 06.07.2007 11:32, Takashi Iwai wrote: > > At Thu, 5 Jul 2007 21:42:21 -0500, > > Matt Mullins wrote: > >> Found what I think is the problem... patch_sigmatel.c set > >> spec->num_pins=14, yet spec->pin_nids pointed to stac9205_pin_nids, > >> which was an array of only 12 NIDs. That caused [total guess here] > >> either stac92xx_save_bios_config_regs or stac92xx_set_config_regs to > >> read past the end of the array and into an uninitialized area. I > >> changed the 14 to a 12, and it seems to work. The attached patch is > >> against the current Mercurial sources, but I made the similar change > >> to kernel 2.6.22-rc7, and it doesn't use single_cmd anymore. > > Argh! Thanks for spotting this nasty bug. > > Agreed; Matt, thx for your work. > > > It'd be better to use ARRAY_SIZE there. Then typos would be more > > obvious. Could you check the patch below? > > Works fine for me (patch was applied to alsa-driver 1.0.14 sources and > compiled against/tested on a Fedora 2.6.21 kernel and a 2.6.22-rc7-git3 > kernel from the Fedora devel tree) Thanks for confirmation. I committed the patch to HG tree now. > >> It still > >> doesn't work after a suspend, though, making me unload and reload the > >> module. > > Do you mean you'll get a communication error after suspend, or got no > > sound output, or any other problem? > > I simply don't get any audio output at all after either suspend or > hibernate. Reloading the module after suspend/hibernate makes the sound > working again. Doesn't changing the mixer values after resume have any effect? Also, could you compare the codec#* proc dump before and after suspend/resume? thanks, Takashi