On 5/8/21 10:06 AM, Vaibhav Jain wrote:
> Currently drc_pmem_qeury_stats() generates a dev_err in case
> "Enable Performance Information Collection" feature is disabled from
> HMC or performance stats are not available for an nvdimm. The error is
> of the form be
Currently the code assumes that only nfit supports error injection,
remove those assumptions before error injection support for PAPR is
added. Add bus operations similar to that of DIMM operations with
injection operations in it.
Signed-off-by: Santosh Sivaraj
---
ndctl/lib/inject.c | 96
Add support for error injection on PAPR family of devices. This is
particularly useful in running 'make check' on non-nfit platforms.
Signed-off-by: Santosh Sivaraj
---
ndctl/lib/libndctl.c | 1 +
ndctl/lib/papr.c | 134 ++
ndctl/lib
Add necessary support for error injection family of tests on non-acpi
platforms.
Signed-off-by: Santosh Sivaraj
---
tools/testing/nvdimm/test/ndtest.c | 455 -
tools/testing/nvdimm/test/ndtest.h | 25 ++
2 files changed, 477 insertions(+), 3 deletions(-)
diff --git
On Sat, May 08, 2021 at 10:06:42AM +0530, Vaibhav Jain wrote:
> Currently drc_pmem_qeury_stats() generates a dev_err in case
> "Enable Performance Information Collection" feature is disabled from
> HMC or performance stats are not available for an nvdimm. The error is
Currently drc_pmem_qeury_stats() generates a dev_err in case
"Enable Performance Information Collection" feature is disabled from
HMC or performance stats are not available for an nvdimm. The error is
of the form below:
papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Faile
t; HMC or performance stats are not available for an nvdimm. The error is
>> of the form below:
>>
>> papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Failed to query
>> performance stats, Err:-10
>>
>> This error message confuses users as it imp
On Thu, May 06, 2021 at 12:46:06AM +0530, Vaibhav Jain wrote:
> Currently drc_pmem_qeury_stats() generates a dev_err in case
> "Enable Performance Information Collection" feature is disabled from
> HMC or performance stats are not available for an nvdimm. The error is
Currently drc_pmem_qeury_stats() generates a dev_err in case
"Enable Performance Information Collection" feature is disabled from
HMC or performance stats are not available for an nvdimm. The error is
of the form below:
papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Faile
Add support for error injection on PAPR family of devices. This is
particularly useful in running 'make check' on non-nfit platforms.
Signed-off-by: Santosh Sivaraj
---
ndctl/lib/libndctl.c | 1 +
ndctl/lib/papr.c | 134 ++
ndctl/lib
Currently the code assumes that only nfit supports error injection,
remove those assumptions before error injection support for PAPR is
added. Add bus operations similar to that of DIMM operations with
injection operations in it.
Signed-off-by: Santosh Sivaraj
---
This patch series is on top of
Add necessary support for error injection family of tests on non-acpi
platforms.
Signed-off-by: Santosh Sivaraj
---
tools/testing/nvdimm/test/ndtest.c | 455 -
tools/testing/nvdimm/test/ndtest.h | 25 ++
2 files changed, 477 insertions(+), 3 deletions(-)
This patch
021 at 06:10:26PM +0530, Vaibhav Jain wrote:
>>>>> Currently drc_pmem_qeury_stats() generates a dev_err in case
>>>>> "Enable Performance Information Collection" feature is disabled from
>>>>> HMC. The error is of the form below:
>>>>>
>
;> "Enable Performance Information Collection" feature is disabled from
> >> HMC. The error is of the form below:
> >>
> >> papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Failed to query
> >> performance stats, Err:-10
> >>
>
c_pmem_qeury_stats() generates a dev_err in case
>> >> "Enable Performance Information Collection" feature is disabled from
>> >> HMC. The error is of the form below:
>> >>
>> >> papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Failed to query
&
Thanks for looking into this Dan,
Dan Williams writes:
> On Wed, Apr 14, 2021 at 5:40 AM Vaibhav Jain wrote:
>>
>> Currently drc_pmem_qeury_stats() generates a dev_err in case
>> "Enable Performance Information Collection" feature is disabled from
>>
On Wed, Apr 14, 2021 at 5:40 AM Vaibhav Jain wrote:
>
> Currently drc_pmem_qeury_stats() generates a dev_err in case
> "Enable Performance Information Collection" feature is disabled from
> HMC. The error is of the form below:
>
> papr_scm ibm,persistent-memory:ibm
se
> >> "Enable Performance Information Collection" feature is disabled from
> >> HMC. The error is of the form below:
> >>
> >> papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Failed to query
> >> performance stats, Err:-10
> >>
> &
Thanks for looking into this patch Ira,
Ira Weiny writes:
> On Wed, Apr 14, 2021 at 06:10:26PM +0530, Vaibhav Jain wrote:
>> Currently drc_pmem_qeury_stats() generates a dev_err in case
>> "Enable Performance Information Collection" feature is disabled from
>>
On Wed, Apr 14, 2021 at 06:10:26PM +0530, Vaibhav Jain wrote:
> Currently drc_pmem_qeury_stats() generates a dev_err in case
> "Enable Performance Information Collection" feature is disabled from
> HMC. The error is of the form below:
>
> papr_scm ibm,persistent-me
Currently drc_pmem_qeury_stats() generates a dev_err in case
"Enable Performance Information Collection" feature is disabled from
HMC. The error is of the form below:
papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Failed to query
performance stats, Err:-10
This err
This patch fixes the compiling error when BCACHE_NVM_PAGES is disabled.
The change could be added into previous nvm-pages patches, so that this
patch can be dropped in next nvm-pages series.
Signed-off-by: Coly Li
Cc: Jianpeng Ma
Cc: Qiaowei Ren
---
drivers/md/bcache/nvm-pages.c | 4
Dear linux-nvdimm,
Your package that was sent through our channel has arrived but we are unable to deliver it to you due to incomplete delivery details.
Please
Click Here
to view and provide us with the required details marke
The static variable match_always_count is supposed to track if there is
a driver registered that has .match_always set. If driver_register()
fails, the previous increment must be undone.
Signed-off-by: Uwe Kleine-König
---
drivers/dax/bus.c | 10 +-
1 file changed, 9 insertions(+), 1 del
The static variable match_always_count is supposed to track if there is
a driver registered that has .match_always set. If driver_register()
fails, the previous increment must be undone.
Signed-off-by: Uwe Kleine-König
---
drivers/dax/bus.c | 10 +-
1 file changed, 9 insertions(+), 1 del
From: Randy Dunlap
[ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ]
fs/dax.c uses copy_user_page() but ARC does not provide that interface,
resulting in a build error.
Provide copy_user_page() in .
../fs/dax.c: In function 'copy_cow_page_dax':
../fs/dax.c:702:2: error
From: Randy Dunlap
[ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ]
fs/dax.c uses copy_user_page() but ARC does not provide that interface,
resulting in a build error.
Provide copy_user_page() in .
../fs/dax.c: In function 'copy_cow_page_dax':
../fs/dax.c:702:2: error
From: Randy Dunlap
[ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ]
fs/dax.c uses copy_user_page() but ARC does not provide that interface,
resulting in a build error.
Provide copy_user_page() in .
../fs/dax.c: In function 'copy_cow_page_dax':
../fs/dax.c:702:2: error
From: Randy Dunlap
[ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ]
fs/dax.c uses copy_user_page() but ARC does not provide that interface,
resulting in a build error.
Provide copy_user_page() in .
../fs/dax.c: In function 'copy_cow_page_dax':
../fs/dax.c:702:2: error
From: Randy Dunlap
[ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ]
fs/dax.c uses copy_user_page() but ARC does not provide that interface,
resulting in a build error.
Provide copy_user_page() in .
../fs/dax.c: In function 'copy_cow_page_dax':
../fs/dax.c:702:2: error
From: Randy Dunlap
[ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ]
fs/dax.c uses copy_user_page() but ARC does not provide that interface,
resulting in a build error.
Provide copy_user_page() in .
../fs/dax.c: In function 'copy_cow_page_dax':
../fs/dax.c:702:2: error
From: Randy Dunlap
[ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ]
fs/dax.c uses copy_user_page() but ARC does not provide that interface,
resulting in a build error.
Provide copy_user_page() in .
../fs/dax.c: In function 'copy_cow_page_dax':
../fs/dax.c:702:2: error
From: Randy Dunlap
[ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ]
fs/dax.c uses copy_user_page() but ARC does not provide that interface,
resulting in a build error.
Provide copy_user_page() in .
../fs/dax.c: In function 'copy_cow_page_dax':
../fs/dax.c:702:2: error
From: Randy Dunlap
[ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ]
fs/dax.c uses copy_user_page() but ARC does not provide that interface,
resulting in a build error.
Provide copy_user_page() in .
../fs/dax.c: In function 'copy_cow_page_dax':
../fs/dax.c:702:2: error
From: Randy Dunlap
[ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ]
fs/dax.c uses copy_user_page() but ARC does not provide that interface,
resulting in a build error.
Provide copy_user_page() in .
../fs/dax.c: In function 'copy_cow_page_dax':
../fs/dax.c:702:2: error
From: Randy Dunlap
[ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ]
fs/dax.c uses copy_user_page() but ARC does not provide that interface,
resulting in a build error.
Provide copy_user_page() in .
../fs/dax.c: In function 'copy_cow_page_dax':
../fs/dax.c:702:2: error
From: Randy Dunlap
[ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ]
fs/dax.c uses copy_user_page() but ARC does not provide that interface,
resulting in a build error.
Provide copy_user_page() in .
../fs/dax.c: In function 'copy_cow_page_dax':
../fs/dax.c:702:2: error
linux-nvdimm@lists.01.org mailbox is full.
5.36 GB
1.98 GB
Your mailbox can no longer send or receive messages. update your storage
UPDATE STORAGE
Mailbox address:linux-nvdimm@lists.01.org___
Linux-nvdimm mailing list -- linux-nvdimm@l
On 1/4/21 7:44 PM, Randy Dunlap wrote:
> fs/dax.c uses copy_user_page() but ARC does not provide that interface,
> resulting in a build error.
>
> Provide copy_user_page() in .
>
> ../fs/dax.c: In function 'copy_cow_page_dax':
> ../fs/dax.c:702:2: error: i
On Thu, Dec 31, 2020 at 08:29:14PM -0800, Randy Dunlap wrote:
> fs/dax.c uses copy_user_page() but ARC does not provide that interface,
> resulting in a build error.
>
> Provide copy_user_page() in (beside copy_page()) and
> add to fs/dax.c to fix the build error.
>
> ../
On Mon, Jan 4, 2021 at 7:47 PM Randy Dunlap wrote:
>
> On 1/4/21 12:13 PM, Dan Williams wrote:
> > On Thu, Dec 31, 2020 at 8:29 PM Randy Dunlap wrote:
> >>
> >> fs/dax.c uses copy_user_page() but ARC does not provide that interface,
> >> result
fs/dax.c uses copy_user_page() but ARC does not provide that interface,
resulting in a build error.
Provide copy_user_page() in .
../fs/dax.c: In function 'copy_cow_page_dax':
../fs/dax.c:702:2: error: implicit declaration of function 'copy_user_page';
did you mean 'cop
On 1/4/21 12:13 PM, Dan Williams wrote:
> On Thu, Dec 31, 2020 at 8:29 PM Randy Dunlap wrote:
>>
>> fs/dax.c uses copy_user_page() but ARC does not provide that interface,
>> resulting in a build error.
>>
>> Provide copy_user_page() in (beside copy_page()) a
On Mon, Jan 04, 2021 at 12:13:02PM -0800, Dan Williams wrote:
> On Thu, Dec 31, 2020 at 8:29 PM Randy Dunlap wrote:
> > +++ lnx-511-rc1/fs/dax.c
> > @@ -25,6 +25,7 @@
> > #include
> > #include
> > #include
> > +#include
>
> I would expect this to come from one of the linux/ includes like
>
On Thu, Dec 31, 2020 at 8:29 PM Randy Dunlap wrote:
>
> fs/dax.c uses copy_user_page() but ARC does not provide that interface,
> resulting in a build error.
>
> Provide copy_user_page() in (beside copy_page()) and
> add to fs/dax.c to fix the build error.
>
>
On Thu, Dec 31, 2020 at 08:29:14PM -0800, Randy Dunlap wrote:
> fs/dax.c uses copy_user_page() but ARC does not provide that interface,
> resulting in a build error.
>
> Provide copy_user_page() in (beside copy_page()) and
> add to fs/dax.c to fix the build error.
>
> ../
fs/dax.c uses copy_user_page() but ARC does not provide that interface,
resulting in a build error.
Provide copy_user_page() in (beside copy_page()) and
add to fs/dax.c to fix the build error.
../fs/dax.c: In function 'copy_cow_page_dax':
../fs/dax.c:702:2: error: implicit decl
On 10/26/20 11:04 AM, Zhang Qilong wrote:
> call trace:
> -> mapping_store()
> -> range_parse()
> ..
> rc = -ENXIO;
>
> According to context, the error return value of
> range_parse should be negative.
>
> Si
call trace:
-> mapping_store()
-> range_parse()
..
rc = -ENXIO;
According to context, the error return value of
range_parse should be negative.
Signed-off-by: Zhang Qilong
---
drivers/dax/bus.c | 2 +-
1 file changed, 1 ins
Signed-off-by: Santosh Sivaraj
---
test/libndctl.c | 61 +++--
1 file changed, 34 insertions(+), 27 deletions(-)
diff --git a/test/libndctl.c b/test/libndctl.c
index aaa72dc..ae87807 100644
--- a/test/libndctl.c
+++ b/test/libndctl.c
@@ -575,7 +575,8 @
Static analysis reports that the bb != NULL check is redundant because
ndctl_namespace_bb_foreach already uses that as a loop condition. Remove
it.
Signed-off-by: Vishal Verma
---
ndctl/inject-error.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/ndctl/inject-error.c b/ndctl/inject-error
On Mon, Sep 21, 2020 at 11:47 AM Dan Williams wrote:
>
> On Mon, Sep 21, 2020 at 11:35 AM Nick Desaulniers
> wrote:
> >
> > Hello DAX maintainers,
> > I noticed our PPC64LE builds failing last night:
> > https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/388047043
> > https:
Hello DAX maintainers,
I noticed our PPC64LE builds failing last night:
https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/388047043
https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/388047056
https://travis-ci.com/github/ClangBuiltLinux/continuous-integ
On Mon, Sep 21, 2020 at 11:35 AM Nick Desaulniers
wrote:
>
> Hello DAX maintainers,
> I noticed our PPC64LE builds failing last night:
> https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/388047043
> https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/388
3
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross
> ARCH=x86_64
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
>
> All errors (new ones pr
=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/dax/super.c:325:6: error: redefinition of 'dax_supported'
bool dax_supported(struct dax_device *dax_dev, str
include/linux/pfn_t.h:76:9: note: in expansion of macro 'pfn_valid'
76 | return pfn_valid(pfn_t_to_pfn(pfn));
| ^
drivers/dax/super.c: At top level:
>> drivers/dax/super.c:31:5: error: redefinition of 'dax_read_lock'
31 | int da
On 2020/9/11 04:29, John Pittman wrote:
> But it should be moved prior to the two bdev_dax_pgoff() checks right?
> Else a misaligned partition on a dax unsupported block device can
> print the below messages.
>
> kernel: sda1: error: unaligned partition for dax
> kernel: sda2
But it should be moved prior to the two bdev_dax_pgoff() checks right?
Else a misaligned partition on a dax unsupported block device can
print the below messages.
kernel: sda1: error: unaligned partition for dax
kernel: sda2: error: unaligned partition for dax
kernel: sda3: error: unaligned
e for the above purpose.
Fixes: c2affe920b0e ("dax: do not print error message for non-persistent memory
block device")
Signed-off-by: Coly Li
Reviewed-and-tested-by: Adrian Huang
Reviewed-by: Ira Weiny
Reviewed-by: Mike Snitzer
Reviewed-by: Pankaj Gupta
Cc: Jan Kara
Cc: Vishal
On 2020/9/4 00:00, Mike Snitzer wrote:
> On Thu, Sep 03 2020 at 11:28am -0400,
> Coly Li wrote:
>
>> When calling __generic_fsdax_supported(), a dax-unsupported device may
>> not have dax_dev as NULL, e.g. the dax related code block is not enabled
>> by Kconfig.
>>
>> Therefore in __generic_fsdax
>> - if (!dax_dev && !bdev_dax_supported(bdev, blocksize)) {
>> + if (!dax_dev || !bdev_dax_supported(bdev, blocksize)) {
>>
>>
>> Fixes: c2affe920b0e ("dax: do not print error message for non-persistent
>> memory blo
v_dax_supported(bdev, blocksize)) {
>
>
> Fixes: c2affe920b0e ("dax: do not print error message for non-persistent
> memory block device")
> Signed-off-by: Coly Li
I hate to do this because I realize this is a bug which people really need
fixed.
However, shouldn't
wing change for the above purpose,
- if (!dax_dev && !bdev_dax_supported(bdev, blocksize)) {
+ if (!dax_dev || !bdev_dax_supported(bdev, blocksize)) {
Fixes: c2affe920b0e ("dax: do not print error message for non-persistent memory
block device")
Signed-off-by
!bdev_dax_supported(bdev, blocksize)) {
Don't think I've ever seen a one-liner fix document the diff in its
patch header. Really no need for that.
> Fixes: c2affe920b0e ("dax: do not print error message for non-persistent
> memory block device")
> Signed-off-by: Coly Li
can be
> recognized as dax-unsupported eventually.
>
> This patch does the following change for the above purpose,
> - if (!dax_dev && !bdev_dax_supported(bdev, blocksize)) {
> + if (!dax_dev || !bdev_dax_supported(bdev, blocksize)) {
>
>
> Fix
wing change for the above purpose,
- if (!dax_dev && !bdev_dax_supported(bdev, blocksize)) {
+ if (!dax_dev || !bdev_dax_supported(bdev, blocksize)) {
Fixes: c2affe920b0e ("dax: do not print error message for non-persistent memory
block device")
Signed-off-by
[PATCH] dax: fix for do not print error message for non-
> persistent memory block device
>
> When calling __generic_fsdax_supported(), a dax-unsupported device may not
> have dax_dev as NULL, e.g. the dax related code block is not enabled by
> Kconfig.
>
> Therefore in
wing change for the above purpose,
- if (!dax_dev && !bdev_dax_supported(bdev, blocksize)) {
+ if (!dax_dev || !bdev_dax_supported(bdev, blocksize)) {
Fixes: c2affe920b0e ("dax: do not print error message for non-persistent memory
block device")
Signed-off-
rg; Adrian Huang12
>> Subject: [External] Re: flood of "dm-X: error: dax access failed" due to 5.9
>> commit 231609785cbfb
>>
>> On 2020/9/3 13:20, Coly Li wrote:
>>> On 2020/9/3 00:51, Mike Snitzer wrote:
>>>> On Wed, Sep 02 2020 at 12:46pm -0400
> -Original Message-
> From: Coly Li
> Sent: Thursday, September 3, 2020 4:37 PM
> To: Mike Snitzer
> Cc: Jan Kara ; Ira Weiny ; Pankaj Gupta
> ; Vishal Verma ;
> linux-nvdimm@lists.01.org; Adrian Huang12
> Subject: [External] Re: flood of "dm-X: error:
-nvdimm@lists.01.org; Adrian Huang12
>> Subject: [External] Re: flood of "dm-X: error: dax access failed" due to 5.9
>> commit 231609785cbfb
>>
>> On 2020/9/3 00:51, Mike Snitzer wrote:
>>> On Wed, Sep 02 2020 at 12:46pm -0400,
>>> Coly Li wrote:
Hi Coly,
> -Original Message-
> From: Coly Li
> Sent: Thursday, September 3, 2020 1:20 PM
> To: Mike Snitzer
> Cc: Jan Kara ; Ira Weiny ; Pankaj Gupta
> ; Vishal Verma ;
> linux-nvdimm@lists.01.org; Adrian Huang12
> Subject: [External] Re: flood of "dm-X:
rote:
>>>>
>>>>> On 2020/9/3 00:04, Mike Snitzer wrote:
>>>>>> 5.9 commit 231609785cbfb ("dax: print error message by pr_info() in
>>>>>> __generic_fsdax_supported()") switched from pr_debug() to pr_info().
>>>>&g
zer wrote:
>>>>> 5.9 commit 231609785cbfb ("dax: print error message by pr_info() in
>>>>> __generic_fsdax_supported()") switched from pr_debug() to pr_info().
>>>>>
>>>>> The justification in the commit header is really inadequa
zer wrote:
>>>>> 5.9 commit 231609785cbfb ("dax: print error message by pr_info() in
>>>>> __generic_fsdax_supported()") switched from pr_debug() to pr_info().
>>>>>
>>>>> The justification in the commit header is really inadequa
On 2020/9/3 07:05, Verma, Vishal L wrote:
> On Thu, 2020-09-03 at 00:40 +0800, Coly Li wrote:
>> On 2020/9/3 00:04, Mike Snitzer wrote:
>>> 5.9 commit 231609785cbfb ("dax: print error message by pr_info() in
>>> __generic_fsdax_supported()") switched from
On Thu, 2020-09-03 at 00:40 +0800, Coly Li wrote:
> On 2020/9/3 00:04, Mike Snitzer wrote:
> > 5.9 commit 231609785cbfb ("dax: print error message by pr_info() in
> > __generic_fsdax_supported()") switched from pr_debug() to pr_info().
> >
> > The justifi
zer wrote:
>>>>> 5.9 commit 231609785cbfb ("dax: print error message by pr_info() in
>>>>> __generic_fsdax_supported()") switched from pr_debug() to pr_info().
>>>>>
>>>>> The justification in the commit header is really inadequa
On Wed, Sep 02 2020 at 12:46pm -0400,
Coly Li wrote:
> On 2020/9/3 00:44, Mike Snitzer wrote:
> > On Wed, Sep 02 2020 at 12:40pm -0400,
> > Coly Li wrote:
> >
> >> On 2020/9/3 00:04, Mike Snitzer wrote:
> >>> 5.9 commit 231609785cbfb
On 2020/9/3 00:44, Mike Snitzer wrote:
> On Wed, Sep 02 2020 at 12:40pm -0400,
> Coly Li wrote:
>
>> On 2020/9/3 00:04, Mike Snitzer wrote:
>>> 5.9 commit 231609785cbfb ("dax: print error message by pr_info() in
>>> __generic_fsdax_supported()") switche
On Wed, Sep 02 2020 at 12:40pm -0400,
Coly Li wrote:
> On 2020/9/3 00:04, Mike Snitzer wrote:
> > 5.9 commit 231609785cbfb ("dax: print error message by pr_info() in
> > __generic_fsdax_supported()") switched from pr_debug() to pr_info().
> >
> > The justifi
On 2020/9/3 00:04, Mike Snitzer wrote:
> 5.9 commit 231609785cbfb ("dax: print error message by pr_info() in
> __generic_fsdax_supported()") switched from pr_debug() to pr_info().
>
> The justification in the commit header is really inadequate. If there
> is a problem
5.9 commit 231609785cbfb ("dax: print error message by pr_info() in
__generic_fsdax_supported()") switched from pr_debug() to pr_info().
The justification in the commit header is really inadequate. If there
is a problem that you need to drill in on, repeat the testing after
enabling t
drivers/nvdimm/e820.c:24:12: error: implicit declaration of function
> ‘phys_to_target_node’; did you mean ‘set_page_node’?
> [-Werror=implicit-function-declaration]
> int nid = phys_to_target_node(res->start);
> ^~~
> set_page_node
&
Hi YueHaibing,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linux-nvdimm/libnvdimm-for-next]
[also build test ERROR on v5.9-rc2 next-20200826]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
Hi YueHaibing,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linux-nvdimm/libnvdimm-for-next]
[also build test ERROR on v5.9-rc2 next-20200826]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
Hi YueHaibing,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linux-nvdimm/libnvdimm-for-next]
[also build test ERROR on v5.9-rc2 next-20200826]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
If MEMORY_HOTPLUG is n, build fails:
drivers/nvdimm/e820.c: In function ‘e820_register_one’:
drivers/nvdimm/e820.c:24:12: error: implicit declaration of function
‘phys_to_target_node’; did you mean ‘set_page_node’?
[-Werror=implicit-function-declaration]
int nid = phys_to_target_node(res
On 2020/8/19 23:42, Adrian Huang wrote:
> From: Adrian Huang
>
> From: Adrian Huang
>
> Commit 231609785cbf ("dax: print error message by pr_info()
> in __generic_fsdax_supported()") happens to print the following
> error message during booting when the non-pe
From: Adrian Huang
From: Adrian Huang
Commit 231609785cbf ("dax: print error message by pr_info()
in __generic_fsdax_supported()") happens to print the following
error message during booting when the non-persistent memory block
devices are configured by device mapper. Those error me
us, ns_offset, ns_size);
- rc = ndctl_cmd_submit(cmd);
- if (rc < 0) {
- dbg(ctx, "Error submitting ars_cap: %d\n", rc);
- goto out;
- }
- buf_size = ndctl_cmd_ars_cap_get_size(cmd)
If your Canon printer is in error state then it could be because of some
connection issue or incompatible drivers. In order to fix canon printer in
error state issue, you can start off by checking the connection between the
printer and the laptop. Ensure that the wireless network or cable that
> The error-number passed into xas_set_err() should be negative. Otherwise,
> the xas_error() will return 0, and grab_mapping_entry() will return the
> found entry instead of a SIGBUS error when the entry is not a value.
> And then, the subsequent code path would be wrong.
>
>
> The error-number passed into xas_set_err() should be negative. Otherwise,
> the xas_error() will return 0, and grab_mapping_entry() will return the
> found entry instead of a SIGBUS error when the entry is not a value.
> And then, the subsequent code path would be wrong.
>
>
The error-number passed into xas_set_err() should be negative. Otherwise,
the xas_error() will return 0, and grab_mapping_entry() will return the
found entry instead of a SIGBUS error when the entry is not a value.
And then, the subsequent code path would be wrong.
Signed-off-by: Hao Li
---
fs
pr_info() to print all the error messages
inside __generic_fsdax_supported(). Then users may find informative clue
from the kernel message at least.
I happen to notice that some servers set their printk levels at 4 by default
to minimize console messages:
# cat /proc/sys/kernel/printk
4 4 1 7
pr_info() to print all the error messages
> > inside __generic_fsdax_supported(). Then users may find informative clue
> > from the kernel message at least.
>
> I happen to notice that some servers set their printk levels at 4 by default
> to minimize console messages:
> # c
Hi,
On 7/25/2020 9:24 AM, Coly Li wrote:
It is not simple to make dax_supported() from struct dax_operations
or __generic_fsdax_supported() to return exact failure type right now.
So the simplest fix is to use pr_info() to print all the error messages
inside __generic_fsdax_supported(). Then
,
missing codepage or helper program, or other error.
And from the dmesg output there is only the following information,
[ 307.853148] EXT4-fs (pmem0): DAX unsupported by block device.
The above information is quite confusing. Because definitely the pmem0
device supports dax operation, and the
1 - 100 of 594 matches
Mail list logo
