MFC: r233827

Fix probing of SAS1068E with a device ID of 0x0059 after r232411 (MFC'ed
to stable/7 in r232610).
Reported by: infofarmer

MFC: r233886

Refine r233827; as it turns out, controllers with a device ID of 0x0059
can be upgraded to MegaRAID mode, in which case mfi(4) should attach to
these based on the sub-vendor and -device ID instead (not currently done).
Therefore, let mpt_pci_probe() return BUS_PROBE_LOW_PRIORITY.
While it, let mpt_pci_probe() return BUS_PROBE_DEFAULT instead of 0 in
the default case.
MFC r233585-233587:
r233585:
  Partially revert r223608 and selectively allow microcode loading
  for 82550C.  For 82550 controllers this change restores CPUSaver
  microcode loading.  Due to silicon bug on 82550 and 82550C with
  server extension, these controllers seem to require CPUSaver
  microcode to receive fragmented UDP datagrams.  However the
  microcode shouldn't be used on client featured 82550C as it locks
  up the controller.  In addition, client featured 82550C does not
  have the silicon bug.  Also clear temporary memory used for
  microcode loading since the same memory area is used for other
  commands.
  While I'm here use 82550C in probe message instead of generic
  82550.

  Reported by:	Andreas Longwitz <longwitz <> incore de>
  Tested by:	Andreas Longwitz <longwitz <> incore de>

r233586:
  Load entire EEPROM contents in device attach time and verify
  whether the checksum of EEPROM is valid or not.  Because driver
  heavily relies on EEPROM information when it selectively enables
  features/workarounds, it would be helpful to know whether driver
  sees valid EEPROM.
  While I'm here remove all other EEPROM accesses since the entire
  EEPROM is loaded at device attach time.

r233587:
  Remove unnecessary #if as the software workaround for PCI protocol
  violation should be activated unless the system is cold-booted
  after updating EEPROM.
  The PCI protocol violation happens only when established link is
  10Mbps so the workaround should be updated whenever link state
  change is detected.  Previously the workaround was activated only
  when user checks current media status with ifconfig(8).
MFC r233688-233689:
r233688:
  Remove task queue based link state change handler. Driver no longer
  needs to defer link state handling.
  While I'm here, mark IFF_DRV_RUNNING before changing media.  If
  link is established without any delay, that link state change
  handling could be lost.

r233689:
  Do not report current link status if driver is not running.
  This change also workarounds dhclient's link state handling bug by
  not giving current link status.

  Unlike other controllers, ale(4)'s PHY hibernation perfectly works
  such that driver does not see a valid link if the controller is not
  brought up.  If dhclient(8) runs on ale(4) it will blindly waits
  until link UP and then gives up after 10 seconds.  Because
  dhclient(8) still thinks interface got a valid link when IFM_AVALID
  is not set for selected media,  this change makes dhclient initiate
  DHCP without waiting for link UP.
MFC r231558: newvers.sh: unbreak git/git-svn support
MFC r234134:
	s/Free Memory Pages/Free Memory/ to avoid confusion, since we're
	reporting a number of bytes rather than a number of pages

Approved by:	cperciva (implicit)
MFC r230347:
	Fix warning when compiling with gcc46:
		error: variable 'addrs' set but not used

Approved by:	cperciva (implicit)
MFC r231813:
	Add err(3) to strerror(3) SEE ALSO section

Approved by:	cperciva (implicit)