On Fri, 6 Oct 2006, Eric W. Biederman wrote:
>
> Forcing irqs to specific cpus is not something this patch adds. That
> is the way the ioapic routes irqs.
What that patch adds is to make it an ERROR if some irq goes to an
unexpected cpu.
And that very much is wrong.
> Yes. A single problem over several months of testing has been found.
Umm. It got found the moment it became part of the standard tree.
The fact is, "months of testing" is not actually very much, if it's the
-mm tree. That's at best a "good vetting", but it really doesn't prove
anything.
> So this is fairly fundamentally an irq migration problem. If you
> never change which cpu an irq is pointed at you don't have problems,
> as there are no races.
So? Does that change the issue that this new model seems inherently racy?
> The current irq migration logic does everything in the irq handler
> after an irq has been received so we can avoid various kinds of races.
No. You don't understand, or you refuse to face the issue.
The races are in _hardware_, outside the CPU. The fact that we do things
in an irq handler doesn't seem to change a lot.
And what do you intend to do if it turns out that the reason it doesn't
work on x366 is that the _hardware_ just is incompatible with your model?
I'm not saying that's the case, and maybe there's some stupid bug that has
been overlooked, and maybe it can all work fine. But the new model _does_
seem to be at least _potentially_ fundamentally broken.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
