On Tuesday, June 19, 2012 9:03:57 am Andrey Zonov wrote: > On Mon, Jun 18, 2012 at 6:26 PM, John Baldwin <[email protected]> wrote: > > On Saturday, June 16, 2012 6:10:47 am Andrey Zonov wrote: > >> On 6/15/12 9:24 PM, John Baldwin wrote: > >> > On Friday, June 15, 2012 2:12:06 am Andrey Zonov wrote: > >> >> On 6/13/12 7:10 PM, John Baldwin wrote: > >> >>> On Tuesday, June 12, 2012 5:57:34 pm Andrey Zonov wrote: > >> >>>> On 6/13/12 12:51 AM, John Baldwin wrote: > >> >>>>> On Tuesday, June 12, 2012 3:53:09 pm Andrey Zonov wrote: > >> >>>>>> On 6/12/12 10:06 PM, John Baldwin wrote: > >> >>>>>>> > >> >>>>>> [snip] > >> >>>>>>> Ok, I've added some more debugging. The patch is a bit larger now and > >> > you > >> >>>>> can > >> >>>>>>> fetch it from www.freebsd.org/~jhb/patches/pcib_debug.patch > >> >>>>>>> > >> >>>>>> > >> >>>>>> New dmesg is in attach. > >> >>>>> > >> >>>>> Sheesh, found another bug (wasn't masking 'front' properly). > >> >>>>> > >> >>>>> Try updated patch (same URL). > >> >>>>> > >> >>>> > >> >>>> Great! It works! > >> >>> > >> >>> Excellent. I've committed the 2 bugs needed to fix your box. However, > >> >>> there is another bug that this exposed that I'd like you to test. Can you > >> >>> update to the latest HEAD, apply the updated pcib_debug.patch, and boot > >> >>> with 'hw.pci.pcib_clear=1' set from the loader? That should exercise the > >> >>> bug I'm worried about and see if my fixes for that (recursively growing > >> >>> windows) works correctly. > >> >>> > >> >> > >> >> Attached. > >> > > >> > Hmm, it doesn't seem like hw.pci.pcib_clear was set (the pcibX devices still > >> > tried to allocate their initial windows). > >> > > >> > >> Ooops. > > > > Thanks. Unfortunately, this didn't actually exercise what I wanted, but that > > is ok. However, this did uncover another bug it seems: > > > > pcib7: <ACPI PCI-PCI bridge> at device 0.3 on pci5 > > pci6: <ACPI PCI bus> on pcib7 > > pci6: domain=0, physical bus=6 > > found-> vendor=0x1000, dev=0x0054, revid=0x02 > > pcib3: attempting to grow I/O port window for (0xd000-0xdfff,0x1000) > > front candidate range: 0xd000-0xdfff > > pcib3: bus_adjust_resource(0xc000, 0xefff) > > pci0: bus_adjust_resource(pcib3, 0x1c, 0xc000, 0xefff) > > pcib0: bus_adjust_resource(pcib3, 0x1c, 0xc000, 0xefff) > > acpi0: bus_adjust_resource(pcib3, 0x1c, 0xc000, 0xefff) > > nexus0: bus_adjust_resource(pcib3, 0x1c, 0xc000, 0xefff) > > pcib3: grew I/O port window to 0xc000-0xefff > > pcib3: allocated I/O port range (0xd000-0xdfff) for rid 1c of pcib7 > > pcib7: allocated initial I/O port window of 0xd000-0xdfff > > > > This grew the range too large resulting in this failure later on: > > > > pcib9: failed to allocate initial I/O port window (0xc000-0xcfff,0x1000) > > > > Can you try the updated pcib_debug.patch? It has some more printf's for > > this case. > > > > Sure.
Ok, found the bug, thanks! -- John Baldwin _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
