linux-kernel - Re: [PATCH v3] Add support for AMD64 EDAC on multiple PCI domains

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 29 Oct 2012 11:32:17 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Daniel J Blueman <daniel@...ascale-asia.com>
Cc:	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	H Peter Anvin <hpa@...or.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org,
	Andreas Herrmann <herrmann.der.user@...il.com>
Subject: Re: [PATCH v3] Add support for AMD64 EDAC on multiple PCI domains

+ Andreas.

Dude, look at this boot log below:

http://quora.org/2012/16-server-boot-2.txt

That's 192 F10h's!

On Mon, Oct 29, 2012 at 04:54:59PM +0800, Daniel J Blueman wrote:
> >A number of other callers lookup the PCI device based on index
> >0..amd_nb_num(), but we can't easily allocate contiguous northbridge IDs
> >from the PCI device in the first place.
> 
> >OTOH we can simply this code by changing amd_get_node_id to generate a
> >linear northbridge ID from the index of the matching entry in the
> >northbridge array.
> >
> >I'll get a patch together to see if there are any snags.

I suspected that after we have this nice approach, you guys would come
with non-contiguous node numbers. Maan, can't you build your systems so
that software people can have it easy at least for once??!

:-)

> This really is a lot less intrusive [1] and boots well on top of
> 3.7-rc3 on one of our 16-server/192-core/512GB systems [2].
> 
> If you're happy with this simpler approach for now, I'll present
> this and a separate patch cleaning up the inconsistent use of
> unsigned and u8 node ID variables to u16?

Sure, bring it on.

> diff --git a/arch/x86/include/asm/amd_nb.h b/arch/x86/include/asm/amd_nb.h
> index b3341e9..b88fc7a 100644
> --- a/arch/x86/include/asm/amd_nb.h
> +++ b/arch/x86/include/asm/amd_nb.h
> @@ -81,6 +81,18 @@ static inline struct amd_northbridge
> *node_to_amd_nb(int node)
>         return (node < amd_northbridges.num) ?
> &amd_northbridges.nb[node] : NULL;
>  }
> 
> +static inline u8 get_node_id(struct pci_dev *pdev)
> +{
> +       int i;
> +
> +       for (i = 0; i != amd_nb_num(); i++)
> +               if (pci_domain_nr(node_to_amd_nb(i)->misc->bus) ==
> pci_domain_nr(pdev->bus) &&
> +                   PCI_SLOT(node_to_amd_nb(i)->misc->devfn) ==
> PCI_SLOT(pdev->devfn))
> +                       return i;

Looks ok, can you send the whole patch please?

> +       BUG();

I'm not sure about this - maybe WARN()? Are we absolutely sure we
unconditionally should panic after not finding an NB descriptor?

> [2] http://quora.org/2012/16-server-boot-2.txt

That's just crazy:

[   45.987953] Brought up 192 CPUs

:-)

Btw, this shouldn't happen on those CPUs:

[   39.279131] TSC synchronization [CPU#0 -> CPU#12]:
[   39.287223] Measured 22750019569 cycles TSC warp between CPUs, turning off TSC clock.
[    0.030000] tsc: Marking TSC unstable due to check_tsc_sync_source failed

I guess TSCs are not starting at the same moment on all boards.

You definitely need ucode on those too:

[  113.392460] microcode: CPU0: patch_level=0x00000000

That's just crazy, hahahah.

Thanks.

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