FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F9.2.0 2013-08-15T12:19:16Z 2013-08-15T12:19:16Z Scott Long scottl@FreeBSD.org 2013-08-15T12:19:16Z urn:sha1:63e0f0f0c230505454bb02922661c407e1b437aa Update PCI drivers to no longer look at the MEMIO-enabled bit in the PCI command register. The lazy BAR allocation code in FreeBSD sometimes disables this bit when it detects a range conflict, and will re-enable it on demand when a driver allocates the BAR. Thus, the bit is no longer a reliable indication of capability, and should not be checked. This results in the elimination of a lot of code from drivers, and also gives the opportunity to simplify a lot of drivers to use a helper API to set the busmaster enable bit. This changes fixes some recent reports of disk controllers and their associated drives/enclosures disappearing during boot. Submitted by: jhb Reviewed by: jfv, marius, adrian, achim Approved by: re 2013-07-15T20:33:54Z Matt Jacob mjacob@FreeBSD.org 2013-07-15T20:33:54Z urn:sha1:75a7d79a772eaeeaa1a651730ef7b8791d5a433f When fiddling with options of which registers to copy out for a mailbox command and which registers to copy back in when the command completes, the bits being set need to not only specify what bits you want to add from the default from the table but also what bits you want *subtract* (mask) from the default from the table. A failing ISP2200 command pointed this out. Approved by: re 2013-07-08T15:54:38Z Alexander Motin mav@FreeBSD.org 2013-07-08T15:54:38Z urn:sha1:3e4e5885166ea909e8b4fb152427c50e5d311a22 Stop abusing xpt_periph in random plases that really have no periph related to CCB, for example, bus scanning. NULL value is fine in such cases and it is correctly logged in debug messages as "noperiph". If at some point we need some real XPT periphs (alike to pmpX now), quite likely they will be per-bus, and not a single global instance as xpt_periph now. 2013-06-18T15:06:02Z Marius Strobl marius@FreeBSD.org 2013-06-18T15:06:02Z urn:sha1:420d0cda0124b2e71cdea9050924fdadade7a5fc Turn off fast posting for the ISP2100- I'd forgotten that it actually might have been enabled for them- now that we use all 32 bits of handle. Fast Posting doesn't pass the full 32 bits. 2013-06-18T15:00:20Z Marius Strobl marius@FreeBSD.org 2013-06-18T15:00:20Z urn:sha1:705a88562431af7f829590ac79d032396c174578 Flag isp(4) as supporting unmapped I/O; all necessary conversion actually already has been done as part of r246713 (MFC'ed to stable/9 in r251874). 2013-06-18T00:36:53Z Scott Long scottl@FreeBSD.org 2013-06-18T00:36:53Z urn:sha1:039e422c063977ba9073fd2c93883dd8a5a36d48 have been in production at Netflix for several months with significant success. MFC r246713: 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. MFC r249538: Some compilers issue a warning when wider integer is casted to narrow pointer. Supposedly shut down the warning by casting through uintptr_t. MFC r251479: Simplify the checking of flags for cam_periph_mapmem(). This gets rid of a lot of code redundancy and grossness at very minor expense. MFC r251837: MFC r251842: Add infrastructure for doing compatibility shims, as has been sorely needed for the last 10 years. Far too much of the internal API is exposed, and every small adjustment causes applications to stop working. To kick this off, bump the API version to 0x17 as should have been done with r246713, but add shims to compensate. Thanks to the shims, there should be no visible change in application behavior. Submitted by: kib, jeffr Approved by: kib Obtained from: Netflix 2012-11-12T14:34:46Z Matt Jacob mjacob@FreeBSD.org 2012-11-12T14:34:46Z urn:sha1:43c8f5830516c4d597a41164439f9731503155a9 control spaces. 2012-09-21T00:36:35Z Matt Jacob mjacob@FreeBSD.org 2012-09-21T00:36:35Z urn:sha1:b534e8fa8aa942a56f5367ac9f38393253daeabe 2012-09-20T00:51:09Z Matt Jacob mjacob@FreeBSD.org 2012-09-20T00:51:09Z urn:sha1:55b5a0944aa73d22e97df6caa6f02f2e9a3e73cf 2012-09-19T22:24:09Z Matt Jacob mjacob@FreeBSD.org 2012-09-19T22:24:09Z urn:sha1:ea26d7cc352ac7788fd7d592ff77b7e9f4ed233b