Le 25/01/2019 à 00:14, Dave Hansen a écrit :
> From: Dave Hansen <[email protected]>
>
> This is intended for use with NVDIMMs that are physically persistent
> (physically like flash) so that they can be used as a cost-effective
> RAM replacement. Intel Optane DC persistent memory is one
> implementation of this kind of NVDIMM.
>
> Currently, a persistent memory region is "owned" by a device driver,
> either the "Direct DAX" or "Filesystem DAX" drivers. These drivers
> allow applications to explicitly use persistent memory, generally
> by being modified to use special, new libraries. (DIMM-based
> persistent memory hardware/software is described in great detail
> here: Documentation/nvdimm/nvdimm.txt).
>
> However, this limits persistent memory use to applications which
> *have* been modified. To make it more broadly usable, this driver
> "hotplugs" memory into the kernel, to be managed and used just like
> normal RAM would be.
>
> To make this work, management software must remove the device from
> being controlled by the "Device DAX" infrastructure:
>
> echo -n dax0.0 > /sys/bus/dax/drivers/device_dax/remove_id
> echo -n dax0.0 > /sys/bus/dax/drivers/device_dax/unbind
Hello Dave
I am trying to use these patches (on top on Dan's nvdimm-pending branch
with Keith's HMAT patches). Writing to remove_id just hangs. echo never
returns, it uses 100% CPU and I can't kill it.
[ 5468.744898] bash R running task 0 21419 21416 0x00000080
[ 5468.744899] Call Trace:
[ 5468.744902] ? vsnprintf+0x372/0x4e0
[ 5468.744904] ? klist_next+0x79/0xe0
[ 5468.744905] ? sprintf+0x56/0x80
[ 5468.744907] ? bus_for_each_dev+0x8a/0xc0
[ 5468.744911] ? do_id_store+0xe8/0x1e0
[ 5468.744914] ? _cond_resched+0x15/0x30
[ 5468.744915] ? __kmalloc+0x17f/0x200
[ 5468.744918] ? kernfs_fop_write+0x83/0x190
[ 5468.744918] ? __vfs_write+0x36/0x1b0
[ 5468.744919] ? selinux_file_permission+0xe1/0x130
[ 5468.744921] ? security_file_permission+0x36/0x100
[ 5468.744922] ? vfs_write+0xad/0x1b0
[ 5468.744922] ? ksys_write+0x52/0xc0
[ 5468.744924] ? do_syscall_64+0x5b/0x180
[ 5468.744927] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
CONFIG_NVDIMM_DAX=y
CONFIG_DAX_DRIVER=y
CONFIG_DAX=y
CONFIG_DEV_DAX=m
CONFIG_DEV_DAX_PMEM=m
CONFIG_DEV_DAX_KMEM=m
CONFIG_DEV_DAX_PMEM_COMPAT=m
CONFIG_FS_DAX=y
CONFIG_FS_DAX_PMD=y
{
"dev":"namespace0.0",
"mode":"devdax",
"map":"dev",
"size":1598128390144,
"uuid":"7046a749-477f-4690-9b3c-a640a1aa44f1",
"chardev":"dax0.0"
}
I've used your patches on fake hardware (memmap=xx!yy) with an older
nvdimm-pending branch (without Keith's patches). It worked fine. This
time I am running on real Intel hardware. Any idea where to look ?
Thanks
Brice
_______________________________________________
Linux-nvdimm mailing list
[email protected]
https://lists.01.org/mailman/listinfo/linux-nvdimm
