Date: Tue, 26 Sep 2006 16:47:18 -0700 From: "Jack Vogel" <jfvogel@gmail.com> To: "John-Mark Gurney" <gurney_j@resnet.uoregon.edu>, "Jack Vogel" <jfvogel@gmail.com>, freebsd-net <freebsd-net@freebsd.org> Subject: Re: Bug or Design limitation?? Message-ID: <2a41acea0609261647t1a5bb839o954e9287ae173d5c@mail.gmail.com> In-Reply-To: <20060926233212.GF80527@funkthat.com> References: <2a41acea0609261615j18437fd9yc5e9ca823f2aab38@mail.gmail.com> <20060926233212.GF80527@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Yes, ifconfig dumps the names correctly. This isnt my machine, so I will have to go get the tester to get me the dmesg, I'll send along when I have it. Jack On 9/26/06, John-Mark Gurney <gurney_j@resnet.uoregon.edu> wrote: > 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?2a41acea0609261647t1a5bb839o954e9287ae173d5c>