Re: [PATCH 2.6.13-rc5-gitNOW] msleep() cannot be used from interrupt
From: Petr Vandrovec
Date: Fri Aug 05 2005 - 09:45:12 EST
linux-os (Dick Johnson) wrote:
On Fri, 5 Aug 2005, Petr Vandrovec wrote:
Hello Linus,
can you apply patch below?
Since beginning of July my Opteron box was randomly crashing and being rebooted
by hardware watchdog. Today it finally did it in front of me, and this patch
will hopefully fix it.
Problem is that at the end of June (28th, commit
47f176fdaf8924bc83fddcf9658f2fd3ef60d573, [PATCH] Using msleep() instead of HZ)
rtc_get_rtc_time was converted to use msleep() instead of busy waiting. But
rtc_get_rtc_time is used by hpet_rtc_interrupt, and scheduling is not allowed
during interrupt. So I'm reverting this part of original change, replacing
msleep() back with busy loop.
Original old code was busy waiting for 20ms, while on my hardware in the worst
case update-in-progress bit was asserted for at most 363 passes through loop
(on 2GHz dual Opteron), much less than even one jiffie, not even talking
about 20ms. So I changed code to just wait only as long as necessary. Otherwise
when RTC was set to generate 8192Hz timer, it stopped doing anything for
20ms (160 pulses were skipped!) from time to time, and this is rather suboptimal
as far as I can tell.
Thanks,
Petr Vandrovec
It this is called from an interrupt (I hope not), jiffies will
not change unless you have two or more CPUs. Please don't do this.
Just spin while rtc is updating some maximum number of loops.
It is called from rtc interrupt (hpet_rtc_interrupt calls it, if
you really want I'll reproduce oopses about scheduling in the
interrupt again and post it here for you convience). But
being inside rtc interrupt should not prevent jiffies from being
incremented as system timer has higher priority than rtc. We had
code which looped around until jiffies expired for years and as far
as I know nobody complained that boxes deadlock from time to time.
I just added test for 'rtc_is_updating()' to the test.
Petr
Signed-off-by: Petr Vandrovec <vandrove@xxxxxxxxxx>
diff -urdN linux/drivers/char/rtc.c linux/drivers/char/rtc.c
--- linux/drivers/char/rtc.c 2005-08-05 12:43:54.000000000 +0000
+++ linux/drivers/char/rtc.c 2005-08-05 13:26:48.000000000 +0000
@@ -1209,6 +1209,7 @@
void rtc_get_rtc_time(struct rtc_time *rtc_tm)
{
+ unsigned long uip_watchdog = jiffies;
unsigned char ctrl;
#ifdef CONFIG_MACH_DECSTATION
unsigned int real_year;
@@ -1224,8 +1225,10 @@
* Once the read clears, read the RTC time (again via ioctl). Easy.
*/
- if (rtc_is_updating() != 0)
- msleep(20);
+ while (rtc_is_updating() != 0 && jiffies - uip_watchdog < 2*HZ/100) {
+ barrier();
+ cpu_relax();
+ }
/*
* Only the values that we read from the RTC are set. We leave
-
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/
Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@xxxxxxxxxxxx - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
-
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/