[PATCH 2/2] virtio_scsi: space required before open parenthesis
Fix coding style warnings from checkpatch
Signed-off-by: Jerry Snitselaar d...@snitselaar.org
---
drivers/scsi/virtio_scsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 9f2fccc..9248a1e 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -723,7 +723,7 @@ static struct scsi_host_template
virtscsi_host_template_multi = {
do { \
typeof(((struct virtio_scsi_config *)0)-fld) __val = (val); \
virtio_cwrite(vdev, struct virtio_scsi_config, fld, __val); \
- } while(0)
+ } while (0)
static void __virtscsi_set_affinity(struct virtio_scsi *vscsi, bool affinity)
{
@@ -771,7 +771,7 @@ static int virtscsi_cpu_callback(struct notifier_block *nfb,
{
struct virtio_scsi *vscsi = container_of(nfb, struct virtio_scsi, nb);
- switch(action) {
+ switch (action) {
case CPU_ONLINE:
case CPU_ONLINE_FROZEN:
case CPU_DEAD:
--
2.0.0.rc0
--
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/2] virtio_scsi: blank line after declaration cleanup
Clean up of coding style warnings from checkpatch
Signed-off-by: Jerry Snitselaar d...@snitselaar.org
---
drivers/scsi/virtio_scsi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 16bfd50..fa0b25f 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -498,8 +498,8 @@ static int virtscsi_queuecommand(struct virtio_scsi *vscsi,
{
struct virtio_scsi_cmd *cmd;
int ret;
-
struct Scsi_Host *shost = virtio_scsi_host(vscsi-vdev);
+
BUG_ON(scsi_sg_count(sc) shost-sg_tablesize);
/* TODO: check feature bit and fail if unsupported? */
@@ -661,6 +661,7 @@ static int virtscsi_target_alloc(struct scsi_target
*starget)
{
struct virtio_scsi_target_state *tgt =
kmalloc(sizeof(*tgt), GFP_KERNEL);
+
if (!tgt)
return -ENOMEM;
@@ -675,6 +676,7 @@ static int virtscsi_target_alloc(struct scsi_target
*starget)
static void virtscsi_target_destroy(struct scsi_target *starget)
{
struct virtio_scsi_target_state *tgt = starget-hostdata;
+
kfree(tgt);
}
@@ -768,6 +770,7 @@ static int virtscsi_cpu_callback(struct notifier_block *nfb,
unsigned long action, void *hcpu)
{
struct virtio_scsi *vscsi = container_of(nfb, struct virtio_scsi, nb);
+
switch(action) {
case CPU_ONLINE:
case CPU_ONLINE_FROZEN:
--
2.0.0.rc0
--
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: two small scsi fixes for 3.15-rc3
On Fri, Apr 25, 2014 at 08:00:48AM -0700, James Bottomley wrote: You should have received my git tree emails that they were already in SCSI fixes ... didn't you? I certainly got a copy. I've not seen a single reply to the patches either in my inbox or on linux-scsi. -- 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
3.2.57 regression: isci driver broken: Unable to reset I T nexus?
Hello, just upgraded a server running 3.2.54-2 to 3.2.57-3 (Debian Wheezy) and it does not boot anymore because of isci driver breakage. A (partial) log transcription: sas: DOING DISCOVERY on port 0, pid:5 sas: Enter sas_scsi_recover_host ata1: sas eh calling libata port error handler sas: sas_ata_hard_reset: Unable to reset I T nexus? sas: sas_ata_hard_reset: Found ATA device. sas: sas_ata_hard_reset: Unable to soft reset sas: sas_ata_hard_reset: Found ATA device. ata1: reset failed (errno=-11), retrying in 10 secs sas: sas_ata_hard_reset: Unable to reset I T nexus? sas: sas_ata_hard_reset: Found ATA device. sas: sas_ata_hard_reset: Unable to soft reset sas: sas_ata_hard_reset: Found ATA device. ata1: reset failed (errno=-11), retrying in 35 secs ata1: reset failed, giving up sas: --- Exit sas_scsi_recover_host sas: DONE DISCOVERY on port 0, pid: 5, result:0 sas: phy-0:1 added to port-0:1, phy_mask:0x2 (5fcf0002) sas: DOING DISCOVERY on port 1, pid:5 sas: Enter sas_scsi_recover_host ata1: sas eh calling libata port error handler sas: sas_ata_hard_reset: Unable to reset I T nexus? sas: sas_ata_hard_reset: Found ATA device. sas: sas_ata_hard_reset: Unable to soft reset sas: sas_ata_hard_reset: Found ATA device. ata2: reset failed (errno=-11), retrying in 10 secs sas: sas_ata_hard_reset: Unable to reset I T nexus? sas: sas_ata_hard_reset: Found ATA device. sas: sas_ata_hard_reset: Unable to soft reset sas: sas_ata_hard_reset: Found ATA device. ata2: reset failed (errno=-11), retrying in 35 secs ata2: reset failed, giving up It should look like this (v3.2.54-2): isci: Intel(R) C600 SAS Controller Driver - version 1.0.0 isci :03:00.0: driver configured for rev: 6 silicon isci :03:00.0: firmware: agent loaded isci/isci_firmware.bin into memory isci :03:00.0: OEM SAS parameters (version: 1.3) loaded (firmware) isci :03:00.0: setting latency timer to 64 scsi0 : isci scsi1 : isci isci :03:00.0: irq 81 for MSI/MSI-X isci :03:00.0: irq 82 for MSI/MSI-X isci :03:00.0: irq 83 for MSI/MSI-X isci :03:00.0: irq 84 for MSI/MSI-X sas: phy-0:0 added to port-0:0, phy_mask:0x1 (5fcf0001) sas: DOING DISCOVERY on port 0, pid:5 sas: Enter sas_scsi_recover_host ata1: sas eh calling libata port error handler sas: sas_ata_hard_reset: Found ATA device. ata1.00: ATA-8: ST9500620NS, CC02, max UDMA/133 ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32) ata1.00: configured for UDMA/133 sas: --- Exit sas_scsi_recover_host scsi 0:0:0:0: Direct-Access ATA ST9500620NS CC02 PQ: 0 ANSI: 5 sas: DONE DISCOVERY on port 0, pid:5, result:0 sas: phy-0:1 added to port-0:1, phy_mask:0x2 (5fcf0002) sas: DOING DISCOVERY on port 1, pid:5 sas: Enter sas_scsi_recover_host ata1: sas eh calling libata port error handler ata2: sas eh calling libata port error handler sas: sas_ata_hard_reset: Found ATA device. ata2.00: ATA-8: ST9500620NS, CC02, max UDMA/133 ata2.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32) ata2.00: configured for UDMA/133 sas: --- Exit sas_scsi_recover_host scsi 0:0:1:0: Direct-Access ATA ST9500620NS CC02 PQ: 0 ANSI: 5 sas: DONE DISCOVERY on port 1, pid:5, result:0 -- Ondrej Zary -- 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 1/1] random: export add_disk_randomness
On Fri, Apr 25, 2014 at 09:49:51AM -0400, Theodore Ts'o wrote: On Fri, Apr 25, 2014 at 12:36:37AM -0700, Christoph Hellwig wrote: This will be needed for pending changes to the scsi midlayer that now calls lower level block APIs, as well as any blk-mq driver that wants to contribute to the random pool. Signed-off-by: Christoph Hellwig h...@lst.de Acked-by: Theodore Ts'o ty...@mit.edu Jens, can you pull this into the block tree for me? -- 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
Attn
Attn Dear; The sum of $4.2 million out of your overdue total sum has been approved for payment through ATM cash card system after all attempts to pay you through bank, and diplomatic courier failed. The approved sum has been programmed into the ATM cash card which will be dispatched to you through your address upon reconfirmation. We have made several attempts to contact you and this is the 3rd and perhaps the last email to you in respect to this matter. Meanwhile, we received a power of attorney from one JOHN GRIMLEY from USA purportedly issued by you asking us to change the fund beneficiary to his name hence we are seeking for your confirmation as soon as possible. To this end, you should Kindly Re-confirm these information’s to Mr Jonathan Peters Through his Private Email peterjonat...@gmail.com (1) Your Full Names:- (2) Address:- (3) Your Phone Numbers:- Yours in Service, Dr. Peters J. E-Mail: peterjonat...@gmail.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
Re: Buffer I/O error after s2ram with usb storage
Hi,
any news on this.
Matthieu CASTET
Le Tue, 22 Apr 2014 16:01:15 +0200,
Matthieu CASTET matthieu.cas...@parrot.com a écrit :
Hi,
while playing with suspend to ram I found a strange behavior with usb
key.
This can be easily reproduced by doing :
- plug a usb key
- start to read the usb key : cat /dev/sdx /dev/null
- go to suspend : echo mem /sys/power/state
- while in suspend, unplug and replug the usb key (simulate usb power
loss for computer that keep power)
- exit suspend
- there is read error on the usb key
Because the power was cut during s2ram, the usb stack reset the device
1.
When new data transfer are done, we got a UNIT_ATTENTION from the
device 2 and IO error are returned to user space application.
After some investigation it seems some (all on the 3 I tested) usb key
report as removable, and scsi layer abort the transfer in case of
UNIT_ATTENTION 3.
The usb storage driver call scsi_report_bus_reset after device reset,
but because of commit dfcf7775 4, we don't ignore unit attention if
sshdr.asc == 0x28 sshdr.ascq == 0x00 (Not-ready to ready).
If dfcf7775 is reverted there is no more Buffer I/O error.
Is that possible to find a way to restore the behavior before dfcf7775
commit (no Buffer I/O error after device reset) after a suspend to ram ?
Matthieu CASTET
PS : the same error happen if sg_reset -b /dev/sdx is used on the
device.
1
[ 117.070255] usb 2-1.4: reset high-speed USB device number 3 using
ehci-pci [...]
[ 117.543922] Restarting tasks ... done.
[ 117.548390] video LNXVIDEO:01: Restoring backlight state
2
[ 117.549179] sd 6:0:0:0: [sdb] Media Changed
[ 117.549184] sd 6:0:0:0: [sdb]
[ 117.549187] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 117.549189] sd 6:0:0:0: [sdb]
[ 117.549191] Sense Key : Unit Attention [current]
[ 117.549195] Info fld=0x0
[ 117.549197] sd 6:0:0:0: [sdb]
[ 117.549201] Add. Sense: Not ready to ready change, medium may have
changed [ 117.549203] sd 6:0:0:0: [sdb] CDB:
[ 117.549205] Read(10): 28 00 00 02 c9 00 00 00 f0 00
[ 117.549212] end_request: I/O error, dev sdb, sector 182528
[ 117.549218] Buffer I/O error on device sdb1, logical block 22560
[ 117.549225] Buffer I/O error on device sdb1, logical block 22561
[ 117.549228] Buffer I/O error on device sdb1, logical block 22562
[ 117.549231] Buffer I/O error on device sdb1, logical block 22563
[ 117.549233] Buffer I/O error on device sdb1, logical block 22564
[ 117.549235] Buffer I/O error on device sdb1, logical block 22565
[ 117.549238] Buffer I/O error on device sdb1, logical block 22566
[ 117.549240] Buffer I/O error on device sdb1, logical block 22567
[ 117.549243] Buffer I/O error on device sdb1, logical block 22568
[ 117.549245] Buffer I/O error on device sdb1, logical block 22569
[ 117.809462] sd 6:0:0:0: [sdb] No Caching mode page found
[ 117.809470] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[ 117.812696] sd 6:0:0:0: [sdb] No Caching mode page found
[ 117.812703] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[ 117.813688] sdb: sdb1
3
case UNIT_ATTENTION:
if (cmd-device-removable) {
/* Detected disc change. Set a bit
* and quietly refuse further access.
*/
cmd-device-changed = 1;
description = Media Changed;
action = ACTION_FAIL;
} else {
/* Must have been a power glitch, or a
* bus reset. Could not have been a
* media change, so we just retry the
* command and see what happens.
*/
action = ACTION_RETRY;
}
4
commit dfcf7775815504d13a1d273073810058caf84b9d
Author: TARUISI Hiroaki taruishi.hir...@jp.fujitsu.com
Date: Thu Aug 11 20:25:20 2011 +0900
[SCSI] Fix out of spec CD-ROM problem with media change
Some CD-ROMs fail to report a media change correctly. The specific
one for this patch simply fails to respond to commands, then gives a
UNIT ATTENTION after being reset which returns ASC/ASCQ 28/00. This
is out of spec behaviour, but add a check in the eat CC/UA on reset
path to catch this case so the CD-ROM will function somewhat properly.
[jejb: fixed up white space and accepted without signoff]
Signed-off-by: James Bottomley jbottom...@parallels.com
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index a4b9cdb..dc6131e 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -293,8 +293,16 @@ static int scsi_check_sense(struct scsi_cmnd *scmd)
* so that we can deal with it there.
*/
if (scmd-device-expecting_cc_ua) {
- scmd-device-expecting_cc_ua = 0;
- return NEEDS_RETRY;
+
Re: two small scsi fixes for 3.15-rc3
On Mon, 2014-04-28 at 11:03 +0200, Christoph Hellwig wrote:
On Fri, Apr 25, 2014 at 08:00:48AM -0700, James Bottomley wrote:
You should have received my git tree emails that they were already in
SCSI fixes ... didn't you? I certainly got a copy.
I've not seen a single reply to the patches either in my inbox or on
linux-scsi.
Well, it might be a bit late to trace what went wrong, but these are the
transfer logs with msgid and remote ack.
Apr 19 13:59:31 bedivere amavis[17271]: (17271-15) Passed CLEAN
{RelayedOpenRelay}, j...@bedivere.hansenpartnership.com -
h...@lst.de,jbottom...@parallels.com,joe.lawre...@stratus.com,
Message-ID: 20140419205930.1dd598ee...@bedivere.hansenpartnership.com,
mail_id: ZmsodClKD9Uy, Hits: -, size: 1796, queued_as: BC8688EE1B6, 663 ms
Apr 19 13:59:33 bedivere postfix/smtp[4861]: BC8688EE1B6: to=h...@lst.de,
relay=verein.lst.de[213.95.11.211]:25, delay=2.6, delays=0.3/0.05/1.9/0.37,
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as E31ED14564)
Apr 19 13:59:31 bedivere amavis[19335]: (19335-15) Passed CLEAN
{RelayedOpenRelay}, j...@bedivere.hansenpartnership.com -
li...@eikelenboom.it,h...@lst.de,jbottom...@parallels.com, Message-ID:
20140419205930.4c52a8ee...@bedivere.hansenpartnership.com, mail_id:
1_YssH8P_WCo, Hits: -, size: 1796, queued_as: D5D558EE213, 473 ms
Apr 19 13:59:33 bedivere postfix/smtp[4865]: D5D558EE213: to=h...@lst.de,
relay=verein.lst.de[213.95.11.211]:25, delay=2.9, delays=0.28/0.14/2.1/0.36,
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 31924145CD)
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
--
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: mvsas: add support for Supermicro AOC-SAS2LP-MV8
Add support for the AOC-SAS2LP-MV8 SAS-2 controller from SuperMicro.
This controller has subdevice id 0x9485 instead of 0x9480, and apparently
this simple patch is the only thing needed to make it work.
# lspci -vn
[...]
03:00.0 0104: 1b4b:9485 (rev 03)
Subsystem: 1b4b:9485
Flags: bus master, fast devsel, latency 0, IRQ 24
Memory at feba (64-bit, non-prefetchable) [size=128K]
Memory at febc (64-bit, non-prefetchable) [size=256K]
Expansion ROM at feb9 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Kernel driver in use: mvsas
Kernel modules: mvsas
Signed-off-by: Jan Kasprzak k...@fi.muni.cz
diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
index 5ff978b..eacee48 100644
--- a/drivers/scsi/mvsas/mv_init.c
+++ b/drivers/scsi/mvsas/mv_init.c
@@ -728,6 +728,15 @@ static struct pci_device_id mvs_pci_table[] = {
.class_mask = 0,
.driver_data= chip_9485,
},
+ {
+ .vendor = PCI_VENDOR_ID_MARVELL_EXT,
+ .device = 0x9485,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = 0x9485,
+ .class = 0,
+ .class_mask = 0,
+ .driver_data= chip_9485,
+ },
{ PCI_VDEVICE(OCZ, 0x1021), chip_9485}, /* OCZ RevoDrive3 */
{ PCI_VDEVICE(OCZ, 0x1022), chip_9485}, /* OCZ RevoDrive3/zDriveR4
(exact model unknown) */
{ PCI_VDEVICE(OCZ, 0x1040), chip_9485}, /* OCZ RevoDrive3/zDriveR4
(exact model unknown) */
--
| Jan Yenya Kasprzak kas at {fi.muni.cz - work | yenya.net - private} |
| New GPG 4096R/A45477D5 - see http://www.fi.muni.cz/~kas/pgp-rollover.txt |
| http://www.fi.muni.cz/~kas/Journal: http://www.fi.muni.cz/~kas/blog/ |
There's clearly a balance between octopus merges are fine and Christ,
that's not an octopus, that's a Cthulhu merge. --Linus Torvalds
--
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 1/1] random: export add_disk_randomness
On 04/28/2014 05:29 AM, Christoph Hellwig wrote: On Fri, Apr 25, 2014 at 09:49:51AM -0400, Theodore Ts'o wrote: On Fri, Apr 25, 2014 at 12:36:37AM -0700, Christoph Hellwig wrote: This will be needed for pending changes to the scsi midlayer that now calls lower level block APIs, as well as any blk-mq driver that wants to contribute to the random pool. Signed-off-by: Christoph Hellwig h...@lst.de Acked-by: Theodore Ts'o ty...@mit.edu Jens, can you pull this into the block tree for me? Yep, I'll add it, thanks. -- 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
[PATCH] scsi_debug: simple short transfer injection
Add an option to only transfer half the data for every n-th command.
Signed-off-by: Christoph Hellwig h...@lst.de
---
drivers/scsi/scsi_debug.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 6de6b1a..5f64dc8 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -130,6 +130,7 @@ static const char * scsi_debug_version_date = 20100324;
#define SCSI_DEBUG_OPT_DIF_ERR 32
#define SCSI_DEBUG_OPT_DIX_ERR 64
#define SCSI_DEBUG_OPT_MAC_TIMEOUT 128
+#define SCSI_DEBUG_OPT_SHORT_TRANSFER 256
/* When every_nth 0 then modulo every_nth commands:
* - a no response is simulated if SCSI_DEBUG_OPT_TIMEOUT is set
* - a RECOVERED_ERROR is simulated on successful read and write
@@ -3583,6 +3584,7 @@ int scsi_debug_queuecommand_lck(struct scsi_cmnd *SCpnt,
done_funct_t done)
int inj_transport = 0;
int inj_dif = 0;
int inj_dix = 0;
+ int inj_short = 0;
int delay_override = 0;
int unmap = 0;
@@ -3628,6 +3630,8 @@ int scsi_debug_queuecommand_lck(struct scsi_cmnd *SCpnt,
done_funct_t done)
inj_dif = 1; /* to reads and writes below */
else if (SCSI_DEBUG_OPT_DIX_ERR scsi_debug_opts)
inj_dix = 1; /* to reads and writes below */
+ else if (SCSI_DEBUG_OPT_SHORT_TRANSFER scsi_debug_opts)
+ inj_short = 1;
}
if (devip-wlun) {
@@ -3744,6 +3748,10 @@ read:
if (scsi_debug_fake_rw)
break;
get_data_transfer_info(cmd, lba, num, ei_lba);
+
+ if (inj_short)
+ num /= 2;
+
errsts = resp_read(SCpnt, lba, num, devip, ei_lba);
if (inj_recovered (0 == errsts)) {
mk_sense_buffer(devip, RECOVERED_ERROR,
--
1.7.10.4
--
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: 3.2.57 regression: isci driver broken: Unable to reset I T nexus?
On Monday 28 April 2014 17:50:29 Jiang, Dave wrote: On Mon, 2014-04-28 at 13:03 +0200, Ondrej Zary wrote: Hello, just upgraded a server running 3.2.54-2 to 3.2.57-3 (Debian Wheezy) and it does not boot anymore because of isci driver breakage. I would not run anything less than 3.8 for the isci controller. 3.2 is VERY old for that particular driver and likely very unstable. The product version of that driver plus libsas started with 3.8. Also I'm concerned that you aren't using the platform OEM parameters. You need to turn your OROM or EFI driver on for the SAS controller. It's a Cisco UCS C22 M3 server with a crappy LSI fakeraid that cannot even be disabled. It was a pain to make it boot properly - had to use dmraid. But it has been working fine since then (2012). Until now. I guess that it could be caused by the following commit but haven't tested it: commit 584ec12265192bf49dfa270d517380f6723a6956 Author: Dan Williams dan.j.willi...@intel.com Date: Thu Feb 6 12:23:01 2014 -0800 A (partial) log transcription: sas: DOING DISCOVERY on port 0, pid:5 sas: Enter sas_scsi_recover_host ata1: sas eh calling libata port error handler sas: sas_ata_hard_reset: Unable to reset I T nexus? sas: sas_ata_hard_reset: Found ATA device. sas: sas_ata_hard_reset: Unable to soft reset sas: sas_ata_hard_reset: Found ATA device. ata1: reset failed (errno=-11), retrying in 10 secs sas: sas_ata_hard_reset: Unable to reset I T nexus? sas: sas_ata_hard_reset: Found ATA device. sas: sas_ata_hard_reset: Unable to soft reset sas: sas_ata_hard_reset: Found ATA device. ata1: reset failed (errno=-11), retrying in 35 secs ata1: reset failed, giving up sas: --- Exit sas_scsi_recover_host sas: DONE DISCOVERY on port 0, pid: 5, result:0 sas: phy-0:1 added to port-0:1, phy_mask:0x2 (5fcf0002) sas: DOING DISCOVERY on port 1, pid:5 sas: Enter sas_scsi_recover_host ata1: sas eh calling libata port error handler sas: sas_ata_hard_reset: Unable to reset I T nexus? sas: sas_ata_hard_reset: Found ATA device. sas: sas_ata_hard_reset: Unable to soft reset sas: sas_ata_hard_reset: Found ATA device. ata2: reset failed (errno=-11), retrying in 10 secs sas: sas_ata_hard_reset: Unable to reset I T nexus? sas: sas_ata_hard_reset: Found ATA device. sas: sas_ata_hard_reset: Unable to soft reset sas: sas_ata_hard_reset: Found ATA device. ata2: reset failed (errno=-11), retrying in 35 secs ata2: reset failed, giving up It should look like this (v3.2.54-2): isci: Intel(R) C600 SAS Controller Driver - version 1.0.0 isci :03:00.0: driver configured for rev: 6 silicon isci :03:00.0: firmware: agent loaded isci/isci_firmware.bin into memory isci :03:00.0: OEM SAS parameters (version: 1.3) loaded (firmware) isci :03:00.0: setting latency timer to 64 scsi0 : isci scsi1 : isci isci :03:00.0: irq 81 for MSI/MSI-X isci :03:00.0: irq 82 for MSI/MSI-X isci :03:00.0: irq 83 for MSI/MSI-X isci :03:00.0: irq 84 for MSI/MSI-X sas: phy-0:0 added to port-0:0, phy_mask:0x1 (5fcf0001) sas: DOING DISCOVERY on port 0, pid:5 sas: Enter sas_scsi_recover_host ata1: sas eh calling libata port error handler sas: sas_ata_hard_reset: Found ATA device. ata1.00: ATA-8: ST9500620NS, CC02, max UDMA/133 ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32) ata1.00: configured for UDMA/133 sas: --- Exit sas_scsi_recover_host scsi 0:0:0:0: Direct-Access ATA ST9500620NS CC02 PQ: 0 ANSI: 5 sas: DONE DISCOVERY on port 0, pid:5, result:0 sas: phy-0:1 added to port-0:1, phy_mask:0x2 (5fcf0002) sas: DOING DISCOVERY on port 1, pid:5 sas: Enter sas_scsi_recover_host ata1: sas eh calling libata port error handler ata2: sas eh calling libata port error handler sas: sas_ata_hard_reset: Found ATA device. ata2.00: ATA-8: ST9500620NS, CC02, max UDMA/133 ata2.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32) ata2.00: configured for UDMA/133 sas: --- Exit sas_scsi_recover_host scsi 0:0:1:0: Direct-Access ATA ST9500620NS CC02 PQ: 0 ANSI: 5 sas: DONE DISCOVERY on port 1, pid:5, result:0 -- Ondrej Zary -- 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: 3.2.57 regression: isci driver broken: Unable to reset I T nexus?
On Monday 28 April 2014 18:51:44 Jiang, Dave wrote: On Mon, 2014-04-28 at 16:28 +, Ondrej Zary wrote: On Monday 28 April 2014 17:50:29 Jiang, Dave wrote: On Mon, 2014-04-28 at 13:03 +0200, Ondrej Zary wrote: Hello, just upgraded a server running 3.2.54-2 to 3.2.57-3 (Debian Wheezy) and it does not boot anymore because of isci driver breakage. I would not run anything less than 3.8 for the isci controller. 3.2 is VERY old for that particular driver and likely very unstable. The product version of that driver plus libsas started with 3.8. Also I'm concerned that you aren't using the platform OEM parameters. You need to turn your OROM or EFI driver on for the SAS controller. It's a Cisco UCS C22 M3 server with a crappy LSI fakeraid that cannot even be disabled. It was a pain to make it boot properly - had to use dmraid. But it has been working fine since then (2012). Until now. Yes but just because it has been working doesn't mean it is a good idea to run unstable code You need the driver updates and the libsas updates for it to function properly. Does this fail on 3.14? If it is that patch I have a feeling it may be interacting badly with whatever is was in 3.2 libsas that may not be a problem with latest kernels It is odd to see all those hard resets however Did you have them when it was working for you? Didn't know that it was unstable - it worked with no problems, better than some products marked as stable :) 3.13 works fine - I've installed it from wheezy-backports to work-around the bug. The log from working 3.2.54 is below (at the end) - there's one reset for each port. I guess that it could be caused by the following commit but haven't tested it: commit 584ec12265192bf49dfa270d517380f6723a6956 Author: Dan Williams dan.j.willi...@intel.com Date: Thu Feb 6 12:23:01 2014 -0800 A (partial) log transcription: sas: DOING DISCOVERY on port 0, pid:5 sas: Enter sas_scsi_recover_host ata1: sas eh calling libata port error handler sas: sas_ata_hard_reset: Unable to reset I T nexus? sas: sas_ata_hard_reset: Found ATA device. sas: sas_ata_hard_reset: Unable to soft reset sas: sas_ata_hard_reset: Found ATA device. ata1: reset failed (errno=-11), retrying in 10 secs sas: sas_ata_hard_reset: Unable to reset I T nexus? sas: sas_ata_hard_reset: Found ATA device. sas: sas_ata_hard_reset: Unable to soft reset sas: sas_ata_hard_reset: Found ATA device. ata1: reset failed (errno=-11), retrying in 35 secs ata1: reset failed, giving up sas: --- Exit sas_scsi_recover_host sas: DONE DISCOVERY on port 0, pid: 5, result:0 sas: phy-0:1 added to port-0:1, phy_mask:0x2 (5fcf0002) sas: DOING DISCOVERY on port 1, pid:5 sas: Enter sas_scsi_recover_host ata1: sas eh calling libata port error handler sas: sas_ata_hard_reset: Unable to reset I T nexus? sas: sas_ata_hard_reset: Found ATA device. sas: sas_ata_hard_reset: Unable to soft reset sas: sas_ata_hard_reset: Found ATA device. ata2: reset failed (errno=-11), retrying in 10 secs sas: sas_ata_hard_reset: Unable to reset I T nexus? sas: sas_ata_hard_reset: Found ATA device. sas: sas_ata_hard_reset: Unable to soft reset sas: sas_ata_hard_reset: Found ATA device. ata2: reset failed (errno=-11), retrying in 35 secs ata2: reset failed, giving up It should look like this (v3.2.54-2): isci: Intel(R) C600 SAS Controller Driver - version 1.0.0 isci :03:00.0: driver configured for rev: 6 silicon isci :03:00.0: firmware: agent loaded isci/isci_firmware.bin into memory isci :03:00.0: OEM SAS parameters (version: 1.3) loaded (firmware) isci :03:00.0: setting latency timer to 64 scsi0 : isci scsi1 : isci isci :03:00.0: irq 81 for MSI/MSI-X isci :03:00.0: irq 82 for MSI/MSI-X isci :03:00.0: irq 83 for MSI/MSI-X isci :03:00.0: irq 84 for MSI/MSI-X sas: phy-0:0 added to port-0:0, phy_mask:0x1 (5fcf0001) sas: DOING DISCOVERY on port 0, pid:5 sas: Enter sas_scsi_recover_host ata1: sas eh calling libata port error handler sas: sas_ata_hard_reset: Found ATA device. ata1.00: ATA-8: ST9500620NS, CC02, max UDMA/133 ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32) ata1.00: configured for UDMA/133 sas: --- Exit sas_scsi_recover_host scsi 0:0:0:0: Direct-Access ATA ST9500620NS CC02 PQ: 0 ANSI: 5 sas: DONE DISCOVERY on port 0, pid:5, result:0 sas: phy-0:1 added to port-0:1, phy_mask:0x2 (5fcf0002) sas: DOING DISCOVERY on port 1, pid:5 sas: Enter sas_scsi_recover_host ata1: sas eh calling libata port error handler ata2: sas eh calling libata port error handler sas: sas_ata_hard_reset: Found ATA device. ata2.00: ATA-8: ST9500620NS, CC02, max UDMA/133 ata2.00: 976773168 sectors, multi 0: LBA48
LOAN
Dear valued customer, Do you need an urgent loan to pay of your bills, invest more on your business, if yes PREMIUM CAPITAL LOAN offer loan at 3% interest rate. We are fast and reliable when it comes to loan lending contact email: premiumcapitall...@hotmail.co.uk for more information. Contact email: premiumcapitall...@hotmail.co.uk -- 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: 3.2.57 regression: isci driver broken: Unable to reset I T nexus?
[ adding Ben ] On Mon, Apr 28, 2014 at 10:22 AM, Ondrej Zary li...@rainbow-software.org wrote: On Monday 28 April 2014 18:51:44 Jiang, Dave wrote: On Mon, 2014-04-28 at 16:28 +, Ondrej Zary wrote: On Monday 28 April 2014 17:50:29 Jiang, Dave wrote: On Mon, 2014-04-28 at 13:03 +0200, Ondrej Zary wrote: Hello, just upgraded a server running 3.2.54-2 to 3.2.57-3 (Debian Wheezy) and it does not boot anymore because of isci driver breakage. I would not run anything less than 3.8 for the isci controller. 3.2 is VERY old for that particular driver and likely very unstable. The product version of that driver plus libsas started with 3.8. Also I'm concerned that you aren't using the platform OEM parameters. You need to turn your OROM or EFI driver on for the SAS controller. It's a Cisco UCS C22 M3 server with a crappy LSI fakeraid that cannot even be disabled. It was a pain to make it boot properly - had to use dmraid. But it has been working fine since then (2012). Until now. Yes but just because it has been working doesn't mean it is a good idea to run unstable code You need the driver updates and the libsas updates for it to function properly. Does this fail on 3.14? If it is that patch I have a feeling it may be interacting badly with whatever is was in 3.2 libsas that may not be a problem with latest kernels It is odd to see all those hard resets however Did you have them when it was working for you? Didn't know that it was unstable - it worked with no problems, better than some products marked as stable :) 3.13 works fine - I've installed it from wheezy-backports to work-around the bug. The log from working 3.2.54 is below (at the end) - there's one reset for each port. I think the right answer for 3.2 is to drop commit 584ec1226519 isci: fix reset timeout handling. libsas and its libata interaction went through significant overhaul after 3.2 so it's not surprising that a change to reset handling regresses like this. Ideally there would be a backport of latest libsas available for 3.2, but no one to my knowledge is working on that. -- Dan -- 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] SCSI fixes for 3.15-rc3
Il 25/04/2014 16:59, James Bottomley ha scritto:
This is a set of seven fixes, three (hpsa) and free'd command references
correcting bugs in the last round of updates and the remaining four
correcting problems within the SCSI error handler that was causing a
deadlock within USB.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Alan Stern (1):
Fix command result state propagation
Christoph Hellwig (2):
don't reference freed command in scsi_prep_return
don't reference freed command in scsi_init_sgtable
Hannes Reinecke (1):
Fix USB deadlock caused by SCSI error handling
James Bottomley (2):
More USB deadlock fixes
Fix spurious request sense in error handling
scame...@beardog.cce.hp.com (1):
hpsa: fix NULL dereference in hpsa_put_ctlr_into_performant_mode()
And the diffstat:
drivers/scsi/hpsa.c | 8
drivers/scsi/scsi_error.c | 12
drivers/scsi/scsi_lib.c | 6 --
3 files changed, 20 insertions(+), 6 deletions(-)
With full diffs below.
James,
can you queue http://article.gmane.org/gmane.linux.kernel/1682301/raw
please?
Thanks,
Paolo
James
---
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 8cf4a0c..9a6e4a2 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -7463,6 +7463,10 @@ static void hpsa_put_ctlr_into_performant_mode(struct
ctlr_info *h)
if (hpsa_simple_mode)
return;
+ trans_support = readl((h-cfgtable-TransportSupport));
+ if (!(trans_support PERFORMANT_MODE))
+ return;
+
/* Check for I/O accelerator mode support */
if (trans_support CFGTBL_Trans_io_accel1) {
transMethod |= CFGTBL_Trans_io_accel1 |
@@ -7479,10 +7483,6 @@ static void hpsa_put_ctlr_into_performant_mode(struct
ctlr_info *h)
}
/* TODO, check that this next line h-nreply_queues is correct */
- trans_support = readl((h-cfgtable-TransportSupport));
- if (!(trans_support PERFORMANT_MODE))
- return;
-
h-nreply_queues = h-msix_vector 0 ? h-msix_vector : 1;
hpsa_get_max_perf_mode_cmds(h);
/* Performant mode ring buffer and supporting data structures */
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 771c16b..f17aa7a 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -189,6 +189,7 @@ scsi_abort_command(struct scsi_cmnd *scmd)
/*
* Retry after abort failed, escalate to next level.
*/
+ scmd-eh_eflags = ~SCSI_EH_ABORT_SCHEDULED;
SCSI_LOG_ERROR_RECOVERY(3,
scmd_printk(KERN_INFO, scmd,
scmd %p previous abort failed\n, scmd));
@@ -920,10 +921,12 @@ void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct
scsi_eh_save *ses,
ses-prot_op = scmd-prot_op;
scmd-prot_op = SCSI_PROT_NORMAL;
+ scmd-eh_eflags = 0;
scmd-cmnd = ses-eh_cmnd;
memset(scmd-cmnd, 0, BLK_MAX_CDB);
memset(scmd-sdb, 0, sizeof(scmd-sdb));
scmd-request-next_rq = NULL;
+ scmd-result = 0;
if (sense_bytes) {
scmd-sdb.length = min_t(unsigned, SCSI_SENSE_BUFFERSIZE,
@@ -1157,6 +1160,15 @@ int scsi_eh_get_sense(struct list_head *work_q,
__func__));
break;
}
+ if (status_byte(scmd-result) != CHECK_CONDITION)
+ /*
+* don't request sense if there's no check condition
+* status because the error we're processing isn't one
+* that has a sense code (and some devices get
+* confused by sense requests out of the blue)
+*/
+ continue;
+
SCSI_LOG_ERROR_RECOVERY(2, scmd_printk(KERN_INFO, scmd,
%s: requesting sense\n,
current-comm));
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 65a123d..9db097a 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -137,6 +137,7 @@ static void __scsi_queue_insert(struct scsi_cmnd *cmd, int
reason, int unbusy)
* lock such that the kblockd_schedule_work() call happens
* before blk_cleanup_queue() finishes.
*/
+ cmd-result = 0;
spin_lock_irqsave(q-queue_lock, flags);
blk_requeue_request(q, cmd-request);
kblockd_schedule_work(q, device-requeue_work);
@@ -1044,6 +1045,7 @@ static int scsi_init_sgtable(struct request *req, struct
scsi_data_buffer *sdb,
*/
int scsi_init_io(struct scsi_cmnd *cmd, gfp_t gfp_mask)
{
+ struct scsi_device *sdev = cmd-device;
struct request *rq =
Re: [PATCH v18 3/4] ata: Add APM X-Gene SoC AHCI SATA host controller driver
Hi Kishon/Felipe, This patch adds support for the APM X-Gene SoC AHCI SATA host controller driver. It requires the corresponding APM X-Gene SoC PHY driver. This initial version only supports Gen3 speed. This version seems workable, thanks for the quick follow-up. The comment about Gen3 speed above reminds me that you took some shortcuts to get here and you removed support for some features as well as some bug workarounds in the process. I'm guessing some of them won't be necessary because they are only for prototype hardware or for early boot loader versions that don't yet set up the hardware right, but others actually need to come back. That is usually a good approach, but I'd also like to make sure we can deal with them nicely when you have to add them back later, and don't have to add ugly extensions to the DT binding to support the old dtb files. Can you list (also in the changelog) the parts of the driver that you have taken out for now and that you expect to add back at later stage? I think that would be helpful for perspective. Here is an list of patches that we will be preparing for once the basic driver is completed. Do you want me to re-generate the patch change log with this info? 1. Support for Gen1/Gen2/Gen3 Solution: The simplest solution is to have the PHY framework support setting the desire speed. I had argued with the TI folks but they are reluctant to add this function to the framework. They argued that this is still not generic enough. I will start the discussion again later on. The other possibility (but not sure if this is doable) is to have the PHY init function to be smarter and do the necessary operation assuming the underlying PHY is capable in detecting the link up speed. I will need to check the spec of this. In order for the X-Gene SATA PHY to support SATA Gen1 and Gen2 speed, we need an method to instruct the underlying PHY driver to switch to an specified setting after link up. For this errata, Suman Tripathi had submitted the patch [1]. It is not possible to hide this within the PHY driver. Each instance of the PHY driver controls two ports. By calling the exit function and then init function, it will affect the other ports - which is not the correct behavior. At this point, we don't see any solution besides introduce an PHY framework function set_rate. Can you let us know if this solution is acceptable? [1] https://lkml.org/lkml/2014/4/18/491 -Loc -- 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 v18 3/4] ata: Add APM X-Gene SoC AHCI SATA host controller driver
On Mon, Apr 28, 2014 at 04:12:02PM -0700, Loc Ho wrote: Hi Kishon/Felipe, This patch adds support for the APM X-Gene SoC AHCI SATA host controller driver. It requires the corresponding APM X-Gene SoC PHY driver. This initial version only supports Gen3 speed. This version seems workable, thanks for the quick follow-up. The comment about Gen3 speed above reminds me that you took some shortcuts to get here and you removed support for some features as well as some bug workarounds in the process. I'm guessing some of them won't be necessary because they are only for prototype hardware or for early boot loader versions that don't yet set up the hardware right, but others actually need to come back. That is usually a good approach, but I'd also like to make sure we can deal with them nicely when you have to add them back later, and don't have to add ugly extensions to the DT binding to support the old dtb files. Can you list (also in the changelog) the parts of the driver that you have taken out for now and that you expect to add back at later stage? I think that would be helpful for perspective. Here is an list of patches that we will be preparing for once the basic driver is completed. Do you want me to re-generate the patch change log with this info? 1. Support for Gen1/Gen2/Gen3 Solution: The simplest solution is to have the PHY framework support setting the desire speed. I had argued with the TI folks but they are reluctant to add this function to the framework. They argued that this is still not generic enough. I will start the discussion again later on. The other possibility (but not sure if this is doable) is to have the PHY init function to be smarter and do the necessary operation assuming the underlying PHY is capable in detecting the link up speed. I will need to check the spec of this. In order for the X-Gene SATA PHY to support SATA Gen1 and Gen2 speed, we need an method to instruct the underlying PHY driver to switch to an specified setting after link up. For this errata, Suman Tripathi had submitted the patch [1]. It is not possible to hide this within the PHY driver. Each instance of the PHY driver controls two ports. By calling the exit function and then init function, it will affect the other ports - which is not the correct behavior. At this point, we don't see any solution besides introduce an PHY framework function set_rate. Can you let us know if this solution is acceptable? [1] https://lkml.org/lkml/2014/4/18/491 that 'lane' argument isn't acceptable. If one PHY talks to two Links, your PHY driver should register two providers, then the lane argument can be ignored. Rate can be reused for different things depending on the underlying Bus; in case of USB, it could be for switching among Superspeed10/Superspeed5Highspeed; or 1Gbit/100Mbit switch on Networking interfaces; or Gen1/2/3 selection for PCI controllers and so on. The only thing I can't find a way to abstract is that 'lane' argument which isn't even specific to SATA, it's particular to how you guys wrote your driver. Should you have one PHY per SATA link, you wouldn't have added that 'lane' argument at all. cheers -- balbi signature.asc Description: Digital signature
RE: PATCH: mvsas: add support for Supermicro AOC-SAS2LP-MV8
Hi, Jan
I think below change may be better:
{ PCI_VDEVICE(MARVELL_EXT, 0x9485), chip_9485 },
Add support for the AOC-SAS2LP-MV8 SAS-2 controller from SuperMicro.
This controller has subdevice id 0x9485 instead of 0x9480, and apparently
this simple patch is the only thing needed to make it work.
# lspci -vn
[...]
03:00.0 0104: 1b4b:9485 (rev 03)
Subsystem: 1b4b:9485
Flags: bus master, fast devsel, latency 0, IRQ 24
Memory at feba (64-bit, non-prefetchable) [size=128K]
Memory at febc (64-bit, non-prefetchable) [size=256K]
Expansion ROM at feb9 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Kernel driver in use: mvsas
Kernel modules: mvsas
Signed-off-by: Jan Kasprzak k...@fi.muni.cz
diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
index 5ff978b..eacee48 100644
--- a/drivers/scsi/mvsas/mv_init.c
+++ b/drivers/scsi/mvsas/mv_init.c
@@ -728,6 +728,15 @@ static struct pci_device_id mvs_pci_table[] = {
.class_mask = 0,
.driver_data= chip_9485,
},
+ {
+ .vendor = PCI_VENDOR_ID_MARVELL_EXT,
+ .device = 0x9485,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = 0x9485,
+ .class = 0,
+ .class_mask = 0,
+ .driver_data= chip_9485,
+ },
{ PCI_VDEVICE(OCZ, 0x1021), chip_9485}, /* OCZ RevoDrive3 */
{ PCI_VDEVICE(OCZ, 0x1022), chip_9485}, /* OCZ RevoDrive3/zDriveR4
(exact
model unknown) */
{ PCI_VDEVICE(OCZ, 0x1040), chip_9485}, /* OCZ RevoDrive3/zDriveR4
(exact
model unknown) */
--
| Jan Yenya Kasprzak kas at {fi.muni.cz - work | yenya.net - private} |
| New GPG 4096R/A45477D5 - see http://www.fi.muni.cz/~kas/pgp-rollover.txt |
| http://www.fi.muni.cz/~kas/Journal: http://www.fi.muni.cz/~kas/blog/
|
There's clearly a balance between octopus merges are fine and Christ,
that's not an octopus, that's a Cthulhu merge. --Linus Torvalds
--
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: mvsas: add support for Supermicro AOC-SAS2LP-MV8
On Mon, 2014-04-28 at 18:16 -0700, Xiangliang Yu wrote:
Hi, Jan
I think below change may be better:
{ PCI_VDEVICE(MARVELL_EXT, 0x9485), chip_9485 },
Ben Hutchings already submitted a patch for this twice, which I cc'd you
on:
http://marc.info/?t=13927720393
will you ack it? PCI_VDEVICE() is a sort of take it or leave it macro.
It's not important and it will look untidy and a bit confusing having a
mix of open coding and macros, so I'd say convert all or none.
James
Add support for the AOC-SAS2LP-MV8 SAS-2 controller from SuperMicro.
This controller has subdevice id 0x9485 instead of 0x9480, and apparently
this simple patch is the only thing needed to make it work.
# lspci -vn
[...]
03:00.0 0104: 1b4b:9485 (rev 03)
Subsystem: 1b4b:9485
Flags: bus master, fast devsel, latency 0, IRQ 24
Memory at feba (64-bit, non-prefetchable) [size=128K]
Memory at febc (64-bit, non-prefetchable) [size=256K]
Expansion ROM at feb9 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Kernel driver in use: mvsas
Kernel modules: mvsas
Signed-off-by: Jan Kasprzak k...@fi.muni.cz
diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
index 5ff978b..eacee48 100644
--- a/drivers/scsi/mvsas/mv_init.c
+++ b/drivers/scsi/mvsas/mv_init.c
@@ -728,6 +728,15 @@ static struct pci_device_id mvs_pci_table[] = {
.class_mask = 0,
.driver_data= chip_9485,
},
+ {
+ .vendor = PCI_VENDOR_ID_MARVELL_EXT,
+ .device = 0x9485,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = 0x9485,
+ .class = 0,
+ .class_mask = 0,
+ .driver_data= chip_9485,
+ },
{ PCI_VDEVICE(OCZ, 0x1021), chip_9485}, /* OCZ RevoDrive3 */
{ PCI_VDEVICE(OCZ, 0x1022), chip_9485}, /* OCZ RevoDrive3/zDriveR4
(exact
model unknown) */
{ PCI_VDEVICE(OCZ, 0x1040), chip_9485}, /* OCZ RevoDrive3/zDriveR4
(exact
model unknown) */
--
| Jan Yenya Kasprzak kas at {fi.muni.cz - work | yenya.net - private} |
| New GPG 4096R/A45477D5 - see http://www.fi.muni.cz/~kas/pgp-rollover.txt |
| http://www.fi.muni.cz/~kas/Journal: http://www.fi.muni.cz/~kas/blog/
|
There's clearly a balance between octopus merges are fine and Christ,
that's not an octopus, that's a Cthulhu merge. --Linus Torvalds
--
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
--
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
On Sat, 26 Apr 2014, James Bottomley wrote: OK, so this is a pretty big change to an unmaintained driver. I'll take it if you're willing to maintain the driver afterwards ... in which case I need another patch to add you to the MAINTAINERS file. Sure, I'm happy to support these patches and future work I plan to do on the driver. What additional responsibilities would come with adding my name the MAINTAINERS file? Perhaps Michael and Sam would be interested in sharing the role, for atari and sun3 NCR5380 drivers (?) I only have hardware to test mac_scsi but I can obtain a Domex DMX3191D PCI card on ebay. -- -- 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: mvsas: add support for Supermicro AOC-SAS2LP-MV8
Ben Hutchings already submitted a patch for this twice, which I cc'd you
on:
http://marc.info/?t=13927720393
will you ack it? PCI_VDEVICE() is a sort of take it or leave it macro.
It's not important and it will look untidy and a bit confusing having a
mix of open coding and macros, so I'd say convert all or none.
Using open coding because PCI_VENDOR_ID_MARVELL_EXT was undefined before.
Now, we should use the macros instead of open coding.
Add support for the AOC-SAS2LP-MV8 SAS-2 controller from SuperMicro.
This controller has subdevice id 0x9485 instead of 0x9480, and apparently
this simple patch is the only thing needed to make it work.
# lspci -vn
[...]
03:00.0 0104: 1b4b:9485 (rev 03)
Subsystem: 1b4b:9485
Flags: bus master, fast devsel, latency 0, IRQ 24
Memory at feba (64-bit, non-prefetchable) [size=128K]
Memory at febc (64-bit, non-prefetchable) [size=256K]
Expansion ROM at feb9 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Kernel driver in use: mvsas
Kernel modules: mvsas
Signed-off-by: Jan Kasprzak k...@fi.muni.cz
diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
index 5ff978b..eacee48 100644
--- a/drivers/scsi/mvsas/mv_init.c
+++ b/drivers/scsi/mvsas/mv_init.c
@@ -728,6 +728,15 @@ static struct pci_device_id mvs_pci_table[] = {
.class_mask = 0,
.driver_data= chip_9485,
},
+ {
+ .vendor = PCI_VENDOR_ID_MARVELL_EXT,
+ .device = 0x9485,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = 0x9485,
+ .class = 0,
+ .class_mask = 0,
+ .driver_data= chip_9485,
+ },
{ PCI_VDEVICE(OCZ, 0x1021), chip_9485}, /* OCZ RevoDrive3 */
{ PCI_VDEVICE(OCZ, 0x1022), chip_9485}, /* OCZ RevoDrive3/zDriveR4
(exact
model unknown) */
{ PCI_VDEVICE(OCZ, 0x1040), chip_9485}, /* OCZ RevoDrive3/zDriveR4
(exact
model unknown) */
--
| Jan Yenya Kasprzak kas at {fi.muni.cz - work | yenya.net - private}
|
| New GPG 4096R/A45477D5 - see http://www.fi.muni.cz/~kas/pgp-rollover.txt
|
| http://www.fi.muni.cz/~kas/Journal:
http://www.fi.muni.cz/~kas/blog/
|
There's clearly a balance between octopus merges are fine and Christ,
that's not an octopus, that's a Cthulhu merge. --Linus Torvalds
--
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
--
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: mvsas: add support for Supermicro AOC-SAS2LP-MV8
Ben Hutchings already submitted a patch for this twice, which I cc'd you on: http://marc.info/?t=13927720393 will you ack it? I can't find this mail in my mail box. -- 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
Finn, On Tue, Apr 29, 2014 at 2:22 PM, Finn Thain fth...@telegraphics.com.au wrote: On Sat, 26 Apr 2014, James Bottomley wrote: OK, so this is a pretty big change to an unmaintained driver. I'll take it if you're willing to maintain the driver afterwards ... in which case I need another patch to add you to the MAINTAINERS file. Sure, I'm happy to support these patches and future work I plan to do on the driver. What additional responsibilities would come with adding my name the MAINTAINERS file? Perhaps Michael and Sam would be interested in sharing the role, for atari and sun3 NCR5380 drivers (?) If you insist ... (kidding - Im OK with it if James thinks it's worth it) Cheers, Michael I only have hardware to test mac_scsi but I can obtain a Domex DMX3191D PCI card on ebay. -- -- 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] scsi_debug: simple short transfer injection
On 14-04-28 11:58 AM, Christoph Hellwig wrote:
Add an option to only transfer half the data for every n-th command.
Signed-off-by: Christoph Hellwig h...@lst.de
Acked-by: Douglas Gilbert dgilb...@interlog.com
---
drivers/scsi/scsi_debug.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 6de6b1a..5f64dc8 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -130,6 +130,7 @@ static const char * scsi_debug_version_date = 20100324;
#define SCSI_DEBUG_OPT_DIF_ERR 32
#define SCSI_DEBUG_OPT_DIX_ERR 64
#define SCSI_DEBUG_OPT_MAC_TIMEOUT 128
+#define SCSI_DEBUG_OPT_SHORT_TRANSFER 256
/* When every_nth 0 then modulo every_nth commands:
* - a no response is simulated if SCSI_DEBUG_OPT_TIMEOUT is set
* - a RECOVERED_ERROR is simulated on successful read and write
@@ -3583,6 +3584,7 @@ int scsi_debug_queuecommand_lck(struct scsi_cmnd *SCpnt,
done_funct_t done)
int inj_transport = 0;
int inj_dif = 0;
int inj_dix = 0;
+ int inj_short = 0;
int delay_override = 0;
int unmap = 0;
@@ -3628,6 +3630,8 @@ int scsi_debug_queuecommand_lck(struct scsi_cmnd *SCpnt,
done_funct_t done)
inj_dif = 1; /* to reads and writes below */
else if (SCSI_DEBUG_OPT_DIX_ERR scsi_debug_opts)
inj_dix = 1; /* to reads and writes below */
+ else if (SCSI_DEBUG_OPT_SHORT_TRANSFER scsi_debug_opts)
+ inj_short = 1;
}
if (devip-wlun) {
@@ -3744,6 +3748,10 @@ read:
if (scsi_debug_fake_rw)
break;
get_data_transfer_info(cmd, lba, num, ei_lba);
+
+ if (inj_short)
+ num /= 2;
+
errsts = resp_read(SCpnt, lba, num, devip, ei_lba);
if (inj_recovered (0 == errsts)) {
mk_sense_buffer(devip, RECOVERED_ERROR,
--
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
Andere Länder haben die besseren Ban ken und die besseren Konditionen für Kr edit e
Hallo, ich habe eine gute Nachricht für Sie ...
wie lange wollen Sie noch bei Ihrer Hausbank um Ge ld betteln?
Gehen Sie doch dorthin, wo man Sie als Kunden noch anständig behandelt.
Auch bei schlechter Auskunft und bereits von Ihrer eigenen Hausbank abgelehntem
Antrag können wir Ihnen ein Darlehen vermitteln zu günstigen Konditionen (zum
Beispiel ab 3,2% für Selbständige, ab 1,8% Zinsen p.a. für Häuslebauer, ab 3,2%
für Privat.
Durch die extrem langen Laufzeiten von 10 bzw. 20 Jahren belastet Sie die mtl.
Zahlung nicht sonderlich.
Unsere Kooperationspartner sind mehrere Banken, und wir kümmern uns um alle
Details.
Also ideal für Jungunternehmer, Angestellte und Pensionäre.
So kommen Sie zum NeuKredit im Eiltempo.
Wenn Sie neugierig geworden sind, dann geht es hier weiter ...:
DIRECTINTERCREDIT und ergänzen Sie
co m
Holen Sie sich Ihren frischen Kredit dort, wo die Geldspeicher voll sind, die
Zinsen unglaublich niedrig und die Laufzeiten lang sind.
Bis bald
Daniel Schulz
Mitarbeiter im support
Sie haben diese Nachricht bekommen, weil wir Ihre Registrierung von einem
Drittanbieter erhalten haben. Wenn Sie sich aus unserer Liste löschen wollen,
dann rufen Sie unsere Seite auf. Den Schalter finden Sie in der Fußnavigation.
N�r��yb�X��ǧv�^�){.n�+{{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
