- Make pccbb/cardbus kld loadable and unloadable.
- Make pccbb/cardbus use the power interface from pccard instead of inventing its own.
- some other minor fixes
The release engineer keeps using the wrong /boot/cdboot when creating the
ISO images. So we'll add the 4.0-RELEASE cdboot to the tree until someone
bothers to fix the source so a working `cdboot' is built.
1) mpsafe (protect the refcount with a mutex).
2) reduce duplicated code by removing the inlined crdup() from crcopy()
and make crcopy() call crdup().
3) use M_ZERO flag when allocating initial structs instead of calling bzero
after allocation.
4) expand the size of the refcount from a u_short to an u_int, by using
shorts we might have an overflow.
Glanced at by: jake
use a mutex lock when looking up/deleting entries on the hashlist
use a mutex lock on each uidinfo when updating fields
make uifree() a void function rather than 'int' since no one cares
allocate uidinfo structs with the M_ZERO flag and don't explicitly initialize
them
Assisted by: eivind, jhb, jakeb
call instead.
This makes a pretty dramatic difference to the amount of work that
the harvester needs to do - it is much friendlier on the system.
(80386 and 80486 class machines will notice little, as the new
get_cyclecounter() call is a wrapper round nanotime(9) for them).
the interface to use callout_* instead of timeout(). Also add an
IS_MPSAFE #define (currently off) which will mark the driver as mpsafe
to the upper layers.
before adding/removing packets from the queue. Also, the if_obytes and
if_omcasts fields should only be manipulated under protection of the mutex.
IF_ENQUEUE, IF_PREPEND, and IF_DEQUEUE perform all necessary locking on
the queue. An IF_LOCK macro is provided, as well as the old (mutex-less)
versions of the macros in the form _IF_ENQUEUE, _IF_QFULL, for code which
needs them, but their use is discouraged.
Two new macros are introduced: IF_DRAIN() to drain a queue, and IF_HANDOFF,
which takes care of locking/enqueue, and also statistics updating/start
if necessary.
using a cardbus based system with pccbb providing the pcic interface).
Something isn't quite right.. when the driver allocates and activates
its resources, the IO space that was requested reads as all zeros (versus
the original 0xff's as it normally is when there is no device responding).
Also, deactivate the resources before releasing them. OLDCARD doesn't
seem to care but NEWCARD/CARDBUS get rather unhappy if you release
a resource that hasn't been deactivated yet.
Make pcic_p.c only compile with oldcard kernels.
(identified by the IO map being 256 bytes long instead of 128)
This chip works very unreliably on my Lanner embedded PC with the rl driver.
Lots of watchdog timeouts or poor performance.
Forcing the media type to 10 Meg (ifconfig rl0 media 10baseT/UTP) is a good
workaround.
This looks very similar to the problem reported in PR kern/18790
It is interesting to note that the linux driver has lots of special
case code for this chip.
* Some dummynet code incorrectly handled a malloc()-allocated pseudo-mbuf
header structure, called "pkt," and could consequently pollute the mbuf
free list if it was ever passed to m_freem(). The fix involved passing not
pkt, but essentially pkt->m_next (which is a real mbuf) to the mbuf
utility routines.
* Also, for dummynet, in bdg_forward(), made the code copy the ethernet header
back into the mbuf (prepended) because the dummynet code that follows expects
it to be there but it is, unfortunately for dummynet, passed to bdg_forward
as a seperate argument.
PRs: kern/19551 ; misc/21534 ; kern/23010
Submitted by: Thomas Moestl <tmoestl@gmx.net>
Reviewed by: bmilekic
Approved by: luigi
