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: <CAHB_Gup0uaOrr9R5qaydc2057o-L290Jwqd2iC0-+tsEwzKbQQ@mail.gmail.com>
Date:	Mon, 18 Jul 2016 17:17:44 +0530
From:	Pratyush Anand <panand@...hat.com>
To:	alexandre.belloni@...e-electrons.com,
	Alessandro Zummo <a.zummo@...ertech.it>
Cc:	rtc-linux@...glegroups.com,
	open list <linux-kernel@...r.kernel.org>,
	Prarit Bhargava <prarit@...hat.com>,
	RuiRui Yang <dyoung@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>, mingo@...nel.org
Subject: Re: [PATCH RFC 0/2] rtc-cmos: Workaround unwanted interrupt generation

Hi RTC-Maintainers,


On Mon, Jul 4, 2016 at 9:49 PM, Pratyush Anand <panand@...hat.com> wrote:
> On 27/06/2016:10:19:07 AM, Pratyush Anand wrote:
>> On 21/06/2016:10:25:34 AM, Pratyush Anand wrote:
>> > We have observed on few machines with rtc-cmos device that
>> > hpet_rtc_interrupt() is called before cmos_do_probe() could call
>> > hpet_rtc_timer_init(). It has not been observed during normal boot/reboot
>> > of machines. It *sometime* happens when system is booted with kdump
>> > secondary kernel. So, neither hpet_default_delta nor hpet_t1_cmp is
>> > initialized by the time interrupt is raised in the given situation.
>> > Therefore while loop of hpet_cnt_ahead() in hpet_rtc_timer_reinit() never
>> > completes. This leads to "NMI watchdog: Watchdog detected hard LOCKUP on
>> > cpu 0".
>> >
>> > I am still clueless, how can an interrupt be raised before RTC is enabled.
>> > But i do not have any idea about this device, so I am putting this patch as
>> > RFC to get feedback from hpet/rtc-cmos developer. I am sure there would be
>> > some better solution than this.
>>
>> Do you think that if I improve commit log of patches as pointed by Thomas and
>> send a formal version of these patches, then they should acceptable to upstream?
>
> A gentle reminder for your comment/feedback :-)

Please let me know how to make progress on this. If you think, there
could be some better way to handle this issue then please let me know.
If you need any more data then also please let me know.

~Pratyush

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ