Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1445414 > unrolled thread

Re: [PATCH RFC 0/2] rtc-cmos: Workaround unwanted interrupt generation

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH RFC 0/2] rtc-cmos: Workaround unwanted interrupt generation Pratyush Anand <panand@redhat.com> - 2016-07-18 13:50 +0200
    Re: [PATCH RFC 0/2] rtc-cmos: Workaround unwanted interrupt  generation Alexandre Belloni <alexandre.belloni@free-electrons.com> - 2016-07-19 16:30 +0200
      Re: [PATCH RFC 0/2] rtc-cmos: Workaround unwanted interrupt  generation Pratyush Anand <panand@redhat.com> - 2016-07-20 06:00 +0200

#1445414 — 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@redhat.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

[toc] | [next] | [standalone]

#1446518 — Re: [PATCH RFC 0/2] rtc-cmos: Workaround unwanted interrupt generation

Hi,

On 18/07/2016 at 17:17:44 +0530, Pratyush Anand wrote :
> Hi RTC-Maintainers,
> 
> 
> On Mon, Jul 4, 2016 at 9:49 PM, Pratyush Anand <panand@redhat.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.
> 

Well, the change is x86 specific and I don't know much about HPET so
until you get an ack from the x86 maintainers, I guess I can't help
much.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1446930 — Re: [PATCH RFC 0/2] rtc-cmos: Workaround unwanted interrupt generation

On 19/07/2016:04:29:07 PM, Alexandre Belloni wrote:
> Hi,
> 
> On 18/07/2016 at 17:17:44 +0530, Pratyush Anand wrote :
> > Hi RTC-Maintainers,
> > 
> > 
> > On Mon, Jul 4, 2016 at 9:49 PM, Pratyush Anand <panand@redhat.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.
> > 
> 
> Well, the change is x86 specific and I don't know much about HPET so
> until you get an ack from the x86 maintainers, I guess I can't help
> much.

Thanks Alexandre for your reply.

Thomas, Ingo, Peter, Your comment/feedback will be very helpful to make progress
on this.

~Pratyush

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web