Re: [PATCH] phy: qcom-ufs: export symbols needed by main drivers

On Mon, Feb 02, 2015 at 03:30:27PM +, James Bottomley wrote: Cc added for linux-scsi, since this is the origin of the problem. How important is bisectability in this? It won't affect any non-embedded user, since most don't build with UFS, so I can go either way on folding or just

Re: [PATCH v5 02/21] libnvdimm, nfit: initial libnvdimm infrastructure and NFIT support

On Wed, Jun 03, 2015 at 07:24:34PM +, Williams, Dan J wrote: +static inline struct acpi_nfit_memory_map *__to_nfit_memdev(struct nfit_mem *nfit_mem) This line is over 80 characters. I generally don't see the point of fixing up occasional small incursions over 80 characters if

Re: [PATCH v5 09/21] libnvdimm, nd_pmem: add libnvdimm support to the pmem driver

On Wed, Jun 03, 2015 at 07:31:38PM +, Williams, Dan J wrote: I like move-modify patches because they make the reason for the move clearer and revertible. Consider a general case where we later decide the reason for a move was invalid. Reverting the reason also reverts the file move, that

Re: [PATCH v3 06/11] scatterlist: support page-less (__pfn_t only) entries

On Wed, May 13, 2015 at 06:35:55PM +, Williams, Dan J wrote: Jens, I'm wondering if you want to take this series(.) as patches or prepare a git branch to pull? Honestly I don't think it should go anyway. It makes a big mess of a structure without providing a real user for it. Given how we

Re: [PATCH v2 5/9] x86, pmem: push fallback handling to arch code

On Sat, Aug 29, 2015 at 04:04:58AM +, Williams, Dan J wrote: On Fri, 2015-08-28 at 15:48 -0600, Toshi Kani wrote: On Fri, 2015-08-28 at 14:47 -0700, Dan Williams wrote: On Fri, Aug 28, 2015 at 2:41 PM, Toshi Kani toshi.k...@hp.com wrote: On Wed, 2015-08-26 at 21:34 +, Williams,

Re: [PATCH v2 9/9] devm_memremap_pages: protect against pmem device unbind

On Wed, Aug 26, 2015 at 09:39:18PM +, Williams, Dan J wrote: On Wed, 2015-08-26 at 14:46 +0200, Christoph Hellwig wrote: On Tue, Aug 25, 2015 at 09:28:13PM -0400, Dan Williams wrote: Given that: 1/ device -remove() can not be failed 2/ a pmem device may be unbound at any

Re: [PATCH v2 5/9] x86, pmem: push fallback handling to arch code

This looks fine to me, Reviewed-by: Christoph Hellwig h...@lst.de -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http

Re: + arc-convert-to-dma_map_ops.patch added to -mm tree

Hi Vineet, the original version went through the buildbot, which succeeded. It seems like the official buildbot does not support arc, and might benefit from helping to set up an arc environment. However in the meantime Guenther send me output from his buildbot and I sent a fix for arc. -- To

Re: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements")

On Wed, Feb 08, 2017 at 10:43:59AM -0700, Jens Axboe wrote: > I've changed the subject line, this issue has nothing to do with the > issue that Hannes was attempting to fix. Nothing really useful in the thread. Dexuan, can you throw in some prints to see which command times out?

Re: [PATCH 1/2] qla2xxx: Fix a recently introduced memory leak

On Wed, Jan 25, 2017 at 03:47:20PM +, Bart Van Assche wrote: > = > BUG kmalloc-16 (Not tainted): Redzone overwritten > - > > Disabling lock

Re: [GIT PULL] Block pull request for- 4.11-rc1

On Fri, Feb 24, 2017 at 01:22:42PM -0700, Jens Axboe wrote: > Bart, I pushed a fix here: > > http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus=61febef40bfe8ab68259d8545257686e8a0d91d1 Yeah, this looks fine to me. It was broken on blk-mq before, but basically impossible to hit. I wonder

Re: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements")

On Tue, Feb 14, 2017 at 02:46:41PM +, Dexuan Cui wrote: > > From: h...@lst.de [mailto:h...@lst.de] > > Sent: Tuesday, February 14, 2017 22:29 > > To: Dexuan Cui <de...@microsoft.com> > > Subject: Re: Boot regression (was "Re: [PATCH] genhd: Do not hold event

Re: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements")

Hi Dexuan, can you try the hack below for now? I disable the TUR call from sd_check_events, which I think your VM is hanging on. The checks it does on the sense data look a bit fishy, but so far I've not identified a possible root cause. diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index

Re: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements")

> I tested today's linux-next (next-20170214) + the 2 patches just now and got > a weird result: > sometimes the VM stills hung with a new calltrace (BUG: spinlock bad > magic) , but sometimes the VM did boot up despite the new calltrace! > > Attached is the log of a "good" boot. > > It looks

Re: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements")

<h...@lst.de> Date: Tue, 14 Feb 2017 15:08:39 +0100 Subject: scsi: always zero sshdr in scsi_normalize_sense This gives us a clear state even if a command didn't return sense data. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/scsi/scsi_common.c | 4 ++-- 1 file change

Re: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements")

Hi Dexuan, I've spent some time with the logs and looking over the code and couldn't find any smoking gun. I start to wonder if it might just be a timing issue? Can you try one or two things for me: 1) run with the blk-mq I/O path for scsi by either enabling it a boot / module load time

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On Thu, Jul 06, 2017 at 12:53:13PM +1000, Oliver wrote: > The main use case is provisioning install media for bare metal > servers. Traditionally that's been handled by having the BMC emulate a > USB CD drive. Unfortunately, most BMCs have limited CPU, limited > memory and a wet-string network

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On Wed, Jul 05, 2017 at 07:08:54PM -0700, Dan Williams wrote: > [ adding Jeff, and Johannes ] > > On Wed, Jul 5, 2017 at 6:17 PM, Kani, Toshimitsu wrote: > > On Wed, 2017-07-05 at 17:07 -0700, Dan Williams wrote: > [..] > >> We have symlinks in /dev/disk/by* to make it easier

Re: [PATCH v3 1/5] acpi, nfit: Switch to use new generic UUID API

On Wed, Jun 07, 2017 at 12:37:51PM +0300, Andy Shevchenko wrote: > It think we may fold it. Yes, I'll fold it and delcare the tree stable late tonight my time. > Besides that we might need the following fix as well. Yeah. Another reasone why buffer.pointer should be a void pointer.

Re: [PATCH v3 1/5] acpi, nfit: Switch to use new generic UUID API

On Wed, Jun 07, 2017 at 06:25:46AM +, Williams, Dan J wrote: > With one compile fix below the 'acpi' branch works for me. Please feel > free to add: The mail seems to contain garbage that can't be applied, but I just applied the changes manually.

Re: [PATCH 2/2] scsi: Preserve retry counter through scsi_prep_fn

On Mon, Aug 21, 2017 at 05:14:00PM -0500, Brian King wrote: > Save / restore the retry counter in scsi_cmd in scsi_init_command. > This allows us to go back through scsi_init_command for retries > and not forget we are doing a retry. So where will we initialize it to zero now?

Re: [PATCH 1/2] scsi: Move scsi_cmd->jiffies_at_alloc initialization to allocation time

On Mon, Aug 21, 2017 at 05:13:20PM -0500, Brian King wrote: > Move the initialization of scsi_cmd->jiffies_at_alloc to allocation > time rather than prep time. Also ensure that jiffies_at_alloc > is preserved when we go through prep. This lets us send retries > through prep again and not break the

Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation

On Fri, May 18, 2018 at 10:05:51PM +0200, Helge Deller wrote: > This patch seems to fix the dma issues I faced on my 32bit B160L parisc box. > > So it leaves only one open issue on parisc: > Now every 32 bit parisc system is unnecessarily non-coherent. I diagree with those comments, let me

Re: [PATCH v9 2/2] blk-mq: Rework blk-mq timeout handling again

On Wed, May 16, 2018 at 04:17:42PM +, Bart Van Assche wrote: > There is another reason the deadline is included in the atomic operation, > namely to handle races between the BLK_EH_RESET_TIMER case in > blk_mq_rq_timed_out() > and blk_mq_complete_request(). I don't think that race is

Re: [PATCH v9 2/2] blk-mq: Rework blk-mq timeout handling again

On Wed, May 16, 2018 at 04:47:54PM +, Bart Van Assche wrote: > I think your patch changes the order of changing the request state and > calling mod_timer(). In my patch the request state and the deadline are > updated first and mod_timer() is called afterwards. I think your patch > changes the

Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation

On Fri, May 18, 2018 at 01:03:46PM +, Alexey Brodkin wrote: > Note mmc_get_dma_dir() is just "data->flags & MMC_DATA_WRITE ? DMA_TO_DEVICE > : DMA_FROM_DEVICE". > I.e. if we're preparing for sending data dma_noncoherent_map_sg() will have > DMA_TO_DEVICE which > is quite OK for passing to

Re: [PATCH 06/22] arc: use generic dma_noncoherent_ops

On Wed, Apr 25, 2018 at 11:17:01AM +, Alexey Brodkin wrote: > Which is actually strange as I would expect ARC code to be built by bots. I don't think I got any notification. Thank for the fixes! I think I found the bug, based on the fact that so far all tests for architectures that also

Re: [PATCH 06/22] arc: use generic dma_noncoherent_ops

On Thu, Apr 26, 2018 at 08:45:00AM +0200, h...@lst.de wrote: > On Wed, Apr 25, 2018 at 11:17:01AM +, Alexey Brodkin wrote: > > Which is actually strange as I would expect ARC code to be built by bots. > > I don't think I got any notification. Thank for the fixes! > > I

Re: [PATCH 32/33] cris: use dma-direct

On Wed, Jan 10, 2018 at 03:27:41PM +, Alexey Brodkin wrote: > Hi Christoph, > > On Wed, 2018-01-10 at 09:00 +0100, Christoph Hellwig wrote: > > cris currently has an incomplete direct mapping dma_map_ops implementation > > is PCI support is enabled. Replace it with the fully feature generic

Re: [PATCH] dma-mapping: move dma configuration to bus infrastructure

On Tue, Mar 13, 2018 at 04:22:53AM +, Nipun Gupta wrote: > > Isn't this one or the other one but not both? > > > > Something like: > > > > if (dev->of_node) > > of_dma_deconfigure(dev); > > else > > acpi_dma_deconfigure(dev); > > > > should work. > > I understand your point. Seems

Re: dma-mapping: clearing GFP_ZERO flag caused crashes of Ethernet on arc/hsdk board.

> > The logical question is why? > > 1. See that's another platform with ARC core so maybe in case of ARM >DMA allocator already zeroes pages regardless provided flags - >personally I didn't check that. Yes, most architectures always clear memory returned by dma_alloc*. Looks like a few

Re: [PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

> > +int dma_configure(struct device *dev) > > +{ > > + if (dev->bus->dma_configure) > > + return dev->bus->dma_configure(dev); > > What if dma_common_configure() is called in case "bus->dma_configure" is not > defined? Then we'd still have a dependency of common code on OF and

Re: [PATCH] dma-mapping: move dma configuration to bus infrastructure

On Tue, Mar 13, 2018 at 04:22:53AM +, Nipun Gupta wrote: > > Isn't this one or the other one but not both? > > > > Something like: > > > > if (dev->of_node) > > of_dma_deconfigure(dev); > > else > > acpi_dma_deconfigure(dev); > > > > should work. > > I understand your point. Seems

Re: [PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

> > +int dma_configure(struct device *dev) > > +{ > > + if (dev->bus->dma_configure) > > + return dev->bus->dma_configure(dev); > > What if dma_common_configure() is called in case "bus->dma_configure" is not > defined? Then we'd still have a dependency of common code on OF and

Re: dma-mapping: clearing GFP_ZERO flag caused crashes of Ethernet on arc/hsdk board.

> > The logical question is why? > > 1. See that's another platform with ARC core so maybe in case of ARM >DMA allocator already zeroes pages regardless provided flags - >personally I didn't check that. Yes, most architectures always clear memory returned by dma_alloc*. Looks like a few

Re: [PATCH 06/22] arc: use generic dma_noncoherent_ops

On Wed, Apr 25, 2018 at 11:17:01AM +, Alexey Brodkin wrote: > Which is actually strange as I would expect ARC code to be built by bots. I don't think I got any notification. Thank for the fixes! I think I found the bug, based on the fact that so far all tests for architectures that also

Re: [PATCH 06/22] arc: use generic dma_noncoherent_ops

On Thu, Apr 26, 2018 at 08:45:00AM +0200, h...@lst.de wrote: > On Wed, Apr 25, 2018 at 11:17:01AM +, Alexey Brodkin wrote: > > Which is actually strange as I would expect ARC code to be built by bots. > > I don't think I got any notification. Thank for the fixes! > > I

Re: [PATCH v9 2/2] blk-mq: Rework blk-mq timeout handling again

On Wed, May 16, 2018 at 04:17:42PM +, Bart Van Assche wrote: > There is another reason the deadline is included in the atomic operation, > namely to handle races between the BLK_EH_RESET_TIMER case in > blk_mq_rq_timed_out() > and blk_mq_complete_request(). I don't think that race is

Re: [PATCH v9 2/2] blk-mq: Rework blk-mq timeout handling again

On Wed, May 16, 2018 at 04:47:54PM +, Bart Van Assche wrote: > I think your patch changes the order of changing the request state and > calling mod_timer(). In my patch the request state and the deadline are > updated first and mod_timer() is called afterwards. I think your patch > changes the

Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation

On Fri, May 18, 2018 at 01:03:46PM +, Alexey Brodkin wrote: > Note mmc_get_dma_dir() is just "data->flags & MMC_DATA_WRITE ? DMA_TO_DEVICE > : DMA_FROM_DEVICE". > I.e. if we're preparing for sending data dma_noncoherent_map_sg() will have > DMA_TO_DEVICE which > is quite OK for passing to

Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation

On Fri, May 18, 2018 at 10:05:51PM +0200, Helge Deller wrote: > This patch seems to fix the dma issues I faced on my 32bit B160L parisc box. > > So it leaves only one open issue on parisc: > Now every 32 bit parisc system is unnecessarily non-coherent. I diagree with those comments, let me

Re: [PATCH 32/33] cris: use dma-direct

On Wed, Jan 10, 2018 at 03:27:41PM +, Alexey Brodkin wrote: > Hi Christoph, > > On Wed, 2018-01-10 at 09:00 +0100, Christoph Hellwig wrote: > > cris currently has an incomplete direct mapping dma_map_ops implementation > > is PCI support is enabled. Replace it with the fully feature generic

Re: [PATCH 1/2] scsi: Move scsi_cmd->jiffies_at_alloc initialization to allocation time

On Mon, Aug 21, 2017 at 05:13:20PM -0500, Brian King wrote: > Move the initialization of scsi_cmd->jiffies_at_alloc to allocation > time rather than prep time. Also ensure that jiffies_at_alloc > is preserved when we go through prep. This lets us send retries > through prep again and not break the

Re: [PATCH 2/2] scsi: Preserve retry counter through scsi_prep_fn

On Mon, Aug 21, 2017 at 05:14:00PM -0500, Brian King wrote: > Save / restore the retry counter in scsi_cmd in scsi_init_command. > This allows us to go back through scsi_init_command for retries > and not forget we are doing a retry. So where will we initialize it to zero now?

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On Wed, Jul 05, 2017 at 07:08:54PM -0700, Dan Williams wrote: > [ adding Jeff, and Johannes ] > > On Wed, Jul 5, 2017 at 6:17 PM, Kani, Toshimitsu wrote: > > On Wed, 2017-07-05 at 17:07 -0700, Dan Williams wrote: > [..] > >> We have symlinks in /dev/disk/by* to make it easier to identify > >>

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On Thu, Jul 06, 2017 at 12:53:13PM +1000, Oliver wrote: > The main use case is provisioning install media for bare metal > servers. Traditionally that's been handled by having the BMC emulate a > USB CD drive. Unfortunately, most BMCs have limited CPU, limited > memory and a wet-string network

Re: [PATCH] dma: Per-NUMA-node CMA should depend on NUMA

On Mon, Oct 26, 2020 at 08:07:43PM +, Song Bao Hua (Barry Song) wrote: > > diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig > > index c99de4a21458..964b74c9b7e3 100644 > > --- a/kernel/dma/Kconfig > > +++ b/kernel/dma/Kconfig > > @@ -125,7 +125,8 @@ if DMA_CMA > > > > config

Re: WARNING in dma_map_page_attrs

On Mon, Oct 26, 2020 at 05:23:48AM +, Parav Pandit wrote: > Hi Christoph, > > > From: Jakub Kicinski > > Sent: Saturday, October 24, 2020 11:45 PM > > > > CC: rdma, looks like rdma from the stack trace > > > > On Fri, 23 Oct 2020 20:07:17 -0700 syzbot wrote: > > > syzbot has found a

Re: [PATCH 08/15] riscv: provide native clint access for M-mode

On Wed, Aug 21, 2019 at 12:24:31AM +, Atish Patra wrote: > > +static inline void clint_set_timer(unsigned long delta) > > +{ > > + writeq_relaxed(clint_read_timer() + delta, > > + clint_time_cmp + > > cpuid_to_hartid_map(smp_processor_id()));' > > This is not compatible with 32

Re: WARNING in dma_map_page_attrs

On Tue, Oct 27, 2020 at 12:52:30PM +, Parav Pandit wrote: > > > From: h...@lst.de > > Sent: Tuesday, October 27, 2020 1:41 PM > > > > On Mon, Oct 26, 2020 at 05:23:48AM +, Parav Pandit wrote: > > > Hi Christoph, > > > > > > >

Re: [RFC PATCH v2 0/3] prerequisites for device reserved local mem rework

On Mon, May 20, 2019 at 05:41:56PM +0200, Fredrik Noring wrote: > 2. A device address is supplied as phys_addr_t phys to gen_pool_add_virt(). >This seems to work in this particular DMA application, but there will be >problems if someone does phys_to_virt() or suchlike. Can this be improved

Re: [PATCH 7/7] arc: use the generic remapping allocator for coherent DMA allocations

On Mon, Jun 24, 2019 at 07:13:17PM +, Eugeniy Paltsev wrote: > Hi Christoph, > > Yep I've reviewed and tested it for both cases: > - coherent/noncoherent dma > - allocation from atomic_pool/regular allocation > > everything works fine for ARC. Thanks. I've applied the whole series to the

Re: [PATCH v7 2/5] USB: use genalloc for USB HCs with local memory

On Wed, May 29, 2019 at 04:23:34AM -0700, Greg KH wrote: > As long as GENERIC_ALLOCATOR works on all arches, yes, that's fine, but > please verify that this is the case. It works everywhere. The issue here is just that it get pulled in by default on most architetures, but not on all.

Re: [PATCH 16/17] riscv: clear the instruction cache and all registers when booting

On Mon, Jul 01, 2019 at 09:26:18PM +, Atish Patra wrote: > That means it should be done for S-mode as well. Right ? For S-mode the bootloader/sbi should take care of it.

Re: [PATCH v3 1/3] RISC-V: Issue a local tlbflush if possible.

On Thu, Aug 22, 2019 at 04:01:24AM +, Atish Patra wrote: > The downside of this is that for every !cmask case in true SMP (more > common probably) it will execute 2 extra cpumask instructions. As > tlbflush path is in performance critical path, I think we should favor > more common case (SMP

Re: [PATCH 0/2] Add support for StorageD3Enable _DSD property

On Wed, Apr 29, 2020 at 05:20:09AM +, Williams, Dan J wrote: > > The platform can know which pm policies will save the most power. But > > since the solution doesn't apply to all PCIe devices (despite BIOS > > specifying it that way) I'll withdraw this patch. Thanks. > > Wait, why withdraw?

Re: [PATCH 0/2] Add support for StorageD3Enable _DSD property

On Wed, Apr 29, 2020 at 09:11:13AM -0700, David E. Box wrote: > Not drop completely. This patch copied the code used to read _DSD > properties under PCI root ports. But I agree that such properties > should apply to all devices on those ports and unfortuntely that's not > the case here. BIOS got

Re: [PATCH] video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs.

> + select DMA_CMA Thіs needs to be select DMA_CMA if HAVE_DMA_CONTIGUOUS > +#include > + /* Allocate from CMA */ > + // request_pages = (request_size >> PAGE_SHIFT) + 1; > + request_pages = (round_up(request_size, PAGE_SIZE) >> PAGE_SHIFT); > + page =

Re: [PATCH] lib/scatterlist: Provide a DMA page iterator

On Tue, Jan 15, 2019 at 03:24:55PM +0100, Christian König wrote: > Yeah, indeed. Bounce buffers are an absolute no-go for GPUs. > > If the DMA API finds that a piece of memory is not directly accessible by > the GPU we need to return an error and not try to use bounce buffers behind > the

Re: [PATCH] lib/scatterlist: Provide a DMA page iterator

On Tue, Jan 15, 2019 at 06:03:39PM +, Thomas Hellstrom wrote: > In the graphics case, it's probably because it doesn't fit the graphics > use-cases: > > 1) Memory typically needs to be mappable by another device. (the "dma- > buf" interface) And there is nothing preventing dma-buf sharing of

Re: [PATCH] lib/scatterlist: Provide a DMA page iterator

On Tue, Jan 15, 2019 at 07:13:11PM +, Koenig, Christian wrote: > Thomas is correct that the interface you propose here doesn't work at > all for GPUs. > > The kernel driver is not informed of flush/sync, but rather just setups > coherent mappings between system memory and devices. > > In

Re: [PATCH 2/4] drm/vmwgfx: remove CONFIG_INTEL_IOMMU ifdefs v2

On Tue, Feb 05, 2019 at 07:59:22AM +, Thomas Hellstrom wrote: > On Mon, 2019-02-04 at 13:11 +0100, Thomas Hellström wrote: > > On Mon, 2019-02-04 at 09:19 +0100, Christoph Hellwig wrote: > > > On Fri, Jan 25, 2019 at 09:12:13AM +0100, Thomas Hellstrom wrote: > > > > -#if

Re: [PATCH] lib/scatterlist: Provide a DMA page iterator

On Wed, Jan 16, 2019 at 07:28:13AM +, Koenig, Christian wrote: > To summarize once more: We have an array of struct pages and want to > coherently map that to a device. And the answer to that is very simple: you can't. What is so hard to understand about? If you want to map arbitrary

Re: [PATCH] lib/scatterlist: Provide a DMA page iterator

On Tue, Jan 15, 2019 at 02:25:01PM -0700, Jason Gunthorpe wrote: > RDMA needs something similar as well, in this case drivers take a > struct page * from get_user_pages() and need to have the DMA map fail > if the platform can't DMA map in a way that does not require any > additional DMA API calls

Re: [PATCH] lib/scatterlist: Provide a DMA page iterator

On Wed, Jan 16, 2019 at 10:24:36AM -0700, Jason Gunthorpe wrote: > The fact is there is 0 industry interest in using RDMA on platforms > that can't do HW DMA cache coherency - the kernel syscalls required to > do the cache flushing on the IO path would just destroy performance to > the point of

Re: [PATCH 1/2] dma-mapping: zero memory returned from dma_alloc_*

On Fri, Dec 14, 2018 at 12:12:00PM +, Eugeniy Paltsev wrote: > Hi Christoph, > > do you have any public git repository with all your dma changes? Most of the tree show up in my misc.git repo for testing. This series is here:

Re: [PATCH v4 2/2] trace nvme submit queue status

On Tue, Dec 18, 2018 at 10:26:46AM -0700, Keith Busch wrote: > No need for a space after the %s. __print_disk_name already appends a > space if there's a disk name, and we don't want the extra space if there > isn't one. Also, every other nvme trace has a ',' after each entry. Not > a big deal,

Re: [PATCH v4 2/2] trace nvme submit queue status

On Tue, Dec 18, 2018 at 05:19:00PM -0800, peng yu wrote: > I think this change is nice. Will you submit this change or are you > suggesting me to do it? I've folded the changes in.

Re: [PATCH] nvme-pci: Use non-operational power state instead of D3 on Suspend-to-Idle

On Fri, May 10, 2019 at 11:18:52PM +0800, Kai Heng Feng wrote: > > I'm afraid the requirement is still not clear to me. AFAIK, all our > > barriers routines ensure data is visible either between CPUs, or between > > CPU and devices. The CPU never accesses HMB memory, so there must be some > >

Re: fix DMA ops layering violations in vmwgfx

On Tue, Jan 08, 2019 at 09:51:45AM +, Thomas Hellstrom wrote: > Hi, Christoph, > > On Sat, 2019-01-05 at 09:01 +0100, Christoph Hellwig wrote: > > Hi Thomas, > > > > vmwgfx has been doing some odd checks based on DMA ops which rely > > on deep DMA mapping layer internals, and I think the

Re: [PATCH] dma-mapping: remove unused attrs parameter to dma_common_get_sgtable

On Fri, Jan 04, 2019 at 01:45:26AM +, Huaisheng HS1 Ye wrote: > From: Stefano Stabellini > Sent: Friday, January 04, 2019 1:55 AM > > On Thu, 3 Jan 2019, Huaisheng Ye wrote: > > > From: Huaisheng Ye > > > > > > dma_common_get_sgtable has parameter attrs which is not used at all. > > > Remove

Re: ensure dma_alloc_coherent always returns zeroed memory

On Thu, Dec 20, 2018 at 02:32:52PM +, Eugeniy Paltsev wrote: > Hi Christoph, > > I test kernel from your 'dma-alloc-always-zero' branch, and as > I can see we have DMA peripherals (like USB) broken. I would be really surprised if that is caused by the patch to add the zeroing. Can you check

Re: ensure dma_alloc_coherent always returns zeroed memory

On Thu, Dec 20, 2018 at 02:39:20PM +, Eugeniy Paltsev wrote: > > I would be really surprised if that is caused by the patch to add > > the zeroing. > Me too :) > > > Can you check which commit caused the issue by bisecting > > from a known good baseline? > > Yep. At least kernel build from

Re: ensure dma_alloc_coherent always returns zeroed memory

Btw, can you try wit the very latests dma-mapping-for-next tree which has a new fix from Thierry Reding that might be related.

Re: [PATCH v3 06/11] scatterlist: support "page-less" (__pfn_t only) entries

On Wed, May 13, 2015 at 06:35:55PM +, Williams, Dan J wrote: > Jens, I'm wondering if you want to take this series(.) as patches or > prepare a git branch to pull? Honestly I don't think it should go anyway. It makes a big mess of a structure without providing a real user for it. Given how

Re: [PATCH v2 5/9] x86, pmem: push fallback handling to arch code

This looks fine to me, Reviewed-by: Christoph Hellwig -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at

Re: [PATCH v2 9/9] devm_memremap_pages: protect against pmem device unbind

On Wed, Aug 26, 2015 at 09:39:18PM +, Williams, Dan J wrote: > On Wed, 2015-08-26 at 14:46 +0200, Christoph Hellwig wrote: > > On Tue, Aug 25, 2015 at 09:28:13PM -0400, Dan Williams wrote: > > > Given that: > > > > > > 1/ device ->remove() can not be failed > > > > > > 2/ a pmem device may

Re: [PATCH v2 5/9] x86, pmem: push fallback handling to arch code

On Sat, Aug 29, 2015 at 04:04:58AM +, Williams, Dan J wrote: > On Fri, 2015-08-28 at 15:48 -0600, Toshi Kani wrote: > > On Fri, 2015-08-28 at 14:47 -0700, Dan Williams wrote: > > > On Fri, Aug 28, 2015 at 2:41 PM, Toshi Kani wrote: > > > > On Wed, 2015-08-26 at 21:34 +, Williams, Dan J

Re: [PATCH] phy: qcom-ufs: export symbols needed by main drivers

On Mon, Feb 02, 2015 at 03:30:27PM +, James Bottomley wrote: > Cc added for linux-scsi, since this is the origin of the problem. How > important is bisectability in this? It won't affect any non-embedded > user, since most don't build with UFS, so I can go either way on folding > or just

Re: [PATCH v5 02/21] libnvdimm, nfit: initial libnvdimm infrastructure and NFIT support

On Wed, Jun 03, 2015 at 07:24:34PM +, Williams, Dan J wrote: > > > +static inline struct acpi_nfit_memory_map *__to_nfit_memdev(struct > > > nfit_mem *nfit_mem) > > > > This line is over 80 characters. > > I generally don't see the point of fixing up occasional small incursions > over 80

Re: [PATCH v5 09/21] libnvdimm, nd_pmem: add libnvdimm support to the pmem driver

On Wed, Jun 03, 2015 at 07:31:38PM +, Williams, Dan J wrote: > I like move-modify patches because they make the reason for the move > clearer and revertible. Consider a general case where we later decide > the reason for a move was invalid. Reverting the reason also reverts > the file move,

Re: [PATCH v3 1/5] acpi, nfit: Switch to use new generic UUID API

On Wed, Jun 07, 2017 at 12:37:51PM +0300, Andy Shevchenko wrote: > It think we may fold it. Yes, I'll fold it and delcare the tree stable late tonight my time. > Besides that we might need the following fix as well. Yeah. Another reasone why buffer.pointer should be a void pointer.

Re: [PATCH v3 1/5] acpi, nfit: Switch to use new generic UUID API

On Wed, Jun 07, 2017 at 06:25:46AM +, Williams, Dan J wrote: > With one compile fix below the 'acpi' branch works for me. Please feel > free to add: The mail seems to contain garbage that can't be applied, but I just applied the changes manually.

Re: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements")

Hi Dexuan, can you try the hack below for now? I disable the TUR call from sd_check_events, which I think your VM is hanging on. The checks it does on the sense data look a bit fishy, but so far I've not identified a possible root cause. diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index

Re: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements")

Ok, thanks for testing. Can you try the patch below? It fixes a clear problem which was partially papered over before the commit you bisected to, although it can't explain why blk-mq still works. >From e4a66856fa2d92c0298000de658365f31bea60cd Mon Sep 17 00:00:00 2001 From: Christoph Hellwig

Re: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements")

On Tue, Feb 14, 2017 at 02:46:41PM +, Dexuan Cui wrote: > > From: h...@lst.de [mailto:h...@lst.de] > > Sent: Tuesday, February 14, 2017 22:29 > > To: Dexuan Cui > > Subject: Re: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock > >

Re: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements")

> I tested today's linux-next (next-20170214) + the 2 patches just now and got > a weird result: > sometimes the VM stills hung with a new calltrace (BUG: spinlock bad > magic) , but sometimes the VM did boot up despite the new calltrace! > > Attached is the log of a "good" boot. > > It looks

Re: [GIT PULL] Block pull request for- 4.11-rc1

On Fri, Feb 24, 2017 at 01:22:42PM -0700, Jens Axboe wrote: > Bart, I pushed a fix here: > > http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus=61febef40bfe8ab68259d8545257686e8a0d91d1 Yeah, this looks fine to me. It was broken on blk-mq before, but basically impossible to hit. I wonder

Re: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements")

On Wed, Feb 08, 2017 at 10:43:59AM -0700, Jens Axboe wrote: > I've changed the subject line, this issue has nothing to do with the > issue that Hannes was attempting to fix. Nothing really useful in the thread. Dexuan, can you throw in some prints to see which command times out?

Re: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements")

Hi Dexuan, I've spent some time with the logs and looking over the code and couldn't find any smoking gun. I start to wonder if it might just be a timing issue? Can you try one or two things for me: 1) run with the blk-mq I/O path for scsi by either enabling it a boot / module load time

Re: [PATCH 1/2] qla2xxx: Fix a recently introduced memory leak

On Wed, Jan 25, 2017 at 03:47:20PM +, Bart Van Assche wrote: > = > BUG kmalloc-16 (Not tainted): Redzone overwritten > - > > Disabling lock

Re: + arc-convert-to-dma_map_ops.patch added to -mm tree

Hi Vineet, the original version went through the buildbot, which succeeded. It seems like the official buildbot does not support arc, and might benefit from helping to set up an arc environment. However in the meantime Guenther send me output from his buildbot and I sent a fix for arc. -- To

Re: [block] 52f019d43c: ndctl.test-libndctl.fail

On Sat, Mar 06, 2021 at 08:33:04PM +, Williams, Dan J wrote: > Yes, it looks like my unit test checks for exactly the behavior you > changed. It was convenient to test that the device could be switched > back to rw via BLKROSET, but I don't require that. The new behaviour of > letting the