Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Sep 2006 16:32:12 -0700
From:      John-Mark Gurney <gurney_j@resnet.uoregon.edu>
To:        Jack Vogel <jfvogel@gmail.com>
Cc:        freebsd-net <freebsd-net@freebsd.org>
Subject:   Re: Bug or Design limitation??
Message-ID:  <20060926233212.GF80527@funkthat.com>
In-Reply-To: <2a41acea0609261615j18437fd9yc5e9ca823f2aab38@mail.gmail.com>
References:  <2a41acea0609261615j18437fd9yc5e9ca823f2aab38@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Jack Vogel wrote this message on Tue, Sep 26, 2006 at 16:15 -0700:
> Our test group just ran into something I hadnt noticed before.
> Take a system and put in two different multiport NIC boards,
> one older (PCI-X) and one new PCI-E board.
> 
> Load a driver that only recognizes the first board. It will show
> em0, em1, em2, em3, the new ports will be none's.
> 
> Unload that driver and then load a newer one that recognizes
> both boards. What you'd expect to see is em0....em7. But
> what you actually see is two sets of em0 - em3!

Could you post a dmesg?  The unit numbers should be provided by
the newbus framework, which doesn't allow this...  a devinfo would
also help..

> Our test lead noticed this because it broke some scripts of
> his. Now, 'ifconfig' gets it right and still presents you with 0-7.

ifconfig -a dumps the names properly?

> If you load the newer driver first then of course all is correct.
> 
> So, the question is, is this a bug? Clearly the enumerated
> data from the older driver loaded is staying around. I do
> not know how this kernel data is handled, so could/should
> it be removed and isnt or what?

There really shouldn't be any data around, and even if it was, the
data the was around would either a) force the new stuff to use a
different unit number, or b) fail to attach due to that unit number
already being in use...

Hmmm... Thinking about this, it might be because of different
devclass's that both have the same name...  though the first
devclass shouldn't be hanging around anymore since it was part
of the first module...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060926233212.GF80527>