Re: [RFC 0/2] target refcounting infrastructure fixes for usb

2014-01-02 Thread James Bottomley
On Thu, 2014-01-02 at 16:45 -0800, Sarah Sharp wrote: > On Sat, Dec 21, 2013 at 03:51:25PM -0500, Alan Stern wrote: > > On Fri, 20 Dec 2013, Sarah Sharp wrote: > > > > > On Thu, Dec 19, 2013 at 11:48:47AM -0800, James Bottomley wrote: > > > > It should apply incrementally on top of the previous tw

Re: [RFC 0/2] target refcounting infrastructure fixes for usb

2014-01-02 Thread Sarah Sharp
On Sat, Dec 21, 2013 at 03:51:25PM -0500, Alan Stern wrote: > On Fri, 20 Dec 2013, Sarah Sharp wrote: > > > On Thu, Dec 19, 2013 at 11:48:47AM -0800, James Bottomley wrote: > > > It should apply incrementally on top of the previous two. If it > > > actually works, I'll fold it into the first patc

[RFC 2/2] dual scan thread bug fix

2014-01-02 Thread James Bottomley
In the highly unusual case where two threads are running concurrently through the scanning code scanning the same target, we run into the situation where one may allocate the target while the other is still using it. In this case, because the reap checks for STARGET_CREATED and kills the target wi

[RFC 1/2] fix our current target reap infrastructure

2014-01-02 Thread James Bottomley
This patch eliminates the reap_ref and replaces it with a proper kref. On last put of this kref, the target is removed from visibility in sysfs. The final call to scsi_target_reap() for the device is done from __scsi_remove_device() and only if the device was made visible. This ensures that the t

[RFC 0/2] target refcounting infrastructure fixes for usb

2014-01-02 Thread James Bottomley
This set should fix our target problems with USB by making the target visibility properly reference counted. Since it's a major change to the infrastructure, we'll incubate upstream first before backporting to stable. James Bottomley (2): [SCSI] fix our current target reap infrastructure. [SC

Re: [RFC 0/2] target refcounting infrastructure fixes for usb

2014-01-02 Thread James Bottomley
On Sat, 2013-12-21 at 15:51 -0500, Alan Stern wrote: > On Fri, 20 Dec 2013, Sarah Sharp wrote: > > > On Thu, Dec 19, 2013 at 11:48:47AM -0800, James Bottomley wrote: > > > It should apply incrementally on top of the previous two. If it > > > actually works, I'll fold it into the first patch. > >

[PATCH v7 3/4] ata: Add APM X-Gene SoC SATA host controller driver

2014-01-02 Thread Loc Ho
This patch adds support for the APM X-Gene SoC SATA host controller driver. It requires the corresponding APM X-Gene SoC PHY driver. Signed-off-by: Loc Ho Signed-off-by: Tuan Phan Signed-off-by: Suman Tripathi --- drivers/ata/Kconfig |8 + drivers/ata/Makefile |1 + drivers/at

[PATCH v7 1/4] ata: Export required functions by APM X-Gene SATA driver

2014-01-02 Thread Loc Ho
This patch exports functions required by APM X-Gene SoC SATA host controller driver to avoid duplication of code. Signed-off-by: Loc Ho Signed-off-by: Tuan Phan Signed-off-by: Suman Tripathi --- drivers/ata/ahci.h|9 + drivers/ata/libahci.c | 16 ++-- 2 files chan

[PATCH v7 4/4] arm64: Add APM X-Gene SoC SATA host controller DTS entries

2014-01-02 Thread Loc Ho
Signed-off-by: Loc Ho Signed-off-by: Tuan Phan Signed-off-by: Suman Tripathi --- arch/arm64/boot/dts/apm-storm.dtsi | 81 1 files changed, 81 insertions(+), 0 deletions(-) diff --git a/arch/arm64/boot/dts/apm-storm.dtsi b/arch/arm64/boot/dts/apm-storm.dt

[PATCH v7 2/4] Documentation: Add documentation for APM X-Gene SoC SATA host controller DTS binding

2014-01-02 Thread Loc Ho
Signed-off-by: Loc Ho Signed-off-by: Tuan Phan Signed-off-by: Suman Tripathi --- .../devicetree/bindings/ata/apm-xgene.txt | 68 1 files changed, 68 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/ata/apm-xgene.txt diff --git

[PATCH v7 0/4] ata: Add APM X-Gene SoC SATA host controller support

2014-01-02 Thread Loc Ho
This patch adds support for the APM X-Gene SoC SATA host controller. In order for the host controller to work, the corresponding PHY driver musts also be available. v7: * Update the clock code by toggle the clock * Update the DTS clock mask values due to the clock spilt between host and v5 o

RE: mpt2sas SATA spinup behavior

2014-01-02 Thread Elliott, Robert (Server Storage)
In SAS systems, it's common for controllers and expanders to rotate spinup permission across phys to avoid overloading the power supply (e.g., if the system is sized to support 8 x 18 W drives, it might not work if 8 x 45 W are briefly consumed). The most common algorithm allows n phys to spinup

Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst

2014-01-02 Thread Sarah Sharp
On Thu, Jan 02, 2014 at 04:01:29PM -0500, Mark Lord wrote: > On 14-01-02 02:15 PM, Sarah Sharp wrote: > > On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote: > .. > >> Unfortunately this patch causes a regression when copying large files to my > >> outboard USB3 drive. (Nothing at all to do with

Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst

2014-01-02 Thread James Bottomley
On Thu, 2014-01-02 at 16:01 -0500, Mark Lord wrote: > On 14-01-02 02:15 PM, Sarah Sharp wrote: > > On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote: > .. > >> Unfortunately this patch causes a regression when copying large files to my > >> outboard USB3 drive. (Nothing at all to do with network

Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst

2014-01-02 Thread Mark Lord
On 14-01-02 02:15 PM, Sarah Sharp wrote: > On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote: .. >> Unfortunately this patch causes a regression when copying large files to my >> outboard USB3 drive. (Nothing at all to do with networking.) >> >> When I try to copy a large (20GB) file to the USB3

Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst

2014-01-02 Thread Sarah Sharp
On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote: > On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote: > > 3.12-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: David Laight > > > > commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3

[Bug 60644] MPT2SAS drops all HDDs when under high I/O

2014-01-02 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=60644 Tommy Apel changed: What|Removed |Added CC||tommyape...@gmail.com --- Comment #36 from T

[PATCH] scsi-sg: pass flag to inhibit setting LUN

2014-01-02 Thread Jiří Pinkava
Hi, This patch implements support for inhibiting setting LUN number for SCSI custom command send via /dev/sgX with ioctl(.., SG_IO, ...) call. This solves problems with some devices which claim support of SCSI v1/v2, but for some special purposes use custom commands which does not conform with st

Re: Can we use SCSI error trace events to monitor SCSI hardware problems ?

2014-01-02 Thread Hannes Reinecke
On 12/23/2013 04:28 AM, Junliang Li wrote: Hello, Hannes I found you owned a project on github named "md_monitor". It supports MD array by using mdadm tool. But how about generic SCSI devices ? There is a "scsi_dispatch_cmd_error" tracepoint in SCSI subsystem, from which we can get something use

[PATCH, RFC 00/30] sleep_on removal

2014-01-02 Thread Arnd Bergmann
The functions sleep_on, sleep_on_timeout, interruptible_sleep_on and interruptible_sleep_on_timeout have been deprecated for as long as I can remember, and a number of people have contributed patches in the past to remove them from various drivers. This has recently popped up again and I decided t

[PATCH, RFC 02/30] scsi: atari_scsi: fix sleep_on race

2014-01-02 Thread Arnd Bergmann
sleep_on is known broken and going away. The atari_scsi driver is one of two remaining users in the falcon_get_lock() function, which is a rather crazy piece of code. This does not attempt to fix the driver's locking scheme in general, but at least prevents falcon_get_lock from going to sleep when

RE: spinlock_irqsave() && flags (Was: pm80xx: Spinlock fix)

2014-01-02 Thread Suresh Thiagarajan
On Fri, Dec 27, 2013 at 9:48 PM, Oleg Nesterov wrote: > On 12/24, Suresh Thiagarajan wrote: >> >> Below is a small pseudo code on protecting/serializing the flag for global >> access. >> struct temp >> { >> ... >> spinlock_t lock; >> unsigned long lock_flags; >> }; >> void my_