Date: Wed, 27 Apr 2011 00:54:34 +0300 From: Alexander Motin <mav@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Changing how PCI-PCI bridges do resource allocation Message-ID: <4DB73F1A.4000009@FreeBSD.org> In-Reply-To: <201104261146.39731.jhb@freebsd.org> References: <mailpost.1303239057.1899175.75529.mailing.freebsd.arch@FreeBSD.cs.nctu.edu.tw> <201104260955.29280.jhb@freebsd.org> <4DB6DA8D.1040802@FreeBSD.org> <201104261146.39731.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On Tuesday, April 26, 2011 10:45:33 am Alexander Motin wrote: >> John Baldwin wrote: >>> On Tuesday, April 26, 2011 2:53:24 am Alexander Motin wrote: >>>> On 26.04.2011 00:21, John Baldwin wrote: >>>>> On Monday, April 25, 2011 3:09:47 pm John Baldwin wrote: >>>>>> On Wednesday, April 20, 2011 4:38:30 am Alexander Motin wrote: >>>>>>> On 19.04.2011 21:50, John Baldwin wrote: >>>>>>>> I've already had at least one testing report that this fixes the issues with >>>>>>>> some machines' BIOS clearing the I/O windows on some PCI-PCI bridges when ACPI >>>>>>>> is enabled as this code re-discovers the original windows and programs them >>>>>>>> correctly. More testing would be good however. >>>>>>> I would like this helped my Acer TM6292 which also has alike problems >>>>>>> with missing PCIe bridge resources, but unluckily it doesn't. >>>>>>> >>>>>>> Here is verbose dmesg when my system uses this dirty hack: >>>>>>> http://people.freebsd.org/~mav/tm6292_pcie.patch >>>>>>> to restore bridges resources to the pre-ACPI state: >>>>>>> http://people.freebsd.org/~mav/dmesg.boot.hacks >>>>>>> >>>>>>> Here is respective `pciconf -lvcb` output: >>>>>>> http://people.freebsd.org/~mav/pciconf.hacks >>>>>>> >>>>>>> Here is dmesg with patches, but without NEW_PCIB: >>>>>>> http://people.freebsd.org/~mav/dmesg.boot.olbpcib >>>>>>> >>>>>>> Here is dmesg with patches with NEW_PCIB: >>>>>>> http://people.freebsd.org/~mav/dmesg.boot.newpcib >>>>>> Ah, your problem is we pick bad ranges when we alloc fresh resources for your >>>>>> bridges. I am working on making that better for ACPI, but for now you can try >>>>>> setting hw.acpi.host_mem_start to a value like '0xf0000000' in loader.conf. >>>>>> >>>>>> Although, it looks like it is not being honored currently. Try adding a printf >>>>>> in acpi_pcib_alloc_resource() in sys/dev/acpica/acpi_pcib_acpi.c to log the >>>>>> type, start, and end of each resource range. >>>>> Actually, try this patch. Then I think you can use the host_mem_start tunable: >>>> I've tried it. With this patch host_mem_start tunable seems like makes >>>> effect. Numbers look closer, but bge0 and iwn0 beyond the bridges are >>>> still not working. >>> Hmmm, I think I need to clear the completely bogus windows when we fail to >>> allocate the initial window. Try this (relative to the previous patches): >> Dmesg changed a bit, but still no luck: >> http://people.freebsd.org/~mav/newpcib/dmesg.next > > Oh, I'm dumb. 'w->base' should be set to 'max_address' and 'w->limit' should > be set to 0 to turn off the bogus windows like this: No luck: http://people.freebsd.org/~mav/newpcib/dmesg.next2 -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DB73F1A.4000009>