We have 32 (MAXSGENTRIES) scatter gather elements embedded
in the command. With all these, the total command size is
about 576 bytes. However, the last entry in the block fetch table
is 35. (the block fetch table contains the number of 16-byte chunks
the firmware needs to fetch for a given number of scatter gather
elements.) 35 * 16 = 560 bytes, which isn't enough. It needs to be
36. (36 * 16 == 576) or, MAXSGENTRIES + 4. (plus 4 because there's a
bunch of stuff at the front of the command before the first scatter
gather element that takes up 4 * 16 bytes.) Without this fix, the
controller may have to perform two DMA operations to fetch the
command since the first one may not get the whole thing.
Signed-off-by: Don Brace <brace@beardog.cce.hp.com>
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
before trying to enter simple mode transport method.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
This patch removes unnecessary #define's from hpsa. The SCSI midlayer
handles all this for us.
Signed-off-by: Mike Miller <mike.miller@hp.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
This uses the scatter-gather chaining feature of Smart Array
controllers. 32 scatter-gather elements are embedded in the
"command list", and the last element in the list may be marked
as a "chain pointer", and point to an additional block of
scatter gather elements. The precise number of scatter gather
elements supported is dependent on the particular kind of
Smart Array, and is determined at runtime by querying the
hardware.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
The intent of the scan thread was to allow a UNIT ATTENTION/LUN
DATA CHANGED condition encountered in the interrupt handler
to trigger a rescan of devices, which can't be done in interrupt
context. However, we weren't able to get this to work, due to
multiple such UNIT ATTENTION conditions arriving during the rescan,
during updating of the SCSI mid layer, etc. There's no way to tell
the devices, "stand still while I scan you!" Since it doesn't work,
there's no point in having the thread, as the rescan triggered via
ioctl or sysfs can be done without such a thread.
Signed-off-by: Mike Miller <mikem@beardog.cce.hp.com>
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
The SCSI status does not need to be shifted.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
The use of the big kernel lock here appears
to be ancient cruft that is no longer needed.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
fix bug in adjust_hpsa_scsi_table which caused devices which have
changed size, etc. to do the wrong thing.
The problem was as follows:
The driver maintains its current idea of what devices are present
in the h->dev[] array. When it updates this array, it scans the
hardware, and produces a new list of devices, call it sd[], for
scsi devices.
Then, it compares each item in h->dev[] vs. sd[], and any items which
are not present sd it removes from h->dev[], and any items present
in sd[], but different, it modifies in h->dev[].
Then, it looks for items in sd[] which are not present in h->dev[],
and adds those items into h->dev[]. All the while, it keeps track
of what items were added and removed to/from h->dev[].
Finally, it updates the SCSI mid-layer by removing and adding
the same devices it removed and added to/from h->dev[]. (modified
devices count as a remove then add.)
originally, when a "changed" device was discovered, it was
removed then added to h->dev[]. The item was added to the *end*
of h->dev[]. And, the item was removed from sd[] as well
(nulled out). As it processed h->dev[], these newly added items
at the end of the list were encountered, and sd[] was searched,
but those items were nulled out. So they ended up getting removed
immediately after they were added.
The solution is to have a way to replace items in the h->dev[]
array instead of doing a remove + add. Then the "changed" items.
are not encountered a second time, and removed.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Mike Miller <mikem@beardog.cce.hp.com>
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
use scan_start and scan_finished entry points for scanning and route
the CCISS_REGNEWD ioctl and sysfs triggering of same functionality
through hpsa_scan_start.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Matt Gates <matthew.gates@hp.com>
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Matt Gates <matthew.gates@hp.com>
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
The commands should be retried, and this will make that happen,
instead of resulting in an i/o error.
Signed-off-by: Matt Gates <matthew.gates@hp.com>
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
The p1210m responsds to SCSI report LUNs, unlike traditional Smart
Array controllers. This means that the bus, target, and lun
assignments done by the driver cannot be arbitrary, but must match
what SCSI REPORT LUNS returns.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
and update pci_ids.h to include new PCI ID for StorageWorks 1210m variant.
Signed-off-by: Mike Miller <mikem@beardog.cce.hp.com>
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
This is done by adding support for the so-called "performant mode"
(that's really what they called it). Smart Array controllers
have a mode which enables multiple command completions to be
delivered with a single interrupt, "performant" mode. We want to use
that mode, as some newer controllers will be requiring this mode.
Signed-off-by: Don Brace <brace@beardog.cce.hp.com>
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: Mike Miller <mikem@beardog.cce.hp.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
