Date: Tue, 26 Apr 2011 09:55:29 -0400 From: John Baldwin <jhb@freebsd.org> To: Alexander Motin <mav@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Changing how PCI-PCI bridges do resource allocation Message-ID: <201104260955.29280.jhb@freebsd.org> In-Reply-To: <4DB66BE4.8070709@FreeBSD.org> References: <mailpost.1303239057.1899175.75529.mailing.freebsd.arch@FreeBSD.cs.nctu.edu.tw> <201104251721.53027.jhb@freebsd.org> <4DB66BE4.8070709@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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): --- //depot/projects/pci/sys/dev/pci/pci_pci.c 2011-04-19 17:42:14.000000000 0000 +++ /home/jhb/work/p4/pci/sys/dev/pci/pci_pci.c 2011-04-19 17:42:14.000000000 0000 @@ -60,6 +60,7 @@ static int pcib_resume(device_t dev); static int pcib_power_for_sleep(device_t pcib, device_t dev, int *pstate); +static void pcib_write_windows(struct pcib_softc *sc, int mask); static device_method_t pcib_methods[] = { /* Device interface */ @@ -181,6 +182,9 @@ device_printf(sc->dev, "failed to allocate initial %s window: %#jx-%#jx\n", w->name, (uintmax_t)w->base, (uintmax_t)w->limit); + w->base = 0; + w->limit = max_address; + pcib_write_windows(sc, w->mask); return; } -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201104260955.29280.jhb>