linux-kernel - Re: [REGRESSION] rtc/interface.c: kills suspend-to-ram

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFLxGvzkcYw-iUA1X8jK+Q8A2HFEG1SSXvfZ3Uj+OwKWgi+zAA@mail.gmail.com>
Date:	Mon, 16 Apr 2012 16:23:36 +0200
From:	richard -rw- weinberger <richard.weinberger@...il.com>
To:	Mark Lord <kernel@...savvy.com>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>,
	rtc-linux@...glegroups.com,
	Alessandro Zummo <a.zummo@...ertech.it>,
	Greg Kroah-Hartman <greg@...ah.com>, stable@...r.kernel.org,
	John Stultz <john.stultz@...aro.org>
Subject: Re: [REGRESSION] rtc/interface.c: kills suspend-to-ram

On Mon, Apr 16, 2012 at 3:55 PM, Mark Lord <kernel@...savvy.com> wrote:
> On 12-04-16 12:36 AM, Mark Lord wrote:
>> Something recent has killed suspend-to-ram on a number of machines here.
>> The symptom is that they suspend, but immediately wake up and panic,
>> with just a black screen so no visible messages to go by.
>>
>> The patch below works around the issue -- making things work as they used to work.
>>
>> +++ linux/drivers/rtc/interface.c     2012-04-16 00:09:14.105387382 -0400
>> @@ -773,7 +773,7 @@
>>       if (!rtc->ops || !rtc->ops->alarm_irq_enable)
>>               return;
>>
>> -     rtc->ops->alarm_irq_enable(rtc->dev.parent, false);
>> +     //rtc->ops->alarm_irq_enable(rtc->dev.parent, false);  // Kills suspend on ZBOX HD-ID41U
>>  }
>>
>> Last known working kernel was 3.2.11.
>> The line above got added somewhere between it and 3.2.15,
>> and is also present (no surprise) in newer kernels.
>>
>> The highest kernel I've tested for this is 3.3.2,
>> which also fails until I nuke the line shown above.
>>
>> This is straight x86_64 (Atom) hardware, using rtc-cmos.
>> I can re-test if anyone has a fix for this.
>>
>> Meanwhile, whatever patch put this into -stable probably
>> ought to be reverted upstream and in -stable as well.
>
>
> Speaking of which -- that batch of RTC updates is riddled with bugs.
> For example, this beauty from rtc-mpc5121.c in the same update:
>
>        ...
>        rtc->rtc = rtc_device_register("mpc5200-rtc", &op->dev,
>                                        &mpc5200_rtc_ops, THIS_MODULE);
>        ...
>
>        rtc->rtc->uie_unsupported = 1;    // <<<< Ooops NULL pointer >>>>
>
>        if (IS_ERR(rtc->rtc)) {           // <<<< this needs to be earlier >>>>
>                err = PTR_ERR(rtc->rtc);
>                goto out_free_irq;
>        }
>        ...
>
> Can somebody show me how to identify the commit from the code?
> I know which lines got changed, but don't know how to find
> the corresponding commits in -git.

CC'in John.

---
commit 4a649903f91232d02284d53724b0a45728111767
Author: John Stultz <john.stultz@...aro.org>
Date:   Tue Mar 6 17:16:09 2012 -0800

    rtc: Provide flag for rtc devices that don't support UIE

    Richard Weinberger noticed that on some RTC hardware that
    doesn't support UIE mode, due to coarse granular alarms
    (like 1minute resolution), the current virtualized RTC
    support doesn't properly error out when UIE is enabled.

    Instead the current code queues an alarm for the next second,
    but it won't fire until up to a miniute later.

    This patch provides a generic way to flag this sort of hardware
    and fixes the issue on the mpc5121 where Richard noticed the
    problem.

    CC: stable@...r.kernel.org
    Reported-by: Richard Weinberger <richard@....at>
    Tested-by: Richard Weinberger <richard@....at>
    Signed-off-by: John Stultz <john.stultz@...aro.org>

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