'RELENG_5_3_0_RELEASE'.

This commit was manufactured to restore the state of the 5.3-RELEASE image.

  Drop the NDIS lock before returning from ndis_start().

  PR:             i386/72795
  Submitted by:   Frank Mayhar <frank@exit.com>

Approved by:  re@ (scottl)

  Fix sis, bfe and ndis in the same way dc was fixed:
    Do not tell the hardware to send when there were no packets enqueued.

  Found and reviewed by: green

Approved by:	re (scottl)

This was tested with a Netgear WG311v2 802.11b/g PCI card. Things
that were fixed:

- This chip has two memory mapped regions, one at PCIR_BAR(0) and the
  other at PCIR_BAR(1). This is a little different from the other
  chips I've seen with two PCI shared memory regions, since they tend
  to have the second BAR ad PCIR_BAR(2). if_ndis_pci.c tests explicitly
  for PCIR_BAR(2). This has been changed to simply fill in ndis_res_mem
  first and ndis_res_altmem second, if a second shared memory range
  exists. Given that NDIS drivers seem to scan for BARs in ascending
  order, I think this should be ok.

- Fixed the code that tries to process firmware images that have been
  loaded as .ko files. To save a step, I was setting up the address
  mapping in ndis_open_file(), but ndis_map_file() flags pre-existing
  mappings as an error (to avoid duplicate mappings). Changed this so
  that the mapping is now donw in ndis_map_file() as expected.

- Made the typedef for 'driver_entry' explicitly include __stdcall
  to silence gcc warning in ndis_load_driver().

NOTE: the Texas Instruments ACX111 driver needs firmware. With my
card, there were 3 .bin files shipped with the driver. You must
either put these files in /compat/ndis or convert them with
ndiscvt -f and kldload them so the driver can use them. Without
the firmware image, the NIC won't work.

- Fix typo in comment
- Remember to free() sc->ndis_txarray on detach
- Remember to do an ifmedia_removeall() for ethernet devices

	an(4), ath(4), hme(4), ndis(4), vr(4) and wi(4)

Please help testing: http://people.freebsd.org/~mlaier/ALTQ_driver/

Tested by:	Vaidas Damosevicius (an, ath, wi)
		Roman Divacky (vr)
Submitted by:	yongari (hme)

now, but it's possible for ndis_reset_nic() to sleep (sometimes the
MiniportReset() method returns NDIS_STATUS_PENDING and we have
to wait for completion). To get around this, execute the ndis_reset_nic()
routine in the NDIS_TASKQUEUE thread.

(which I apparently forgot to commit earlier).

Acquire NDIS_LOCK() in ndis_linksts_done().

actually work.

Make the PCI and PCCARD attachments provide a bus_get_resource_list()
method so that resource listing for PCCARD works. PCCARD does not
have a bus_get_resource_list() method (yet), so I faked up the
resource list management in if_ndis_pccard.c, and added
bus_get_resource_list() methods to both if_ndis_pccard.c and if_ndis_pci.c.
The one in the PCI attechment just hands off to the PCI bus code.
The difference is transparent to the NDIS resource handler code.

Fixed ndis_open_file() so that opening files which live on NFS
filesystems work: pass an actual ucred structure to VOP_GETATTR()
(NFS explodes if the ucred structure is NOCRED).

Make NdisMMapIoSpace() handle mapping of PCMCIA attribute memory
resources correctly.

Turn subr_ndis.c:my_strcasecmp() into ndis_strcasecmp() and export
it so that if_ndis_pccard.c can use it, and junk the other copy
of my_strcasecmp() from if_ndis_pccard.c.

- In subr_ndis.c:ndis_allocate_sharemem(), create the busdma tags
  used for shared memory allocations with a lowaddr of 0x3E7FFFFF.
  This forces the buffers to be mapped to physical/bus addresses within
  the first 1GB of physical memory. It seems that at least one card
  (Linksys Instant Wireless PCI V2.7) depends on this behavior. I
  don't know if this is a hardware restriction, or if the NDIS
  driver for this card is truncating the addresses itself, but using
  physical/bus addresses beyong the 1GB limit causes initialization
  failures.

- Create am NDIS_INITIALIZED() macro in if_ndisvar.h and use it in
  if_ndis.c to test whether the device has been initialized rather
  than checking for the presence of the IFF_UP flag in if_flags.
  While debugging the previous problem, I noticed that bringing
  up the device would always produce failures from ndis_setmulti().
  It turns out that the following steps now occur during device
  initialization:

	- IFF_UP flag is set in if_flags
	- ifp->if_ioctl() called with SIOCSIFADDR (which we don't handle)
	- ifp->if_ioctl() called with SIOCADDMULTI
	- ifp->if_ioctl() called with SIOCADDMULTI (again)
	- ifp->if_ioctl() called with SIOCADDMULTI (yet again)
	- ifp->if_ioctl() called with SIOCSIFFLAGS

  Setting the receive filter and multicast filters can only be done
  when the underlying NDIS driver has been initialized, which is done
  by ifp->if_init(). However, we don't call ifp->if_init() until
  ifp->if_ioctl() is called with SIOCSIFFLAGS and IFF_UP has been
  set. It appears that now, the network stack tries to add multicast
  addresses to interface's filter before those steps occur. Normally,
  ndis_setmulti() would trap this condition by checking for the IFF_UP
  flag, but the network code has in fact set this flag already, so
  ndis_setmulti() is fooled into thinking the interface has been
  initialized when it really hasn't.

  It turns out this is usually harmless because the ifp->if_init()
  routine (in this case ndis_init()) will set up the multicast
  filter when it initializes the hardware anyway, and the underlying
  routines (ndis_get_info()/ndis_set_info()) know that the driver/NIC
  haven't been initialized yet, but you end up spurious error messages
  on the console all the time.

Something tells me this new behavior isn't really correct. I think
the intention was to fix it so that ifp->if_init() is only called
once when we ifconfig an interface up, but the end result seems a
little bogus: the change of the IFF_UP flag should be propagated
down to the driver before calling any other ioctl() that might actually
require the hardware to be up and running.