Re: 3.16 crashes on resume from Suspend-To-disk

From: Takashi Iwai
Date: Thu Aug 07 2014 - 05:34:33 EST


At Wed, 06 Aug 2014 01:15 +0200,
Rafael J. Wysocki wrote:
>
> On Tuesday, August 05, 2014 07:07:09 PM Janek Kozicki wrote:
> > Rafael J. Wysocki said: (by the date of Tue, 05 Aug 2014 03:30:58 +0200)
> >
> > > On Monday, August 04, 2014 09:06:52 AM Markus Gutschke wrote:
> > > > Thanks for checking in. And no, I have not heard from Zhang since my
> > > > last e-mail. I suspect he is still working on finding a solution. But
> > > > you are of course right, reverting the patch in the meantime might be
> > > > a good idea.
> > >
> > > It has too many dependencies. Besides, reverting it now (at the beginning of
> > > a merge window) won't be particularly useful anyway.
> > >
> > > We need to fix it.
> >
> >
> > Hi, sorry for hijacking this thread, but apparently my other plead
> > for help got ignored in this very busy mailing list.
> >
> > I have an up-to-date recently installed debian wheezy. I downloaded
> > https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.16.tar.xz and compiled it using:
> > cp /boot/config-`uname -r` ./.config
> > make menuconfig
> > fakeroot make-kpkg --initrd --append-to-version=-vanilla.1 kernel_image kernel_headers -j38
> > dpkg -i linux-image-3.16.0-vanilla.1_3.16.0-vanilla.1-10.00.Custom_amd64.deb linux-headers-3.16.0-vanilla.1_3.16.0-vanilla.1-10.00.Custom_amd64.deb
> >
> > where .config was taken from debian /boot/config-3.14-0.bpo.1-amd64
> >
> > my PC has 64GB of RAM, 32 Xeon E5-2687W cores and motherboard SuperMicro MBD-X9DRI
> >
> > I just did 25 tries of suspend/resume cycle. I tried 4 different
> > methods of hibernation:
> >
> > 1. /usr/sbin/hibernate # 7 successess, 1 failure
> > 2. /usr/sbin/s2disk # 8 successess, 2 failures
> > 3. echo platform > /sys/power/disk # 0 successess, 5 failures
> > echo disk > /sys/power/state
> > 4. echo shutdown > /sys/power/disk # 2 successess, 3 failures
> > echo disk > /sys/power/state
> >
> >
> >
> > The failure was always a reboot after resume had almost succeeded. In
> > cases when there was a success there was a following ---[cut here]--- part:
>
> This is warning is from _request_firmware() and is triggered by the snd-hda-intel
> driver (audio).
>
> Why don't you file a bug at bugzilla.kernel.org against hibernation/suspend and
> put that information into it?

.... or involve the relevant maintainer :)

I can't tell exactly because of lack of the whole kernel message, but
if my guess is correct, the problem is that the machine has no
firmware installed. Usually, the firmware is cached in the firmware
core code and reused in the resume code path. If the prior
request_firmware() failed, however, the succeeding request_firmware()
at resume will go into the actual f/w loading code, thus it triggers
such a warning.

A quick patch below is an untested fix. Let me know if this really
fixes the issue.


thanks,

Takashi

---
diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c
index 4f3aba78f720..5d8455e2dacd 100644
--- a/sound/pci/hda/patch_ca0132.c
+++ b/sound/pci/hda/patch_ca0132.c
@@ -4376,6 +4376,9 @@ static void ca0132_download_dsp(struct hda_codec *codec)
return; /* NOP */
#endif

+ if (spec->dsp_state == DSP_DOWNLOAD_FAILED)
+ return; /* don't retry failures */
+
chipio_enable_clocks(codec);
spec->dsp_state = DSP_DOWNLOADING;
if (!ca0132_download_dsp_images(codec))
@@ -4552,7 +4555,8 @@ static int ca0132_init(struct hda_codec *codec)
struct auto_pin_cfg *cfg = &spec->autocfg;
int i;

- spec->dsp_state = DSP_DOWNLOAD_INIT;
+ if (spec->dsp_state != DSP_DOWNLOAD_FAILED)
+ spec->dsp_state = DSP_DOWNLOAD_INIT;
spec->curr_chip_addx = INVALID_CHIP_ADDRESS;

snd_hda_power_up(codec);
@@ -4663,6 +4667,7 @@ static int patch_ca0132(struct hda_codec *codec)
codec->spec = spec;
spec->codec = codec;

+ spec->dsp_state = DSP_DOWNLOAD_INIT;
spec->num_mixers = 1;
spec->mixers[0] = ca0132_mixer;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/