[conspire] How to check if a mobo is compatible with Linux

[Rick Moen]

Quoting K Sandoval (indigo.kai at gmail.com):

> That still leaves me with building a new system for me.  I would guess
> I need to decide which mobo to go with, but where do I start?

Let's take another running leap at your questions, now that I've had
both sleep and coffee, and tackled at least a couple of the errands that
have been piling up.

> I already have an idea about the case and some hardware that I want.
> 
> I am looking for an ATX or a Micro ATX mobo that would support 2
> IDE/PATA HD, 2 CD/DVD, eventually upgrade to 4 GB RAM (or more), able
> to upgrade processor, support a floppy drive, and have 4 or more USB
> ports.

You know, if you don't have a compelling need to buy PATA, you really
should switch to SATA, at this point.  The drives run a little cooler,
draw a little less power, the bus is one that has a future, and the
cables are thin with the effect of not blocking much airflow.  (Airflow
is vital to cooling.)  Thus, you can have more-compact system cases
without risk of blowing up (runaway heat buildup).  _Do_ be aware, by
the way, that the act of burning a CDR/DVD-ROM does generate a fair
amount of heat.  One can argue that it's a sufficient reason to have the
burner in an external case, e.g., on USB.

RAM:  If you're honestly expecting to max out the RAM over time, make
very sure that you buy sticks with a sufficient memory density -- which
requires being mindful of of how many memory slots the motherboard has,
and what density of sticks they support.

Floppy drive:  Seriously?  Why?  The only reason I am even considering
finding a floppy drive, these days, is to attempt, if still possible, to
retrieve (via the "dd" utility) image files of certain old Infocom game
floppies and store those image files to long-term media.  Floppies are
not only dead, but were buried almost a decade ago.


[I'm moving your bit about three particular motherboards to further down.]

> Opinions on this hardware is welcome....
> Reason why I looked at these particular motherboards...
> 
> 1) The CPU is upgradeable.

Everyone _expects_ to upgrade CPUs -- or at least optimistically expects
to find value in the ability to do so -- and almost nobody ever does.
The economics of it tend to just not work out -- and, by the time you
seriously consider it, you suddenly realise that the motherboard itself
is so relatively obsolete compared to newer offerings that you're better
off getting a new combination of current-production motherboard and
current-production CPU.


> 2) RAM Memory can support 1 GB, 2 GB, 4 GB therefore I can upgrade the
> RAM later.

This is actually pretty routine.  What you _didn't_ glom onto, and is
sometimes significant, is how many _slots_ for memory each motherboard
has.  Cheap motherboards often have just two.  Having more than two
gives you more flexible options for putting in some RAM today, and
upgrading later without needing to take a stick out and put it in a
drawer because it wasn't a dense-enough stick.  

OTOH, having just two slots is a perfectly reasonable compromise if your 
upgrade plan is to buy a single 2GB stick today, and later max out the
motherboard at its 4GB potential by purchasing a second 2GB stick for
the now-empty slot.  (Note:  This strategoy works only for motherboards
that aren't interleaving RAM in "banks", which complication you also
need to watch out for.  Sometimes on a particular motherboard, RAM slots
are usable usable only in pairs, each pair of slots needing to have a
pair of sticks of identical size.)


> 3) I believe the chipsets are Linux compatible.  North Bridge Intel
> G31 South Bridge Intel ICH7 

Sure, ICH7 is fine.  (You're referring to the SATA, PATA, sound, and USB 
driver aspects of that chip family.  And, by the way, "ICH7" is a
_family_ of chips, which each have slightly more human-hostile
individual model numbers.)

But I'll want to details what is and is not meant by "Linux-compatible",
and explore the fuzzy edges of the concept.

Cast your mind back to several years ago, when Intel was developing the
ICH7 chip-family design, as an evolution of the prior ICH6 design, which
in turn was based on ICH5, the first of their motherboard southbridge
families to support SATA (alongside PATA).

When ICH5 had come out, Intel realised that they'd inadvertantly created
a challenge for the Linux/BSD coders of SATA support:  Jeff Garzik, on
the Linux side, had to work for a while to make his ata_piix driver
compatible with the ICH5 chips.  Intel, being clueful in such matters,
wanted to prevent that situation from recurring, and also figured it
couldn't hurt to have a standard, openly documented programming
interface for SATA chips.  So, Intel wrote a hardware interface
specification called "AHCI" (advanced hardware control interface), made
it publicly available to other manufacturers and the entire world, and
announced that the SATA functions of its future southbridge chips would
(at least for the near term) be AHCI-compliant.  (It's possible that
non-SATA functions were also covered by the AHCI spec:  I personally
know only about the SATA aspect.)  So, for example, when ICH6 chips came
out, they supported two modes of SATA operation:  AHCI, and a "legacy" 
backwards-compatibility mode in which they "looked" to software like an
ICH5 chip.  ICH7 chips, when _they_ came out, did likewise.  To my
knowledge, ICH8 and ICH9 are continuing that tradition.

The consequence was that, when the new ICH6 chips hit the market, if
you, the user of a then-current Linux distribution, bought such a
motherboard, you could (1) use the bog-standard ata_piix driver with the
SATA chip set to "legacy" mode, at a very minor cost in HD performance,
or (2) use Garzik's new-ish "ahci" driver, _if_ your distro's kernel
included that driver in a sufficiently well debugged state.

The point is that inclusion of proper support for a new chipset in
mainline kernels[1], and the inclusion of those kernels in newer versions
of distros (in particular, in the kernels used by their installers), and
thus the availability of support for the hardware when needed by
end-users is a _process_.  That process occurs over time.  Whether a
suitable driver will be actually present in a distro installer's kernel
at the time you need it for installation to be successful depends on
passage of time -- in part.  Other factors that help determine whether a
driver will be present (and how long after introduction of the chip a
suitable driver will be in released distributions) is how cooperative
the chipmaker is with the open source community.  Historically, Intel
has been (mostly) very cooperative.  Among the least cooperative have
been Marvell, Broadcom, and Nvidia.  Cooperation makes the kernel
coders' job of creating and debugging suitable drivers easier and
quicker.  Absent that cooperation, the job is still _possible_, but
takes longer because it involves reverse-engineering (probing the
hardware to trace out its programming interfaces experimentally).

As a minor footnote (further) complication, it's technically not _quite_
enough for a driver to exist in one's kernel that can support a piece of
hardware.  You also want the kernel to autorecognise that hardware, and
say "Oh, that's going to need driver [foo]" and insmod it (insert, i.e.,
load, the module into the running kernel).  For PCI-type devices such as
ICH7-family southbridge chips, this is done using a lookup table of PCI
ID numbers.  You can actually look at that table:  It's an ASCII file,
and maintained here:  http://sourceforge.net/projects/pciids/  That file
gets embedded into kernels, which get into distro installers, and so on.
If your distro installer's kernel doesn't have a recent enough PCI IDs
table in it, it won't recognise (say) a ICH7-family southbridge chip as
one it can support, even if it _can_ indeed support it.

So, after all of that, you might wonder:  How do you determine whether X
piece of hardware is going to be properly supported by Y distro
release's installation kernel?  Good question.  If you want to be as
certain as can be, you can try to search for, say, mentions that Gutsy's
installer had no problem with X.  Or, you could look up Gutsy's
installer kernel release number (2.6.22), then search for information
about whether a functional driver for X was included in 2.6.22.  Or, you
could just say to yourself "Screw it.  Hardware component X appeared on
the market over two years ago.  It _has_ to have decent driver support
in current distro releases by now."  And you'd almost certainly be
right.


> In conclusion: I am looking for an ATX or a Micro ATX mobo that would
> support 2 IDE/PATA HD, 2 CD/DVD, eventually upgrade to 4 GB RAM, able
> to upgrade processor, support a floppy drive, and have 4 or more USB
> ports.

You know, those are extremely modest requirements, really.  You can
scarely go wrong -- except by buying stuff that's too brand-new to the
market, especially if the names Nvidia, Broadcom, or Marvell are
excessively involved.[2]  (Don't expect any computer retailers to ever
have Clue One about chipsets at all, let alone to know how long they've
been on the market, let alone to have anything trustworthy to say about
Linux support.  Remember Steve Wozniak's classic industry joke from the
1970s:

Q:  How do you distinguish a used car salesman from a computer salesman?
A:  The used car salesman _knows_ when he's lying.


> This is what I have found
> 1) GIGABYTE GA-G31M-S2L LGA 775 Intel G31 Micro ATX Intel
> 
> 2) GIGABYTE GA-P35-S3G LGA 775 Intel P35 ATX
> 
> 3) Intel BOXDG31PR LGA 775 Intel G31 Micro ATX
> 
> I did look at the 4) GIGABYTE GA-P35-DS3L LGA 775 Intel P35 ATX All
> Solid Capacitor Intel Motherboard, but there is no onboard video and I
> was not sure which is better onboard video or dealing with a video
> card?

This was of course the meat of your question, and I -still- haven't
gotten to it -- but will (again) do so when I have time.


[1] Or, in the case of video chipsets, in releases of X.org.

[2] That is not to say that, e.g., motherboards with Broadcom ethernet
chips cannot be supported by Linux.  In fact, they are routinely
supportable, which is a bloody good thing, because Broadcom ethernet
chips, being cheaply priced junk, are nearly ubiquitous.  The point,
however, is that _newly introduced_ Broadcom, Marvell, and Nvidia chips,
among others, tend to be slower to gain reliable Linux drivers than
those from competitors who are more cooperative.