Re: [PATCH 1/2][RESEND] x86/pci/amd: Restoreearly_fill_mp_bus_to_node

[Andreas Herrmann]

On Wed, May 02, 2012 at 11:33:17AM -0600, Bjorn Helgaas wrote:
> On Fri, Apr 27, 2012 at 8:36 AM, Andreas Herrmann
> <andreas.herrmann3@xxxxxxx> wrote:
> >
> > Once upon a time this function was overloaded with quirky stuff to fix
> > resource detection on systems w/ _CRS defects (seems that some Sun and
> > HP systems were affected).
> >
> > See commit 30a18d6c3f1e774de656ebd8ff219d53e2ba4029
> > (x86: multi pci root bus with different io resource range, on 64-bit)
> >
> > Restore the old function and thus decouple it from the quirk that is
> > CPU family specific (e.g. it won't work on AMD family 15h CPUs). BTW,
> > I assume that the _CRS stuff is working on current systems.
> >
> > This is required to properly initilize the numa_node information of
> > existing PCI busses and associated devices.
> 
> I applied some of Yinghai's patches that also touch this area.  Can
> you refresh these so they apply on top of my "next" branch
> (git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next)?

Arrgh, will adapt my patch and resend it (asap).

> Can you also be more specific about what these patches fix?

> My understanding is that amd_bus.c (1) sets NUMA info with
> set_mp_bus_to_node() and (2) figures out MMIO and I/O port apertures,
> which are only used when blind probing and when ignoring _CRS.
> 
> It seems like the main change in this patch is that we skip (2)
> completely when family >= 0x11, and I don't understand what that could
> fix.
> 

The patch restores a very old function that was used to detect the
nearest node for a PCI bus, so yes it's used to do (1). IMHO this
function was totally screwed up with Yinghai's code to do (2). It
seems that Sun has (had?) some systems where (2) was req'd. I don't
care about this part. But I'd like to do (1) on all AMD CPU NUMA
systems.

> [more comments below]

Will consider them when reworking the patch.


Thanks,
Andreas


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/