public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lech Szychowski <lech.szychowski@pse.pl>
To: linux-kernel@vger.kernel.org
Subject: PCI network card detection/initalization order
Date: Wed, 1 Aug 2001 21:14:44 +0200	[thread overview]
Message-ID: <20010801211444.A3413@lech.pse.pl> (raw)

I have a machine (IBM x330) with a dual on-board FastEthernet
card (eepro100) and one additional (3c900) card in one of the
PCI slots. Kernel inits the 3COM card earlier than the Intel
one, assigning eth0 to 3c900 and eth[12] to Etherexpresses.
For a bunch of reasons (making the machine free of the "eth1
becomes eth0 when the additional card is removed" symptom being
one of them) I would like to reverse the initialization order
for the cards - or, to be more exact, make the on-board Intel
cards always detected and initialized first (as eth0 and eth1).
Since this machine has only PCI slots (and I don't really feel
anyone would ever try to attach to it anything like a parport
network card :) I believe in general there are two cases:
(a) another Etherexpress Pro - one or more - inserted into
    PCI slot(s),
(b) another type of NIC - one or more - inserted into PCI slot(s).

I came to conclusion that editing drivers/net/Makefile
and moving "obj-$(CONFIG_EEPRO100) += eepro100.o" entry
towards the start of the section beginnig with "link order
important here" would solve the (b) case. Indeed, when I put
eepro100.o entry before the 3c59x.o one I was able to have
kernel init Intel-based interfaces as eth0 and eth1. And I
believe that in general case (a) is impossible to solve
because it depends on the actual motherboard design/wireing.

Is changing linking order the right way to control initalization
ordering of PCI network cards? Is my assumption about case (a) right?

-- 
	Leszek.

-- lech7@pse.pl 2:480/33.7          -- REAL programmers use INTEGERS --
-- speaking just for myself...

                 reply	other threads:[~2001-08-01 19:15 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010801211444.A3413@lech.pse.pl \
    --to=lech.szychowski@pse.pl \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox