On Fri, Oct 23, 2015 at 05:19:46PM +1100, Andrew Donnellan wrote:
>In eeh_pci_enable(), after making the request to set the new options, we
>call eeh_ops->wait_state() to check that the request finished successfully.
>
>At the moment, if eeh_ops->wait_state() returns 0, we return 0 without
>checkin
On Sat, 2015-09-19 at 23:29 -0500, Scott Wood wrote:
> The existing device tree bindings are error-prone and inflexible.
> Correct the mistake by moving the knowledge into the driver, which has
> more flexibility in describing the quirks of each chip. This leaves the
> device tree to its proper r
[Apologies for the subject line, should just have the [RFC PATCH 5/7]]
On 23.10.2015 [14:00:08 -0700], Nishanth Aravamudan wrote:
> In order to cleanly expose the desired IOMMU page shift via the new
> dma_get_page_shift API, we need to have the sparc constants available in
> a more typical locati
We received a bug report recently when DDW (64-bit direct DMA on Power)
is not enabled for NVMe devices. In that case, we fall back to 32-bit
DMA via the IOMMU, which is always done via 4K TCEs (Translation Control
Entries).
The NVMe device driver, though, assumes that the DMA alignment for the
PR
On sparc, the kernel's page size differs from the IOMMU's page size, so
override the generic implementation, which always returns the kernel's
page size, and return IOMMU_PAGE_SHIFT instead.
Signed-off-by: Nishanth Aravamudan
---
I know very little about sparc, so please correct me if this patch
In order to cleanly expose the desired IOMMU page shift via the new
dma_get_page_shift API, we need to have the sparc constants available in
a more typical location. There should be no functional impact to this
move, but it is untested.
Signed-off-by: Nishanth Aravamudan
---
arch/sparc/include/a
Don't send HTML e-mail.
On Fri, 2015-10-23 at 02:06 -0500, Zhao Qiang-B45475 wrote:
> On Fri, 2015-10-23 at 11:00 AM, Wood Scott-B07421
> wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Friday, October 23, 2015 11:00 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-ker...@
When DDW (Dynamic DMA Windows) are present for a device, we have stored
the TCE (Translation Control Entry) size in a special device tree
property. Check if we have enabled DDW for the device and return the TCE
size from that property if present. If the property isn't present,
fallback to looking t
The IOMMU page size is not always stored in struct iommu on Power.
Specifically if a device is configured for DDW (Dynamic DMA Windows aka.
64-bit direct DMA), the used TCE (Translation Control Entry) size is
stored in a special device property created at run-time by the DDW
configuration code. DDW
[Sorry, subject should have been 0/7!]
On 23.10.2015 [13:54:20 -0700], Nishanth Aravamudan wrote:
> We received a bug report recently when DDW (64-bit direct DMA on Power)
> is not enabled for NVMe devices. In that case, we fall back to 32-bit
> DMA via the IOMMU, which is always done via 4K TCEs
On Power, the kernel's page size can differ from the IOMMU's page size,
so we need to override the generic implementation, which always returns
the kernel's page size. Lookup the IOMMU's page size from struct
iommu_table, if available. Fallback to the kernel's page size,
otherwise.
Signed-off-by:
On Fri, 2015-10-23 at 02:45 -0500, Zhao Qiang-B45475 wrote:
> On Fri, 2015-10-23 at 11:10 AM, Wood Scott-B07421
> wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Friday, October 23, 2015 11:10 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-ker...@vger.kernel.org; linuxppc
Drivers like NVMe need to be able to determine the page size used for
DMA transfers. Add a new API that defaults to return PAGE_SHIFT on all
architectures.
Signed-off-by: Nishanth Aravamudan
---
v1 -> v2:
Based upon feedback from Christoph Hellwig, implement the IOMMU page
size lookup as a g
On Fri, 2015-10-23 at 02:49 -0500, Zhao Qiang-B45475 wrote:
> On Fri, Oct 23, 2015 at 11:20 AM, Wood Scott-B07421 > wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Friday, October 23, 2015 11:20 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-ker...@vger.kernel.org; linuxpp
We received a bug report recently when DDW (64-bit direct DMA on Power)
is not enabled for NVMe devices. In that case, we fall back to 32-bit
DMA via the IOMMU, which is always done via 4K TCEs (Translation Control
Entries).
The NVMe device driver, though, assumes that the DMA alignment for the
PR
On 10/23/15, Aneesh Kumar K.V wrote:
> Denis Kirjanov writes:
>
>> On 10/17/15, Aneesh Kumar K.V wrote:
>>> Hi All,
>>>
>>> This patch series attempt to update book3s 64 linux page table format to
>>> make it more flexible. Our current pte format is very restrictive and we
>>> overload multiple
When DLPAR adding a CPU we should verify that the CPU does not already
exist. Failure to do so can generate a kernel oops;
[9.465585] kernel BUG at arch/powerpc/platforms/pseries/dlpar.c:382!
[9.465796] Oops: Exception in kernel mode, sig: 5 [#1]
This oops can be generated by causing a pr
On 21.10.2015 22:16, Matthew R. Ochs wrote:
> From: Manoj Kumar
>
> A 'login timed out' asynchronous error interrupt is generated if no
> response is seen to a FLOGI within 2 seconds. If the time out error
> is not escalated to a LINK_RESET the port will not be available for
> use. This fix provi
On 21.10.2015 22:16, Matthew R. Ochs wrote:
> When running with an unsupported AFU, the cxlflash driver fails
> the probe. When the driver is removed, the following Oops is
> encountered on a show_interrupts() thread:
>
> Call Trace:
> [c01fba5a7a10] [0003] 0x3 (unreliable)
> [c
On 21.10.2015 22:15, Matthew R. Ochs wrote:
> Ioctl threads that use scsi_execute() can run for an excessive amount
> of time due to the fact that they have lengthy timeouts and retry logic
> built in. Under normal operation this is not an issue. However, once EEH
> enters the picture, a long execu
On 21.10.2015 22:15, Matthew R. Ochs wrote:
> The trace following the failure of alloc_mem() incorrectly identifies
> which function failed. This can lead to misdiagnosing a failure.
>
> Fix the string to correctly indicate that alloc_mem() failed.
>
> Reported-by: Brian King
> Signed-off-by: Matt
On 21.10.2015 22:15, Matthew R. Ochs wrote:
> The fops owned by the adapter can be corrupted in certain scenarios,
> opening a window where certain fops are temporarily NULLed before being
> reset to their proper value. This can potentially lead software to make
> incorrect decisions, leaving the u
On 21.10.2015 22:15, Matthew R. Ochs wrote:
> From: Manoj Kumar
>
> The operator used to double the master context response delay
> is incorrect and does not result in delay doubling.
>
> To fix, use a left shift instead of the XOR operator.
>
> Reported-by: Tomas Henzl
> Signed-off-by: Matthew R
On 21.10.2015 22:15, Matthew R. Ochs wrote:
> Following an adapter reset, the AFU RRQ that resides in host memory
> holds stale data. This can lead to a condition where the RRQ interrupt
> handler tries to process stale entries and/or endlessly loops due to an
> out of sync generation bit.
>
> To f
On 21.10.2015 22:15, Matthew R. Ochs wrote:
> There are several spelling and grammar mistakes throughout the
> driver. Additionally there are a handful of places where there
> are extra lines and unnecessary variables/statements. These are
> a nuisance and pollute the driver.
>
> Fix spelling and g
On 21.10.2015 22:14, Matthew R. Ochs wrote:
> The process_sense() routine can perform a read capacity which
> can take some time to complete. If an EEH occurs while waiting
> on the read capacity, the EEH handler will wait to obtain the
> context's mutex in order to put the context in an error stat
On 21.10.2015 22:14, Matthew R. Ochs wrote:
> Sparse uncovered several errors with MMIO operations (accessing
> directly) and handling endianness. These can cause issues when
> running in different environments.
>
> Introduce __iomem and proper endianness tags/swaps where
> appropriate to make driv
On 21.10.2015 22:14, Matthew R. Ochs wrote:
> Several function prologs have incorrect parameter names and return
> code descriptions. This can lead to confusion when reviewing the
> source and creates inaccurate documentation.
>
> To remedy, update the function prologs to properly reflect parameter
On 21.10.2015 22:14, Matthew R. Ochs wrote:
> The host reset handler is called with I/O already blocked, thus
> there is no need to explicitly block and unblock I/O in the handler.
>
> Signed-off-by: Matthew R. Ochs
> Signed-off-by: Manoj N. Kumar
> Reviewed-by: Brian King
Reviewed-by: Tomas He
On 21.10.2015 22:14, Matthew R. Ochs wrote:
> When the device reset handler is entered while a reset operation
> is taking place, the handler exits without actually sending a
> reset (TMF) to the targeted device. This behavior is incorrect
> as the device is not reset. Further complicating matters
On 21.10.2015 22:14, Matthew R. Ochs wrote:
> The workq can process work in parallel with a remove event, leading
> to a condition where the workq handler can access freed memory.
>
> To remedy, the workq should be terminated prior to freeing memory. Move
> the termination call earlier in remove an
On 21.10.2015 22:14, Matthew R. Ochs wrote:
> Currently, scsi_host_put() is being called prematurely in the
> remove path and is missing entirely in an error cleanup path.
> The former can lead to memory being freed too early with
> subsequent access potentially corrupting data whilst the former
>
On 21.10.2015 22:13, Matthew R. Ochs wrote:
> The resid is incorrectly set which can lead to unnecessary retry
> attempts by the stack. This is due to resid _always_ being set
> using a value returned from the adapter. Instead, the value
> should only be interpreted and set when in an underrun scen
On 21.10.2015 22:14, Matthew R. Ochs wrote:
> The AFU version is stored as a non-terminated string of bytes within
> a 64-bit little-endian register. Presently the value is read directly
> (no MMIO accessor) and is stored in a buffer that is not big enough
> to contain a NULL terminator. Additional
On 21.10.2015 22:13, Matthew R. Ochs wrote:
> At present, both ports must be online for the device to
> configure properly. Remove this dependency and the unnecessary
> internal LUN override logic as well. Additionally, as a refactoring
> measure, change the return code variable name to match that
On 21.10.2015 22:13, Matthew R. Ochs wrote:
> A bug was introduced earlier in the development cycle when cleaning
> up logic statements. Instead of skipping bits that are not set, set
> bits are skipped, causing async interrupts to not be handled correctly.
>
> To fix, simply add back in the proper
On 21.10.2015 22:13, Matthew R. Ochs wrote:
> Following a link up event, the LUNs available to the host may
> have changed. Without rescanning the host, the LUN topology is
> unknown to the user. In such a state, the user would be unable
> to locate provisioned resources.
>
> To remedy, the host sh
On 21.10.2015 22:13, Matthew R. Ochs wrote:
> Borrowing the TMF waitq's spinlock causes a stall condition when
> waiting for the TMF to complete. To remedy, introduce our own spin
> lock to serialize TMF and use the appropriate wait services.
>
> Also add a timeout while waiting for a TMF completio
On 21.10.2015 22:13, Matthew R. Ochs wrote:
> During run-time the driver can be very chatty and spam the system
> kernel log. Various print statements can be limited and/or moved
> to development-only mode. Additionally, numerous prints can be
> converted to trace the corresponding device. Lastly,
On 21.10.2015 22:12, Matthew R. Ochs wrote:
> Implement the following suggestions and add two new attributes
> to allow for debugging the port LUN table.
>
> - use scnprintf() instead of snprintf()
> - use DEVICE_ATTR_RO and DEVICE_ATTR_RW
>
> Suggested-by: Shane Seymour
> Signed-off-by: Matthew
Am Freitag, 23. Oktober 2015, 12:54:56 schrieb Michael Ellerman:
> On Thu, 2015-10-22 at 12:15 -0700, Geoff Levand wrote:
> > Hi,
> >
> > On Fri, 2015-10-09 at 23:13 +0200, Marc Dietrich wrote:
> > > Am Freitag, 9. Oktober 2015, 10:45:42 schrieb Geoff Levand:
> > > > With the 4.2-rc4 kernel, kexec
On Fri, Oct 23, 2015 at 11:20 AM, Wood Scott-B07421
wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, October 23, 2015 11:20 AM
> To: Zhao Qiang-B45475
> Cc: linux-ker...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> b.
On Fri, 2015-10-23 at 11:10 AM, Wood Scott-B07421
wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, October 23, 2015 11:10 AM
> To: Zhao Qiang-B45475
> Cc: linux-ker...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> b...
43 matches
Mail list logo
