Hi!
From: Chuck Silvers <c...@chuq.com> Date: Sun, 5 May 2013 18:54:54 -0700 > On Mon, Apr 22, 2013 at 09:21:50PM +0900, KIYOHARA Takashi wrote: > > Hi! > > > > > > From: Chuck Silvers <c...@chuq.com> > > Date: Sun, 21 Apr 2013 08:33:24 -0700 > > > > > On Mon, Apr 15, 2013 at 09:14:51PM +0900, KIYOHARA Takashi wrote: > > > > > > > in acpi_pci.c, why do you need to skip the check for > > > > > > > ACPI_VALID_ADR? > > > > > > > does the ACPI info on ia64 not have that flag set when it should? > > > > > > > > > > > > In my memory, YES. :-< > > > > > > But I can't access to my ia64 now. I will try and check at next > > > > > > weekend. > > > > > > > > > > In my ia64(zx6000), it looked that AcpiNsSearchAndEnter() returned > > > > > AE_NOT_FOUND. > > > > > How enable ACPI_DEBUG_PRINT or others many print? > > > > > > > > I look this messages on my ia64. (e.g. PCI0) > > > > > > > > _ADR Not found in 0xe00000003f9dd1e8 [Not adding] > > > > Name [_ADR] not found in scope [PCI0] 0xe00000003f9dd1e8 > > > > > > > > > > > > I think that no this problem crops up by all ia64 machines. Do you know > > > > the better evasion method? > > > > # Can I fixup by acpi_md_callback()? I look and find that now. > > > > > > I was thinking that acpi_md_callback() was called before the code where > > > you > > > removed the check for ACPI_VALID_ADR, so you could have acpi_md_callback() > > > walk through the device tree constructed by acpi_build_tree() and set > > > ACPI_VALID_ADR on any devices where it was missing, as well as > > > initializing > > > ad->ad_devinfo->Address. but the check for ACPI_VALID_ADR in question is > > > in > > > acpi_pcidev_scan(), which is called at the end of acpi_build_tree(), > > > so it's actually called before acpi_md_callback() is called. > > > > > > it happens that ad->ad_devinfo->Address will be zero if ACPI_VALID_ADR > > > isn't set, I guess that value is actually correct on your system? > > > > By my ia64 machine, it cannot ensure that address of pchb is right. > > I checked the boot log(typescript) of FreeBSD and Debian. > > FreeBSD had returned AE_NOT_FOUND. The value of device and function > > was not displayed in Linux. > > > > > > http://ftp.netbsd.org/pub/NetBSD/misc/kiyohara/ia64/typescript.FreeBSD_ia64 > > http://ftp.netbsd.org/pub/NetBSD/misc/kiyohara/ia64/typescript.ia64.debian > > if you don't know the right value for ad->ad_devinfo->Address should be, > how would you know how to set ap->ap_device and ap->ap_function? > setting those two fields are what ad->ad_devinfo->Address is used for > in acpi_pcidev_scan(). if you know how you should set those fields, > then I think you should be able to just initialize ad->ad_devinfo->Address > and set ACPI_VALID_ADR in ad->ad_devinfo->Valid. > > I looked at the diff you sent later, but it wasn't clear how that > was supposed to work. could you also send the ia64 version of that > new callback so we can see how the MI and MD parts would fit together? I add this change to my ia64. Index: acpi_machdep.c =================================================================== RCS file: /cvsroot/src/sys/arch/ia64/acpi/acpi_machdep.c,v retrieving revision 1.6 diff -u -r1.6 acpi_machdep.c --- acpi_machdep.c 23 Sep 2012 00:31:05 -0000 1.6 +++ acpi_machdep.c 8 May 2013 11:49:39 -0000 @@ -195,6 +195,20 @@ } int +acpi_node_md_callback(struct acpi_devnode *ad) +{ + + if (ad->ad_devinfo->Flags & ACPI_PCI_ROOT_BRIDGE) + if (!(ad->ad_devinfo->Valid & ACPI_VALID_ADR)) { + /* Fixup no _ADR */ + ad->ad_devinfo->Valid |= ACPI_VALID_ADR; + return 1; + } + + return 0; +} + +int acpi_md_sleep(int state) { printf("%s: not yet...\n", __func__); Thanks, -- kiyohara
