Re: [PATCH 3/9] scsi: improved eh timeout handler
On 09/03/2013 11:13 AM, Bart Van Assche wrote: On 09/02/13 15:11, Hannes Reinecke wrote: On 09/02/2013 02:45 PM, Bart Van Assche wrote: This patch adds several new calls to LLD EH handlers. Is it guaranteed that these will only be invoked before scsi_remove_host() has finished ? For more background information, see also [PATCH] Make scsi_remove_host() wait until error handling finished (http://thread.gmane.org/gmane.linux.scsi/82572/focus=82779). Well, that depends how scsi_remove_host() handles outstanding commands. What happens if you call scsi_remove_host() and there is still I/O in flight? I would assume that any HBA would have to kill any outstanding I/O prior to calling scsi_remove_host() (FC most certainly does this). Which would mean that it'll have to wait for scsi_put_command() to be called for all outstanding commands. And as scsi_put_command() will be called only _after_ our routine runs (see the reasoning above) we should be safe. Hello Hannes, Since fc_remove_host() has to be invoked before scsi_remove_host() and since fc_remove_host() changes the port state into FC_PORTSTATE_DELETED this means that fc_remote_port_chkready() will return DID_NO_CONNECT while scsi_remove_host() is in progress. I think this prevents that the SYNCHRONIZE CACHE command submitted by sd_remove() reaches SCSI disks over FC since sd_remove() is invoked from inside scsi_remove_host(). The SRP transport patch I had posted recently makes sure that the SYNCHRONIZE CACHE command submitted by sd_remove() reaches the target SCSI disk. This makes me wonder what the correct behavior is for SCSI transport drivers - disabling I/O before scsi_remove_host() starts or ensuring that I/O is still possible while scsi_remove_host() is in progress ? I think the call chain is as follows: scsi_remove_host() - device_del() - bus_remove_device() - device_release_driver() - __device_release_driver() - sd_remove() - sd_shutdown() - sd_sync_cache(). The actual call chain is scsi_remove_host() - scsi_forget_host() - __scsi_remove_device() - device_del() etc. What's important here is that __scsi_remove_device() sets the state 'SDEV_DEL' and calls blk_cleanup_queue(). So after __scsi_remove_device() no further I/O is possible. However, prior to setting SDEV_DEL I/O should be perfectly okay, so one would assume that the SYNCHRONIZE CACHE command should be sent to the device. USB most certainly does it. A safe practice, however, would be to ensure that no _other_ I/O can be sent to the device, ie that all I/O coming in via the request queue or ioctl should be short-circuited and never hit the device at all. That's what fc_remote_port_chkready() does. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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 4/5] uas: add dead request list
On Di, 2013-09-03 at 10:39 -0700, Sarah Sharp wrote: Don't you need to send an ABORT TASK message to the device to cancel the outstanding request for that stream ID? I don't see that in this code. I see lots of URB cancellation code, but nothing to remove the request from the device-side queue. It is there. uas_eh_abort_handler() cancels a single request. There is also uas_eh_device_reset_handler() which will try a LOGICAL UNIT RESET. Those might not work though, depending on the failure mode. If your usb3 streams stop working you can't cancel scsi requests that way. Or does it simply ensure that SCSI bus reset works? The scsi layer invokes the uas_eh_bus_reset_handler() as last resort, when everything else fails. So, yes, there we'll have the sledge hammer approach to recover: cancel all usb urbs, abort all requests, full usb device reset + re-initialization. But we hardly have another chance when the less invasive methods to cancel a requests didn't work ... Plus, as Joe mentioned, this code is full of BUG_ON(), which is not friendly to users, and doesn't increase my confidence that the driver is ready to have CONFIG_BROKEN removed. Huh? Why you are thinking BUG_ON() is a indicator for bad code quality? I'm using BUG_ON() like assert() in userspace, i.e. they are extra sanity checks which should never ever trigger. I can switch them to less disruptive WARN_ON() if that is the preferred way these says. cheers, Gerd -- 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 60758] module scsi_wait_scan not found kernel panic on boot
https://bugzilla.kernel.org/show_bug.cgi?id=60758 --- Comment #27 from zakrzews...@wp.pl --- Hetzner is using these boards inside their EX40 or EX40-SSD dedicated servers: http://wiki.hetzner.de/index.php/Wake_On_LAN/en -- 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 60758] module scsi_wait_scan not found kernel panic on boot
https://bugzilla.kernel.org/show_bug.cgi?id=60758 --- Comment #28 from zakrzews...@wp.pl --- One more thing - these boards does not boot kernel-lt-3.0.94-1 and latest official CentOS kernel too ! -- 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
[patch] [SCSI] atp870u: 64 bit bug in probe()
On 64 bit CPUs there is a memory corruption bug on probe(). It should
be setting 32 bits of data on both 32 and 64 bit.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
Static checker stuff. I can't test this.
diff --git a/drivers/scsi/atp870u.c b/drivers/scsi/atp870u.c
index 15a629d..3edbf30 100644
--- a/drivers/scsi/atp870u.c
+++ b/drivers/scsi/atp870u.c
@@ -2791,11 +2791,11 @@ next_fblk_885:
p-global_map[m]= 0;
for (k=0; k 4; k++) {
outw(n++,base_io + 0x3c);
- ((unsigned long *)setupdata[m][0])[k]=inl(base_io +
0x38);
+ ((u32 *)setupdata[m][0])[k]=inl(base_io + 0x38);
}
for (k=0; k 4; k++) {
outw(n++,base_io + 0x3c);
- ((unsigned long *)p-sp[m][0])[k]=inl(base_io + 0x38);
+ ((u32 *)p-sp[m][0])[k]=inl(base_io + 0x38);
}
n += 8;
}
--
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
My Proposal
Good day, I Am Chi Pui;Do not be surprised! I got your email contact via the World Email On-line Directory I am crediting officer at Sino Pac Bank Plc in Hong Kong and i have a deal of $17.3M to discuss with you urgently. Regards, Mr.Chi Pui -- 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: Potential out-of-bounds access in drivers/scsi/sd.c
Il 04/09/2013 16:32, Alan Stern ha scritto:
On Wed, 4 Sep 2013, Dmitry Vyukov wrote:
Hi,
We are working on a memory error detector AddressSanitizer for Linux
kernel
(https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel),
it can detect use-after-free and buffer-overflow errors.
...
The code in sd_read_cache_type does the following:
while (offset len) {
...
}
...
if ((buffer[offset] 0x3f) != modepage) {
sd_printk(KERN_ERR, sdkp, Got wrong page\n);
goto defaults;
}
When control leaves the while loop, offset = len, so buffer[offset]
reads random garbage out-of-bounds.
It the worst case it can lead to crash, or if (buffer[offset] 0x3f)
happen to be == modepage, then it will read more garbage.
Please help validate and triage this.
The tool's output is correct. The patch below should fix it.
Alan Stern
Index: usb-3.11/drivers/scsi/sd.c
===
--- usb-3.11.orig/drivers/scsi/sd.c
+++ usb-3.11/drivers/scsi/sd.c
@@ -2419,7 +2419,7 @@ sd_read_cache_type(struct scsi_disk *sdk
}
}
- if (modepage == 0x3F) {
+ if (modepage == 0x3F || offset + 2 = len) {
sd_printk(KERN_ERR, sdkp, No Caching mode page
present\n);
goto defaults;
If you do this, the buggy if becomes dead code (the loop above doesn't
have any break, so you know that offset = len and the new condition
is always true).
So the patch does indeed prevent the bug, but the code can be simplified.
Paolo
--
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: Potential out-of-bounds access in drivers/scsi/sd.c
On Wed, 4 Sep 2013, Dmitry Vyukov wrote:
Hi,
We are working on a memory error detector AddressSanitizer for Linux
kernel
(https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel),
it can detect use-after-free and buffer-overflow errors.
...
The code in sd_read_cache_type does the following:
while (offset len) {
...
}
...
if ((buffer[offset] 0x3f) != modepage) {
sd_printk(KERN_ERR, sdkp, Got wrong page\n);
goto defaults;
}
When control leaves the while loop, offset = len, so buffer[offset]
reads random garbage out-of-bounds.
It the worst case it can lead to crash, or if (buffer[offset] 0x3f)
happen to be == modepage, then it will read more garbage.
Please help validate and triage this.
The tool's output is correct. The patch below should fix it.
Alan Stern
Index: usb-3.11/drivers/scsi/sd.c
===
--- usb-3.11.orig/drivers/scsi/sd.c
+++ usb-3.11/drivers/scsi/sd.c
@@ -2419,7 +2419,7 @@ sd_read_cache_type(struct scsi_disk *sdk
}
}
- if (modepage == 0x3F) {
+ if (modepage == 0x3F || offset + 2 = len) {
sd_printk(KERN_ERR, sdkp, No Caching mode page
present\n);
goto defaults;
--
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
Geschaftsvorschlag.
Lieber Freund Ich vermute das diese E-Mail eine Überraschung für Sie sein wird, aber es ist wahr.Ich bin bei einer routinen Überprüfung in meiner Bank (StandardBank PLC von Süd Afrika) wo ich arbeite, auf einem Konto gestoßen, was nicht in anspruch genommen worden ist, wo derzeit USD$18.5M (Achtzehn Million, Fünf Hundert Tausend, US Dollar) gutgeschrieben sind.Dieses Konto gehörte Herrn Peter Hartmann, der ein Kunde in unsere Bank war, der leider verstorben ist. Herr Hartmann war ein gebürtiger Deutscher. Damit es mir möglich ist dieses Geld $18,500,000 inanspruch zunehmen,benötige ich die zusammenarbeit eines Ausländischen Partners wie Sie,den ich als Verwandter und Erbe des verstorbenen Herrn Hartmann vorstellen kann,damit wir das Geld inanspruch nehmen können. Für diese Unterstützung erhalten Sie 30% der Erbschaftsumme und die restlichen 70% teile ich mirmit meinen zwei Arbeitskollegen, die mich bei dieser Transaktion ebenfalls unterstützen. Wenn Sie interessiert sind, können Sie mir bitte eine E-Mail auf meinen prtivat E-Mail zuschicken oliver_ekm...@live.com, damit ich Ihnen mehr Details zukommen lassen kann. Mit freundlichen Grüßen Oliver Ekmann. -- 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: Potential out-of-bounds access in drivers/scsi/sd.c
On Wed, 4 Sep 2013, Paolo Bonzini wrote:
--- usb-3.11.orig/drivers/scsi/sd.c
+++ usb-3.11/drivers/scsi/sd.c
@@ -2419,7 +2419,7 @@ sd_read_cache_type(struct scsi_disk *sdk
}
}
- if (modepage == 0x3F) {
+ if (modepage == 0x3F || offset + 2 = len) {
sd_printk(KERN_ERR, sdkp, No Caching mode page
present\n);
goto defaults;
If you do this, the buggy if becomes dead code (the loop above doesn't
have any break, so you know that offset = len and the new condition
is always true).
So the patch does indeed prevent the bug, but the code can be simplified.
That's right. I didn't realize it at first, but the only way to get
here is if the next page offset lies beyond the end of the data in the
buffer. Therefore the patch can be simplified as follows.
Alan Stern
Index: usb-3.11/drivers/scsi/sd.c
===
--- usb-3.11.orig/drivers/scsi/sd.c
+++ usb-3.11/drivers/scsi/sd.c
@@ -2419,14 +2419,9 @@ sd_read_cache_type(struct scsi_disk *sdk
}
}
- if (modepage == 0x3F) {
- sd_printk(KERN_ERR, sdkp, No Caching mode page
- present\n);
- goto defaults;
- } else if ((buffer[offset] 0x3f) != modepage) {
- sd_printk(KERN_ERR, sdkp, Got wrong page\n);
- goto defaults;
- }
+ sd_printk(KERN_ERR, sdkp, No Caching mode page found\n);
+ goto defaults;
+
Page_found:
if (modepage == 8) {
sdkp-WCE = ((buffer[offset + 2] 0x04) != 0);
--
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: Potential out-of-bounds access in drivers/scsi/sd.c
On Wed, Sep 4, 2013 at 6:32 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 4 Sep 2013, Dmitry Vyukov wrote:
Hi,
We are working on a memory error detector AddressSanitizer for Linux
kernel
(https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel),
it can detect use-after-free and buffer-overflow errors.
...
The code in sd_read_cache_type does the following:
while (offset len) {
...
}
...
if ((buffer[offset] 0x3f) != modepage) {
sd_printk(KERN_ERR, sdkp, Got wrong page\n);
goto defaults;
}
When control leaves the while loop, offset = len, so buffer[offset]
reads random garbage out-of-bounds.
It the worst case it can lead to crash, or if (buffer[offset] 0x3f)
happen to be == modepage, then it will read more garbage.
Please help validate and triage this.
The tool's output is correct. The patch below should fix it.
Thanks, Alan!
I agree with Paolo that the branch can be removed.
Will you take care of landing the patch?
Index: usb-3.11/drivers/scsi/sd.c
===
--- usb-3.11.orig/drivers/scsi/sd.c
+++ usb-3.11/drivers/scsi/sd.c
@@ -2419,7 +2419,7 @@ sd_read_cache_type(struct scsi_disk *sdk
}
}
- if (modepage == 0x3F) {
+ if (modepage == 0x3F || offset + 2 = len) {
sd_printk(KERN_ERR, sdkp, No Caching mode page
present\n);
goto defaults;
--
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: Potential out-of-bounds access in drivers/scsi/sd.c
On Wed, 4 Sep 2013, Dmitry Vyukov wrote: Thanks, Alan! I agree with Paolo that the branch can be removed. Will you take care of landing the patch? I will when everyone agrees it is ready. Alan Stern -- 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 1/4] hpsa: add HP Smart Array Gen9 PCI ID's
Patch 1 of 4
From: Mike Miller mike.mil...@hp.com
This patch adds the PCI ID's for HP Smart Array Gen9 controllers. Please
consider this patch for inclusion.
Signed-off-by: Mike Miller mike.mil...@hp.com
---
drivers/scsi/hpsa.c | 25 +
include/linux/pci_ids.h |1 +
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 7f4f790..ee71153 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -108,6 +108,19 @@ static const struct pci_device_id hpsa_pci_device_id[] = {
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1926},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1928},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x334d},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1929},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21BD},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21BE},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21BF},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21C0},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21C1},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21C2},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21C3},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21C4},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21C5},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21C7},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21C8},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21C9},
{PCI_VENDOR_ID_HP, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_RAID 8, 0x 8, 0},
{0,}
@@ -143,6 +156,18 @@ static struct board_type products[] = {
{0x1926103C, Smart Array, SA5_access},
{0x1928103C, Smart Array, SA5_access},
{0x334d103C, Smart Array P822se, SA5_access},
+ {0x21BD103C, Smart Array, SA5_access},
+ {0x21BE103C, Smart Array, SA5_access},
+ {0x21BF103C, Smart Array, SA5_access},
+ {0x21C0103C, Smart Array, SA5_access},
+ {0x21C1103C, Smart Array, SA5_access},
+ {0x21C2103C, Smart Array, SA5_access},
+ {0x21C3103C, Smart Array, SA5_access},
+ {0x21C4103C, Smart Array, SA5_access},
+ {0x21C5103C, Smart Array, SA5_access},
+ {0x21C7103C, Smart Array, SA5_access},
+ {0x21C8103C, Smart Array, SA5_access},
+ {0x21C9103C, Smart Array, SA5_access},
{0x103C, Unknown Smart Array, SA5_access},
};
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 3bed2e8..2ce3926 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -756,6 +756,7 @@
#define PCI_DEVICE_ID_HP_CISSE 0x323a
#define PCI_DEVICE_ID_HP_CISSF 0x323b
#define PCI_DEVICE_ID_HP_CISSH 0x323c
+#define PCI_DEVICE_ID_HP_CISSI 0x3239
#define PCI_DEVICE_ID_HP_ZX2_IOC 0x4031
#define PCI_VENDOR_ID_PCTECH 0x1042
--
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 2/4] hpsa: add HP Smart Array Gen8 names
Patch 2 of 4
From: Mike Miller mike.mil...@hp.com
Add the marketing names for HP Smart Array Gen8 controllers. Also removes an
unused ID. Please consider this for inclusion.
Signed-off-by: Mike Miller mike.mil...@hp.com
---
drivers/scsi/hpsa.c | 15 +++
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index ee71153..d02bdf0 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -147,14 +147,13 @@ static struct board_type products[] = {
{0x3354103C, Smart Array P420i, SA5_access},
{0x3355103C, Smart Array P220i, SA5_access},
{0x3356103C, Smart Array P721m, SA5_access},
- {0x1920103C, Smart Array, SA5_access},
- {0x1921103C, Smart Array, SA5_access},
- {0x1922103C, Smart Array, SA5_access},
- {0x1923103C, Smart Array, SA5_access},
- {0x1924103C, Smart Array, SA5_access},
- {0x1925103C, Smart Array, SA5_access},
- {0x1926103C, Smart Array, SA5_access},
- {0x1928103C, Smart Array, SA5_access},
+ {0x1921103C, Smart Array P830i, SA5_access},
+ {0x1922103C, Smart Array P430, SA5_access},
+ {0x1923103C, Smart Array P431, SA5_access},
+ {0x1924103C, Smart Array P830, SA5_access},
+ {0x1926103C, Smart Array P731m, SA5_access},
+ {0x1928103C, Smart Array P230i, SA5_access},
+ {0x1929103C, Smart Array P530, SA5_access},
{0x334d103C, Smart Array P822se, SA5_access},
{0x21BD103C, Smart Array, SA5_access},
{0x21BE103C, Smart Array, SA5_access},
--
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 3/4] hpsa: housekeeping patch for device_id and product arrays
Patch 3 of 4
From: Mike Miller mike.mil...@hp.com
This patch does a bit of housekeeping for hpsa. Change lowercase alpha hex
digits to uppercase for consistency within the driver. Also moves the P822se
in the tables to keep controllers of each family grouped together.
Signed-off-by: Mike Miller mike.mil...@hp.com
---
drivers/scsi/hpsa.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index d02bdf0..5097e0c 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -89,13 +89,14 @@ static const struct pci_device_id hpsa_pci_device_id[] = {
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x3245},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x3247},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x3249},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x324a},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x324b},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x324A},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x324B},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x3233},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3350},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3351},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3352},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3353},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x334D},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3354},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3355},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3356},
@@ -107,7 +108,6 @@ static const struct pci_device_id hpsa_pci_device_id[] = {
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1925},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1926},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1928},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x334d},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1929},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21BD},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21BE},
@@ -138,12 +138,13 @@ static struct board_type products[] = {
{0x3245103C, Smart Array P410i, SA5_access},
{0x3247103C, Smart Array P411, SA5_access},
{0x3249103C, Smart Array P812, SA5_access},
- {0x324a103C, Smart Array P712m, SA5_access},
- {0x324b103C, Smart Array P711m, SA5_access},
+ {0x324A103C, Smart Array P712m, SA5_access},
+ {0x324B103C, Smart Array P711m, SA5_access},
{0x3350103C, Smart Array P222, SA5_access},
{0x3351103C, Smart Array P420, SA5_access},
{0x3352103C, Smart Array P421, SA5_access},
{0x3353103C, Smart Array P822, SA5_access},
+ {0x334D103C, Smart Array P822se, SA5_access},
{0x3354103C, Smart Array P420i, SA5_access},
{0x3355103C, Smart Array P220i, SA5_access},
{0x3356103C, Smart Array P721m, SA5_access},
@@ -154,7 +155,6 @@ static struct board_type products[] = {
{0x1926103C, Smart Array P731m, SA5_access},
{0x1928103C, Smart Array P230i, SA5_access},
{0x1929103C, Smart Array P530, SA5_access},
- {0x334d103C, Smart Array P822se, SA5_access},
{0x21BD103C, Smart Array, SA5_access},
{0x21BE103C, Smart Array, SA5_access},
{0x21BF103C, Smart Array, SA5_access},
--
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 4/4] hpsa: bump driver version to reflect changes
Patch 4 of 4 From: Mike Miller mike.mil...@hp.com Changes the version of hpsa so we know something has changed. Please consider this for inclusion. Signed-off-by: Mike Miller mike.mil...@hp.com --- drivers/scsi/hpsa.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c index 5097e0c..9bf6304 100644 --- a/drivers/scsi/hpsa.c +++ b/drivers/scsi/hpsa.c @@ -54,7 +54,7 @@ #include hpsa.h /* HPSA_DRIVER_VERSION must be 3 byte values (0-255) separated by '.' */ -#define HPSA_DRIVER_VERSION 2.0.2-1 +#define HPSA_DRIVER_VERSION 3.4.0-1 #define DRIVER_NAME HP HPSA Driver (v HPSA_DRIVER_VERSION ) #define HPSA hpsa -- 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: [SCSI] esas2r: ATTO Technology ExpressSAS 6G SAS/SATA RAID Adapter Driver
+struct esas2r_adapter {
+struct esas2r_target targetdb[ESAS2R_MAX_TARGETS];
+struct esas2r_target *targetdb_end;
...
+u8 fw_coredump_buff[ESAS2R_FWCOREDUMP_SZ];
+void esas2r_reset_chip(struct esas2r_adapter *a)
+{
+if (!esas2r_is_adapter_present(a))
+return;
+
+/*
+ * Before we reset the chip, save off the VDA core dump. The VDA core
+ * dump is located in the upper 512KB of the onchip SRAM. Make sure
+ * to not overwrite a previous crash that was saved.
+ */
+if ((a-flags2 AF2_COREDUMP_AVAIL)
+ !(a-flags2 AF2_COREDUMP_SAVED)
+ a-fw_coredump_buff) {
+esas2r_read_mem_block(a,
+ a-fw_coredump_buff,
+ MW_DATA_ADDR_SRAM + 0x8,
+ ESAS2R_FWCOREDUMP_SZ);
Comparing an array (fw_coredump_buff) to null probably isn't what you intended
here.
Dave
--
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
fix swapped arguments in aic7xxx:ahc_find_pci_device
The prototype for ahc_9005_subdevinfo_valid shows that the caller has the arguments in the wrong order. 637 ahc_9005_subdevinfo_valid(uint16_t device, uint16_t vendor, 638 uint16_t subdevice, uint16_t subvendor) Signed-off-by: Dave Jones da...@fedoraproject.org diff --git a/drivers/scsi/aic7xxx/aic7xxx_pci.c b/drivers/scsi/aic7xxx/aic7xxx_pci.c index 6917b4f..22d5a94 100644 --- a/drivers/scsi/aic7xxx/aic7xxx_pci.c +++ b/drivers/scsi/aic7xxx/aic7xxx_pci.c @@ -692,7 +692,7 @@ ahc_find_pci_device(ahc_dev_softc_t pci) * ID as valid. */ if (ahc_get_pci_function(pci) 0 - ahc_9005_subdevinfo_valid(vendor, device, subvendor, subdevice) + ahc_9005_subdevinfo_valid(device, vendor, subdevice, subvendor) SUBID_9005_MFUNCENB(subdevice) == 0) return (NULL); -- 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
[ANNOUNCE]: Emulex SCST support for 16Gb/s FC and FCoE CNAs
I'm glad to announce that SCST support for 16Gb/s FC and FCoE Emulex CNAs is now available as part of the Emulex OneCore Storage SDK tool set based on the Emulex SLI-4 API. Support for 16Gb/s Fibre Channel LPe16000 series and FCoE hardware using target mode versions of the OneConnect FCoE CNAs is included. Documented for use with RHEL/CentOS 6.x based distributions, ocs_fc_scst works with the stable SCST 2.2.1 as well as the development versions of 2.2.x and 3.0.x. The driver code and documentation are available on the Emulex web site at: http://www.emulex.com/products/onecore-storage-software-development-kit/overview.html Registration is required on the Developer Portal, but this is free. Questions regarding this driver better to ask via the Developer Portal. SCST is SCSI target mode stack for Linux. SCST allows creation of sophisticated storage devices, which provide advanced functionality, like replication, thin provisioning, deduplication, high availability, automatic backup, etc. Majority of recently developed SAN appliances, especially higher end ones, are SCST based. It might well be that your favorite storage appliance running SCST in the firmware. More info about SCST and its modules you can find on: http://scst.sourceforge.net Vlad -- 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: sr: use block layer runtime PM
Migrate SCSI Optical Disk Drive(ODD) driver sr to make use of block
layer runtime PM. Accordingly, the SCSI bus layer runtime PM callback is
simplified as all SCSI devices that implement runtime PM are now request
based.
Signed-off-by: Aaron Lu aaron...@intel.com
---
Note that due to ODD will be polled every 2 seconds, for suspend to
actually happen, the autosuspend_delay can not be set to more than 2
seconds.
Also, make sure to use the util-linux utility of version 2.23.2 or later,
as there is a bug fix for eject command to correctly update the ODD's
locked state. If the fix is not applied, after the ODD is ejected with the
eject command, it will not be able to enter runtime suspend state any
more due to SCSI EH code will submit a lock door command for the ODD
right after its parent ATA port is runtime suspended.
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=12272030e563201e0b06732d8a87d8cea7157a04
drivers/scsi/scsi_pm.c | 58 --
drivers/scsi/sr.c | 37 +++-
2 files changed, 27 insertions(+), 68 deletions(-)
diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
index 4c5aabe..752edf0 100644
--- a/drivers/scsi/scsi_pm.c
+++ b/drivers/scsi/scsi_pm.c
@@ -144,38 +144,22 @@ static int scsi_bus_restore(struct device *dev)
#ifdef CONFIG_PM_RUNTIME
-static int sdev_blk_runtime_suspend(struct scsi_device *sdev,
- int (*cb)(struct device *))
+static int sdev_runtime_suspend(struct device *dev)
{
+ const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL;
+ struct scsi_device *sdev = to_scsi_device(dev);
int err;
err = blk_pre_runtime_suspend(sdev-request_queue);
if (err)
return err;
- if (cb)
- err = cb(sdev-sdev_gendev);
+ if (pm pm-runtime_suspend)
+ err = pm-runtime_suspend(dev);
blk_post_runtime_suspend(sdev-request_queue, err);
return err;
}
-static int sdev_runtime_suspend(struct device *dev)
-{
- const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL;
- int (*cb)(struct device *) = pm ? pm-runtime_suspend : NULL;
- struct scsi_device *sdev = to_scsi_device(dev);
- int err;
-
- if (sdev-request_queue-dev)
- return sdev_blk_runtime_suspend(sdev, cb);
-
- err = scsi_dev_type_suspend(dev, cb);
- if (err == -EAGAIN)
- pm_schedule_suspend(dev, jiffies_to_msecs(
- round_jiffies_up_relative(HZ/10)));
- return err;
-}
-
static int scsi_runtime_suspend(struct device *dev)
{
int err = 0;
@@ -189,31 +173,20 @@ static int scsi_runtime_suspend(struct device *dev)
return err;
}
-static int sdev_blk_runtime_resume(struct scsi_device *sdev,
- int (*cb)(struct device *))
+static int sdev_runtime_resume(struct device *dev)
{
+ struct scsi_device *sdev = to_scsi_device(dev);
+ const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL;
int err = 0;
blk_pre_runtime_resume(sdev-request_queue);
- if (cb)
- err = cb(sdev-sdev_gendev);
+ if (pm pm-runtime_resume)
+ err = pm-runtime_resume(dev);
blk_post_runtime_resume(sdev-request_queue, err);
return err;
}
-static int sdev_runtime_resume(struct device *dev)
-{
- struct scsi_device *sdev = to_scsi_device(dev);
- const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL;
- int (*cb)(struct device *) = pm ? pm-runtime_resume : NULL;
-
- if (sdev-request_queue-dev)
- return sdev_blk_runtime_resume(sdev, cb);
- else
- return scsi_dev_type_resume(dev, cb);
-}
-
static int scsi_runtime_resume(struct device *dev)
{
int err = 0;
@@ -234,14 +207,11 @@ static int scsi_runtime_idle(struct device *dev)
/* Insert hooks here for targets, hosts, and transport classes */
if (scsi_is_sdev_device(dev)) {
- struct scsi_device *sdev = to_scsi_device(dev);
-
- if (sdev-request_queue-dev) {
- pm_runtime_mark_last_busy(dev);
- pm_runtime_autosuspend(dev);
- return -EBUSY;
- }
+ pm_runtime_mark_last_busy(dev);
+ pm_runtime_autosuspend(dev);
+ return -EBUSY;
}
+
return 0;
}
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index 119d67f..40d8592 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -161,14 +161,10 @@ static inline struct scsi_cd *scsi_cd_get(struct gendisk
*disk)
goto out;
cd = scsi_cd(disk);
kref_get(cd-kref);
- if (scsi_device_get(cd-device))
- goto out_put;
- if (!scsi_autopm_get_device(cd-device))
-
