Re: Thread will be terminated on monday 'Argh, Stray interrupts 2006'

["Dmitri Nikulin" <dnikulin@xxxxxxxxx>]

On 6/5/06, Danial Thom <danial_thom@xxxxxxxxx> wrote:
> Seemed appropriate. People that terminate threads
> because they don't want to fix a problem in their
> OS because its too much work deserve such.
>
> Why can't he just admit that he broke something
> that was fixed and it needs to be repaired,
> rather than blaming it on chip manufacturers, and
> somehow claiming that its not his problem? Its
> his OS, so its his problem. Its just lame.

Okay, so if you know so much about hardware, why don't you know that
there are multiple methods of interrupt routing? Most rely on hardware
and if that hardware component is faulty, either fundamentally or in a
certain configuration, you'll have unusual effects. By merely using a
different mechanism for interrupt routing you'll eliminate the
problem, by working around a *hardware* failure.

Matt suggested trying APIC_IO which should use the IO APIC for
interrupt routing, which may well fix the problem. Did you try it? Did
you investigate what the 'working' systems use for their routing? Did
you actually make sure the working systems aren't simply IGNORING the
problem? Linux does that for a lot of things. Quite scary.

Anyway, you're blaming a kernel for what is clearly a hardware
failure, and if it's just a quirk, it's probably extremely simple to
fix. Since you haven't helped the developers track down the problem,
they *can't* do anything practical to solve it. Funny how that works,
isn't it?

To maybe shut you up with regards to what you consider to be DragonFly
avoiding optimizing its network stack, read
http://leaf.dragonflybsd.org/mailarchive/kernel/2005-08/msg00012.html

I guess this is a waste of time since you can't actually be this
pathologically incapable of understanding how OS development works,
and you're just trolling. Can you just stop? Everyone's asked nicely.
You have nothing to gain from doing what you're doing.

 -- Dmitri Nikulin