An error occurred fetching the project authors.
- 23 Apr, 2012 1 commit
-
-
Akinobu Mita authored
Use check_signature to find a signature in the mmio address. Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Acked-by:
Mike Miller <mike.miller@hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
- 19 Feb, 2012 12 commits
-
-
Tomas Henzl authored
Some other older controllers also do have problems to perform a kdump. Adding controllers to this list means that the driver will signal this non-ability via a resettable flag correctly. The unsupported list was created after a consultation with HP. Signed-off-by:
Tomas Henzl <thenzl@redhat.com> Acked-by:
Mike Miller <mike.miller@hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Akinobu Mita authored
Use find_first_zero_bit to find the first cleared bit in a memory region. This also includes the following minor changes. - Use bitmap_zero - Reduce unnecessary atomic bitops usage Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Acked-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Scott Teel authored
Certain types of changes to devices should not be interpreted as a device change that would cause the device to be removed and re-added. These include RAID level and Firmware revision changes. However, these attribute changes DO need to be reflected in the controller info structure's dev structure list, so that sysfs and /proc info files for the devices will reflect the new values. Signed-off-by:
Scott Teel <scott.stacy.teel@hp.com> Acked-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Scott Teel authored
Reduce confusion and inaccuracy caused by dated naming of vars and functions referring to external target devices. CURRENT NAMING: PROPOSED NAMING: "MSA2xxx devices" "external target devices" msa2xxx_model ext_target_model is_msa2xxx is_ext_target add_msa2xxx_enclosure add_ext_target_dev nmsa2xxx_enclosures n_ext_target_devs Signed-off-by:
Scott Teel <scott.teel@hp.com> Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Scott Teel authored
Driver limits SAS external target IDs to range 1-8. Need to increase limit and clean up overlapping concepts of targets and paths in the code. There are several defined constants that control this: HPSA_MAX_TARGETS_PER_CTLR 16 MAX_MSA2XXX_ENCLOSURES 32 HPSA_MAX_PATHS 8 We can condense this to one constant: MAX_EXT_TARGETS 32 SAS switches allow for 8 connections, and there is capacity for 4 switches per enclosure in largest blade enclosure type. Signed-off-by:
Scott Teel <scott.teel@hp.com> Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Stephen M. Cameron authored
It should call hpsa_set_bus_target_lun rather than individually setting bus, target and lun. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Stephen M. Cameron authored
Some distros have a "rescan-scsi-bus.sh" script which depends on SCSI REPORT LUNs not reporting something different than what the driver tells the kernel, even if the driver uses scan_start and scan_finished methods of the SCSI host template to override the usual SCSI midlayer discovery code. Previously, 1 was added to the LUN to make room to insert the RAID controller device at LUN 0. Now, the RAID controller is moved to bus 3, and 1 is no longer added to the LUN. However, SCSI REPORT LUNS on Smart Array doesn't report physical devices like tape drives or auto-loaders as it turns out, so those particular device types still won't match. Generally the logical drives are reported first however, so at least those should match. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Stephen M. Cameron authored
Upgraded firmware on Smart Array P7xx (and some others) made them show up as SCSI revision 5 devices and this caused the driver to fail to map MSA2xxx logical drives to the correct bus/target/lun. A symptom of this would be that the target ID of the logical drives as presented by the external storage array is ignored, and all such logical drives are assigned to target zero, differentiated only by LUN. Some multipath software reportedly does not deal well with this behavior, failing to recognize different paths to the same device as such. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
Scott Teel <scott.teel@hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Stephen M. Cameron authored
Sometimes, for testing purposes (e.g. testing rmmod on a system that normally boots using hpsa) it's nice to rename the driver and split it into two drivers and restrict it to certain controllers. This makes that easier. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Stephen M. Cameron authored
hpsa_register_scsi just calls hpsa_scsi_detect. Move the guts of hpsa_scsi_detect into hpsa_register_scsi and get rid of hpsa_scsi_detect. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Stephen M. Cameron authored
[SCSI] hpsa: removed unneeded structure member max_sg_entries and fix badly named constant MAXSGENTRIES We had both h->max_sg_entries and h->maxsgentries in the per controller structure which is terribly confusing. max_sg_entries was really just a constant, 32, which defines how big the "block fetch table" is, which is as large as the max number of SG elements embedded within a command (excluding SG elements in chain blocks). MAXSGENTRIES was the constant used to denote the max number of SG elements embedded within a command, also a poor name. So renamed MAXSGENTREIS to SG_ENTRIES_IN_CMD, and removed h->max_sg_entries and replaced it with SG_ENTRIES_IN_CMD. h->maxsgentries is unchanged, and is the maximum number of sg elements the controller will support in a command, including those in chain blocks, minus 1 for the chain block pointer.. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Stephen M. Cameron authored
Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
- 16 Jan, 2012 1 commit
-
-
Stephen M. Cameron authored
Don't call kthread_stop with a spin lock held and interrupts disabled because kthread_stop will sleep waiting for the thread to stop. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
- 15 Dec, 2011 2 commits
-
-
Tomas Henzl authored
The '5i' controller freezes when a kdump is attemted. This patch admits it and adds the controller to the unresetable list. Signed-off-by:
Tomas Henzl <thenzl@redhat.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Stephen M. Cameron authored
IRQF_SHARED is required for older controllers that don't support MSI(X) and which may end up sharing an interrupt. All the controllers hpsa normally supports have MSI(X) capability, but older controllers may be encountered via the hpsa_allow_any=1 module parameter. Also remove deprecated IRQF_DISABLED. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
- 14 Nov, 2011 1 commit
-
-
Matthew Garrett authored
The Windows driver .inf disables ASPM on hpsa devices. Do the same because the selection of a non default ASPM policy can cause the device to hang. Signed-off-by:
Matthew Garrett <mjg@redhat.com> Cc: stable@kernel.org Acked-by:
Mike Miller <mike.miller@hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
- 30 Oct, 2011 6 commits
-
-
Stephen M. Cameron authored
When controller lockup condition is detected, we should fail all outstanding commands and disable the controller. This will enable multipath solutions to recover gracefully. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Stephen M. Cameron authored
We weren't filling in the transfer length of the flush cache command (it transfers 4 bytes of zeroes). Firmware didn't seem to be bothered by this, but it should be fixed. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Scott Teel authored
The currentsd[] array in hpsa_update_scsi_devices had room for 256 devices. The code was iterating over however many physical and logical devices plus an additional number of possible external MSA2XXX controllers, which together could potentially exceed 256. We increased the size of the currentsd array to 1024 + 1024 + 32 + 1 elements to reflect a reasonable maximum possible number of devices which might be encountered. We also don't just walk off the end of the array if the array controller reports more devices than we are prepared to handle, we just ignore the excessive devices. Signed-off-by:
Scott Teel <scott.teel@hp.com> Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Scott Teel authored
Rename HPSA_MAX_SCSI_DEVS_PER_HBA to HPSA_MAX_DEVICES Signed-off-by:
Scott Teel <scott.teel@hp.com> Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Stephen M. Cameron authored
Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Stephen M. Cameron authored
Set the max hardware sectors in the SCSI host template to 8192 to allow for larger i/o's (8192 is the same limit the cciss driver currently has.) Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
- 21 Oct, 2011 1 commit
-
-
Mike Miller authored
The P600 requires a small delay when changing states. Otherwise we may think the board did not reset and we bail. This for kdump only and is particular to the P600. Signed-off-by:
Mike Miller <mike.miller@hp.com> Cc: stable@kernel.org Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
- 20 Oct, 2011 1 commit
-
-
Mike Miller authored
The following warning message may be confusing to some users: dev_warn(&pdev->dev, "Controller claims that " "'Bit 2 doorbell reset' is " "supported, but not 'bit 5 doorbell reset'. " "Firmware update is recommended.\n"); Most users don't know or care what bit we may be hitting. Also change "recommended" to "required." Signed-off-by:
Mike Miller <mike.miller@hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
- 26 Aug, 2011 2 commits
-
-
Stephen M. Cameron authored
If a physical device exposed to the OS by hpsa is replaced (e.g. one hot plug tape drive is replaced by another, or a tape drive is placed into "OBDR" mode in which it acts like a CD-ROM device) and a rescan is initiated, the replaced device will be added to the SCSI midlayer with target and lun numbers set to -1. After that, a panic is likely to ensue. When a physical device is replaced, the lun and target number should be preserved. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Cc: stable@kernel.org Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Stephen M. Cameron authored
The test to detect OBDR ("One Button Disaster Recovery") cd-rom devices was comparing against uninitialized data. Fixed by moving the test for the device to where the inquiry data is collected, and uninitialized variable altogether as it wasn't really being used. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Cc: stable@kernel.org Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
- 27 Jul, 2011 1 commit
-
-
Stephen M. Cameron authored
In a shared SAS setup, target devices may be reset by one of several hosts, and outstanding commands on that device will be completed to corresponding hosts with status of UNSOLICITED_ABORT. Such commands should be retried instead of being treated as i/o errors. Also fixed a nearby spelling error. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
- 26 Jul, 2011 1 commit
-
-
Arun Sharma authored
This allows us to move duplicated code in <asm/atomic.h> (atomic_inc_not_zero() for now) to <linux/atomic.h> Signed-off-by:
Arun Sharma <asharma@fb.com> Reviewed-by:
Eric Dumazet <eric.dumazet@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: David Miller <davem@davemloft.net> Cc: Eric Dumazet <eric.dumazet@gmail.com> Acked-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 29 Jun, 2011 2 commits
-
-
Stephen M. Cameron authored
This memcpy: memcpy(cmd->sense_buffer, ei->SenseInfo, ei->SenseLen > SCSI_SENSE_BUFFERSIZE ? SCSI_SENSE_BUFFERSIZE : ei->SenseLen); The ei->SenseLen field is filled in by the Smart Array. For requests to logical drives, it will not exceed 32 bytes, so should be ok, but for physical requests it depends on the target device, not the Smart Array. It's conceivable that this could exceed the 32 byte size of ei->SenseInfo. In that case, the memcpy would read past the end of ei->SenseInfo, copying data from the next command, as if it were sense data, or, if it happened to be the very last command in the block of allocated commands, could fall off the end of the allocated area and crash. I'm not aware of anyone ever encountering this behavior, but it could conceivably happen. This bug was found by Coverity. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Stephen M. Cameron authored
Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
- 17 May, 2011 9 commits
-
-
Joe Perches authored
Not at all sure this is correct or appropriate to change, but this seems odd. Found via coccinelle script @@ type T; T* ptr; expression E1; @@ * memset(E1, 0, sizeof(ptr)); Signed-off-by:
Joe Perches <joe@perches.com> Acked-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <jbottomley@parallels.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de>
-
Stephen M. Cameron authored
Signed-off-by:
Scott Teel <scott.stacy.teel@hp.com> Signed-off-by:
James Bottomley <jbottomley@parallels.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de>
-
Stephen M. Cameron authored
Just go straight to the soft-reset method instead. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <jbottomley@parallels.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de>
-
Stephen M. Cameron authored
Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <jbottomley@parallels.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de>
-
Stephen M. Cameron authored
on driver load, if reset_devices is set, and the hard reset attempts fail, try to bring up the controller to the point that a command can be sent, and send it a soft reset command, then after the reset undo whatever driver initialization was done to get it to the point to take a command, and re-do it after the reset. This is to get kdump to work on all the "non-resettable" controllers (except 64xx controllers which can't be reset due to the potentially shared cache module.) Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <jbottomley@parallels.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de>
-
Stephen M. Cameron authored
The bit-2-doorbell reset method seemed to cause (survivable) NMIs on some systems and (unsurvivable) IOCK NMIs on some G7 servers. Firmware guys implemented a new doorbell method to alleviate these problems triggered by bit 5 of the doorbell register. We want to use it if it's available. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <jbottomley@parallels.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de>
-
Stephen M. Cameron authored
hpsa_scsi_setup at one time contained enough code to justify its existence, but that time has passed. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <jbottomley@parallels.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de>
-
Stephen M. Cameron authored
When waiting for the board to become "not ready" don't print a message saying "waiting for board to become ready" (possibly followed by a message saying "failed waiting for board to become not ready". Instead, it should be "waiting for board to reset" and "failed waiting for board to reset." Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <jbottomley@parallels.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de>
-
Stephen M. Cameron authored
Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <jbottomley@parallels.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de>
-