[PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks

2014-10-10 Thread Sitsofe Wheeler
Microsoft Hyper-V virtual disks currently only claim SPC-2 compliance even though they implement post SPC-2 features (such as thin provisioning) which means the Linux kernel does not go on to test for those features even though they are advertised. A previous patch attempted to add a quirk to

[PATCH 1/3] Revert Drivers: add blist flags

2014-10-10 Thread Sitsofe Wheeler
This reverts commit f3cfabce7a2e92564d380de3aad4b43901fb7ae6 (Drivers: add blist flags) as it does not enable thin provisioning for my Hyper-V 2012 R2 virtual disks. Signed-off-by: Sitsofe Wheeler sits...@yahoo.com --- drivers/scsi/storvsc_drv.c | 10 -- 1 file changed, 10 deletions(-)

[PATCH 2/3] scsi: add try_rc16 blacklist flag

2014-10-10 Thread Sitsofe Wheeler
Microsoft Hyper-V virtual disks currently only claim SPC-2 compliance causing the kernel skip checks for features such as thin provisioning even though the virtual disk advertises them. Add a blacklist flag that can allow such devices to quirk past READ CAPACITY(16) guards. Signed-off-by:

[PATCH 3/3] scsi: Use try_rc16 and try_vpd_pages quirks on Hyper-V virtual disks

2014-10-10 Thread Sitsofe Wheeler
Microsoft Hyper-V virtual disks currently only claim SPC-2 compliance causing feature tests not to be run (even though those features are correctly announced elsewhere). Make Hyper-V virtual disks quirk past READ CAPACITY(16) and VPD page guards so appropriate tests are performed. This only

Re: [PATCH 8/8] IB/srp: Add multichannel support

2014-10-10 Thread Roland Dreier
On Mon, Oct 6, 2014 at 4:16 AM, Bart Van Assche bvanass...@acm.org wrote: On 10/02/14 19:30, Christoph Hellwig wrote: Also if we want to merge scsi LLDDs that can take advantage of multiqueue support it would probably be best if I take this via the SCSI tree. Sending these patches to you is

[Bug 85151] pm80xx + 7805H + HP SAS port expander = mpi_smp_completion 2604:smp IO status 0x2 and sas: expander ... discovery failed(0xffffffa6)

2014-10-10 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=85151 --- Comment #11 from linux-...@crashplan.pro --- Created attachment 153151 -- https://bugzilla.kernel.org/attachment.cgi?id=153151action=edit pm80xx dmesg even more verbose output after patching pm80xx.ko This is the applied patch: === diff

[Bug 85151] pm80xx + 7805H + HP SAS port expander = mpi_smp_completion 2604:smp IO status 0x2 and sas: expander ... discovery failed(0xffffffa6)

2014-10-10 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=85151 --- Comment #12 from linux-...@crashplan.pro --- Note the changed behavior with kernel Linux ubuntu14 3.17.0-031700rc7-generic #201409281835 SMP Sun Sep 28 22:36:30 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux patched pm80xx, despite the SAS discovery

Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-10-10 Thread Anatol Pomozov
Hi On Fri, Sep 12, 2014 at 1:09 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: On Thu, Sep 11, 2014 at 10:48 PM, Tom Gundersen t...@jklm.no wrote: On Fri, Sep 12, 2014 at 12:26 AM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: On Thu, Sep 11, 2014 at 2:43 PM, Tom Gundersen

[Bug 85151] pm80xx + 7805H + HP SAS port expander = mpi_smp_completion 2604:smp IO status 0x2 and sas: expander ... discovery failed(0xffffffa6)

2014-10-10 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=85151 --- Comment #13 from linux-...@crashplan.pro --- Note: having 2 pieces of the HP SAS expander connected at the same time, one to each port of the Adaptec 7805H, results in a kernel oops: 35.475138] sas: DONE DISCOVERY on port 7, pid:137,

Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-10-10 Thread Tom Gundersen
On Fri, Oct 10, 2014 at 11:54 PM, Anatol Pomozov anatol.pomo...@gmail.com wrote: 1) Why not to make the timeout configurable through config file? There is already udev.conf you can put config option there. Thus people with modprobe issues can easily fix the problem. And then decrease default

Concurrent SG_SCSI_RESET ioctls

2014-10-10 Thread Elliott, Robert (Server Storage)
The sg3_utils command sg_reset --device /dev/sda invokes an ioctl with SG_SCSI_RESET, an argument of SG_SCSI_RESET_DEVICE, on a device opened with O_NDELAY. The call chain is like this: sd_ioctl[sd.c] scsi_nonblockable_ioctl