for each device.
- Added option processing. The new API wants the option BLOCKIO,
but SCST then shows the device having been opened with
option BIO. We now warp BIO to BLOCKIO.
- Added the concept of handler aliases. Handler vdisk with
option BLOCKIO shows as a handler of vdisk_blk. We now
warp vdisk_blk to just vdisk.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@184 d57e44dd-8a1f-0410-8b47-8ef2f437770f
- Pass to SCST port WWN as registration name.
- Avoid race condition when we receive new tmd and bp->scst_tmd
may (or not) be NULL.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@182 d57e44dd-8a1f-0410-8b47-8ef2f437770f
set it up. Otherwise we get irq number from legacy BIOS range and proper irq
(other number from PCI range) is not handled or handled by other driver -
- VERY VERY BAD THINGS happen then.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@178 d57e44dd-8a1f-0410-8b47-8ef2f437770f
time selectable. In run-time it is turned on only for 24xx chipsets. With
this workaround (hopply) we don't need to limit queue length (see comment
in patch).
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@177 d57e44dd-8a1f-0410-8b47-8ef2f437770f
- scst_check_local_events() cleanups
- In scst_user notification about aborted commands added, user space interface changed
- Other minor fixes and cleanups
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@159 d57e44dd-8a1f-0410-8b47-8ef2f437770f
We use the 64-bit tag field in the SRP commands to store information allowing us to track each command. However, SCST only saves/uses 32-bits out of this 64-bit field. This causes our code to fail when we get a response SRP command that doesn't match any tags we used.
I have updated SCST to work with our product by changing it to save all 64-bits of the tag.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@150 d57e44dd-8a1f-0410-8b47-8ef2f437770f
We are using OFED target machines to export a large number of disks, many of which are just NULLIO disks, but we have noticed that VPD numbers have a significant tendency to conflict. For example if we name one disk abc12 and another abc21 they will end up with the same VPD.
We are using a quick, slightly hackish way to solve this, by just creating a random hash for each ascii value and then rotating that hash based on the position of the character in the name. If you would like here is our changes.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@149 d57e44dd-8a1f-0410-8b47-8ef2f437770f
- pass FC transport error to SCST
- give SCST info about WWN of remote initiator
- info about expected transfer length and direction
- unifying printk error messages
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@145 d57e44dd-8a1f-0410-8b47-8ef2f437770f
- VDISK_ONLY was removed, SCSI_EXEC_REQ_FIFO_DEFINED, defined by corresponding kernel patch used instead
- Minor fixes
- Docs updates
All users will need to revert old SCST kernel patch and apply the corresponding new one.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@142 d57e44dd-8a1f-0410-8b47-8ef2f437770f
First, the problem: you cannot calculate sgv_max_local_order and
sgv_max_trans_order by excess and then compare them with
get_order(size). The maximum number of local (SG + trans) entries may be
112 (like in amd64 case) and you bzero 128 sg_entries for every
allocation request between 65 and 128 pages because the order is the
same. This is the reason why single transfers of (70 * PAGE_SIZE) =
~285k or more fail on amd64. On i386 the limit is higher, since you can
shrink more records in one page, and so it's very difficult to reach.
Now, the solution: I created a patch, which consists in decreasing
sgv_max_local_order and sgv_max_trans_order by 1.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@140 d57e44dd-8a1f-0410-8b47-8ef2f437770f
