>
> On Wed, 11 Jun 1997, linux kernel (linker@nightshade.ml.org) wrote:
>
> > Forget about 386es'.. People do what they want.. If you WANT to
> > stop adaptec timeouts then why dont you find some time and contribute to
> > what YOU want and stop trying to tell the rest of us what to do.
>
> This series of messages was (and is) directed to the kernel development
> team in hopes that since we're helping each other by writing our
> respective parts of the TOTAL Linux package that you'll listen to the
> concerns of your counterparts.
>
> As an application software developer the thought that feature
> development is abandonned or postponed in favor of backward compatibility
> worries me. If I'm mistaken, and the trend exists in my mind only, I
> apologize for the message clutter and return to irradiating myself in
> front of my X console.
>
> I sincerely hope that Linux has not adopted the "We know whats best and
> screw you and your suggestions" attitude. Yes - I can roll up my sleeves
> and hack the SMP code but I doubt I can do it better than you guys.
> However I'll produce a hell of a development tool - if we cooperate.
>
Well said. However... Has anybody tested my "simple irq patch" so I
can find out if it works okay on __ALL__ machines? I would really like
to know if it works everywhere without breaking anything. I know
that "everywhere" is impossible, but I would like to get close!
I submitted it a few days ago. It fixes a problem with old '386SXes and
their interrupt controllers. It ACKs the cascade with a SPECIFIC
EOL so other pending interrupt(s) still stay pending and are not lost.
It's here again:
--- /usr/src/linux/arch/i386/kernel/irq.c.orig Mon Jun 9 07:57:15 1997
+++ /usr/src/linux/arch/i386/kernel/irq.c Mon Jun 9 08:02:14 1997
@@ -82,12 +82,13 @@
if (irq_nr & 8) {
inb(0xA1); /* DUMMY */
outb(cached_A1,0xA1);
+ outb(0x62,0x20); /* Specific EOI to cascade */
outb(0x20,0xA0);
} else {
inb(0x21); /* DUMMY */
outb(cached_21,0x21);
+ outb(0x20,0x20);
}
- outb(0x20,0x20);
spin_unlock(&irq_controller_lock);
}
This has now been tested (is operational) on 9 Linux machines running
2.1.42. Unfortunately, most of them have the same motherboards so it's
not a very good test.
I would like to get it into the current distribution after some testing
because I think that it will fix a few other "strange halt" problems
that I have heard both SMP and non SMP machines have sometime occurred.
You see, if IRQ0 gets lost, you have a single-thread machine. That
thread could wait forever for something to happen. No more ticks, nothing
is going to happen --ever. With the current code, there is a nonzero
probability of IRQ0 getting acked the instant it occurs. This could
prevent the first controller from even raising the CPUs maskable (main)
interrupt line. With a specific EOI on the cascade, only it gets acked
without risk of acking the higher-priority IRQs at the instant they
occur. This metastable state problem is not unique to PCs.
Cheers,
DJ
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Richard B. Johnson
Analogic Corporation
Email : rjohnson@analogic.com, johnson@analogic.com
Penguin : Linux version 2.1.42 on an i586 machine (66.15 BogoMips).
Warning : It's hard to stay on the trailing edge of technology.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-