274819 |
21-Nov-2014 |
smh |
Prevent overflow issues in timeout processing
Previously, any timeout value for which (timeout * hz) will overflow the signed integer, will give weird results, since callout(9) routines will convert negative values of ticks to '1'. For unsigned integer overflow we will get sufficiently smaller timeout values than expected.
Switch from callout_reset, which requires conversion to int based ticks to callout_reset_sbt to avoid this.
Also correct isci to correctly resolve ccb timeout.
This was based on the original work done by Eygene Ryabinkin <rea@freebsd.org> back in 5 Aug 2011 which used a macro to help avoid the overlow.
Differential Revision: https://reviews.freebsd.org/D1157 Reviewed by: mav, davide MFC after: 1 month Sponsored by: Multiplay
|
246713 |
12-Feb-2013 |
kib |
Reform the busdma API so that new types may be added without modifying every architecture's busdma_machdep.c. It is done by unifying the bus_dmamap_load_buffer() routines so that they may be called from MI code. The MD busdma is then given a chance to do any final processing in the complete() callback.
The cam changes unify the bus_dmamap_load* handling in cam drivers.
The arm and mips implementations are updated to track virtual addresses for sync(). Previously this was done in a type specific way. Now it is done in a generic way by recording the list of virtuals in the map.
Submitted by: jeff (sponsored by EMC/Isilon) Reviewed by: kan (previous version), scottl, mjacob (isp(4), no objections for target mode changes) Discussed with: ian (arm changes) Tested by: marius (sparc64), mips (jmallet), isci(4) on x86 (jharris), amd64 (Fabian Keil <freebsd-listen@fabiankeil.de>)
|
168752 |
15-Apr-2007 |
scottl |
Remove Giant from CAM. Drivers (SIMs) now register a mutex that CAM will use to synchornize and protect all data objects that are used for that SIM. Drivers that are not yet MPSAFE register Giant and operate as usual. RIght now, no drivers are MPSAFE, though a few will be changed in the coming week as this work settles down.
The driver API has changed, so all CAM drivers will need to be recompiled. The userland API has not changed, so tools like camcontrol do not need to be recompiled.
|
163816 |
31-Oct-2006 |
mjacob |
The first of 3 major steps to move the CAM layer forward to using the CAM_NEW_TRAN_CODE that has been in the tree for some years now.
This first step consists solely of adding to or correcting CAM_NEW_TRAN_CODE pieces in the kernel source tree such that a both a GENERIC (at least on i386) and a LINT build with CAM_NEW_TRAN_CODE as an option will compile correctly and run (at least with some the h/w I have).
After a short settle time, the other pieces (making CAM_NEW_TRAN_CODE the default and updating libcam and camcontrol) will be brought in.
This will be an incompatible change in that the size of structures related to XPT_PATH_INQ and XPT_{GET,SET}_TRAN_SETTINGS change in both size and content. However, basic system operation and basic system utilities work well enough with this change.
Reviewed by: freebsd-scsi and specific stakeholders
|
122360 |
09-Nov-2003 |
imp |
Minor tweaks to make it behave better: o When we're resetting the board, make sure that we error out the pending CCBs first. Otherwise the aha_cmd won't accept further commands, such as those that are used to reset the card (AOP_INITIALIZE_MBOX). This appears to cause a cascade failure where no more commands are possible to the card. o Reduce from 10s down to 1s the amount of time we're willing to tolerate the card being awol. This helps the above case. o Add some error checking to two commands issued in the probe.
I have a dim memory of gibbs@ trying to tell me about this problem a few years ago, so pointy hat to imp@ for sitting on it so long.
|
117126 |
01-Jul-2003 |
scottl |
Mega busdma API commit.
Add two new arguments to bus_dma_tag_create(): lockfunc and lockfuncarg. Lockfunc allows a driver to provide a function for managing its locking semantics while using busdma. At the moment, this is used for the asynchronous busdma_swi and callback mechanism. Two lockfunc implementations are provided: busdma_lock_mutex() performs standard mutex operations on the mutex that is specified from lockfuncarg. dftl_lock() is a panic implementation and is defaulted to when NULL, NULL are passed to bus_dma_tag_create(). The only time that NULL, NULL should ever be used is when the driver ensures that bus_dmamap_load() will not be deferred. Drivers that do not provide their own locking can pass busdma_lock_mutex,&Giant args in order to preserve the former behaviour.
sparc64 and powerpc do not provide real busdma_swi functions, so this is largely a noop on those platforms. The busdma_swi on is64 is not properly locked yet, so warnings will be emitted on this platform when busdma callback deferrals happen.
If anyone gets panics or warnings from dflt_lock() being called, please let me know right away.
Reviewed by: tmm, gibbs
|
52174 |
12-Oct-1999 |
dfr |
* Add struct resource_list* argument to resource_list_alloc and resource_list_release. This removes the dependancy on the layout of ivars.
* Move set_resource, get_resource and delete_resource from isa_if.m to bus_if.m.
* Simplify driver code by providing wrappers to those methods:
bus_set_resource(dev, type, rid, start, count); bus_get_resource(dev, type, rid, startp, countp); bus_get_resource_start(dev, type, rid); bus_get_resource_count(dev, type, rid); bus_delete_resource(dev, type, rid);
* Delete isa_get_rsrc and use bus_get_resource_start instead.
* Fix a stupid typo in isa_alloc_resource reported by Takahashi Yoshihiro <nyan@FreeBSD.org>.
* Print a diagnostic message if we can't assign resources to a PnP device.
* Change device_print_prettyname() so that it doesn't print "(no driver assigned)-1" for anonymous devices.
|
51738 |
28-Sep-1999 |
imp |
Newbusification of aha. dfr sent me the first cut, and I made it work. Be more verbose when one cannot allocate IRQ, et al since this is a common configuration problem. The cards have the IRQ soft wired into their BIOS and do not try to do collision detection. This can cause problems when this IRQ is the same as another card/device.
The PNP hasn't been tested. My PNP board is in a deployed system. I'll sneak in testing of it sometime later. I've been able to mount the 3.3R cdrom that arrived today and access files off it.
Submitted by: dfr
|
47506 |
25-May-1999 |
gibbs |
The 1542 cards do not allow adapter commands to be queued while mailbox commands are outstanding. You'd think they'd just clear the IDLE bit, but alas, no. Delay until all pending mailbox commands have completed in aha_cmd to work around this.
Report sync rates correctly on Fast Adaptec cards. Clones may still be reported incorrectly since there is no documenation on how they report extended sync values.
Clean up some unused fields in the aha softc.
|
47208 |
14-May-1999 |
imp |
Put a small delay in before sending the inquire_setup command. The docs don't seem to shed light on why this is needed, but reports from the field indicate this helps prevent problems in this area. Ken's changes seem to have exposed this bug, rather than caused it, as far as I can tell.
Thanks to Jack O'Neill for tracking this down.
Submitted by: jack@germanium.xtalwind.net
Very strong 3.2 merge candidate.
|
46581 |
06-May-1999 |
ken |
Add a number of interrelated CAM feature enhancements and bug fixes.
NOTE: These changes will require recompilation of any userland applications, like cdrecord, xmcd, etc., that use the CAM passthrough interface. A make world is recommended.
camcontrol.[c8]: - We now support two new commands, "tags" and "negotiate".
- The tags commands allows users to view the number of tagged openings for a device as well as a number of other related parameters, and it allows users to set tagged openings for a device.
- The negotiate command allows users to enable and disable disconnection and tagged queueing, set sync rates, offsets and bus width. Note that not all of those features are available for all controllers. Only the adv, ahc, and ncr drivers fully support all of the features at this point. Some cards do not allow the setting of sync rates, offsets and the like, and some of the drivers don't have any facilities to do so. Some drivers, like the adw driver, only support enabling or disabling sync negotiation, but do not support setting sync rates.
- new description in the camcontrol man page of how to format a disk - cleanup of the camcontrol inquiry command - add support in the 'devlist' command for skipping unconfigured devices if -v was not specified on the command line. - make use of the new base_transfer_speed in the path inquiry CCB. - fix CCB bzero cases
cam_xpt.c, cam_sim.[ch], cam_ccb.h:
- new flags on many CCB function codes to designate whether they're non-immediate, use a user-supplied CCB, and can only be passed from userland programs via the xpt device. Use these flags in the transport layer and pass driver to categorize CCBs.
- new flag in the transport layer device matching code for device nodes that indicates whether a device is unconfigured
- bump the CAM version from 0x10 to 0x11
- Change the CAM ioctls to use the version as their group code, so we can force users to recompile code even when the CCB size doesn't change.
- add + fill in a new value in the path inquiry CCB, base_transfer_speed. Remove a corresponding field from the cam_sim structure, and add code to every SIM to set this field to the proper value.
- Fix the set transfer settings code in the transport layer.
scsi_cd.c:
- make some variables volatile instead of just casting them in various places - fix a race condition in the changer code - attach unless we get a "logical unit not supported" error. This should fix all of the cases where people have devices that return weird errors when they don't have media in the drive.
scsi_da.c:
- attach unless we get a "logical unit not supported" error
scsi_pass.c:
- for immediate CCBs, just malloc a CCB to send the user request in. This gets rid of the 'held' count problem in camcontrol tags.
scsi_pass.h:
- change the CAM ioctls to use the CAM version as their group code.
adv driver:
- Allow changing the sync rate and offset separately.
adw driver
- Allow changing the sync rate and offset separately.
aha driver:
- Don't return CAM_REQ_CMP for SET_TRAN_SETTINGS CCBs.
ahc driver:
- Allow setting offset and sync rate separately
bt driver:
- Don't return CAM_REQ_CMP for SET_TRAN_SETTINGS CCBs.
NCR driver:
- Fix the ultra/ultra 2 negotiation bug - allow setting both the sync rate and offset separately
Other HBA drivers: - Put code in to set the base_transfer_speed field for XPT_GET_TRAN_SETTINGS CCBs.
Reviewed by: gibbs, mjacob (isp), imp (aha)
|
45720 |
16-Apr-1999 |
peter |
Bring the 'new-bus' to the i386. This extensively changes the way the i386 platform boots, it is no longer ISA-centric, and is fully dynamic. Most old drivers compile and run without modification via 'compatability shims' to enable a smoother transition. eisa, isapnp and pccard* are not yet using the new resource manager. Once fully converted, all drivers will be loadable, including PCI and ISA.
(Some other changes appear to have snuck in, including a port of Soren's ATA driver to the Alpha. Soren, back this out if you need to.)
This is a checkpoint of work-in-progress, but is quite functional.
The bulk of the work was done over the last few years by Doug Rabson and Garrett Wollman.
Approved by: core
|
42887 |
20-Jan-1999 |
imp |
o enable plug and play support for the aha driver. Given the cumbersome pnp system in freebsd, I'm not sure how useful this will be, but my 1542CP seems to work well in plug and play mode and does seem to probe correctly at all the oddball addresses/irq/drqs that I tried. [[ I was unable to get /kernel.conf or /kernel.config to read in, so I wasn't able to verify that this method of userconfig works. that's one thing that makes pnp so hard to use in the current scheme. Pointers to the right new way of doing this accepted. ]] o Add some kludges to maybe bring support for 1540A/1542A into the driver. Since I have no 154xA cards, and the only person I know that has them hasn't given me feedback, I'm making this commit blind. o Honor unit numbers that are in the config file now. This allows one to hard wire the unit numbers (and have high unit numbers for plug and pray devices, which can't seem to be hardwired) and have the cards not migrate from aha1 -> aha0 should aha0 go on the fritz. I didn't verify that hard wired scsi busses would work, but did verify that hard wired aha addresses did work to a limited extent. Both aha0 and aha1 must be hardwired, or when the card that was in aha0 goes away, the probe for aha0 might pick up the card that otherwise would have been aha1.
|
41807 |
15-Dec-1998 |
imp |
o Convert length of hccb to integer from the array. Eivind Eklund pointed this out, but I've not seen a manifestation of this. o Check against 0x00 as well as 0xff for geometry register, as some clone cards don't return 0xff. Vadim Mikhailov pointed this out in PR 8743 for his Dell SCSI Array controller working in AHA-1540 emulation mode. Note that this test is likely to go away in the future in favor of a better one Justin has recommended.
|
41514 |
04-Dec-1998 |
archie |
Examine all occurrences of sprintf(), strcat(), and str[n]cpy() for possible buffer overflow problems. Replaced most sprintf()'s with snprintf(); for others cases, added terminating NUL bytes where appropriate, replaced constants like "16" with sizeof(), etc.
These changes include several bug fixes, but most changes are for maintainability's sake. Any instance where it wasn't "immediately obvious" that a buffer overflow could not occur was made safer.
Reviewed by: Bruce Evans <bde@zeta.org.au> Reviewed by: Matthew Dillon <dillon@apollo.backplane.com> Reviewed by: Mike Spengler <mks@networkcs.com>
|
41335 |
25-Nov-1998 |
imp |
o Patch, slightly altered, from Graham Menhennitt for older aha 1542B cards. My machine didn't tickle this problem, so I can't tell if it fixed anything or not. However, it didn't break my already working 1542-{B,C,CF,CP} probes. o Minor comment correction o Minor correction in printf
|
40160 |
10-Oct-1998 |
imp |
Fix conficts in probe: o For bt and aha only probe the one I/O range if a specific I/O is specified in the config file. o Don't even try to probe I/O ranges that have been seen already. o If we conflict with an IRQ or DRQ, then fail the probe.
Requested by: bde, gibbs Approved by: jkh
|
39852 |
01-Oct-1998 |
imp |
Misc cleanup and probe rework:
o Use the board id command to find out what kind of board we're talking to. If we're talking to a board that is has an ID that is shared between boards supported by the aha driver and the bt driver, then use the bt's geometry register to weed out the bt cards. Otherwise assume that we support this card. o Remove bt esetup command sending to the card. It seems to wedge too many cards. o Revert to doing a soft reset after an invalid command. This change didn't fix anything, so I'm backing it out. The whole issue of card resetting needs to be revisisted at some point so that we can do it properly on all hardware. o GC unused stuff in some places.
|
39751 |
29-Sep-1998 |
imp |
Several minor cleanups, inspired by bug reports and the old driver:
o Unlock mailbox interface if we have a new card. Before only newer cards (B or newer) that had the BIOS disabled would probe. Cards with the BIOS enabled would fail to probe in the mailbox initialization code. o Increase the number of ccbs and sg to 17 from 16 to support 64k I/O on a non page aligned boundary. Ideas for dynamic determination of this value welcomed, as more of these are better. o Took credit for this driver, even though I derived it from Justin's code. Made sure that Justin's copyright from bt.c was preserved, along with his name, since the error handling code is nearly identical. Add my own, identical copyright. Point people to aha_isa.c.
Cards tested: 1542C and 1542CF. The B and CP might work now as well, but logistical problems precluded me from testing them this evening (if you have jumper settings for the B card, please send me private mail).
|