IRQ deadlocks

[Robert G. Brown]

On Tue, 22 Sep 1998, System Administrator wrote:

> 
> ok, it froze this morning with 2.0.35 and pre10. I tried patching pre10
> against 2.0.33 but it failed.

The stuff below should be cross-posted to linux-smp.  You're really
moving out of the realm of aic7xxx per se, as now you really are talking
a generic SMP bug that might hit anybody running a high performance U2W
driver.


> I did however discover something that may be relevant. Normally with SMP
> you enable RTC support in the kernel. in linux/Documentation/rtc.txt
> it says:
> 
> "
> At high frequencies, or under high loads, the user process should check
> the number of interrupts received since the last read to determine if
> there has been any interrupt "pileup" so to speak. Just for reference, a
> typical 486-33 running a tight read loop on /dev/rtc will start to suffer
> occasional interrupt pileup (i.e. > 1 IRQ event since last read) for
> frequencies above 1024Hz. So you really should check the high bytes
> of the value you read, especially at frequencies above that of the
> normal timer interrupt, which is 100Hz.
> "
> 
> procinfo shows for rtc:
> irq  0:    216740   timer               irq  8:         0 + rtc                
> 
> then rtc.txt says:
> "
> Also, if the kernel time is synchronized with an external source, the 
> kernel will write the time back to the CMOS clock every 11 minutes. In 
> the process of doing this, the kernel briefly turns off RTC periodic 
> interrupts, so be aware of this if you are doing serious work. If you
> don't synchronize the kernel time with an external source (via ntp or
> whatever) then the kernel will keep its hands off the RTC, allowing you
> exclusive access to the device for your applications.
> "
> 
> I sync my time via caldera's time server with xntpd/ntpdate. Maybe this is
> messing with it? Maybe I should just turn the external sync with caldera
> off and see what happens?
> 
> -Tony
> .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> Anthony J. Biacco                           Network Administrator/Engineer
> admin at intergrafix.net                        Intergrafix Internet Services
> 
>           "The best way to predict the future, is to invent it."
> http://cygnus.ncohafmuta.com                    http://www.intergrafix.net
> .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> 
> 
> To Unsubscribe: send mail to majordomo at FreeBSD.org
> with "unsubscribe freebsd-aic7xxx" in the body of the message
> 

Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu




To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe freebsd-aic7xxx" in the body of the message