> Supporting non-commodity mainboard chipsets (2/4-way memory,
> multiple-PCI) in Linux ...
>
> I've dabbled in some searches on the 450GX chipset and glanced
> through the kernel source code, but I was wondering if someone
> could give me the "straight shot" to understanding non-commodity
> mainboard chipsets in non-Windows OSes (Linux, FreeBSD, etc...),
> or unpatched/unsupporting Windows OSes. E.g., server chipsets like
> the Intel 450GX, the ServerWorks' (fka Reliance Computer
> Corporation) new ServerSet IIILE/HE/WS chipsets with multiple
> memory busses and multiple PCI busses.
The fundamental assumption is that the firmware has set the devices up
correctly.
> [ Hence what is _my_problem_ because (thanx to all the help on
> this and other lists with my problem, which really wasn't a Linux
> problem), that is my problem with my server (Linux is doing a fine
> job, but the hardware cannot handle the I/O load we have on my
> server because high-throughput PCI devices are contending with each
> other). ]
At this point, I'd just point you at a Tsunami-based Alpha. 8)
> Basically, I'm making the following assumptions and/or have the
> following questions (TOTAL IGNORANCE HERE):
>
> A. Assumption: Stock Linux, FreeBSD and even unpatched Windows
> NT will work with any x86 mainboard, but will only use the
> components that the BIOS reports -- e.g., on a 450NX with (2) PCI
> channels and (4) Slot-2 , the older, early 2.0 kernels would work
> on the board, but only use one PCI channel (or two?) and one (or
> two?) processors (but not four)?
Not correct, at least in the FreeBSD case. The issue with the 450NX
chipset has simply been the odd reporting of the high PCI bus number, and
buggy PCI bus enumeration firmware. I think that the 3.x family and later
is getting this right now on most or all of the current 450NX systems.
High PCI bus/bridge function number reporting continues to be a
problematic issue.
> B. Assumption: It didn't take much modification to support
> the 450NX and its 4-way Xeon, dual-PCI bus systems once someone
> reverse engineered the actual, undisclosed Intel specifications
> (e.g., detections, register settings, etc...).
Actually, this never came into it. The 450NX is quite well publically
documented; certainly to the point where the changes required to
correctly detect and probe on all PCI busses were just a few hours work.
> C. Question: What is the status of [full] support for the
> ServerWorks/RCC chipsets?
I can't comment on this, as "full" support is somewhat of a vague item.
I understand that there have been a number of issues with correctly
detecting the high function number for the secondary host:PCI bridges,
but I believe that FreeBSD 4.0 and onwards is capable of getting this
right.
I'm a little short on information simply because, as yet, FTL doesn't
have any sample hardware. We're so strapped for space with what we've
got right now that I'm not sure what we'd do with it at any rate. 8)
Regards,
Mike Smith
Principal Engineer
FreeBSD Test Labs
-- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:15 EST