date:20140411

[PATCH] virtio-scsi: Skip setting affinity on uninitialized vq

2014-04-11 Thread Fam Zheng

virtscsi_init calls virtscsi_remove_vqs on err, even before initializing
the vqs. The latter calls virtscsi_set_affinity, so let's check the
pointer there before setting affinity on it.

This fixes a panic when setting device's num_queues=2 on RHEL 6.5:

qemu-system-x86_64 ... \
-device virtio-scsi-pci,id=scsi0,addr=0x13,...,num_queues=2 \
-drive file=/stor/vm/dummy.raw,id=drive-scsi-disk,... \
-device scsi-hd,drive=drive-scsi-disk,...

[0.354734] scsi0 : Virtio SCSI HBA
[0.379504] BUG: unable to handle kernel NULL pointer dereference at 
0020
[0.380141] IP: [] __virtscsi_set_affinity+0x4f/0x120
[0.380141] PGD 0
[0.380141] Oops:  [#1] SMP
[0.380141] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0+ #5
[0.380141] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
[0.380141] task: 88003c9f ti: 88003c9f8000 task.ti: 
88003c9f8000
[0.380141] RIP: 0010:[]  [] 
__virtscsi_set_affinity+0x4f/0x120
[0.380141] RSP: :88003c9f9c08  EFLAGS: 00010256
[0.380141] RAX:  RBX: 88003c3a9d40 RCX: 1070
[0.380141] RDX: 0002 RSI:  RDI: 
[0.380141] RBP: 88003c9f9c28 R08: 000136c0 R09: 88003c801c00
[0.380141] R10: 81475229 R11: 0008 R12: 
[0.380141] R13: 81cc7ca8 R14: 88003cac3d40 R15: 88003cac37a0
[0.380141] FS:  () GS:88003e40() 
knlGS:
[0.380141] CS:  0010 DS:  ES:  CR0: 8005003b
[0.380141] CR2: 0020 CR3: 01c0e000 CR4: 06f0
[0.380141] Stack:
[0.380141]  88003c3a9d40  88003cac3d80 
88003cac3d40
[0.380141]  88003c9f9c48 814742e8 88003c26d000 
88003c26d000
[0.380141]  88003c9f9c68 81474321 88003c26d000 
88003c3a9d40
[0.380141] Call Trace:
[0.380141]  [] virtscsi_set_affinity+0x28/0x40
[0.380141]  [] virtscsi_remove_vqs+0x21/0x50
[0.380141]  [] virtscsi_init+0x91/0x240
[0.380141]  [] ? vp_get+0x50/0x70
[0.380141]  [] virtscsi_probe+0xf4/0x280
[0.380141]  [] virtio_dev_probe+0xe5/0x140
[0.380141]  [] driver_probe_device+0x89/0x230
[0.380141]  [] __driver_attach+0x9b/0xa0
[0.380141]  [] ? driver_probe_device+0x230/0x230
[0.380141]  [] ? driver_probe_device+0x230/0x230
[0.380141]  [] bus_for_each_dev+0x8c/0xb0
[0.380141]  [] driver_attach+0x19/0x20
[0.380141]  [] bus_add_driver+0x198/0x220
[0.380141]  [] driver_register+0x5f/0xf0
[0.380141]  [] ? spi_transport_init+0x79/0x79
[0.380141]  [] register_virtio_driver+0x1b/0x30
[0.380141]  [] init+0x88/0xd6
[0.380141]  [] ? scsi_init_procfs+0x5b/0x5b
[0.380141]  [] do_one_initcall+0x7f/0x10a
[0.380141]  [] kernel_init_freeable+0x14a/0x1de
[0.380141]  [] ? kernel_init_freeable+0x1de/0x1de
[0.380141]  [] ? rest_init+0x80/0x80
[0.380141]  [] kernel_init+0x9/0xf0
[0.380141]  [] ret_from_fork+0x7c/0xb0
[0.380141]  [] ? rest_init+0x80/0x80
[0.380141] RIP  [] __virtscsi_set_affinity+0x4f/0x120
[0.380141]  RSP 
[0.380141] CR2: 0020
[0.380141] ---[ end trace 8074b70c3d5e1d73 ]---
[0.475018] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x0009
[0.475018]
[0.475068] Kernel Offset: 0x0 from 0x8100 (relocation range: 
0x8000-0x9fff)
[0.475068] ---[ end Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x0009

Signed-off-by: Fam Zheng 
---
 drivers/scsi/virtio_scsi.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 16bfd50..3019267 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -750,8 +750,12 @@ static void __virtscsi_set_affinity(struct virtio_scsi 
*vscsi, bool affinity)
 
vscsi->affinity_hint_set = true;
} else {
-   for (i = 0; i < vscsi->num_queues; i++)
+   for (i = 0; i < vscsi->num_queues; i++) {
+   if (!vscsi->req_vqs[i].vq) {
+   continue;
+   }
virtqueue_set_affinity(vscsi->req_vqs[i].vq, -1);
+   }
 
vscsi->affinity_hint_set = false;
}
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] blk-mq: move request structures into struct blk_mq_tags

2014-04-11 Thread Christoph Hellwig

On Thu, Apr 10, 2014 at 08:42:27PM -0600, Jens Axboe wrote:
> Great. Will you send out an updated patchset?

I was waiting for you to apply the previous series, but I'll just resend my
whole set of outstanding patches, it'll need a bit of rebasing against
your updated tree anyway.

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug 71231] System unresponsable after a lot of LUNs have been added to the system

2014-04-11 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=71231

--- Comment #13 from Alex  ---
Thanks for these tips.
It looks like disabling serial console helps.

But I need this one.
I will try to get his patches working so that I can enbale serial console
again.

-- 
You are receiving this mail because:
You are the assignee for the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: aic94xx: maybe uninitialized variable in asd_process_ctrl_a_user

2014-04-11 Thread Paul Bolle

On Thu, 2014-04-10 at 22:13 -0700, Filipe Brandenburger wrote:
> While building a recent kernel with -Werror I found this warning:
> 
> drivers/scsi/aic94xx/aic94xx_sds.c: In function 'asd_read_flash':
> drivers/scsi/aic94xx/aic94xx_sds.c:597:21: error: 'offs' may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
> drivers/scsi/aic94xx/aic94xx_sds.c:985:6: note: 'offs' was declared here

This warning is actually rather old.

> This looks like a valid complaint from the compiler, since in
> asd_process_ctrl_a_user if the call to asd_find_flash_de fails (and
> returns -ENOENT) then offs will not be set, but that will not prevent
> the variable to be later passed to the call to asd_read_flash_seg
> later in that same function.
> 
> Would you please have a look at it? Let me know if there's a more
> appropriate way to report these issues (e.g. bug tracker.)

I tried a few times to fix this warning.

In the end I just asked Fedora to disable aic94xx in their kernel builds
(which they did for Rawhide, their development branch). See
https://lists.fedoraproject.org/pipermail/kernel/2014-January/004759.html for 
all the boring details.


Paul Bolle

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [SCSI] libsas: replace IS_ERR and PTR_ERR with PTR_ERR_OR_ZERO

2014-04-11 Thread Duan Jiong

This patch fixes coccinelle error regarding usage of IS_ERR and
PTR_ERR instead of PTR_ERR_OR_ZERO.

Signed-off-by: Duan Jiong 
---
 drivers/scsi/libsas/sas_scsi_host.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/scsi/libsas/sas_scsi_host.c 
b/drivers/scsi/libsas/sas_scsi_host.c
index 25d0f12..400a2aa 100644
--- a/drivers/scsi/libsas/sas_scsi_host.c
+++ b/drivers/scsi/libsas/sas_scsi_host.c
@@ -1093,9 +1093,7 @@ int sas_init_queue(struct sas_ha_struct *sas_ha)
 
core->queue_thread = kthread_run(sas_queue_thread, sas_ha,
 "sas_queue_%d", core->shost->host_no);
-   if (IS_ERR(core->queue_thread))
-   return PTR_ERR(core->queue_thread);
-   return 0;
+   return PTR_ERR_OR_ZERO(core->queue_thread);
 }
 
 void sas_shutdown_queue(struct sas_ha_struct *sas_ha)
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: hpsa driver bug crack kernel down!

2014-04-11 Thread David Woodhouse

On Thu, 2014-04-10 at 17:17 -0600, Shuah Khan wrote:
> This smells very much like the problem that was solved couple of years
> ago for SI domain. It is likely that path is broken with the DMAR
> device scope array change. Please take a look to see if the following
> no longer occurs. Looks like BIOS could be expecting this RMRR to be
> still mapped.
> 
>/*
>  * We want to prevent any device associated with an RMRR from
>  * getting placed into the SI Domain. This is done because
>  * problems exist when devices are moved in and out of domains
>  * and their respective RMRR info is lost. We exempt USB 
> devices
>  * from this process due to their usage of RMRRs that are 
> known
>  * to not be needed after BIOS hand-off to OS.
>  */
> if (device_has_rmrr(dev) &&
> (pdev->class >> 8) != PCI_CLASS_SERIAL_USB)
> return 0;

Yeah, I'd be inclined to agree although I've tested with graphics
*since* these patches. That's another case where we need to preserve the
RMRR mapping after the driver takes over — and it *was* working.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


smime.p7s
Description: S/MIME cryptographic signature

[no subject]

2014-04-11 Thread Mercantile Finance


We are Christain organization we give out  loan/financial help contact us
via email: mercantilefinanceloanserv...@yahoo.com



--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[no subject]

2014-04-11 Thread Mercantile Finance


We are Christain organization we give out  loan/financial help contact us
via email: mercantilefinanceloanserv...@yahoo.com



--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] scsi: lpfc: lpfc_init: use kcalloc for allocating memory

2014-04-11 Thread Matei Oprea

It's easier to use kcalloc for allocating arrays. While at it
also remove useless casting value.

Signed-off-by: Matei Oprea 
Cc: ROSEdu Kernel Community 
---
 drivers/scsi/lpfc/lpfc_init.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 635eeb3..7e58c22 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -4742,12 +4742,13 @@ lpfc_sli_driver_resource_setup(struct lpfc_hba *phba)
phba->cfg_sg_seg_cnt = LPFC_DEFAULT_MENLO_SG_SEG_CNT;
}
 
-   if (!phba->sli.ring)
-   phba->sli.ring = (struct lpfc_sli_ring *)
-   kzalloc(LPFC_SLI3_MAX_RING *
-   sizeof(struct lpfc_sli_ring), GFP_KERNEL);
-   if (!phba->sli.ring)
-   return -ENOMEM;
+   if (!phba->sli.ring) {
+   phba->sli.ring = kcalloc(LPFC_SLI3_MAX_RING,
+sizeof(struct lpfc_sli_ring),
+GFP_KERNEL);
+   if (!phba->sli.ring)
+   return -ENOMEM;
+   }
 
/*
 * Since lpfc_sg_seg_cnt is module parameter, the sg_dma_buf_size
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: hpsa driver bug crack kernel down!

2014-04-11 Thread Woodhouse, David

On Thu, 2014-04-10 at 09:19 -0700, Davidlohr Bueso wrote:
> Attaching a dmesg from one of the kernels that boots. It doesn't appear
> to have much of the related information... is there any debug config
> option I can enable that might give you more data?

I'd like the contents of /sys/firmware/acpi/tables/DMAR please. And
please could you also apply this patch to both the last-working and
first-failing kernels and show me the output in both cases?

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index dd576c0..d52ac03 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -683,6 +683,12 @@ static struct intel_iommu *device_to_iommu(int segment, u8 
bus, u8 devfn)
 out:
rcu_read_unlock();
 
+   if (iommu)
+   printk("Device %x:%02x:%02x.%d on IOMMU at %llx\n", segment, 
bus,
+  PCI_SLOT(devfn), PCI_FUNC(devfn), drhd->reg_base_addr);
+   else
+   printk("Device %x:%02x:%02x.%d on no IOMMU\n", segment, bus,
+  PCI_SLOT(devfn), PCI_FUNC(devfn));
return iommu;
 }
 


-- 
  Sent with Evolution's ActiveSync support.

David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation






smime.p7s
Description: S/MIME cryptographic signature

SUSPECT: General web-mail maintenance

2014-04-11 Thread Semple, Kylie M

General web-mail maintenance
Dear Account Owner,
 THIS MESSAGE IS DIRECTED TO THOSE USING Office Outlook Web Access Web-mail 
(2007 version). We want to upgrade all Microsoft Exchange email account 
scheduled for today as part of our duty to strengthen security of your mailbox. 
CLICK HERE to upgrade your account to Outlook Web Apps 
2014. If your settings is not updated today, your account will be inactive and 
cannot send or receive message any longer.
Sincerely,
IT Helpdesk DEPT
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug 71231] System unresponsable after a lot of LUNs have been added to the system

2014-04-11 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=71231

Alex  changed:

   What|Removed |Added

  Component|SCSI|Other
Product|IO/Storage  |Other

-- 
You are receiving this mail because:
You are the assignee for the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug 71231] System unresponsable after a lot of LUNs have been added to the system

2014-04-11 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=71231

--- Comment #14 from Alex  ---
My Grub entry is:

title   Test
root(hd0,0)
kernel  /boot/vmlinuz-3.10.25 root=/dev/sdb2 ro console=ttyS0
boot

Removing "console=ttyS0" will fix this problem.
But this isn't a solution for me.

-- 
You are receiving this mail because:
You are the assignee for the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug 71231] System unresponsable after a lot of LUNs have been added to the system

2014-04-11 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=71231

--- Comment #15 from Alex  ---
After disabling ACPI Processor and cpuidle, I get these four different stack
traces (system is working, but not rebooting anymore for example) several
times:


Call Trace:
 [] __mutex_lock_slowpath+0x5d/0x1d0
 [] ? __mutex_lock_slowpath+0x1a8/0x1d0
 [] mutex_lock+0x1d/0x40
 [] sysfs_dentry_revalidate+0x35/0x100
 [] lookup_fast+0x299/0x2e0
 [] ? __inode_permission+0x46/0x70
 [] link_path_walk+0x19a/0x800
 [] ? physflat_send_IPI_mask+0x9/0x10
 [] path_openat.isra.68+0x94/0x450
 [] ? __mutex_lock_slowpath+0x1a8/0x1d0
 [] do_filp_open+0x3c/0x90
 [] ? __alloc_fd+0x42/0x100
 [] do_sys_open+0xef/0x1d0
 [] ? do_notify_resume+0x51/0x80
 [] compat_SyS_open+0x16/0x20
 [] sysenter_dispatch+0x7/0x25

Call Trace:
 [] default_idle+0x9/0x10
 [] arch_cpu_idle+0xa/0x10
 [] cpu_startup_entry+0x91/0x180
 [] start_secondary+0x1a0/0x1a4

Call Trace:
 [] ? simple_read_from_buffer+0x42/0xa0
 [] sysfs_read_file+0xe3/0x190
 [] vfs_read+0xa4/0x180
 [] SyS_read+0x4d/0x90
 [] sysenter_dispatch+0x7/0x25

Call Trace:
 [] __mutex_lock_slowpath+0x5d/0x1d0
 [] mutex_lock+0x1d/0x40
 [] sysfs_getattr+0x2b/0x60
 [] vfs_getattr+0x24/0x40
 [] vfs_fstat+0x38/0x70
 [] ? __alloc_fd+0x42/0x100
 [] sys32_fstat64+0x15/0x30
 [] ? do_sys_open+0x164/0x1d0
 [] sysenter_dispatch+0x7/0x25


I have booted this Multiprocessor server with 40 FC-LUNs connected
(multipathing --> 80).

-- 
You are receiving this mail because:
You are the assignee for the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] blk-mq: move request structures into struct blk_mq_tags

2014-04-11 Thread Jens Axboe


On 04/11/2014 01:33 AM, Christoph Hellwig wrote:

On Thu, Apr 10, 2014 at 08:42:27PM -0600, Jens Axboe wrote:

Great. Will you send out an updated patchset?


I was waiting for you to apply the previous series, but I'll just resend my
whole set of outstanding patches, it'll need a bit of rebasing against
your updated tree anyway.


I'll take a look at the previous series and apply/comment.

--
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] virtio-scsi: Skip setting affinity on uninitialized vq

2014-04-11 Thread Greg KH

On Fri, Apr 11, 2014 at 03:23:45PM +0800, Fam Zheng wrote:
> virtscsi_init calls virtscsi_remove_vqs on err, even before initializing
> the vqs. The latter calls virtscsi_set_affinity, so let's check the
> pointer there before setting affinity on it.
> 
> This fixes a panic when setting device's num_queues=2 on RHEL 6.5:
> 
> qemu-system-x86_64 ... \
> -device virtio-scsi-pci,id=scsi0,addr=0x13,...,num_queues=2 \
> -drive file=/stor/vm/dummy.raw,id=drive-scsi-disk,... \
> -device scsi-hd,drive=drive-scsi-disk,...
> 
> [0.354734] scsi0 : Virtio SCSI HBA
> [0.379504] BUG: unable to handle kernel NULL pointer dereference at 
> 0020
> [0.380141] IP: [] __virtscsi_set_affinity+0x4f/0x120
> [0.380141] PGD 0
> [0.380141] Oops:  [#1] SMP
> [0.380141] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0+ #5
> [0.380141] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
> [0.380141] task: 88003c9f ti: 88003c9f8000 task.ti: 
> 88003c9f8000
> [0.380141] RIP: 0010:[]  [] 
> __virtscsi_set_affinity+0x4f/0x120
> [0.380141] RSP: :88003c9f9c08  EFLAGS: 00010256
> [0.380141] RAX:  RBX: 88003c3a9d40 RCX: 
> 1070
> [0.380141] RDX: 0002 RSI:  RDI: 
> 
> [0.380141] RBP: 88003c9f9c28 R08: 000136c0 R09: 
> 88003c801c00
> [0.380141] R10: 81475229 R11: 0008 R12: 
> 
> [0.380141] R13: 81cc7ca8 R14: 88003cac3d40 R15: 
> 88003cac37a0
> [0.380141] FS:  () GS:88003e40() 
> knlGS:
> [0.380141] CS:  0010 DS:  ES:  CR0: 8005003b
> [0.380141] CR2: 0020 CR3: 01c0e000 CR4: 
> 06f0
> [0.380141] Stack:
> [0.380141]  88003c3a9d40  88003cac3d80 
> 88003cac3d40
> [0.380141]  88003c9f9c48 814742e8 88003c26d000 
> 88003c26d000
> [0.380141]  88003c9f9c68 81474321 88003c26d000 
> 88003c3a9d40
> [0.380141] Call Trace:
> [0.380141]  [] virtscsi_set_affinity+0x28/0x40
> [0.380141]  [] virtscsi_remove_vqs+0x21/0x50
> [0.380141]  [] virtscsi_init+0x91/0x240
> [0.380141]  [] ? vp_get+0x50/0x70
> [0.380141]  [] virtscsi_probe+0xf4/0x280
> [0.380141]  [] virtio_dev_probe+0xe5/0x140
> [0.380141]  [] driver_probe_device+0x89/0x230
> [0.380141]  [] __driver_attach+0x9b/0xa0
> [0.380141]  [] ? driver_probe_device+0x230/0x230
> [0.380141]  [] ? driver_probe_device+0x230/0x230
> [0.380141]  [] bus_for_each_dev+0x8c/0xb0
> [0.380141]  [] driver_attach+0x19/0x20
> [0.380141]  [] bus_add_driver+0x198/0x220
> [0.380141]  [] driver_register+0x5f/0xf0
> [0.380141]  [] ? spi_transport_init+0x79/0x79
> [0.380141]  [] register_virtio_driver+0x1b/0x30
> [0.380141]  [] init+0x88/0xd6
> [0.380141]  [] ? scsi_init_procfs+0x5b/0x5b
> [0.380141]  [] do_one_initcall+0x7f/0x10a
> [0.380141]  [] kernel_init_freeable+0x14a/0x1de
> [0.380141]  [] ? kernel_init_freeable+0x1de/0x1de
> [0.380141]  [] ? rest_init+0x80/0x80
> [0.380141]  [] kernel_init+0x9/0xf0
> [0.380141]  [] ret_from_fork+0x7c/0xb0
> [0.380141]  [] ? rest_init+0x80/0x80
> [0.380141] RIP  [] __virtscsi_set_affinity+0x4f/0x120
> [0.380141]  RSP 
> [0.380141] CR2: 0020
> [0.380141] ---[ end trace 8074b70c3d5e1d73 ]---
> [0.475018] Kernel panic - not syncing: Attempted to kill init! 
> exitcode=0x0009
> [0.475018]
> [0.475068] Kernel Offset: 0x0 from 0x8100 (relocation range: 
> 0x8000-0x9fff)
> [0.475068] ---[ end Kernel panic - not syncing: Attempted to kill init! 
> exitcode=0x0009
> 
> Signed-off-by: Fam Zheng 
> ---
>  drivers/scsi/virtio_scsi.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/12] scsi/NCR5380: fix debugging macros and #include structure

2014-04-11 Thread Sam Creasey

Acked-by: Sam Creasey 

On Wed, Mar 19, 2014 at 11:35:16PM +1100, Finn Thain wrote:
> 
> This patch series addresses several issues with NCR5380 drivers:
> 
> 1. The complex network of #include directives.
> 
> 2. Three inconsistent implementations of the core driver all attempting
>to share the same macro definitions in NCR5380.h.
> 
> 3. Broken debugging code.
> 
> In the past these issues have led to compiler warnings and ugly hacks to
> fix build failures.
> 
> This patch series fixes the debugging code by reducing the divergence
> between the various core driver implementations.
> 
> The final two patches in the series further reduce divergence by refactoring
> sun3_scsi.c and sun3_scsi_vme.c so that they follow the same structure as
> the other NCR5380 drivers.
> 
> By the end of this patch series over 800 net lines of code have been
> removed. This is mostly duplicated code that's easily eliminated once the
> debugging code is made consistent (and some dead code is removed).
> 
> Better uniformity and less duplication should assist future work such as
> modernization and trivial clean-up.
> 
> To make code review easier I've tried to keep these patches succinct and
> free of extraneous changes. Though I did run checkpatch.pl, I've ignored
> whitespace issues in existing code. I will send separate patches for
> whitespace clean-up of NCR5380 drivers.
> 
> All NCR5380 drivers have been compile-tested with this patch series:
>   arm/cumana_1.c
>   arm/oak.c
>   atari_scsi.c
>   dmx3191d.c
>   dtc.c
>   g_NCR5380.c
>   g_NCR5380_mmio.c
>   mac_scsi.c
>   pas16.c
>   sun3_scsi.c
>   sun3_scsi_vme.c
>   t128.c
> 
> I've successfully regression tested this patch series using mac_scsi on a 
> PowerBook 180. The debugging macros are now usable again.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] m68k/atari - atari_scsi: change abort/reset return codes

2014-04-11 Thread Sam Creasey

Acked-by: Sam Creasey 

On Thu, Mar 13, 2014 at 01:30:15AM +1100, Finn Thain wrote:
> 
> This is a larger version of Michael's patch. It takes care of the header 
> files and comments and it addresses sun3_NCR5380 as well as atari_NCR5380. 
> This means that the initio.h include (!) can be dropped from sun3_scsi.h.
> 
> Signed-off-by: Finn Thain 
> 
> ---
> 
> This version defines RESET_RUN_DONE in sun3_scsi.c, to avoid changing 
> driver behaviour whilst trying to keep sun3_NCR5380.c in sync with 
> atari_NCR5380.c (from which it was originally copied).
> 
> 
> Index: linux-m68k/drivers/scsi/atari_NCR5380.c
> ===
> --- linux-m68k.orig/drivers/scsi/atari_NCR5380.c  2014-03-13 
> 01:12:33.0 +1100
> +++ linux-m68k/drivers/scsi/atari_NCR5380.c   2014-03-13 01:13:55.0 
> +1100
> @@ -2683,11 +2683,11 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
>   local_irq_restore(flags);
>   cmd->scsi_done(cmd);
>   falcon_release_lock_if_possible(hostdata);
> - return SCSI_ABORT_SUCCESS;
> + return SUCCESS;
>   } else {
>  /*   local_irq_restore(flags); */
>   printk("scsi%d: abort of connected command failed!\n", 
> HOSTNO);
> - return SCSI_ABORT_ERROR;
> + return FAILED;
>   }
>   }
>  #endif
> @@ -2711,7 +2711,7 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
>* yet... */
>   tmp->scsi_done(tmp);
>   falcon_release_lock_if_possible(hostdata);
> - return SCSI_ABORT_SUCCESS;
> + return SUCCESS;
>   }
>   }
>  
> @@ -2729,7 +2729,7 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
>   if (hostdata->connected) {
>   local_irq_restore(flags);
>   ABRT_PRINTK("scsi%d: abort failed, command connected.\n", 
> HOSTNO);
> - return SCSI_ABORT_SNOOZE;
> + return FAILED;
>   }
>  
>   /*
> @@ -2764,7 +2764,7 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
>   ABRT_PRINTK("scsi%d: aborting disconnected command.\n", 
> HOSTNO);
>  
>   if (NCR5380_select(instance, cmd, (int)cmd->tag))
> - return SCSI_ABORT_BUSY;
> + return FAILED;
>  
>   ABRT_PRINTK("scsi%d: nexus reestablished.\n", HOSTNO);
>  
> @@ -2791,7 +2791,7 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
>   local_irq_restore(flags);
>   tmp->scsi_done(tmp);
>   
> falcon_release_lock_if_possible(hostdata);
> - return SCSI_ABORT_SUCCESS;
> + return SUCCESS;
>   }
>   }
>   }
> @@ -2816,7 +2816,7 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
>*/
>   falcon_release_lock_if_possible(hostdata);
>  
> - return SCSI_ABORT_NOT_RUNNING;
> + return FAILED;
>  }
>  
>  
> @@ -2825,7 +2825,7 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
>   *
>   * Purpose : reset the SCSI bus.
>   *
> - * Returns : SCSI_RESET_WAKEUP
> + * Returns : SUCCESS or FAILURE
>   *
>   */
>  
> @@ -2834,7 +2834,7 @@ static int NCR5380_bus_reset(Scsi_Cmnd *
>   SETUP_HOSTDATA(cmd->device->host);
>   int i;
>   unsigned long flags;
> -#if 1
> +#if defined(RESET_RUN_DONE)
>   Scsi_Cmnd *connected, *disconnected_queue;
>  #endif
>  
> @@ -2859,7 +2859,14 @@ static int NCR5380_bus_reset(Scsi_Cmnd *
>* through anymore ... */
>   (void)NCR5380_read(RESET_PARITY_INTERRUPT_REG);
>  
> -#if 1/* XXX Should now be done by midlevel code, but it's broken XXX 
> */
> + /* MSch 20140115 - looking at the generic NCR5380 driver, all of this
> +  * should go.
> +  * Catch-22: if we don't clear all queues, the SCSI driver lock will
> +  * not be released by atari_scsi_reset()!
> +  */
> +
> +#if defined(RESET_RUN_DONE)
> + /* XXX Should now be done by midlevel code, but it's broken XXX */
>   /* XXX see belowXXX */
>  
>   /* MSch: old-style reset: actually abort all command processing here */
> @@ -2915,7 +2922,7 @@ static int NCR5380_bus_reset(Scsi_Cmnd *
>* the midlevel code that the reset was SUCCESSFUL, and there is no
>* need to 'wake up' the commands by a request_sense
>*/
> - return SCSI_RESET_SUCCESS | SCSI_RESET_BUS_RESET;
> + return SUCCESS;
>  #else /* 1 */
>  
>   /* MSch: new-style reset handling: let the mid-level do what it can */
> @@ -2963,6 +2970,6 @@ static int NCR5380_bus_reset(Scsi_Cmnd *
>   local_irq_restore(flags);
>  
>   /* we did no complete reset of all commands, so a wakeup is required */
>

Re: [PATCH] Update Maintainers for IBM Power 842, vscsi, and vfc drivers

2014-04-11 Thread Robert Jennings

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 04/09/2014 01:32 PM, Nathan Fontenot wrote:
> Update the MAINTAINERS file to indicate the current maintainers
> for the IBM Power 842 Compression driver, IBM Power Virtual SCSI
> driver and the IBM Power Virtual FC Driver.
> 
> Signed-off-by: Nathan Fontenot 

Nathan, sorry I didn't take care of this before I gave up
r...@linux.ibm.com.

Acked-by: Robert Jennings 

> --- MAINTAINERS |   16 +++- 1 file changed, 11 
> insertions(+), 5 deletions(-)
> 
> Index: linux/MAINTAINERS 
> ===
>
>
> 
- --- linux.orig/MAINTAINERS2014-04-08 14:14:57.0 -0500
> +++ linux/MAINTAINERS 2014-04-08 14:25:29.0 -0500 @@ 
> -4358,7 +4358,7 @@ F: drivers/crypto/nx/
> 
> IBM Power 842 compression accelerator -M: Robert Jennings 
>  +M: Nathan Fontenot 
>  S: Supported F: 
> drivers/crypto/nx/nx-842.c F: include/linux/nx842.h @@ -4374,12 
> +4374,18 @@ S:Supported F:drivers/net/ethernet/ibm/ibmveth.*
> 
> -IBM Power Virtual SCSI/FC Device Drivers -M: Robert Jennings 
>  +IBM Power Virtual SCSI Device Drivers
> +M: Nathan Fontenot  L: 
> linux-scsi@vger.kernel.org S: Supported -F:   drivers/scsi/ibmvscsi/
>  -X:  drivers/scsi/ibmvscsi/ibmvstgt.c +F: 
> drivers/scsi/ibmvscsi/ibmvscsi* +F:   drivers/scsi/ibmvscsi/viosrp.h
>  + +IBM Power Virtual FC Device Drivers +M:   Brian King 
>  +L:   linux-scsi@vger.kernel.org +S: 
> Supported +F: drivers/scsi/ibmvscsi/ibmvfc*
> 
> IBM ServeRAID RAID DRIVER P:  Jack Hammer
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJTSA1/AAoJEHQMPZ7t8u1zbmwQAJXdfa1pObeOpukcuE924zGH
jKxeDsFSLSrkxltO7vVMZ/y2LsKJtOaNXy1GzSqX7y3TbaDv2hWYi+GcI6/AlBl+
cgTtMBfYmSUpyuOxEdDzkj4KRx8cF02V0ajCcCqkwTqwvDw5JWBR3/sjDTAvYhes
RzCv3Fl6F3Nf0ksTmmmUxlAmXUITH++4paYTZjrTW2N4YVUKVVzszr4K0dFqqqlW
Ffi/brOXPF7ItfdL4/cEm5j2cZPh/zMLHJb24z67WMmzhCIUELzBjlEFRsBalaz/
X+/pKED01KqNiOpWOLR7FKWZlNkiHV2ZB9QxoUAsepI/s94TxOK94nNHiT6feunG
5WQjrwiWYC2ntG/arNITtz/t+Hs0OKsAvT5mCQ4W+e+UzHB/61zeN3p2/avrA0H6
A33yN2BeHkUyR3ra4uzhn+Sx2nOJvArMNGrnw+LAxrxg17ymE7qGvAqGmDExeTRl
dLJv58B94QlchIgApuESQ4pLGvftvgT0bE/34DgWcTIBzQyTneTn5UTCOYR9h6hA
wpDPmujlt5aEEb2Pm11pJSJ7lvY8MoPOqyc7aHWPkz7t6qfKEdJ8IquRFAyqi+/6
MeiinUCUW1Tp4gif+sy+Dc8UIsMIniUDeyA0//aWZCkA+CfF++P89WWdke/c2t+X
otp+JW8ZqTgHZi1DUuiv
=TcEI
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: LSI SAS - SSDs with DRAT and DZAT

2014-04-11 Thread Bernd Schubert

On 02/12/2014 03:27 AM, Kurt Miller wrote:

I can report that the Samsung 840 Pro*does* support trim on the LSI
SAS2008. As suspected it supports deterministic read zeros after trim.

One other thing to note, in my testing the P16 LSI firmware has broken
trim support. P14 and P15 report incorrect values for
/sys/block/sdX/queue/discard_granularity. P17 and P18 appear to work
fine and report correct values for discard_granularity.

We are just looking for SSDs for our new compute cluster and would like
to get SSDs that support trim on LSI sas controllers out of the box.
Unfortunately, for a test sample of Samsungs MZ7WD240HCFV discard is not
enabled by default, so probably DRAT and DZAT are missing
(I can't test that right now, as 'hdparm -I' does not seem to work with
devices attached to the controller).

A colleague just told me that Samsung 840 Pro are also not an ideal
option, as these have set overprovisioning to 0 bytes by default and
there only seems to be windows tool to set it to a higher value. Not a
nice idea if you want to do that for dozens or hundreds of drives.

Any other suggestions for ~240GB SSDs supporting DRAT and DZAT or
trim-on-lsi-sas in general? The LSI support link sent by Kurt [1] is
also not perfect with respect to trim, as it lists Intel510, although we
definitely know that Intel510s are disabled by default and forcing
write-same trim causes data corruption (unmap works, though).

Thanks in advance,
Bernd

[1]

http://www.lsi.com/downloads/Public/Host%20Bus%20Adapters/Host%20Bus%20Adapters%20Common%20Files/LSI_6Gb_SAS_SATA_HBA_Compatibility_List.pdf

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] qla4xxx: 5.04.00-k6: Updates for scsi "misc" branch

2014-04-11 Thread Mike Christie

On 04/09/2014 08:12 PM, vikas.chaudh...@qlogic.com wrote:
> From: Vikas Chaudhary 
> 
> James,
> 
> Please apply the following patches to the scsi tree at your earliest 
> convenience.
> 
> Adheer Chandravanshi (2):
>   qla4xxx: Fix smatch warning in func qla4xxx_get_ep_param
>   qla4xxx: Fix smatch warning in func qla4xxx_conn_get_param
> 
> Nilesh Javali (2):
>   qla4xxx: Export sysfs DDBs from DPC handler
>   qla4xxx: Fix memory leak for ha->saved_acb
> 
> Tej Parkash (1):
>   qla4xxx: Disable INTx interrupt for ISP82XX
> 
> Vikas Chaudhary (1):
>   qla4xxx: Update driver version to 5.04.00-k6
> 

Looks ok.

Reviewed-by: Mike Christie 

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] async scsi resume for 3.15

2014-04-11 Thread James Bottomley

On Thu, 2014-04-10 at 18:24 -0700, Dan Williams wrote:
> Hi Linus,
> 
> James might still be in the process of sending this your way.  However,
> given the proximity to -rc1, my reasoning for sending this directly is:
> 
> 1/ It provides a tangible speed up for a non-esoteric use case (laptop
> resume):
> 
>   
> https://01.org/suspendresume/blogs/tebrandt/2013/hard-disk-resume-optimization-simpler-approach
> 
> 2/ You already pulled the first half of this enabling from Tejun.
> Quoting Tejun's ATA pull request:
> 
>   "Dan finishes the patchset to make libata PM operations
>asynchronous.  Combined with one patch being routed through scsi,
>this should speed resume measurably."
> 
> 3/ As far as I can tell it is acceptable to James:
> 
>   http://marc.info/?l=linux-scsi&m=139499409510791&w=2
>   http://marc.info/?l=linux-scsi&m=139508044602605&w=2
>   http://marc.info/?l=linux-scsi&m=139536062515216&w=2
> 
> 4/ I promised Todd I would get it upstream before he returns from
> vacation.
> 
> Please pull, thank you.

OK, so this missed the SCSI cutoff window because the series wasn't
finalised until 17 March and, originally, I thought Linus would cut us
off at -rc7 which was 16 March.  In reality we got an extra week, but I
spent that ironing out a few late arriving bugs in the tree itself
rather than integrating features.

For drivers, I'm willing to buck the release protocols a bit because
they're self contained, but for core features, they are supposed to be
all finalised by -rc5.  Plus Linus bites me every time I do it even for
drivers, so I was actually letting the scars heal a bit.

I also don't see this in linux-next, unless I'm not looking in the right
place, so it would be a bit of a risk adding it just before -rc1.

James

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] async scsi resume for 3.15

2014-04-11 Thread Dan Williams

On Fri, Apr 11, 2014 at 11:20 AM, James Bottomley
 wrote:
> On Thu, 2014-04-10 at 18:24 -0700, Dan Williams wrote:
>> Hi Linus,
>>
>> James might still be in the process of sending this your way.  However,
>> given the proximity to -rc1, my reasoning for sending this directly is:
>>
>> 1/ It provides a tangible speed up for a non-esoteric use case (laptop
>> resume):
>>
>>   
>> https://01.org/suspendresume/blogs/tebrandt/2013/hard-disk-resume-optimization-simpler-approach
>>
>> 2/ You already pulled the first half of this enabling from Tejun.
>> Quoting Tejun's ATA pull request:
>>
>>   "Dan finishes the patchset to make libata PM operations
>>asynchronous.  Combined with one patch being routed through scsi,
>>this should speed resume measurably."
>>
>> 3/ As far as I can tell it is acceptable to James:
>>
>>   http://marc.info/?l=linux-scsi&m=139499409510791&w=2
>>   http://marc.info/?l=linux-scsi&m=139508044602605&w=2
>>   http://marc.info/?l=linux-scsi&m=139536062515216&w=2
>>
>> 4/ I promised Todd I would get it upstream before he returns from
>> vacation.
>>
>> Please pull, thank you.
>
> OK, so this missed the SCSI cutoff window because the series wasn't
> finalised until 17 March and, originally, I thought Linus would cut us
> off at -rc7 which was 16 March.  In reality we got an extra week, but I
> spent that ironing out a few late arriving bugs in the tree itself
> rather than integrating features.
>
> For drivers, I'm willing to buck the release protocols a bit because
> they're self contained, but for core features, they are supposed to be
> all finalised by -rc5.  Plus Linus bites me every time I do it even for
> drivers, so I was actually letting the scars heal a bit.
>
> I also don't see this in linux-next, unless I'm not looking in the right
> place, so it would be a bit of a risk adding it just before -rc1.
>
[forgive the resend... google apps converted the last one to html]

Correct, I did not push to -next as not to collide with an appearance
in scsi-misc.  However, it is on korg, so the 0-day kbuild robot has
seen it.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] Fix USB deadlock caused by SCSI error handling

2014-04-11 Thread Andreas Reis

I did set the scsi_logging_level as you wrote, but it still resulted 
into exactly the same dmesg (resp. sudo journalctl -b 0) output with the 
entire patchset (including the "scmd->eh_eflags = 0;"). Except for the 
reverted "do nothing"s, for course.


However, I did miss to mention the following which is printed once with 
or without the scsi_logging_level change:


[16254.735372] sd 9:0:0:0: Device offlined - not ready after error recovery
[16254.735393] sd 9:0:0:0: rejecting I/O to offline device
[16254.735397] sd 9:0:0:0: [sdf] killing request
[16254.735488] sd 9:0:0:0: [sdf] Unhandled error code
[16254.735489] sd 9:0:0:0: [sdf]
[16254.735490] Result: hostbyte=0x01 driverbyte=0x00
[16254.735492] sd 9:0:0:0: [sdf] CDB:
[16254.735493] cdb[0]=0x2a: 2a 00 03 1c 10 f8 00 00 f0 00
[16254.735498] end_request: I/O error, dev sdf, sector 52171000

Another:

[19389.907015] sd 11:0:0:0: Device offlined - not ready after error recovery
[19389.907037] sd 11:0:0:0: [sdf] Unhandled error code
[19389.907044] sd 11:0:0:0: [sdf]
[19389.907049] Result: hostbyte=0x05 driverbyte=0x00
[19389.907055] sd 11:0:0:0: [sdf] CDB:
[19389.907060] cdb[0]=0x28: 28 00 03 13 0d 28 00 00 08 00
[19389.907083] end_request: I/O error, dev sdf, sector 51580200
[19389.907121] sd 11:0:0:0: rejecting I/O to offline device
[19389.907126] sd 11:0:0:0: killing request

In case it matters, the stick's partition stays readable with regard to 
any data on it that has been cached.


On 10.04.2014 13:37, Hannes Reinecke wrote:

Andreas, can you test with the entire patch series and enable
'scsi_logging_level -s -E 5' prior to running the tests?

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

71 matches

Mail list logo