China PCB Suppier-Try us and you will like us

Hi! We are pcb supplier since 2007 and we have special materials in stock. If you are interested just email me back. Best Regards, Sammy Chang Overseas Sales Mobile: +86 13580982656 Skype: +86 13580982656 Shenzhen Plus Circuits Limited Website: www.pluscircuits.com Add: Building 05, Lisheng

[PATCH V10 4/4] libsas: Align sata_device's rps_resp on a cacheline

The rps_resp buffer in ata_device is a DMA target, but it isn't explicitly cacheline aligned. Due to this, adjacent fields can be overwritten with stale data from memory on non-coherent architectures. As a result, the kernel is sometimes unable to communicate with an SATA device behind a SAS

[PATCH V10 3/4] scsi: Align block queue to dma_get_cache_alignment()

In non-coherent DMA mode, kernel uses cache flushing operations to maintain I/O coherency, so scsi's block queue should be aligned to ARCH_DMA_MINALIGN. Otherwise, If a DMA buffer and a kernel structure share a same cache line, and if the kernel structure has dirty data, cache_invalidate (no

[PATCH V10 2/4] MIPS: Implement dma_map_ops::get_cache_alignment()

Currently, MIPS is an architecture which support coherent & noncoherent devices co-exist. So implement get_cache_alignment() function pointer in 'struct dma_map_ops' to return different dma alignments. Signed-off-by: Huacai Chen --- arch/mips/cavium-octeon/dma-octeon.c

[PATCH V10 1/4] dma-mapping: Rework dma_get_cache_alignment()

Make dma_get_cache_alignment() to accept a 'dev' argument. As a result, it can return different alignments due to different devices' I/O cache coherency. Currently, ARM/ARM64 and MIPS support coherent & noncoherent devices co-exist. This may be extended in the future, so add a new function

Re: mvsas sata drives with high ioerr_cnt and long stalls

Here's another error. This time I was doing a sequential write to a single drive. [ 2546.890238] ata12: log page 10h reported inactive tag 30 [ 2546.895887] ata12.00: exception Emask 0x1 SAct 0x1 SErr 0x0 action 0x6 [ 2546.902780] ata12.00: failed command: WRITE FPDMA QUEUED [ 2546.908404]

Re: mvsas sata drives with high ioerr_cnt and long stalls

It just got worse, under heavy sequential write load, all of the drives in the array where thrown out of the array and I got a stack trace. I know I've been able to stress this array without issue but the last time I did that was several kernels ago. --Larkin [ 5723.912580] ata14.00:

КЛИЕНТСКИЕ БАЗЫ!!! Подробнее: prodawez...@gmail.com Узнайте подробности!

KLIENTSKIE BAZI!!! Podrobnee: prodawez...@gmail.com Uznaite podrobnosti!

[REGRESSION][v4.13.y][v4.14.y] scsi: libsas: allow async aborts

Hi Christoph, A kernel bug report was opened against Ubuntu [0].  After a kernel bisect, it was found that reverting the following commit resolved this bug: 909657615d9b ("scsi: libsas: allow async aborts")   The regression was introduced as of v4.12-rc1, and it still exists in 4.14

Re: Seagate External SMR drive USB resets (XHCI transfer error, not timeout)

On Wed, 15 Nov 2017, Jérôme Carretero wrote: > I performed an usbmon capture extract, centered around the event > (there was a few hundred MBs written for this to happen): > > Nov 15 22:16:33 Bidule kernel: usb 6-4.3.2.1: reset SuperSpeed USB > device number 8 using xhci_hcd > > I can see

[PATCH] scsi: pmcraid: use correct size unit when calling find_first_zero_bit()

find_first_zero_bit()'s parameter 'size' is defined in bits, not in bytes. Signed-off-by: Niklas Cassel --- drivers/scsi/pmcraid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c index

Re: [PATCH 3/3] zfcp: drop open coded assignments of timer_list.function

On Thu, 16 Nov 2017 14:16:39 +0100 Heiko Carstens wrote: > On Thu, Nov 16, 2017 at 01:38:18PM +0100, Steffen Maier wrote: > > If this has not been picked/merged yet (it's not in Linus' tree yet), > > could you please drop it because it's buggy? > > > > This would buy

Re: [PATCH 3/3] zfcp: drop open coded assignments of timer_list.function

On Thu, Nov 16, 2017 at 01:38:18PM +0100, Steffen Maier wrote: > If this has not been picked/merged yet (it's not in Linus' tree yet), > could you please drop it because it's buggy? > > This would buy me time to come up with a proper solution, > otherwise I would be forced to fix it within

Re: [PATCH 3/3] zfcp: drop open coded assignments of timer_list.function

If this has not been picked/merged yet (it's not in Linus' tree yet), could you please drop it because it's buggy? This would buy me time to come up with a proper solution, otherwise I would be forced to fix it within 4.15-rc and am not sure I can make it. On 11/08/2017 03:17 PM, Steffen Maier

КЛИЕНТСКИЕ БАЗЫ!!! Подробнее: prodawez...@gmail.com Узнайте подробности!

KLIENTSKIE BAZI!!! Podrobnee: prodawez...@gmail.com Uznaite podrobnosti!