- Eliminate the use of a recursive mutex.
- Mark the driver INTR_MPSAFE.
This work is incomplete and will be refined in a future commit.
- Most notably, _locked() variants of entry points need to be introduced.
- The mii upcall/downcall may still be racy.
- Add a stubbed-out guard against racing rl_detach() for the time being.
Tested on: UP, debug.mpsafenet && !debug.mpsafenet
Reviewed by: silence on -net
Use C99 types. Use ANSI function definitions. Sort prototypes.
Split long lines correctly. Punctuate/wordsmith comments.
Use device_printf()/if_printf() where possible.
Reviewed by: -net (silence)
- Eliminate the use of a recursive mutex.
- Mark the driver as INTR_MPSAFE.
- Split the default media choice code out into xl_choose_media() to
avoid making poor assumptions about the state of the lock during attach.
- The miibus upcall/downcall paths may still be racy.
Change to commented-out locking assertions there for now.
- Tested with nfsclient, routed, ssh, ntp, dhclient and quagga bgpd.
- This needs SMP test coverage. I do not have such resources.
Tested on: UP, !debug.mpsafenet && debug.mpsafenet
Hardware: 3C905B-TX (0x905510b7)
- Use device_printf() during device probe/attach.
- Move if_xname initialization to before xl_reset() is called.
- Use if_printf() at all other times after struct ifnet has been
initialized.
- Remove recursive locking situations. Remove the MTX_RECURSE bit.
- Take the lock for any routine which is not called from within if_vr.c
itself; this includes entry points called by newbus, ifnet, callout,
ifmedia, and polling subsystems.
- Remove spl references from the code added to miibus callbacks in rev 1.60.
- Add the INTR_MPSAFE bit.
- Tidy up some assignments; locks are not needed for taking the address
of something at a known offset, for example.
- Tested on the machine this was committed from.
Tested on: UP only, !debug.mpsafenet && debug.mpsafenet
Reviewed by: rwatson
Put some braces around the busy-wait loop in vr_rxeoc() to make the
no-op semicolon more obvious.
No functional changes.
Running on the machine I am committing from without problems.
Reviewed by: jmallett
following drivers: bfe(4), em(4), fxp(4), lnc(4), tun(4), de(4) rl(4),
sis(4) and xl(4)
More patches are pending on: http://peoples.freebsd.org/~mlaier/ Please take
a look and tell me if "your" driver is missing, so I can fix this.
Tested-by: many
No-objection: -current, -net
algorithm, supplied by wpaul himself. The lame one has an origin
that's been called into question, so rather than argue about that (one
could make an excellent fair use argument), replace it with better
code since that's what FreeBSD is about.
Submitted by: wpaul[1], Klaus Klein
[1] Bill called this a silly bikeshed. Maybe his is not incorrect.
registers, so add a register offset array to the softc. We key off the
device ID to determine which set of register offsets. Currently the 8385
host bridge used on amd64 is the only bridge to use the AGP3_VIA_*
register offsets and all other bridges use the AGP_VIA_* offsets. It is
currently unclear if the AGP3_VIA_* offsets are for VIA bridges that
implement AGP 3.0 bridges or just for amd64 bridges.
Submitted by: Kenneth Culver culverk at sweetdreamsracing dot biz
caller to vm_page_grab(). Although this gives VM_ALLOC_ZERO a
different meaning for vm_page_grab() than for vm_page_alloc(), I feel
such change is necessary to accomplish other goals. Specifically, I
want to make the PG_ZERO flag immutable between the time it is
allocated by vm_page_alloc() and freed by vm_page_free() or
vm_page_free_zero() to avoid locking overheads. Once we gave up on
the ability to automatically recognize a zeroed page upon entry to
vm_page_free(), the ability to mutate the PG_ZERO flag became useless.
Instead, I would like to say that "Once a page becomes valid, its
PG_ZERO flag must be ignored."
same problems as their Hurricane 575* bretheren in that one could set
the memory mapped port, but that has no effect. Add a quirk for this.
# I'll have to see if I can dig up documentation on these parts to see
# if there's someway software can know this other than a table...
status registers for error conditions and updating statistics
when there are cycles left (inspired by the nge(4) driver).
- Removed the TX list counter and the producer/consumer gap; it's
enough to just ensure we don't reuse the last (free) descriptor,
as the chip may not have read its next pointer yet. If we reuse
it, the TX may stall under a heavy TX load with polling enabled.
- Dropped code to recharge the watchdog timer, it's pointless; the
watchdog routine will re-init the chip and both RX and TX lists.
without the (defunct) isa compatibility shims. The new-bus-specific
parts are very similar to the ones for the pci probe and attach.
This was held up too long waiting for a repo copy to src/sys/dev/cy,
so I decided to fix the files in their old place. This gives easier
to read and merge diffs anyway.
The "count" line in src/sys/conf/files won't be changed until after
the repo copy, so old kernel configs that specify a count need not be
(and must not be) changed until then. The count is just ignored in
the driver. One unfinished detail is dynamic allocation of arrays
with <count> and (<count> * 32) entries, and iteration over the arrays.
This is now kludged with a fixed count of 10 (up to 10 cards with up
to 32 ports each).
Prodded by: imp
Submitted by: mostly by imp
Approved by: imp
Add in missing case for i845G in the attach routine. I'll MFC this
with the rest of the change after the 4.10 codefreeze lifts.
Reviewed By: Doug Rabson
Under polling(4), we counted non-existent output packets and wasted
CPU cycles, corrected. (PR kern/64975.)
The fix in revision 1.71 to correct resetting of the watchdog timer
was wrong.
In rl(4), the TX list does not have a gap between the consumer and
producer, so the "empty TX list" test was wrong, corrected.
Also, resetting the timer to five each time we know there is still
some TX work to do was a bad idea -- under polling(4), if the chip
goes out to lunch, this results in the watchdog routine to _never_
be called. Instead, let the timer downgrade to zero and fire the
watchdog, then reset it to five when it is zero AND there is some
TX work left. (Most other network drivers need this fix too.)
MFC after: 3 days
Moved the RX ring resyncing code to ste_rxeoc(), and only run it
if we were asked to POLL_AND_CHECK_STATUS, under DEVICE_POLLING.
(This significantly reduces the CPU load.)
Improved the RX ring resyncing code by re-checking if the head
is still empty before doing resyncing. This mostly affects the
DEVICE_POLLING mode, where we run this code periodically. We
could start checking with an empty head (well, an empty ring
even), and after doing a few iterations, the chip might write
a few entries, including the head, and we would bogusly consider
this case as requiring resyncing. On a test box, this reduced
the number of resyncs done by a factor of 10.
In ste_txeof(sc), only reset the watchdog timer to zero when
the TX list is completely empty.
Converted ste_tx_prev_idx to a pointer -- faster.
Removed some bitrot.
the driver's RX ring head may fall behind the chip, causing the
stuck traffic, disordered packets, etc. Work around this by
adopting the technique of resyncing RX head used in dc(4) and
xl(4) drivers, but do it in a slightly different place to reduce
the number of resyncs needed.
Also, set the NIC's RX polling period to a more meaningful value,
to stop overloading the PCI bus (this also reduces the number of
resyncs by a factor of 3 or more in a long run; the actual number
is very dependent on a nature of the traffic).
Maintain the statistics counter as the hw.ste_rxsyncs sysctl.
In cooperation with: Vsevolod Lobko
OK'ed by: ambrisko
MFC after: 5 days
they all do and handle that without alarming the user. Also pull in a bit
of defensive code from OpenBSD that triggers when a card is recognised but
not properly classified as either Genesis or Yukon. Not that I could ever
have needed this. :-)
Obtained from: OpenBSD/NetBSD (partially)
MFC after: 2 weeks
No functional change, the previous ste_encap() was correct WRT
long mbuf chains; this just reduces code duplication.
MFC after: 3 days
Prodded by: ambrisko
attach/detach time.
Assigning the default behaviour to this particular device is
incorrect, corrupting the video BIOS aperture, and breaking
VESA support in the kernel and XFree86.
Reviewed By: dfr
MFC after: 1 week
PR: kern/62906
Introduce d_version field in struct cdevsw, this must always be
initialized to D_VERSION.
Flip sense of D_NOGIANT flag to D_NEEDGIANT, this involves removing
four D_NOGIANT flags and adding 145 D_NEEDGIANT flags.
Free approx 86 major numbers with a mostly automatically generated patch.
A number of strategic drivers have been left behind by caution, and a few
because they still (ab)use their major number.
MAC address in the EEPROM, and we need to get it from OpenFirmware.
This isn't very pretty but time is lacking to do this in a better
way this near 5.2-RELEASE. This is a RELENG_5_2 candidate.
Original version by: Marius Strobl <marius@alchemy.franken.de>
Tested by: Pete Bentley <pete@sorted.org>
Reviewed by: jake
frame, not the first. It is probably also not safe to free the mbuf chain
as soon as the OWN bit is cleared on the first descriptor since the chip
may not be done copying the frame into the transmit FIFO. Revert the part of
of busdma conversion (if_dc.c rev 1.115) which changed dc_txeof() to look for
the status in the first descriptor and free the mbuf chain when processing
the first descriptor for the frame, and revert the matching changes elsewhere
in the driver. This part of the busdma change caused the driver to report
spurious collisions and output errors, even when running in full-duplex mode.
Reverting the mbuf chain handling slightly complicates dc_dma_map_txbuf(),
since it is responsible for setting the OWN bits on the descriptors, but does
not normally have direct access to the mbuf chain.
Tested by:
Dejan Lesjak <dejan.lesjak at ijs.si> alpha/<Intel 21143 10/100BaseTX>
"Xin LI" <delphij at frontfree.net> i386/<Macronix 98713 10/100BaseTX>
Wiktor Niesiobedzki <bsd at w.evip.pl> i386/<3Com OfficeConnect 10/100B>
Reviewed by: mux
report a hardware rev of 0x00000000. Sadly, the 8169 gigE MAC
also reports 0x00000000, so testing against this for exclusion
results in both cards being skipped by rl_probe(). Make the 8169
test more specific by matching against both the hwrev and the PCI
ID for this chip.
PR: kern/60824
this driver by introducing a flag saying we already stopped the device.
On my Soekris net4801, this took a ping -i 0.001 from spending 80% of
time in interrupt handling to 10% (approx numbers).
This was a particular problem for the net4801 because the tree
interfaces share the same interrupt, but it would be a problem for
any configuration where an unused if_sis interface shares an interrupt
with a busy device.
Other drivers may have similar problems.
Thanks to: Luigi
Only do short-cable on revisions that need it.
Move generic initialization before short-cable fix, in order to not
clobber short cable fix register setting.
code. Both the driver and the new code were wrong. Driver interrupt
handlers are supposed to take "void *vsc" arg, but some including all
COMPAT_ISA drivers and the pci part of the cy driver want an "int unit"
arg. They got this using bogus casts of function pointers which should
have kept working despite their bogusness. However, the new interrupt
code doesn't honor requests to pass an arg of ((void *)0), so things
are very broken if the arg is actually a representation of unit 0.
The fix is to use a normal "void *vsc" arg for the pci case and a
wrapper for the COMPAT_ISA case (of the cy driver). This cleans up
new-busification of the pci case but takes the COMPAT_ISA case a little
further from new-bus. The corresponding bug for the COMPAT_ISA case
has already been fixed similarly using a wrapper in compat_isa.c and
we need another wrapper just to undo that.
Fixed some directly related style bugs (mainly by removing compatibility
cruft).
cy.c:
Fixed an indirectly related old bug in cyattach_common(). A wrong status
was returned in the unlikely event that malloc() failed.
Approved by: re (scottl)
this problem put these lines back in. While they should be
unnecessary, they appear to be sometimes necessary.
Reviewed in concept: dfr
Approved by: re (scottl@)
the packets are immediately returned for sending (e.g. when bridging
or packet forwarding). There are more efficient ways to do this
but for now use the least intrusive approach.
Reviewed by: imp, rwatson
multicast hash are written. There are still two distinct algorithms used,
and there actually isn't any reason each driver should have its own copy
of this function as they could all share one copy of it (if it grew an
additional argument).
- Fail in agp_alloc_gatt if the aperture size is 0 instead of panicing in
contigmalloc.
Reported by: Bjoern Fischer <bfischer@Techfak.Uni-Bielefeld.DE>
Reviewed by: jhb
MFC after: 1 week
to the pci attachment. Cardbus is a derived class of pci so all pci
drivers are automatically available for matching against cardbus devices.
Reviewed by: imp
if_xname, if_dname, and if_dunit. if_xname is the name of the interface
and if_dname/unit are the driver name and instance.
This change paves the way for interface renaming and enhanced pseudo
device creation and configuration symantics.
Approved By: re (in principle)
Reviewed By: njl, imp
Tested On: i386, amd64, sparc64
Obtained From: NetBSD (if_xname)
part of the support is that it still assumes one master and one target
where as AGP 3.0 actually supports multiple devices on the bus.
Submitted by: Keith Whitwell <keith@tungstengraphics.com>
Sponsored by: The Weather Channel
chain passed into dc_encap, which dc_start was unaware of. This caused
the old (now invalid) mbuf to be passed to BPF_MTAP.
Spotted by: Kenjiro Cho <kjc@csl.sony.co.jp>
for 21143 based cards which use SIA mode.
This fixes 10mbit mode for ZNYX ZX346Q cards and other
21143 based cards.
PR: 32118
Submitted by: Rene de Vries <rene@tunix.nl>
Geert Jan de Groot <GeertJan.deGroot@tunix.nl>
Obtained from: BSDI
MFC after: 2 weeks
Tested at 100Mbit only, using Asus P4P800 onboard 3C940.
The -stable version of this patch I have in use for ~2 weeks now, and works
just fine for me.
Based on: Nathan L. Binkert's patch for OpenBSD
Patch submitted by and thanks to: Jung-uk Kim <jkim@niksun.com>
MFC after: 2 weeks
that has been recorded earlier and overwrite it again later by
reading it directly from the EEPROM again.
Read the MAC address from the PAR0/PAR1 registers instead, which
are autoloaded on reboot.
Tested on AN985, AN983B. According to the datasheets, it should
also work for the AL981 (I don't have such a chip on a card at home)
PR: 52988
Submitted by: Andrew Gordon <arg-bsd@arg.me.uk>
MFC after: 2 weeks
we're on a 32-bit/64-bit bus or not. Use this to decide if we should
set the PCI dual-address cycle enable bit in the C+ command register.
(Enabling DAC on a 32-bit bus seems to do bad things.)
Also, initialize the C+ command register early in the re_init() routine.
The documentation says this register should be configured first.
autoload and then copying the contends of the station address
registers. For some reason, reading the EEPROM on the 8169S doesn't
work right. This gets around the problem, and allows us to read
the station address correctly on the 8169S.
- Insert a delay after initiating packet transmition in re_diag() to
allow lots of time for the frame to echo back to the host, and wait
for both the 'RX complete' and 'timeout expired' bits in the ISR
register to be set.
- Deal more intelligently with the fact that the frame length
field in the RX descriptor is a different width on the 8139C+
than it is on the 8169/8169S/8110S
- For the 8169, you have to set bit 17 in the TX config register
to enter digital loopback mode, but for the 8139C+, you have to
set both bits 17 and 18. Take this into account so that re_diag()
works properly for both types of chips.
ethernet chips. This driver is pretty simple, however it contains
special DSP initialization code which is needed in order to get
the chip to negotiate a gigE link. (This special initialization
may not be needed in subsequent chip revs.) Also:
- Fix typo in if_rlreg.h (RL_GMEDIASTAT_1000MPS -> RL_GMEDIASTAT_1000MBPS)
- Deal with shared interrupts in re_intr(): if interface isn't up,
return.
- Fix another bug in re_gmii_writereg() (properly apply data field mask)
- Allow PHY driver to read the RL_GMEDIASTAT register via the
re_gmii_readreg() register (this is register needed to determine
real time link/media status).
for the 8169S, according to my sample board. The RealTek Linux driver
mentions 0x00800000. I'm assigning this to the 8110S until I get
more info on it. (The (preliminary) RealTek docs only say that 8169S/8110S
chips will have some combination of those two bits set, but doesn't say
exactly what bit combination goes with which chip variant.)
rl(4) driver and put it in a new re(4) driver. The re(4) driver shares
the if_rlreg.h file with rl(4) but is a separate module. (Ultimately
I may change this. For now, it's convenient.)
rl(4) has been modified so that it will never attach to an 8139C+
chip, leaving it to re(4) instead. Only re(4) has the PCI IDs to
match the 8169/8169S/8110S gigE chips. if_re.c contains the same
basic code that was originally bolted onto if_rl.c, with the
following updates:
- Added support for jumbo frames. Currently, there seems to be
a limit of approximately 6200 bytes for jumbo frames on transmit.
(This was determined via experimentation.) The 8169S/8110S chips
apparently are limited to 7.5K frames on transmit. This may require
some more work, though the framework to handle jumbo frames on RX
is in place: the re_rxeof() routine will gather up frames than span
multiple 2K clusters into a single mbuf list.
- Fixed bug in re_txeof(): if we reap some of the TX buffers,
but there are still some pending, re-arm the timer before exiting
re_txeof() so that another timeout interrupt will be generated, just
in case re_start() doesn't do it for us.
- Handle the 'link state changed' interrupt
- Fix a detach bug. If re(4) is loaded as a module, and you do
tcpdump -i re0, then you do 'kldunload if_re,' the system will
panic after a few seconds. This happens because ether_ifdetach()
ends up calling the BPF detach code, which notices the interface
is in promiscuous mode and tries to switch promisc mode off while
detaching the BPF listner. This ultimately results in a call
to re_ioctl() (due to SIOCSIFFLAGS), which in turn calls re_init()
to handle the IFF_PROMISC flag change. Unfortunately, calling re_init()
here turns the chip back on and restarts the 1-second timeout loop
that drives re_tick(). By the time the timeout fires, if_re.ko
has been unloaded, which results in a call to invalid code and
blows up the system.
To fix this, I cleared the IFF_UP flag before calling ether_ifdetach(),
which stops the ioctl routine from trying to reset the chip.
- Modified comments in re_rxeof() relating to the difference in
RX descriptor status bit layout between the 8139C+ and the gigE
chips. The layout is different because the frame length field
was expanded from 12 bits to 13, and they got rid of one of the
status bits to make room.
- Add diagnostic code (re_diag()) to test for the case where a user
has installed a broken 32-bit 8169 PCI NIC in a 64-bit slot. Some
NICs have the REQ64# and ACK64# lines connected even though the
board is 32-bit only (in this case, they should be pulled high).
This fools the chip into doing 64-bit DMA transfers even though
there is no 64-bit data path. To detect this, re_diag() puts the
chip into digital loopback mode and sets the receiver to promiscuous
mode, then initiates a single 64-byte packet transmission. The
frame is echoed back to the host, and if the frame contents are
intact, we know DMA is working correctly, otherwise we complain
loudly on the console and abort the device attach. (At the moment,
I don't know of any way to work around the problem other than
physically modifying the board, so until/unless I can think of a
software workaround, this will have do to.)
- Created re(4) man page
- Modified rlphy.c to allow re(4) to attach as well as rl(4).
Note that this code works for the sample 8169/Marvell 88E1000 NIC
that I have, but probably won't work for the 8169S/8110S chips.
RealTek has sent me some sample NICs, but they haven't arrived yet.
I will probably need to add an rlgphy driver to handle the on-board
PHY in the 8169S/8110S (it needs special DSP initialization).
we actually use. Originally, the code reserved 0x8000 to 0x80ff inclusive
which on my hardware conflicts with the acpi timer. This broke the amdpm
driver since it was actually given ports 0x800c to 0x810b (which should
not have happened, IMHO).
This also allows us to considerably simplify the handling of the nForce
smb driver, removing the need for a separate nfpm driver. With this, SMB
accesses appear to work on my Tyan Tiger MP board. Your mileage may vary.
In particular, the nForce changes have not been tested.
We can't update the device description in attach (why not ?), so
we device_print() what we find.
Conditionalize the short cable fix on this being older than rev 16A.
Call device_printf() when we apply short cable fix.
Include interrupt hold-off setting for rev 16+ under "#ifdef notyet"
The device_printf()'s will go under bootverbose once the various
issues have settled a bit.
METEORSSIGNAL ioctl. Applications use this ioctl with the value
METEOR_SIG_MODE_MASK (0xFFFF0000, -65536) to reset signal delivery,
but revision 1.126 caused the driver to return EINVAL in this case.
Interestingly, the same METEORSSIGNAL ioctl in the meteor driver uses
0 to reset signal delivery.
This commit allows METEOR_SIG_MODE_MASK as a synonym for 0 in the
bktr driver, and restructures the code a bit so that it is otherwise
identical between the bktr and meteor drivers.
case, a "Vortex86" mini PC), the PCI device ID value in the EEPROM (0x8100)
does not agree with the PCI device ID returned by pci_get_device() (0x8139).
This means that while rl_probe() matches the device, rl_attach() doesn't.
Work around this by adding an entry to the rl_devs table for the 8100 with
a device ID of 0x8100.
Also, get rid of extra instance of __FBSDID(). One is enough.
multi-fragment transmission. I'm not sure if this is a bug or a requirement
that I overlooked with going through the documentation, but the sample
8169 NIC that I have seems to require it at least some of the time or
else it botches TCP checksums on segments that span multiple descriptors.
ioctls.
In the particular case of ptrace(), this commit more-or-less reverts
revision 1.53 of sys_process.c, which appears to have been erroneous.
Reviewed by: iedowse, jhb
word between the 8139C+ and the 8169. The 8139C+ has a 'frame alignment
error bit' (bit 27) but the 8169 does not. Rather than simply mark this
bit as reserved, RealTek removed it completely and shifted the remaining
status bits one space to the left. This was causing rl_rxeofcplus()
to misparse the error and checksum bits.
To workaround this, rl_rxeofcplus() now shifts the rxstat word one
bit to the right before testing any of the status bits (but after
the frame length has been extracted).
note the existence of the 8169S and 8110S components. (The 8169
is just a MAC, the 8169S and 8110S contain both a MAC and PHY.)
- Properly handle list and buffer addresses as 64-bit. The RX and
TX DMA list addresses should be bus_addr_t's. Added RL_ADDR_HI()
and RL_ADDR_LO() macros to obtain values for writing into chip
registers.
- Set a slightly different TIMERINT value for 8169 NICs for improved
performance.
- Change left out of previous commit log: added some additional
hardware rev codes for other 10/100 chips and for the 8169S/8110S
'rev C' gigE MACs.
