From owner-freebsd-stable Wed Apr 5 16:57:14 2000 Delivered-To: freebsd-stable@freebsd.org Received: from set.spradley.org (set.spradley.tmi.net [207.170.107.99]) by hub.freebsd.org (Postfix) with ESMTP id 6227837B6A3 for ; Wed, 5 Apr 2000 16:56:57 -0700 (PDT) (envelope-from tsprad@set.spradley.org) Received: from set.spradley.org (localhost.spradley.tmi.net [127.0.0.1]) by set.spradley.org (8.9.3/8.9.2) with ESMTP id UAA77852; Sun, 2 Apr 2000 20:33:03 -0500 (CDT) (envelope-from tsprad@set.spradley.org) Message-Id: <200004030133.UAA77852@set.spradley.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Matthew N. Dodd" Cc: "Chad R. Larson" , stable@FreeBSD.ORG Subject: Re: FIXED --> Thanks! Re: ep0 eeprom failed to come ready... In-reply-to: Your message of "Sun, 02 Apr 2000 19:17:38 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 02 Apr 2000 20:33:03 -0500 From: Ted Spradley Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm not going to bother tearing apart your reply. > > You obviously have -no- idea what the current state of the PnP system in > FreeBSD is. Me neither. I would have appreciated a brief discussion of how the PnP system deals with the sort of problem Mr. Larson describes. > If the FreeBSD kernel -knows- about non-PnP resources then it will not > 'remap' PnP hardware to conflict. But does it 'remap' PnP hardware to remove a conflict that already exists? [...] > On Sun, 2 Apr 2000, Chad R. Larson wrote: [...] > > It's good you chose that example. I went through =exactly= that > > exercise two weeks ago. A 3c509B which wouldn't do squat. Even the > > 3Com MS-DOS configurator program claimed there were "no Etherlink > > cards found" until I pulled out the Creative Labs Soundblaster that > > was in there. Can FreeBSD deal with that? When the MS-DOS configurator from the manufacturer can't? That would be wonderful. That seems to me to be a very hard problem, a problem that was created by the (imperfect) addition of Plug'n'Play on top of the already imperfect mechanism of jumper-selected addresses and IRQs. And that was (to my understanding) Mr. Larson's original complaint: that the evolution of address and IRQ (etc.) selection mechanisms over the years (while it may or may not have made things easier for some people, I don't know) has made it more difficult for some of us to isolate, identify, and correct it when it doesn't work. This is not a complaint about FreeBSD. This is a complaint about the architecture of PeeCee equipment. And I don't expect any of you to try to address the complaint; I'm just venting. Sorry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message