the same thing as the SMC 1211, but with their own vendor ID.
Update the device list to support this NIC. (Discovered these
cards lying around the lab at work.)
calling vtophys() and contigmalloc()/contigfree() directly. Hopefully,
I have shaken out all of the problems with busdma on the alpha now.
(Everything seems to work as expected.)
Also, change the max RX DMA limit to 1024 bytes instead of "unlimited,"
as the latter seems not to work correctly on the alpha that I tested.
(At 100Mbps, all attempts to receive frames yield RX errors.)
- Use pci_get_powerstate()/pci_set_powerstate() in all the other drivers
that need them so we don't have to fiddle with the PCI power management
registers directly.
- Use pci_enable_busmaster()/pci_enable_io() to turn on busmastering and
PIO/memory mapped accesses.
- Add support to the RealTek driver for the D-Link DFE-530TX+ which has
a RealTek 8139 with its own PCI ID. (Submitted by Jason Wright)
- Have the SiS 900/National DP83815 driver be sure to disable PME
mode in sis_reset(). This apparently fixes a problem on some
motherboards where the DP83815 chip fails to receive packets.
(Submitted by Chuck McCrobie <mccrobie@cablespeed.com>)
mtx_enter(lock, type) becomes:
mtx_lock(lock) for sleep locks (MTX_DEF-initialized locks)
mtx_lock_spin(lock) for spin locks (MTX_SPIN-initialized)
similarily, for releasing a lock, we now have:
mtx_unlock(lock) for MTX_DEF and mtx_unlock_spin(lock) for MTX_SPIN.
We change the caller interface for the two different types of locks
because the semantics are entirely different for each case, and this
makes it explicitly clear and, at the same time, it rids us of the
extra `type' argument.
The enter->lock and exit->unlock change has been made with the idea
that we're "locking data" and not "entering locked code" in mind.
Further, remove all additional "flags" previously passed to the
lock acquire/release routines with the exception of two:
MTX_QUIET and MTX_NOSWITCH
The functionality of these flags is preserved and they can be passed
to the lock/unlock routines by calling the corresponding wrappers:
mtx_{lock, unlock}_flags(lock, flag(s)) and
mtx_{lock, unlock}_spin_flags(lock, flag(s)) for MTX_DEF and MTX_SPIN
locks, respectively.
Re-inline some lock acq/rel code; in the sleep lock case, we only
inline the _obtain_lock()s in order to ensure that the inlined code
fits into a cache line. In the spin lock case, we inline recursion and
actually only perform a function call if we need to spin. This change
has been made with the idea that we generally tend to avoid spin locks
and that also the spin locks that we do have and are heavily used
(i.e. sched_lock) do recurse, and therefore in an effort to reduce
function call overhead for some architectures (such as alpha), we
inline recursion for this case.
Create a new malloc type for the witness code and retire from using
the M_DEV type. The new type is called M_WITNESS and is only declared
if WITNESS is enabled.
Begin cleaning up some machdep/mutex.h code - specifically updated the
"optimized" inlined code in alpha/mutex.h and wrote MTX_LOCK_SPIN
and MTX_UNLOCK_SPIN asm macros for the i386/mutex.h as we presently
need those.
Finally, caught up to the interface changes in all sys code.
Contributors: jake, jhb, jasone (in no particular order)
- Add DRIVER_MODULE() declaration to make this driver a
child of cardbus
- Handle different width EEPROMs
The CIS parser still barfs when scanning this card, but it seems to
probe/attach correctly anyway. I can't do a traffic test just yet
since I don't have a proper crossover cable handy.
a RealTek 8139 cardbus device. Unfortunately it doesn't quite work yet
because the CIS parser barfs on it.
Submitted by msmith, with some small tweaks by me.
takes care of all the 10/100 and gigE PCI drivers that I've done.
Next will be the wireless drivers, then the USB ones. I may pick up
some stragglers along the way. I'm sort of playing this by ear: if
anyone spots any places where I've screwed up horribly, please let me
know.
- Fix a bug in rl_rxeof() handler: in the case where the packet wraps
from the end of the receive buffer back to the beginning, we need to
insure that at least sizeof(ether_header) bytes make it into the first
mbuf. If we don't, then doing eh = mtod(m, struct ether_header *)
loses. To avoid this, we use m_pullup() to suck at least MHLEN -
RL_ETHER_ALIGN bytes into the first mbuf, which should also help
small packets fit into a single mbuf.
Pointed out by: Philip A. Prindeville <philipp@zembu.com>
- Make the transmit threshold autotuning: start off with a small value
and jack it up when TX underruns are detected.
- Also improve TX error recovery: kick the chip in the head with a
reset/init sequence to make sure it recovers afer a transmit error.
few changes:
- there was a bug in rl_list_tx_init(): it was calculating the registers
to initialize incorrectly. Not a problem on the x86 where unaligned
access are allowed, but a problem on the alpha.
- set rl_btag accordingly depending on the machine type
- rl_rxeof() needs to be sure to longword-align the packet data. This
is a little tricky since we copy the data out of the receive buffer
using m_devget(), however there's no way to tell m_devget() to fill
in the mbufs starting at a particular offset. To get around this,
we tell m_devget to copy bytes+2 bytes starting at offset offset-2. This
results in the proper alignment, and we can trim off the two leading
bytes afterwards with m_adj(). We also allocate some extra space before
the start of the receive buffer so that we don't get into trouble in
the case where offset == 0.
- redefine vtophys() in if_rlreg.h for the alpha.
Making this chipset work on the alpha is sort of the inverse of putting
a jet engine on a rowboat (putting a propeller on a 747?) but when
you can get these things for $5 a pop, it's hard to stop people from
buying them.
- Rewrite the transmit section to be a little less bogus.
- Set ifq_maxlen correctly. RL_TX_LIST_CNT - 1 is wrong, because for the
RealTek, RL_TX_LIST_CNT is 4. Set it to IFQ_MAXLEN instead.
Addtron appear to have their own VIA Rhine II and RealTek 8139 boards
with custom PCI vendor and device IDs. This commit updates the PCI
vendor and device lists in the vr and rl drivers so that we can probe
the additional devices.
Found by: nosing around the PCI vendor and device code list at:
http://www.halcyon.com/scripts/jboemler/pci/pcicode
as a RealTek 8139
if_rlreg.h: use bus_space_read_X() in CSR_READ_X() macros instead of
directly calling inb()/outb() etc...
rl.4 + RELNOTES.TXT: mention that SMC EtherEZ PCI 1211-TX is supported
by the RealTek driver
which is either a RealTek 8139 in disguise or a RealTek workalike.
This commit fixes the PCI vendor/device ID for this device
and updates the description string to reflect the actual identity
of the device.
I also changed the transmit encapsulation routine to always to
buffer copies on transmit. We end up doing this 99% of the time
anyway. I also tweaked the code that pads packets out to the minimum
length (60) bytes. I was fixing up the m_pkthdr.len value but not
m_len. I don't think this makes that much difference in the grand
scheme of things, but it makes me feel better.
RealTek 8129/8139 chipset like I've been threatening. Update kernel
configs, userconfig.c, relnotes and sysinstall. No man page yet;
comming soon.
I consider this driver stable enough that I want to give it some
exposure in -current.
