rtc-cmos: Workaround unwanted interrupt generation

RFC PATCH Superseded Pratyush Anand 3 participants 10 messages Jun 21, 2016 – Jul 20, 2016

Subsystems (3)

x86 Real time clock (RTC) Hpet: x86

lore

Share & tools

lore

Pratyush Anand

author

2016-06-21 04:55 UTC #0 lore raw

cover rtc-cmos: Workaround unwanted interrupt generation

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.

Pratyush Anand (2):
rtc/hpet: Factorize hpet_rtc_timer_init()
rtc/rtc-cmos: Initialize software counters before irq is registered

 arch/x86/include/asm/hpet.h |  2 ++
 arch/x86/kernel/hpet.c      | 41 +++++++++++++++++++++++++++++++++++------
 drivers/rtc/rtc-cmos.c      | 13 ++++++++++++-
 3 files changed, 49 insertions(+), 7 deletions(-)

Signature · 11 lines

2.5.5

-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Pratyush Anand

author

2016-06-21 04:56 UTC #1 lore raw

RFC PATCH 1/2 rtc/hpet: Factorize hpet_rtc_timer_init()

This patch factorize hpet_rtc_timer_init(), so that counter can be initialized before irq is registered.

Signed-off-by Pratyush Anand <[email protected]>

---
 arch/x86/include/asm/hpet.h |  2 ++
 arch/x86/kernel/hpet.c      | 41 +++++++++++++++++++++++++++++++++++------
 2 files changed, 37 insertions(+), 6 deletions(-)

arch/x86/include/asm/hpet.h +2 -0

index cc285ec4b2c1..8eecb31bebcb 100644
@@ -96,6 +96,8 @@ extern int hpet_set_alarm_time(unsigned char hrs, unsigned char min,
 			       unsigned char sec);
 extern int hpet_set_periodic_freq(unsigned long freq);
 extern int hpet_rtc_dropped_irq(void);
+extern int hpet_rtc_timer_counter_init(void);
+extern int hpet_rtc_timer_enable(void);
 extern int hpet_rtc_timer_init(void);
 extern irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id);
 extern int hpet_register_irq_handler(rtc_irq_handler handler);

arch/x86/kernel/hpet.c +35 -6

61 lines not on this page · raw message

Signature · 11 lines

2.5.5

-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Thomas Gleixner

2016-06-23 08:35 UTC #2 lore raw

Re: [PATCH RFC 1/2] rtc/hpet: Factorize hpet_rtc_timer_init()

Quoted 2 lines · Pratyush Anand

This patch factorize hpet_rtc_timer_init(), so that counter can be initialized before irq is registered.

This changelog is useless. It tells what the patch does, but not WHY this is required.

Thanks,

tglx

Pratyush Anand

author

2016-06-23 14:37 UTC #3 lore raw

Re: [PATCH RFC 1/2] rtc/hpet: Factorize hpet_rtc_timer_init()

Hi Thomas,

Quoted 7 lines · Thomas Gleixner

Quoted 2 lines · Pratyush Anand
This patch factorize hpet_rtc_timer_init(), so that counter can be initialized before irq is registered.
This changelog is useless. It tells what the patch does, but not WHY this is required.

Sorry, I have described the problem in the cover letter which is here [1]. Please, let me know if any further test/debug result you would need.

Thanks for your help!!

~Pratyush

[1] https://lkml.org/lkml/2016/6/21/35

Signature · 8 lines

You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Pratyush Anand

author

2016-06-21 04:56 UTC #4 lore raw

RFC PATCH 2/2 rtc/rtc-cmos: Initialize software counters before irq is registered

In reply to Pratyush Anand

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 initializing software counters in this patch so that LOCKUP could be avoided. Even if it resolves the issue, I understand that proposed patch may not be the best way to solve this issue.

Signed-off-by Pratyush Anand <[email protected]>

---
 drivers/rtc/rtc-cmos.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

drivers/rtc/rtc-cmos.c +12 -1

index fbe9c72438e1..101dc948295f 100644
@@ -129,6 +129,16 @@ static inline int hpet_rtc_dropped_irq(void)
 	return 0;
 }
 
+static inline int hpet_rtc_timer_counter_init(void)
+{
+	return 0;
+}
+
+static inline int hpet_rtc_timer_enable(void)
+{
+	return 0;
+}
+
 static inline int hpet_rtc_timer_init(void)
 {
 	return 0;

@@ -710,6 +720,7 @@ cmos_do_probe(struct device *dev, struct resource *ports, int rtc_irq)
 		goto cleanup1;
 	}
 
+	hpet_rtc_timer_counter_init();
 	if (is_valid_irq(rtc_irq)) {
 		irq_handler_t rtc_cmos_int_handler;

@@ -732,7 +743,7 @@ cmos_do_probe(struct device *dev, struct resource *ports, int rtc_irq)
 			goto cleanup1;
 		}
 	}
-	hpet_rtc_timer_init();
+	hpet_rtc_timer_enable();
 
 	/* export at least the first block of NVRAM */
 	nvram.size = address_space - NVRAM_OFFSET;

Signature · 11 lines

2.5.5

-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Pratyush Anand

author

2016-06-27 04:49 UTC #5 lore raw

In reply to Pratyush Anand

Quoted 10 lines · Pratyush Anand

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".

Quoted 4 lines

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?

Thanks

~Pratyush

Quoted 14 lines

Pratyush Anand (2):
rtc/hpet: Factorize hpet_rtc_timer_init()
rtc/rtc-cmos: Initialize software counters before irq is registered
 arch/x86/include/asm/hpet.h |  2 ++
 arch/x86/kernel/hpet.c      | 41 +++++++++++++++++++++++++++++++++++------
 drivers/rtc/rtc-cmos.c      | 13 ++++++++++++-
 3 files changed, 49 insertions(+), 7 deletions(-)
Signature · 1 line
2.5.5

Signature · 8 lines

You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Pratyush Anand

author

2016-07-04 16:19 UTC #6 lore raw

Quoted 11 lines · Pratyush Anand

Quoted 10 lines · Pratyush Anand
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".

Quoted 7 lines

Quoted 4 lines
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 :-)

~Pratyush

Signature · 8 lines

You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Pratyush Anand

author

2016-07-18 11:47 UTC #7 lore raw

Hi RTC-Maintainers,

Quoted 17 lines · Pratyush Anand

Quoted 16 lines · Pratyush Anand
Quoted 14 lines · Pratyush Anand
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.

Quoted 4 lines

Quoted 2 lines
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

Signature · 8 lines

You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Alexandre Belloni

2016-07-19 14:29 UTC #8 lore raw

Hi,

Quoted 21 lines · Pratyush Anand

Hi RTC-Maintainers,
Quoted 17 lines · Pratyush Anand
Quoted 16 lines · Pratyush Anand
Quoted 14 lines · Pratyush Anand
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.

Quoted 9 lines

Quoted 4 lines
Quoted 2 lines
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.

Signature · 13 lines

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

-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Pratyush Anand

author

2016-07-20 03:57 UTC #9 lore raw

Quoted 29 lines · Alexandre Belloni

Hi,
Quoted 26 lines · Pratyush Anand
Hi RTC-Maintainers,
Quoted 21 lines · Pratyush Anand
Quoted 11 lines · Pratyush Anand
Quoted 10 lines · Pratyush Anand
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".
Quoted 7 lines
Quoted 4 lines
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 :-)

Quoted 8 lines

Quoted 4 lines
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

Signature · 8 lines

You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.