From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 19:13:19 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C09FE16A41C for ; Sat, 16 Jul 2005 19:13:19 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3D7443D91 for ; Sat, 16 Jul 2005 19:13:11 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6GJAYLI031986; Sat, 16 Jul 2005 13:10:34 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 16 Jul 2005 13:11:17 -0600 (MDT) Message-Id: <20050716.131117.23013098.imp@bsdimp.com> To: harrycoin@qconline.com From: "M. Warner Losh" In-Reply-To: <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> References: <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> <20050716.113059.82101301.imp@bsdimp.com> <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, nate@root.org Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2005 19:13:19 -0000 In message: <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> Harry Coin writes: : Thank you. I should have been more clear. I'm aware of this. The driver : in question is the mss.c which indeed has a mss_probe non pnp routine : called, and which succeeds, with acpi as a parent -- which when the : following attach call is made fails. Extensive documentation is upstream. Yes. Just read the thread. Please delete the line that John suggests, as has already been committed to current. If there are PNP ids we need to add to the pnp probe, we should add those and not kludge around it. : My thought is, if the current roster of non pnp isa drivers is not to be : touched, then the OS ought to avoid to call their probe routines unless the : pnp cards are all sleeping whether by acpi or whatever. Also it is my : experience that there are quite a good many sound chips out there that are : pnp but are not in the roster of pnp devices in the pnp mss detect : driver. The current setup will allow these devices to be probed and to : operate (maybe not as pcm0) via the non-pnp detect routine called from the : acpi. A lucky side effect that helps some folk but which will go away if : this issue is cleaned up I fear. Ummm, that's not the way things should work. Sorry to disappoint you, but John and I are telling you the same thing: don't have acpi attachments that use isa_get_logicalid(). I've taken a look at the other drivers. gusc and esscontrol seem to also have this problem. Of course, we should also fix the ACPI layer to do the right thing. The right thing here is for isa_get_logicalid() to always return non-zero because, by definition, all acpi devices have logical ids. That's the real bug here, and the rest of your observations are downstream effects that aren't important. Warner