DragonFly BSD
DragonFly users List (threaded) for 2006-06
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Argh, Stray interrupts 2006

From: John Von Essen <john@xxxxxxxxxx>
Date: Sat, 3 Jun 2006 14:48:27 -0400

These comments are really unfair.

You have to consider that people who work on projects like DFly or FreeBSD - they dont have access to every single motherboard every made. And the Bios quirks can be like fixing leaky pipes. You fix a leak in one spot, and it causes a new leak somewhere else.

People who decide to use OS's like FreeBSD, NetBSD, DFly, etc.,. have to understand that compatibility is not gauranteed. If you want that, go with Solaris or Windows.

I just built a system for a customer. I had to go through 3 different motherboards. The first two simple wouldn't work on FreeBSD. Things have changed, the old PII and PIII days are gone. Chipsets and Bios's are getting more and more complex, and more separate. Shit, back in the late 90's - several motherboard manufactures all used the same Bios and all used the same 2 or 3 available chipsets. Nowaday's, every motherboard bios is different, every chipset is different, motherboards themselves are phased out faster. I bought some real nice Tyan single P4 boards back in 8/05, 64bit PCI - real nice - real compatible. Tyan stopped making them after 4 months, and replaced them with something else with a new chipset. I sure hope nobody wasted time in tweaking code for those boards!


On Jun 3, 2006, at 2:16 PM, Danial Thom wrote:

--- Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>

:Thats not really a solution as I don't want a :system thats processing 100s of interrupts per :second for no reason. I previously reported that :these were gone, but now that I put another card :in the box (a dual port intel ethernet), they're :back. : :I know I've been told that its a bios :configuration problem, however I don't get stray :interrupts if I pop a FreeBSD disk on the exact :same hardware. So why is it a misconfiguration in :DFLY but not in FreeBSD? : :DT

    I like how you always twist things so it's
somehow our fault.

    The BIOS/MB issue is that some motherboards
route all system interrupts
    to a single PIC IRQ line in order to allow
the BIOS to implement things
    like USB keyboard support and NetBoot
during boot.  The chipset
    manufacturers do not publish how to turn it
off, and on some motherboards
    there is no way to turn it off short of
turning off the PIC itself,
    and even then it is sometimes not possible
to turn it off.

    It might be possible to bypass the issue
using the SMP + APIC_IO option,
    but chipset vendors have also had the keen
idea of doing the same sort
    of shit for IOAPIC interrupts too.  Some of
Intel's own chipsets completely
    break IOAPIC pin masking by causing the
chip to route to a default
    vector if a pin is masked.  Sometimes it is
possible to bypass
    the problem by not using IOAPIC interrupt
masking (and sometimes it isn't),
    and sometimes it is possible to bypass the
problem by masking the
    pin representing the default vector.  Or

    FreeBSD has recently moved away from using
the PIC alltogether, primarily
    by using the LAPIC timer instead of the
i2854.  I think its a good idea,
    but it represents quite a chunk of work.
It may or may not solve this
    particular issue (it is just one of many
related to broken BIOSes and
    motherboards that pop up).

    In anycase, if you want to solve the
problem the source code is right
    there, start coding!  You seem to want to
simplify problems down to
    one-liner's, and blame us for all your woes
in the process, but the
    reality is that it is a far more complex
issue then you seem to want to

You can call it "twisting", but your OS is based on Freebsd 4.8, and it doesn't happen with FreeBSD 4.9. So unless its something that they fixed in 4.9, its likely something that you folks changed or do differently. In fact I've never seen so MANY stray interrupts on any box on any OS in the 23 years or so that I've been using one un*x or another. Not to be negative, but those are the facts.

My view is that its the responsibility of the
programmer to mask hardware quirks and bios
"bugs". You don't "explain" that an ethernet
controller has a bug so it locks up all the time;
you figure out a way to make it so that it either
doesn't lock up or so that it is restarts as
tranparently as possible. Lazy programmers
complain about how difficult it is to do things,
and good ones come up with solutions. Its fairly
clear that whatever the bug is, you've made it
worse, or removed some work-around. As more and
more people use DFLY, you'll spend more and more
time explaining to people that its not your
fault. Its probably less effort in the long run
to just figure something out that corrects it.

Turning on SMP stopped the stray irq messages. I
get one stray IRQ message immediately after
loading the acpi.ko module, and then no more. If
you think of something that might fix it in UP
mode, I'm happy to try it out.

Is there a performance cost of running an smp
kernel on a UP machine? I don't intend to run
DFLY UP anyway, but just interested in knowing if
it shuts off the SMP modes when only 1 cpu is


Its been suggested that I turn acpi off, and
there doesn't seem to be a toggle in the bios,
and dfly insists on loading the module

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]