- 09 Nov, 2015 24 commits
-
-
Scott Teel authored
External array LUNs must use target and lun numbers assigned by the external array. So the driver must treat these differently from local LUNs when assigning lun/target. LUN's 'model' field has been used to detect Lun types that need special treatment, but the desire is to eliminate the need to reference specific array models, and support any external array. Pass-through RAID (PTRAID) luns are not luns of the local controller, so they are not reported in LUN count of command 'ID controller'. However, they ARE reported in "Report logical Luns" command. Local luns are listed first, then PTRAID LUNs. The number of luns from "Report LUNs" in excess of those reported by 'ID controller' are therefore the PTRAID LUNS. We can now remove function is_ext_target, and the 'white list' array of supported model names. Reviewed-by:
Scott Teel <scott.teel@pmcs.com> Reviewed-by:
Justin Lindley <justin.lindley@pmcs.com> Reviewed-by:
Kevin Barnett <kevin.barnett@pmcs.com> Signed-off-by:
Don Brace <don.brace@pmcs.com> Reviewed-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Kevin Barnett authored
preparation for adding the sas transport class Reviewed-by:
Tomas Henzl <thenzl@redhat.com> Reviewed-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
-
Kevin Barnett authored
setup for sas transport. Need to set the bus and target accordingly. Reviewed-by:
-
Don Brace authored
use an index into vpd data for SAS/SATA drives Reviewed-by:
-
Kevin Barnett authored
simplify checking for logical/physical devices Reviewed-by:
-
Kevin Barnett authored
remove repeated calculation that checks for physical or logical devices. Reviewed-by:
-
Kevin Barnett authored
remove macros and cleanup device exposure checking Reviewed-by:
-
Don Brace authored
Reviewed-by:
-
Don Brace authored
The driver is using two MACROs which seemingly are looking in the wrong location for the device_flags returned from CISS_REPORT_PHYS. Both MACROs, NON_DISK_PHYS_DEV and PHYS_IOACCEL, are using the pointer returned from figure_lunaddrbytes which is the address of the LUN.lunid element in the extended CISS_REPORT_PHYS. But the MACROS are using offsets beyond the range of the element (offset 17 of an 8 byte element). These MACROs actually are looking at the correct location but they fail static checker analysis. It also will not work if any new elements are added to the extended LUN structure. Change the code to use the structure elements directly since this MACRO is only used in one location. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Scott Teel authored
Set reset type in device_reset_handler to do either logical unit reset for logical devices, or physical target reset, for physical devices. Reviewed-by:
-
Don Brace authored
Fix a NULL pointer issue in the driver when devices are removed during a reset. Signed-off-by:
-
Don Brace authored
handle block counts of 0. Cleanup block and block count calculations. Reviewed-by:
-
Don Brace authored
Abandon and reschedule rescan process only if device inquiries fail due to mem alloc failures, which are likely to occur for all devices. Otherwise, skip device if inquiry fails for other reasons, and continue rescanning process for other devices. Reviewed-by:
-
Don Brace authored
Reviewed-by:
-
Don Brace authored
Reviewed-by:
Manoj Kumar <manoj@linux.vnet.ibm.com> Signed-off-by:
-
Don Brace authored
Check for NULLs. Reviewed-by:
-
Don Brace authored
This member is used in calls to scsi_device_type. It should be unsigned since the kernel checks for upper bounds and it should never be negative. Suggested-by:
-
Don Brace authored
This function is no longer used. Reviewed-by:
-
Don Brace authored
pulling the rug out from under the reset handler likewise for ioaccel_cmds_out Reviewed-by:
-
Don Brace authored
This parameter was once used before scan_start was defined but now it is no longer used. Signed-off-by:
-
Peter Oberparleiter authored
Writing a number to /sys/bus/scsi/devices/<sdev>/queue_ramp_up_period returns the value of that number instead of the number of bytes written. This behavior can confuse programs expecting POSIX write() semantics. Fix this by returning the number of bytes written instead. Signed-off-by:
Peter Oberparleiter <oberpar@linux.vnet.ibm.com> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
-
Johannes Thumshirn authored
Export the RAW SCSI Inquiry to sysfs as binfile. This way the data can be used by userland without the need to have and ioctl or use the sg_inq tool. Here is an example of the provided data linux:~ # hexdump /sys/class/scsi_device/1\:0\:0\:0/device/inquiry 0000000 8005 3205 001f 0000 4551 554d 2020 2020 0000010 4551 554d 4420 4456 522d 4d4f 2020 2020 0000020 2e32 2e33 0000024 Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Sumit Saxena authored
Signed-off-by:
Sumit Saxena <sumit.saxena@avagotech.com> Signed-off-by:
-
Sumit Saxena authored
The DELL PERC5 controller firmware does not list tape drives in response to MR_DCMD_PD_LIST_QUERY. This causes tape drives not be exposed to the OS when connected to a PERC5 controller. This patch permits detection of tape drives connected to a PERC5 controller by exposing non-TYPE_DISK devices unconditionally. Signed-off-by:
Kashyap Desai <kashyap.desai@avagotech.com> Signed-off-by:
-
- 03 Nov, 2015 13 commits
-
-
Calvin Owens authored
In sg_common_write(), we free the block request and return -ENODEV if the device is detached in the middle of the SG_IO ioctl(). Unfortunately, sg_finish_rem_req() also tries to free srp->rq, so we end up freeing rq->cmd in the already free rq object, and then free the object itself out from under the current user. This ends up corrupting random memory via the list_head on the rq object. The most common crash trace I saw is this: ------------[ cut here ]------------ kernel BUG at block/blk-core.c:1420! Call Trace: [<ffffffff81281eab>] blk_put_request+0x5b/0x80 [<ffffffffa0069e5b>] sg_finish_rem_req+0x6b/0x120 [sg] [<ffffffffa006bcb9>] sg_common_write.isra.14+0x459/0x5a0 [sg] [<ffffffff8125b328>] ? selinux_file_alloc_security+0x48/0x70 [<ffffffffa006bf95>] sg_new_write.isra.17+0x195/0x2d0 [sg] [<ffffffffa006cef4>] sg_ioctl+0x644/0xdb0 [sg] [<ffffffff81170f80>] do_vfs_ioctl+0x90/0x520 [<ffffffff81258967>] ? file_has_perm+0x97/0xb0 [<ffffffff811714a1>] SyS_ioctl+0x91/0xb0 [<ffffffff81602afb>] tracesys+0xdd/0xe2 RIP [<ffffffff81281e04>] __blk_put_request+0x154/0x1a0 The solution is straightforward: just set srp->rq to NULL in the failure branch so that sg_finish_rem_req() doesn't attempt to re-free it. Additionally, since sg_rq_end_io() will never be called on the object when this happens, we need to free memory backing ->cmd if it isn't embedded in the object itself. KASAN was extremely helpful in finding the root cause of this bug. Signed-off-by:Calvin Owens <calvinowens@fb.com> Acked-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
-
Benjamin Rood authored
If MSI(X) interrupts are disabled via the kernel command line (pci=nomsi), the pm8001 driver will kernel panic because it does not detect that MSI interrupts are disabled and will soldier on and attempt to configure MSI interrupts anyways. This leads to a kernel panic, most likely because a required data structure is not available down the line. Using the pci_msi_enabled() function in order to detect if MSI interrupts are enabled before configuring them resolves this issue and avoids a kernel panic when the module is loaded. Additionally, the irq_vector structure must be initialized when legacy interrupts are being used otherwise legacy interrupts will simply not function and result in another panic. Signed-off-by:
Benjamin Rood <brood@attotech.com> Reviewed-by:
Jack Wang <jinpu.wang@profitbricks.com> Reviewed-by:
-
Benjamin Rood authored
The documentation for the 8070 and 8072 SPCv chip explicitly states that a minimum of 500ms must elapse before issuing commands, otherwise the SPCv may not process them and the firmware may get into an unrecoverable state requiring a reboot. While the Linux guys will probably think this is 'racy', it is called out in the chip documentation and inserting this delay makes power management function properly. Signed-off-by:
-
Benjamin Rood authored
ATTO adapters do not support this feature. If the firmware fails to be ready, it should not check the examined registers in order to examine the state of the feature in order to prevent undefined behavior. Signed-off-by:
-
Benjamin Rood authored
PHY profiles are not saved in NVRAM on ATTO 12Gb SAS controllers. Therefore, in order for the controller to function in a wide range of configurations, the PHY profiles must be statically set. This patch provides the necessary functionality to do so. Signed-off-by:
-
Benjamin Rood authored
ATTO SAS controllers retrieve the SAS address from the NVRAM in a location different from non-ATTO PMC Sierra SAS controllers. This patch makes the necessary adjustments in order to retrieve the SAS address on these types of adapters. Signed-off-by:
-
Benjamin Rood authored
These PCI IDs allow the pm8001 driver to load against ATTO 12Gb SAS controllers that use PMC Sierra 8070 and PMC Sierra 8072 SAS chips. Signed-off-by:
-
Benjamin Rood authored
These SAS controllers support speeds up to 12Gb. Signed-off-by:
-
Benjamin Rood authored
Previuosly, all PMC Sierra 80xx controllers are assumed to be a motherboard controller, except if the subsystem vendor ID was equal to PCI_VENDOR_ID_ADAPTEC. The driver then attempts to load PHY settings from NVRAM. While this may be correct behavior for most controllers, it does not work with Adaptec and ATTO controllers since they do not store PHY settings in NVRAM and choose to use either custom PHY settings or chip defaults. Loading random values from NVRAM may cause the controllers to malfunction in this edge case. Signed-off-by:
-
Brian King authored
This patch fixes an issue seen with an IBM 2145 (SVC) where, following an error injection test which results in paths going offline, when they came back online, the path would timeout the REPORT_LUNS issued during the scan. This timeout situation continued until retries were expired, resulting in falling back to a sequential LUN scan. Then, since the target responds with PQ=1, PDT=0 for all possible LUNs, due to the way the sequential LUN scan code works, we end up adding 512 LUNs for each target, when there is really only a small handful of LUNs that are actually present. This patch increases the timeout used on the REPORT_LUNS to 30 seconds. This patch solves the issue of 512 non existent LUNs showing up after this event. Signed-off-by:
Brian King <brking@linux.vnet.ibm.com> Reviewed-by:
-
sumit.saxena@avagotech.com authored
Signed-off-by:
-
sumit.saxena@avagotech.com authored
Signed-off-by:
-
sumit.saxena@avagotech.com authored
This is an issue on SMAP enabled CPUs and 32 bit apps running on 64 bit OS. Do not access user memory from kernel code. The SMAP bit restricts accessing user memory from kernel code. Cc: <stable@vger.kernel.org> Signed-off-by:
-
- 29 Oct, 2015 3 commits
-
-
sumit.saxena@avagotech.com authored
Signed-off-by:
-
sumit.saxena@avagotech.com authored
It may happen (kdump), that an interrupt is invoked just after the setup_irqs function was called but before the tasklet was initialised. At this phase the hw ints should have been disabled, but for unknown reason this mechanism seems to not work properly. From: Tomas Henzl <thenzl@redhat.com> Signed-off-by:
-
sumit.saxena@avagotech.com authored
Signed-off-by:
-
