Date: Tue, 02 Jan 2001 12:06:55 -0800 (PST) From: John Baldwin <john@baldwin.cx> To: alpha@FreeBSD.org Subject: Disabling ints via IPL Message-ID: <XFMail.010102120655.john@baldwin.cx> Resent-Message-ID: <200101022006.f02K6VG01715@meow.osd.bsdi.com>
next in thread | raw e-mail | index | archive | help
Ok, here's the first installment. :) On 06-Nov-00 Doug Rabson wrote: > On Mon, 6 Nov 2000, Matthew Jacob wrote: > >> >> I now finally have *one* working -current machine at Feral (a borrowed for >> NetBSD XP1000). All of the week before when I tried to run -current on it it >> destroyed the root filesystem. This problem seems to have gone away. >> >> So- at least I have something I can consistently refer back to for A/B >> comparisons that works (i.e., activation energy is now less). I *still* >> don't >> have enough power in the office yet to fire up the 4100!! >> >> It's still my theory that the enable/disable interrupt design is asking a >> lot of a platform. I don't recall seeing a refutation of this from John or >> Doug- did I somehow miss that? > > I think you are right about the enable/disable scheme. The alternative > (which should be more efficient anyway) is to simply run the irq threads > at a higher IPL - I think you already suggested this. It means being > careful to switch to the ithread directly from the interrupt code > otherwise the irq will be re-fired when the low-level handler returns. Err, so basically no ithreads until we have light-weight ithreads? This will break if an ithread sleeps or blocks though. Basically, you would have to change the low-level code to not restore the IPL on exit, and wait until the ithread runs, all its handlers run and then lower the IPL when the thread finishes execution. If one device interrupt handler ever depends on another device interrupt handler it would be an instant deadlock. :-( We'd also end up running userland processes at the higher IPL while we were waiting to run an interrupt thread, e.g. if the thread blocks trying to obtain a mutex. Has anyone confirmed that the problems are due to not being able to disable an interrupt source? -- Actually, it's not as bad as it sounds here, but this is the basic idea. An ithread will only block if another kernel thread has the mutex, so you won't bounce back to userland with a raised IPL as there will be another runnable kernel thread. More on this in later messages.. -- John Baldwin <john@baldwin.cx> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010102120655.john>