This Message was undeliverable due to the following reason:
Your message was not delivered because the destination computer was
not reachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.
Most likely
Integration testing with a BIOS that generates injected health event
notifications fails to communicate those events to userspace. The nfit
driver neglects to link the ACPI DIMM device with the necessary driver
data so acpi_nvdimm_notify() fails this lookup:
nfit_mem =
When we first scan the SMBIOS table, save the size of the DIMM.
Provide a function for other code (EDAC driver) to look up the size
of a DIMM from its SMBIOS handle.
Signed-off-by: Tony Luck
---
drivers/firmware/dmi_scan.c | 29 +
There are now non-volatile versions of DIMMs. Add a new entry to
"enum mem_type" and update places that use it with new strings.
Signed-off-by: Tony Luck
---
drivers/edac/edac_mc.c | 1 +
drivers/edac/edac_mc_sysfs.c | 3 ++-
include/linux/edac.h | 3 +++
3
A Skylake server may have some DIMM slots filled with NVDIMMs
instead of normal DDR4 DIMMs. These are enumerated differently
by the memory controller.
Sadly there isn't an easy way to just peek at some memory controller
register to find the size of these DIMMs, so we have to rely on the
NFIT and
This just covers the topology function of the EDAC driver.
We locate which DIMM slots are populated with NVDIMMs and
query the NFIT and SMBIOS tables to get the size.
Signed-off-by: Tony Luck
---
drivers/edac/Kconfig| 2 ++
drivers/edac/skx_edac.c | 56
EDAC driver needs to look up attributes of NVDIMMs provided in SMBIOS.
Provide a function that looks up an acpi_nfit_memory_map from a device
handle (node/socket/mc/channel/dimm) and returns the SMBIOS handle.
Also pass back the "flags" so we can see if the NVDIMM is OK.
Signed-off-by: Tony Luck
[ adding linux-rdma ]
On Thu, Nov 30, 2017 at 10:17 AM, Michal Hocko wrote:
>
> On Thu 30-11-17 10:03:26, Dan Williams wrote:
> > On Thu, Nov 30, 2017 at 9:42 AM, Michal Hocko wrote:
> > >
> > > On Thu 30-11-17 08:39:51, Dan Williams wrote:
> > > > On Thu,
On Thu 30-11-17 10:03:26, Dan Williams wrote:
> On Thu, Nov 30, 2017 at 9:42 AM, Michal Hocko wrote:
> >
> > On Thu 30-11-17 08:39:51, Dan Williams wrote:
> > > On Thu, Nov 30, 2017 at 1:53 AM, Michal Hocko wrote:
> > > > On Wed 29-11-17 10:05:35, Dan
On Thu, Nov 30, 2017 at 9:42 AM, Michal Hocko wrote:
>
> On Thu 30-11-17 08:39:51, Dan Williams wrote:
> > On Thu, Nov 30, 2017 at 1:53 AM, Michal Hocko wrote:
> > > On Wed 29-11-17 10:05:35, Dan Williams wrote:
> > >> Until there is a solution to the
On Thu 30-11-17 08:39:51, Dan Williams wrote:
> On Thu, Nov 30, 2017 at 1:53 AM, Michal Hocko wrote:
> > On Wed 29-11-17 10:05:35, Dan Williams wrote:
> >> Until there is a solution to the dma-to-dax vs truncate problem it is
> >> not safe to allow long standing memory
On Thu, Nov 30, 2017 at 1:53 AM, Michal Hocko wrote:
> On Wed 29-11-17 10:05:35, Dan Williams wrote:
>> Until there is a solution to the dma-to-dax vs truncate problem it is
>> not safe to allow long standing memory registrations against
>> filesytem-dax vmas. Device-dax vmas
On Wed 29-11-17 10:05:35, Dan Williams wrote:
> Until there is a solution to the dma-to-dax vs truncate problem it is
> not safe to allow long standing memory registrations against
> filesytem-dax vmas. Device-dax vmas do not have this problem and are
> explicitly allowed.
>
> This is temporary
13 matches
Mail list logo