--- Matthew Dillon <[EMAIL PROTECTED]> wrote:
> > :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 > not. > > 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 > believe. 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 detected. DT 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 http://mail.yahoo.com