Date: Wed, 04 Dec 2002 17:19:33 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Michael Richards <michael@fastmail.ca> Cc: jhb@FreeBSD.org, freebsd-smp@freebsd.org Subject: Re: Intel SE7500CW2 narrowed down... Message-ID: <3DEEA9A5.98315710@mindspring.com> References: <3DEE5F37.000003.43942@ns.interchange.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Michael Richards wrote: > Wow, looks like someone who really knows what they're talking about > stepped up here. Peter Wemm knows it too, and so do other people (PHK, Steve Passe, Bruce Evans, etc.). Mostly, though, we just avoid that hardware, so it keeps it from being our problem. > So I know we could look at the BIOS to find if the > user actually has this buggy board. This being the case we could then > decide to hardcode whatever is wrong in the APIC tables so we can > talk to the hardware. No. The BIOS does not initialize the chipset for the way interrupt routing is done in FreeBSD. Basically, the BIOS will support virtual wire, or it will support all interrupts sent to the BP. FreeBSD uses whatever CPU is in the kernel, and allows in only one at a time (in the older code). In any case, interrupts are vectored to a single CPU at a time, which may be the AP. > I didn't look at the APIC I/O code and it may take a while for me to > actually understand it. Would you be interested in or able to write > something describing the problem so it can be submitted to Intel in > the unlikely event that they would actually fix it? If they knew enough to fix NetWare, then they are aware of the problem (NetWare runs non-preemptive multitasking, with threads run to copletion, with NLM's and *not* the main server code running on the AP's). The real question is whether the ServerWorks chipset can even *be* programmed to do the right thing, or whether it sucks, like the CMD640B IDE controller just sucked, with no way to fix it with software. The problem with solving it the Linux way is that you can't send the interrupt to the BP, if an AP is holding Giant. It would take a lot of work to keep all the AP's out of the kernel; it might not be that possible. Going the other direction works, but, again, you are up against the global lock. It's probably going to be a lot of work, and whoever does it is going to have to have one of the damaged boxes in hand to hack on. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DEEA9A5.98315710>