From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 18:04:48 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 A816C16A41C for ; Mon, 11 Jul 2005 18:04:48 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15D7143D48 for ; Mon, 11 Jul 2005 18:04:47 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 11 Jul 2005 14:18:51 -0400 From: John Baldwin To: Harry Coin Date: Mon, 11 Jul 2005 13:58:46 -0400 User-Agent: KMail/1.8 References: <4.3.2.7.2.20050711100325.01f2a108@mail.qconline.com> <4.3.2.7.2.20050711121036.02caa348@mail.qconline.com> In-Reply-To: <4.3.2.7.2.20050711121036.02caa348@mail.qconline.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507111358.50262.jhb@FreeBSD.org> Cc: freebsd-current@FreeBSD.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: Mon, 11 Jul 2005 18:04:48 -0000 On Monday 11 July 2005 01:30 pm, Harry Coin wrote: > John, > > The verbose dmesg doesn't tell you enough. What was needed was debug > writes in the pnp and non pnp mss.c probe routines that displayed the > parent device id and the probed device id. That solved it because there > you could see the acpi parent calling the non-pnp isa mss probe routine > (mss_probe) which would _accept_ the probe, wrongly, on a few various > attempts, only to have the non pnp mss_attach fail for lack of resources. Well, that would be helpful to see as well. :) It would be helpful to dump the name of the parent device via device_get_nameunit(device_get_parent(dev)) if you aren't already. > I haven't looked into the newbus logic enough to know for sure but my hunch > is that the current mss.c call to detect pnp and so avoid to use the non > pnp probe code (isa_get_logicalid) didn't get mapped through the > acpi_isa_xxx but instead the isa routine directly-- which returned a zero > in the context of an ACPI parent bus-- signaling not-a-pnp device -- while > the acpi version would not have done. Hence the directive in the manual to > use the ISA_PNP_PROBE even on non-PNP probe routines. Well, isa_get_logicalid() just asks the parent device for the ISA logical ID IVAR which maps to a call to bus_read_ivar(). For the non-ACPI case, it is implemented by returning the id read by the PnP code in in isa_read_ivar() in sys/isa/isa_common.c. However, for devices that are children of acpi0, they call acpi_read_ivar() which does end up calling acpi_isa_get_logicalid(): static int acpi_read_ivar(device_t dev, device_t child, int index, uintptr_t *result) { ... case ISA_IVAR_LOGICALID: *(int *)result = acpi_isa_get_logicalid(child); break; ... return (0); } So, you see, isa_get_logicalid() should work fine, and it's actually something that many ISA device drivers use to avoid probing PnP devices, so the root problem needs to be fixed if acpi_isa_get_logicalid() has a bug. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org