From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 18:54:58 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 EA09216A41C for ; Sat, 16 Jul 2005 18:54:57 +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 8B47243D46 for ; Sat, 16 Jul 2005 18:54:57 +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 j6GIqjpf031820; Sat, 16 Jul 2005 12:52:45 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 16 Jul 2005 12:53:27 -0600 (MDT) Message-Id: <20050716.125327.85414312.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 18:54:58 -0000 In message: <4.3.2.7.2.20050716124022.01f08460@mail.qconline.com> Harry Coin writes: : Warner, : : Thanks for engaging. Responses within. : : At 11:30 AM 7/16/2005 -0600, M. Warner Losh wrote: : >In message: <4.3.2.7.2.20050716114020.01f0fcb8@mail.qconline.com> : > Harry Coin writes: : >: I think all that's needed to wrap this up is for the powers that be to : >: offer clarity about one thing, final decision about the case of arbitrary : >: (beyond com1, etc.) non-pnp ISA devices probe routines. : > : >As far as I kow, there's nothing wrong with them. Please state the : >problem. They work and work well today. Without a clear problem : >statement, it is hard to know what you are complaining about. : : There is significant comment upstream, and certainly a significant issue : that didn't work at all today, nor in the past (many unanswered bugs : relating to 'attach returned 6' and soundcards in the freebsd : history). The issue arose in mss.c that has both a pnp and a non pnp probe : routine for drives that share other routines. ??? : There is extensive comment upstream, I hesitate to repeat it all. The : short story is that from the freebsd architecture manual on the subect we : have: : http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/isa-driver-config.html : ...That means that absolutely every driver, even the ones not supporting : any PnP devices must call ISA_PNP_PROBE(), at least with an empty PnP ID : table to return failure on unknown PnP devices.... No. That's not true. They can call isa_get_logicalid() and return if it is not zero. For example, sn: static int sn_isa_probe (device_t dev) { if (isa_get_logicalid(dev)) /* skip PnP probes */ return (ENXIO); if (sn_probe(dev) != 0) return (ENXIO); return (0); } This has always been the way. The isa-driver-config.html is mistaken if it says otherwise. This has been the recommended way to avoid pnp probes since 3.0 (I know I've added it to a bunch of drivers). : is violated in mss_probe, which uses another way to detect whether a device : is pnp and so avoid the non pnp probe. That alternate call fails in the : case the bus parent is acpi, causing mss_probe to succeed, mss_attach to : fail, the pcmx count to ratchet up x, and then, depending, you get a pcm3 : without a pcm0, pcm1 or pcm2 if the isa bus probes eventually find : it. John was dismayed by this because the alternate way is employed in : many isa drivers. John's misremembering things. This has always been the case. ACPI should return non-zero always (since it has no non-pnp devices). ACPI is at fault here, for not returning PNP information that it has. If it is trying to 'cheat' by using the 'isa' attachments, then it has to follow the old isa rules. Looking at mss.c, mss_probe shouldn't be called in the acpi case. There's no 'acpi' attachment for it Why is it being called at all? : John Baldwin has offered that the architecture manuals suggestion is not a : good course to follow for elegance reasons. However if mss_probe is : changed to employ that the problem goes away. John discovered a tension in : the OS calls related to the various detection alternatives and ACPI. He : also suggested removing the mss routines from the acpi class, which too : avoided the problem on the system that I have, but may or may not cause : breakage with other systems. I think this points out a fundamental problem. Can you send me devinfo -v for your machine and/or a dmesg (or a pointer to the message that has it in it)? mss_probe should only be called for isa bus, and it should only make it pass its resource allocation if you have mss hints in your /boot/device.hints. If acpi is behaving otherwise, then that's an acpi bug. Warner