A few more updates:
a) This issue does not happen a lot I need to do a lot of power cycles for
this to happen.
b) We use 2 numa nodes but for some reason it happens only on the second
c) We added a debug feature that when page fault occurs we will trigger a
thread from command line in the kernel(through configfs) that will read
any physical address that we give it. When we give it the faulty address -
the thread succeeds reading from it with no page fault.
We verified that it accessed the same virtual address that caused the page
On 10 January 2018 at 09:21, Oren Berman <oren(a)lightbitslabs.com> wrote:
Which driver are you referring to?
If it is the dax driver than it is always loaded - we see /dev/dax0.
If you refer to the user space application which called the mmap on the
dax device then this application is not running anymore.
We used this application to get the virtual address mapping(doing mmap on
dax) and then by going over the proc pagemap we got the physical address.
After that the application terminates and we pass this physical address to
our kernel thread .
Then from the kernel thread we access this range by using phys_to_virt (we
know the physical so we convert it virtual).
As far as I know once in kernel space all address range should be mapped
to the kernel page tables in 64 bit architecture ofcourse,
thus accessible using phys_to_virt.
Is this a wrong assumption when dealing with NVRAM?
If I know the physical address of the nvram isn't it accessible from the
kernel using the simple conversion of phys_to_virt?
On 10 January 2018 at 01:05, Dan Williams <dan.j.williams(a)intel.com>
> On Tue, Jan 9, 2018 at 2:25 PM, Oren Berman <oren(a)lightbitslabs.com>
> > Hi
> > I would like to know if you encountered such a problem.
> > We are accessing the nvram as memory from withing the kernel.
> > By mapping dax device and reading its mapping we can know the physical
> > address of the nvram.
> > As a result we can access this address range in the kernel by calling
> > phys_to_virt.
> > This is working in most case but we saw some issue that after reboot,
> > trying to read the info saved
> > on the nvram before the power off, one kernel thread was able to read
> > from this range but another kernel thread got page fault.
> > This is not recreated very easily and we need run many reboot sequences
> > get this failure again.
> > Are you aware of any mapping issues of nvram to kernel space?
> When are you using phys_to_virt()? That will only return a valid
> virtual address as long as the driver is loaded. It sounds like you
> may be losing a race with the driver setting up or tearing down the