Re: [PATCH 06/23] qla2xxx: Update the FTP site references in the driver sources.
Giridhar Malavali wrote: From: Giridhar Malavali giridhar.malav...@qlogic.com Signed-off-by: Giridhar Malavali giridhar.malav...@qlogic.com Signed-off-by: Saurav Kashyap saurav.kash...@qlogic.com --- drivers/scsi/qla2xxx/qla_init.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c index a581c85..bbf5688 100644 --- a/drivers/scsi/qla2xxx/qla_init.c +++ b/drivers/scsi/qla2xxx/qla_init.c @@ -5054,7 +5054,7 @@ qla24xx_load_risc_flash(scsi_qla_host_t *vha, uint32_t *srisc_addr, return rval; } -#define QLA_FW_URL ftp://ftp.qlogic.com/outgoing/linux/firmware/; +#define QLA_FW_URL http://ldriver.qlogic.com/firmware/; int qla2x00_load_risc(scsi_qla_host_t *vha, uint32_t *srisc_addr) -- qla2xxx/Kconfig should also be changed: Firmware images can be retrieved from: ftp://ftp.qlogic.com/outgoing/linux/firmware/ FYI, they are also included in linux-firmware. -- 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: [RESEND PATCH] scsi: make struct scsi_varlen_cdb_hdr packed
Hi James,
On 11/10/12 15:10, James Hogan wrote:
On 11/10/12 13:58, James Bottomley wrote:
On Thu, 2012-10-11 at 12:32 +0100, James Hogan wrote:
On 11/10/12 11:24, James Bottomley wrote:
On Thu, 2012-10-11 at 10:15 +0100, James Hogan wrote:
The struct scsi_varlen_cdb_hdr is expected to be exactly 10 bytes when
used in struct osd_cdb_head, but it isn't marked as packed. Some
architectures will round the struct size up which triggers BUILD_BUG_ON
compile errors in osd_initiator.c when the outer structs are unexpected
sizes. This is fixed by marking struct scsi_varlen_cdb_hdr as __packed.
What actual problem have you encountered? The structure is {u8[8], u16}
which is naturally packed on every architecture I know about. I've even
built osd_initiator without problem on parisc, which has some of the
most rigid alignment rules I've seen.
Hi James,
The alignment is fine (the offset of the u16 is 8 bytes), but
unfortunately with the metag port of gcc, sizeof(struct
scsi_varlen_cdb_hdr) is rounded up to a 4 byte boundary (even though the
largest data member alignment is only 2 bytes), which is 12 bytes
instead of 10.
That sounds to be a bug in your compiler ... it shouldn't be rounding up
structure sizes if the structure can fit in 10 bytes. This isn't
happening in any other architecture that I know of (otherwise we'd have
had a reported build break).
This was my initial thought, and I share your feeling that this isn't
ideal compiler behaviour, however it's pretty much set in stone as part
of our ABI now. Having talked to one of our compiler folk about it
here's what he had to say:
In GCC 4.2 the following backends have STRUCTURE_SIZE_BOUNDARY set to =32
which will trigger this behaviour:
Alpha+unicos
Arm prior to AAPCS
Mt
This is within standards to my knowledge.
What are the chances of getting this patch accepted? I believe it is
correct and the compiler behaviour is within standards, and hopefully
arch/metag will be merged for v3.9 so without this patch the build of
osd_initiator.c will be broken on an in-tree architecture.
Thanks
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
[PATCH] scsi_debug: Fix endianess in partition table
Both start_sect and nr_sects in struct partition are __le32 and require cpu_to_le32() on assignment. Without this fix tools like fdisk show an invalid partition table for SCSI devices emulated by scsi_debug on big-endian architectures, like s390x. Besides a kernel message like this was emitted: sda: p1 start 536870912 is beyond EOD, enabling native capacity sda: p1 start 536870912 is beyond EOD, truncated For verification 'xxd -l 512 /dev/sda' has been used to make sure that this fix makes scsi_debug generated partition tables on s390x look like the ones generated on my laptop. Signed-off-by: Martin Peschke mpesc...@linux.vnet.ibm.com Reviewed-by: Steffen Maier ma...@linux.vnet.ibm.com --- drivers/scsi/scsi_debug.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/scsi/scsi_debug.c +++ b/drivers/scsi/scsi_debug.c @@ -2662,8 +2662,8 @@ static void __init sdebug_build_parts(un / sdebug_sectors_per; pp-end_sector = (end_sec % sdebug_sectors_per) + 1; - pp-start_sect = start_sec; - pp-nr_sects = end_sec - start_sec + 1; + pp-start_sect = cpu_to_le32(start_sec); + pp-nr_sects = cpu_to_le32(end_sec - start_sec + 1); pp-sys_ind = 0x83; /* plain Linux partition */ } } -- 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] dc395x: uninitialized variable in device_alloc()
This bug was introduced back in bitkeeper days in 2003. We use dcb-dev_mode before it has been initialized. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c index 865c64f..fed486bf 100644 --- a/drivers/scsi/dc395x.c +++ b/drivers/scsi/dc395x.c @@ -3747,13 +3747,13 @@ static struct DeviceCtlBlk *device_alloc(struct AdapterCtlBlk *acb, dcb-max_command = 1; dcb-target_id = target; dcb-target_lun = lun; + dcb-dev_mode = eeprom-target[target].cfg0; #ifndef DC395x_NO_DISCONNECT dcb-identify_msg = IDENTIFY(dcb-dev_mode NTC_DO_DISCONNECT, lun); #else dcb-identify_msg = IDENTIFY(0, lun); #endif - dcb-dev_mode = eeprom-target[target].cfg0; dcb-inquiry7 = 0; dcb-sync_mode = 0; dcb-min_nego_period = clock_period[period_index]; -- 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 v8 0/10] More device removal fixes
On 02/09/13 10:28, Bart Van Assche wrote: On 02/09/13 00:29, Joe Lawrence wrote: I haven't had time to rerun the test without the two patches that wait in scsi_remove_host(), however I did rerun the test and verify the same behavior as in my earlier mail. I didn't see any __scsi_remove_device() instances running. Some more investigation revealed that MD RAID was holding a reference to the removed device. (In short, mdadm --remove had failed and left the device as a faulty member of the array.) When I did finally manage to kick that disk from the MD device, scsi host/device removal continued to completion as expected. There's a bit more context to the MD situation that I'll post to the raid list once I get the details together for Neil. I will CC you if you are interested in following. The loop in scsi_remove_host() waits too long. It should stop waiting as soon as the blk_cleanup_queue() calls for all sdev's have finished instead of waiting until all sdev users have closed these sdev's. I will repost patches 07/10 and 08/10. (replying to my own e-mail) Hello Joe, It would be appreciated if you could repeat your test with this kernel tree (tested with iSCSI and SRP): http://github.com/bvanassche/linux/tree/device-removal-fixes. If that test succeed I will repost the patches in that tree. Thanks, Bart. -- 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 47/62] scsi/lpfc: convert to idr_alloc()
Acked-by: James Smart james.sm...@emulex.com
-- james s
On 2/2/2013 8:20 PM, Tejun Heo wrote:
Convert to the much saner new idr interface.
Only compile tested.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: James Smart james.sm...@emulex.com
Cc: linux-scsi@vger.kernel.org
---
This patch depends on an earlier idr changes and I think it would be
best to route these together through -mm. Please holler if there's
any objection. Thanks.
drivers/scsi/lpfc/lpfc_init.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 89ad558..7de4ef14 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -3165,14 +3165,10 @@ destroy_port(struct lpfc_vport *vport)
int
lpfc_get_instance(void)
{
- int instance = 0;
-
- /* Assign an unused number */
- if (!idr_pre_get(lpfc_hba_index, GFP_KERNEL))
- return -1;
- if (idr_get_new(lpfc_hba_index, NULL, instance))
- return -1;
- return instance;
+ int ret;
+
+ ret = idr_alloc(lpfc_hba_index, NULL, 0, 0, GFP_KERNEL);
+ return ret 0 ? -1 : ret;
}
/**
--
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 63/77] scsi/lpfc: convert to idr_alloc()
Acked-by: James Smart james.sm...@emulex.com
-- james s
On 2/6/2013 2:40 PM, Tejun Heo wrote:
Convert to the much saner new idr interface.
Only compile tested.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: James Smart james.sm...@emulex.com
Cc: linux-scsi@vger.kernel.org
---
drivers/scsi/lpfc/lpfc_init.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 26ca2ef..314b4f6 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -3165,14 +3165,10 @@ destroy_port(struct lpfc_vport *vport)
int
lpfc_get_instance(void)
{
- int instance = 0;
-
- /* Assign an unused number */
- if (!idr_pre_get(lpfc_hba_index, GFP_KERNEL))
- return -1;
- if (idr_get_new(lpfc_hba_index, NULL, instance))
- return -1;
- return instance;
+ int ret;
+
+ ret = idr_alloc(lpfc_hba_index, NULL, 0, 0, GFP_KERNEL);
+ return ret 0 ? -1 : ret;
}
/**
--
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
Fwd: Re: New USB storage device, not detected by Ubuntu 12.10 (kernel 3.5.0-17-generic)
Hi linux-scsi people, the problem described (and worked around) during the conversation below seems to be related to your realm. I apologize if this is redundant and for not taking my own time to suggest a patch for it. However, as it affects users, I still wanted to get it out of my backlog and at least mention it here. Cheers Daniel Original Message Subject: Re: New USB storage device, not detected by Ubuntu 12.10 (kernel 3.5.0-17-generic) Date: Sun, 27 Jan 2013 13:22:42 -0800 From: Matthew Dharm mdharm-...@one-eyed-alien.net To: Daniel dan...@makrotopia.org I don't know. You would need to ask the linux-scsi mailing lists. Matt On Sun, Jan 27, 2013 at 3:48 AM, Daniel dan...@makrotopia.org wrote: Hi Matt, the delay_use parameter to usb-storage doesn't solve the problem. It seems like the delay has to be added to scsi_mod via scsi_inq_timeout=25 for this harddrive to be detected properly (and this obviously needs to be set already in the initramfs when scsi_mod is initially loaded). Is there any way scsi_inq_timeout can be raised on a per device/vendor basis? Thank you for your support! Cheers Daniel On 27.01.2013 02:33, Matthew Dharm wrote: In that case, this is an easy fix. There is already a parameter for this. When you load the usb-storage module, add the delay_use=5 parameter -- that will add a 5-second delay before scanning for the device. Through much of 2.6.x, the default for this parameter was 5 seconds. Later is was changed to 1 second (I guess people didn't like to wait). Try playing around with the value to find something you like, and then you can configure that to be the default via modprobe.conf Matt On Sat, Jan 26, 2013 at 10:22 AM, Daniel dan...@makrotopia.org wrote: Hi again, I just figured out that calling echo scsi add-single-device 8 0 0 0 /proc/scsi/scsi (with 8 being the usb-storage controller for that device) makes it work if called a few seconds after adding the device. Probably the waiting time before probing is not high enough and a quirk for that device needs to be added. Cheers Daniel On 01/26/2013 07:54 PM, Matthew Dharm wrote: Is this a kernel you compiled yourself? Did you compile in the SCSI disk modules? Are you saying that /proc/scsi/scsi is empty? You may have to compile with USB Storage Verbose Debug enabled and capture a log from that... Matt On Sat, Jan 26, 2013 at 9:41 AM, Daniel dan...@makrotopia.org wrote: Hi Matt, thank you for getting back to me after just a few minutes! You are doing an amazing job! So this is a Transcend StoreJet 1TB external 2.5 HDD connected via USB. I meanwhile also tried it on another machine which runs kernel 3.8.0rc1, the result is the same. It shows up as a usb-sata-bridge and usb-storage seems to detect it. However, no connected SCSI device shows up in /proc/scsi/scsi . If you need any more information or if I can assist in any way (I'm familiar with compiling the kernel form source) Thank you much! Daniel from lsusb -v Bus 002 Device 004: ID 152d:2329 JMicron Technology Corp. / JMicron USA Technology Corp. JM20329 SATA Bridge Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x152d JMicron Technology Corp. / JMicron USA Technology Corp. idProduct 0x2329 JM20329 SATA Bridge bcdDevice0.00 iManufacturer 1 iProduct 11 iSerial 5 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 bmAttributes 0xc0 Self Powered MaxPower2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 6 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None
