RETURNED MAIL: DATA FORMAT ERROR
___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
RE: [RFC PATCH v4] ndctl: monitor: add ndctl monitor daemon
> >> > >> This seems to needlessly tie ndctl to systemd, it should be able to > >> operate without requiring systemd. I expect it would be > >> straightforward to copy the configuration file implementation from git. > > > > Would you like to explain why it should be able to operate without requiring > systemd? > > systemd is not universally available in all distributions and it is useful to > have custom > configuration files for manually started daemons. > > Another consideration is that a sub-set of monitoring activities can be done > without > root privileges. It would be unforunate if a user could not specify changes > to the > configuration because those files are root-only and owned by systemd. > > > The reason we want to add the configuration file is that when starting > > the monitors by systemd, options and arguments cannot be passed by systemd. > > When we start monitors by using "# ndctl monitor" command, we do not > > need any configuration files, because options and arguments can be added > directly. > > > > Furthermore, if we choose configuration file implementation, we may > > encounter > the following problem. > > If we start the monitor with command like "# ndctl monitor --dimm > > nmem1 --daemon --conf-file /etc/ndctl.conf", when the variable of dimm > > in configuration file is not the same as the argument of [--dimm] option, > > which > argument should the filter_dimm() refer to? > > The command line option should union with the configuration file for > filtering options. > I.e. if the config file says to monitor nmem0 and the command line says to > monitor > nmem1 then the tool should monitor both. If there are other settings the > might be > in conflict then command line should override the configuration file. > > This matches the policy of most daemons that I have encountered in Linux. OK, I see. Thank you very much. ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re : {Alerting You}
Hello, I am very sorry I have to reach you through this medium. I am a member of the European Debt Recovery Unit and I am aware of your ordeal about your unpaid fund. It may also interest you to know that, not long after the Debt Management Office (DMO) completed the merger and acquisition process of all pending payments in response to the petition raised by the international community about their unpaid funds. I discovered that their boss connived with some top officials to divert funds approve to settle unpaid inheritances, email lottery winners, Internet scam victims, unclaimed consignments(concealed funds) and International Contractors. The DMO has already given approval for the payment of your fund but they deliberately withheld your payment file and continue to demand fees from you through their associates from different unassigned affiliates mostly from Africa, US and the Netherlands all in an attempt to frustrate you and enrich themselves. I wonder why you haven’t notice all these while. You may choose to disbelieve this email as inconceivable facts but my doctrine does not permit such act, reason I have to open up to you to seek the right channel. Your fund was authorized to be paid to you through the DMO asset management firm with a Claim Code Numbers, which was supposed to have been issued to you before now. Upon your response, I shall guide you through and provide you with details to contact the assigned affiliate who will expeditiously facilitate the release of your fund. Thanks and have a wonderful day. Yours Faithfully, Administrative Staff. European Debt Recovery Agent, UK.Ref:EDRA/290318/UK03. ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH 1/2] acpi/libnvdimm: rework ARS query and removing blocking on timeout at init
On Fri, Mar 30, 2018 at 5:52 PM, Dave Jiang wrote: > On initialization we are going to set bit 1 of Start ARS DSM flag. This > allows us to retrieve the data from the previous scrub without starting a > scrub. This is to obtain any badblocks on all the DIMMs that does not have > scrubbing started by the BIOS. Previously we block surfacing the regions > until ARS is completed on all regions. That has been removed and we will > now do scrubbing in the background with a delayed workqueue. The delayed > workqueue will be scheduled starting at 1 second delay and doubled every > time it has to be rescheduled up to 30 minutes delay. The reschedule will > no longer be timing out. > > Signed-off-by: Dave Jiang > --- > drivers/acpi/nfit/core.c | 263 > ++ > drivers/acpi/nfit/nfit.h | 14 ++ > 2 files changed, 135 insertions(+), 142 deletions(-) > With the change in policy to never wait for the initial scrub and perform quick scrubs at initialization time I think this rework needs to include the removal of acpi_desc->init_complete. Also, to make the request based scrubbing easier to understand I think acpi_desc->ars_start_flags needs to be killed in favor of a per-nfit_spa request flags to trigger "return previous data" scrubs. Once we have request flags per-nfit_spa I think we can also reduce the number of scrub states from 6. Given the short time we have to land this for 4.17 I'll take a stab at this further rework, but this patch has definitely helped identify the further cleanups that are possible from where I had things originally. ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
[linux-nvdimm:libnvdimm-for-next 49/56] drivers//dax/super.c:209:44: error: dereferencing pointer to incomplete type
tree: https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
libnvdimm-for-next
head: 4f2e6ecbd1cb397d65ead8aab4fd4d05fcbfeaff
commit: 45d0fd3c767f81356f880be9a8893bb12a39488a [49/56] mm, dev_pagemap:
introduce CONFIG_DEV_PAGEMAP_OPS
config: x86_64-randconfig-g0-04011906 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 45d0fd3c767f81356f880be9a8893bb12a39488a
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers//dax/super.c: In function 'fs_dax_claim_bdev':
drivers//dax/super.c:207:2: error: implicit declaration of function
'blk_queue_dax' [-Werror=implicit-function-declaration]
if (!blk_queue_dax(bdev->bd_queue))
^
>> drivers//dax/super.c:209:44: error: dereferencing pointer to incomplete type
dax_dev = fs_dax_get_by_host(bdev->bd_disk->disk_name);
^
cc1: some warnings being treated as errors
vim +209 drivers//dax/super.c
b42158bb Dan Williams 2018-03-29 202
b42158bb Dan Williams 2018-03-29 203 struct dax_device
*fs_dax_claim_bdev(struct block_device *bdev, void *owner)
b42158bb Dan Williams 2018-03-29 204 {
b42158bb Dan Williams 2018-03-29 205 struct dax_device *dax_dev;
b42158bb Dan Williams 2018-03-29 206
b42158bb Dan Williams 2018-03-29 @207 if (!blk_queue_dax(bdev->bd_queue))
b42158bb Dan Williams 2018-03-29 208 return NULL;
b42158bb Dan Williams 2018-03-29 @209 dax_dev =
fs_dax_get_by_host(bdev->bd_disk->disk_name);
b42158bb Dan Williams 2018-03-29 210 if (dax_dev->ops->fs_claim)
b42158bb Dan Williams 2018-03-29 211 return
dax_dev->ops->fs_claim(dax_dev, owner);
b42158bb Dan Williams 2018-03-29 212 else
b42158bb Dan Williams 2018-03-29 213 return fs_dax_claim(dax_dev,
owner);
b42158bb Dan Williams 2018-03-29 214 }
b42158bb Dan Williams 2018-03-29 215 EXPORT_SYMBOL_GPL(fs_dax_claim_bdev);
b42158bb Dan Williams 2018-03-29 216
:: The code at line 209 was first introduced by commit
:: b42158bb23c9db316c12e3b3845ef01d41013314 dax, dm: introduce
->fs_{claim,release}() dax_device infrastructure
:: TO: Dan Williams
:: CC: Dan Williams
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
