Commit Graph

208 Commits

Author SHA1 Message Date
sam
d1c253ce23 change timeout to be MPSAFE
Sponsored by:	FreeBSD Foundation
2003-09-05 22:37:31 +00:00
jhb
dc11e45b68 Use PCIR_BAR(x) instead of PCIR_MAPS.
Glanced over by:	imp, gibbs
Tested by:		i386 LINT
2003-09-02 17:30:40 +00:00
obrien
c63dab466c Use __FBSDID().
Also some minor style cleanups.
2003-08-24 17:55:58 +00:00
imp
c23aaeeba4 Prefer new location of pci include files (which have only been in the
tree for two or more years now), except in a few places where there's
code to be compatible with older versions of FreeBSD.
2003-08-22 05:54:52 +00:00
jdp
7d24cc9a9e Use the revision ID from PCI configuration space to identify Intel
8255x chips more precisely.  The information was obtained from Intel's
Open Source Software Developer Manual for the 8255x.

MFC after:	1 day
2003-08-04 00:17:16 +00:00
mux
a134e1ecc4 Use the BUS_DMA_ZERO flag. 2003-07-27 14:00:02 +00:00
mux
127ef7b2f3 De-inline some functions. It doesn't gain us anything and bloats
code size by 3616 bytes.  Furthemore, it was previously ignored by GCC.

While I'm at it, fix some bogus comments.
2003-07-22 15:50:54 +00:00
jhb
2e87863b04 Unlock the fxp driver lock before calling fxp_poll() to avoid recursing on
the lock when using DEVICE_POLLING.

Tested by:	Robin P. Blanchard <Robin.Blanchard@gactr.uga.edu>
Reviewed by:	njl
2003-07-11 20:49:36 +00:00
imp
e9df6b7a14 All current uses of pci_set_powerstate are bogus, at least in theory.
However, they are presently necessary due to bigger bogusness in the
pci bus layer not doing the right thing on suspend/resume or on
initial device probe.  This is exactly the sort of thing that the
BURN_BRIDGES option was invented for.  Mark all of them as
BURN_BRIDGES.  As soon as I have the powerstate stuff properly
integrated into the pci bus code, I intend to remove all these
workarounds.
2003-07-03 14:00:57 +00:00
scottl
4d495abb9d Mega busdma API commit.
Add two new arguments to bus_dma_tag_create(): lockfunc and lockfuncarg.
Lockfunc allows a driver to provide a function for managing its locking
semantics while using busdma.  At the moment, this is used for the
asynchronous busdma_swi and callback mechanism.  Two lockfunc implementations
are provided: busdma_lock_mutex() performs standard mutex operations on the
mutex that is specified from lockfuncarg.  dftl_lock() is a panic
implementation and is defaulted to when NULL, NULL are passed to
bus_dma_tag_create().  The only time that NULL, NULL should ever be used is
when the driver ensures that bus_dmamap_load() will not be deferred.
Drivers that do not provide their own locking can pass
busdma_lock_mutex,&Giant args in order to preserve the former behaviour.

sparc64 and powerpc do not provide real busdma_swi functions, so this is
largely a noop on those platforms.  The busdma_swi on is64 is not properly
locked yet, so warnings will be emitted on this platform when busdma
callback deferrals happen.

If anyone gets panics or warnings from dflt_lock() being called, please
let me know right away.

Reviewed by:	tmm, gibbs
2003-07-01 15:52:06 +00:00
njl
9a60d0f2a2 Drop locks before calling if_input() since it may re-enter fxp_start()
in the netisr case. This would result in a lock reversal.  This
fixes the net.isr.enable=1 case.  Better performance might be
obtained by chaining all packets received, dropping the lock, and
then calling if_input() on each one.

Reported by:	hmp
2003-06-23 23:23:49 +00:00
mux
69d791a081 Add a new device ID.
Submitted by:	Tom Alsberg <alsbergt@cs.huji.ac.il>
2003-06-12 11:21:06 +00:00
silby
855f61b550 Replace if_fxp's handrolled defrag function with m_defrag.
No actual bug with the existing code, just tidying things up.

Submitted by:	hmp
2003-06-02 05:16:42 +00:00
truckman
52630e2ed7 Always set the hardware parse bit in the IPCB structure when this
structure, which is new to the 82550 and 82551, is used to transmit
a packet.  This appears to fix the packet truncation problem that was
observed when using 82550-based fxp cards to transmit ICMP or fragmented
UDP packets of certain lengths which only had one to three bytes in the
second and final mbuf of the packet.  This matches a note in the "Intel
8255x 10/100 Mbps Ethernet Controller Family Open Source Software Developer
Manual", which says that the hardware parse bit should be set when sending
these types of packets.

There have also been unconfirmed reports of similar problems when
transmitting TCP packets, which should not be affected by the above
mentioned change because the hardware parse bit was already being set
if the stack requested hardware checksumming of the packet.  If the
problem remains, the use of the IPCB structure can be disabled to
cause the driver to fall back to using the older 82559 interface with
82550-based cards by setting
        hint.fxp.UNIT_NUMBER.ipcbxmit_disable
to a non-zero value at boot time, or using kenv to set this variable
before using kldload to load the fxp driver.

Approved by:	re (jhb)
2003-05-25 05:04:26 +00:00
rwatson
49ec42645b Add a tunable/sysctl "hw.fxp_noflow" which disables flow control support
on if_fxp cards.  When flow control is enabled, if the operating system
doesn't acknowledge the packet buffer filling, the card will begin to
generate ethernet quench packets, but appears to get into a feedback
loop of some sort, hosing local switches.  This is a temporary workaround
for 5.1: the ability to configure flow control should probably be
exposed by some or another management interface on ethernet link layer
devices.

Approved by:	re (bmah)
Reviewed by:	mux
2003-05-16 01:13:16 +00:00
mux
cf946a9034 GCC 3.3 complains about anonymous structures in unions, so
give the fxp_ipcb structure a name in the fxp_rfa structure.

Submitted by:	peter
Approved by:	re (jhb)
2003-05-14 20:33:41 +00:00
mux
1170968d0c Fix the unaligned access problems that some people saw on alpha
by using a __packed keyword for the fxp_rfa structure.  The Intel
guys who designed this structure with unaligned fields deserve
to be shot.

Tested by:	kris
Approved by:	re@ (jhb)
2003-05-12 18:15:33 +00:00
imp
d05cdb70bf Fix tpyo in last commit.
Noticed by: kuriyama-san
2003-04-30 04:14:56 +00:00
imp
c89b23b0ae Get rid of the redundant 'gone' field, and overload suspend instead.
Check for suspend before the device polling, rather than after it.
Check to see if the current thread owns the lock in ioctl and return
EBUSY if it does.

This advances the locking to the point that I can eject my fxp card 10
times in a row, but I agree with Jeff Hsu that we need to get the
network layer locking finished before chasing more of the races here
(actually, he doesn't think this set is worth it even).  There's a
number of races between FXP_LOCK in detach and all other users of
FXP_LOCK, and this gets back to the 'device with sleepers being
forcibly detached' problem as well...
2003-04-30 01:54:38 +00:00
imp
b6df52c653 (5) from last commit was omitted by mistake:
(5) Return immediately from fxp_intr() if gone is set.
2003-04-29 05:47:14 +00:00
imp
6acb819c04 Fix 5 bugs:
1) always call fxp_stop in fxp_detach.  Since we don't read from
	   the card, there's no need to carefully look at things with
	   bus_child_present.
	2) Call FXP_UNLOCK() before calling bus_teardown_intr to avoid
	   a possible deadlock reported by jhb.
	3) add gone to the softc.  Set it to true in detach.
	4) Return immediately if gone is true in fxp_ioctl
	5) Return immediately if gone is true in fxp_intr
2003-04-29 05:45:09 +00:00
njl
9b009b5d4a Make fxp(4) INTR_MPSAFE (but do not enable MPSAFE just yet):
- Add fxp_start_body() and change fxp_start() to just acquire locks and
  then call fxp_start_body().  Places that would call fxp_start() with
  locks held (mutex recursion) now call fxp_start_body() directly.
  Remove MTX_RECURSE flag from sc_mtx. [gallatin]
- Change fxp_attach() to work without the softc lock, saving interrupt
  hooking until the head of fxp_attach().
- Call ether_ifattach() before overriding ifp parameters. This reverts
  part of 1.155.
- Remove multiple error paths in fxp_attach().
- Teardown interrupt in fxp_detach() before unlocking the softc.
- Make sure mutex is not held in fxp_release()
- Delete the miibus instance and/or self in fxp_release(), not in
  fxp_detach().  This can happen if attach fails partway through.
- Move ifmedia_removeall to fxp_release() since attach may fail after
  media have been allocated.
- Add locking to fxp_suspend, fxp_resume, fxp_start, fxp_intr,
  fxp_poll, fxp_tick, fxp_ioctl, fxp_watchdog.
- Pass in ifp to fxp_intr_body since its callers sometimes already use
  it.
- Add compatibility define for INTR_MPSAFE for 4.x. [gallatin]
- You don't need to bzero softc.

Ideas from:	gallatin, mux
Tested by:	>400M packets of dd/ssh, NFS, ping on i386 UP
2003-04-25 09:01:54 +00:00
sobomax
2c8ec42bdf Update comment to match reality. 2003-04-16 09:16:55 +00:00
mdodd
74c95b7f29 - Don't call pci_enable_io() in drivers (unless needed for resume).
- Don't test memory/port status and emit an error message; the PCI
  bus code will do this now.
2003-04-16 03:16:57 +00:00
mdodd
261178d14f - Express hard dependencies on bus (pci, isa, pccard) and
network layer (ether).
- Don't abuse module names to facilitate ifconfig module loading;
  such abuse isn't really needed.  (And if we do need type information
  associated with a module then we should make it explicit and not
  use hacks.)
2003-04-15 06:37:30 +00:00
sobomax
ac94030547 Use pci_enable_{busmaster|io}() instead of directly writing into
PCI configuration register.

Submitted by:	mdodd
2003-04-14 15:50:04 +00:00
sobomax
6efce81948 Before attaching device set PCIM_CMD_PORTEN in addition to
PCIM_CMD_MEMEN and PCIM_CMD_BUSMASTEREN, becaise some braindead
BIOSes (such as one found in my vprmatrix notebook) forget
to initialize it properly resulting in attachment failure.
2003-04-14 09:45:25 +00:00
mux
b64a74ff56 - Call ether_ifdetach() before shutting down the hardware.
- Remove a useless device_is_alive() check.
- Disable interrupts if bus_child_present() so that this
  check is more useful.

This fixes the hangs I was seeing when unloading the fxp driver.

Suggestions from:	hsu, njl
2003-04-11 12:52:52 +00:00
mux
b3e58d6801 - Clean up the fxp_release() and fxp_detach() functions.
- Be sure to teardown the interrupt first so that "kldunload if_fxp"
  doesn't panic the box.  It's now deadlocking rather than crashing,
  which isn't really better, but I'm unsure this is fxp(4)'s fault.
- Change a bus_dmamap_sync() call to also do a BUS_DMASYNC_PREREAD
  now that we can pass several operations.
2003-04-10 23:15:12 +00:00
mux
f8e2ba2ce6 - Pass a busdma tag and a busdma map to fxp_dma_wait() so that
it can do the necessary bus_dmamap_sync() calls.
- While I'm here, reorder arguments to match other functions.
2003-04-08 18:56:45 +00:00
mux
9ca3a50f70 Add an XXX comment for the atomic operation in the __alpha__
case so that it doesn't confuse more people.  Use the more
correct atomic_clear_16() instead of atomic_clear_short().
2003-04-08 18:35:51 +00:00
mux
d266784cd1 - Endian fixes.
- 6 -> ETHER_ADDR_LEN.
2003-04-08 17:21:15 +00:00
mux
e105056ea6 Fix the hangs people have been seeing. For some reason, the
atomic operation change caused this, so backout it until I
can figure out what's wrong with it.
2003-04-08 13:05:11 +00:00
mux
9c534b08bc Correct the maxsize and maxsegsz parameters for the
bus_dma_tag_create() calls.  Without this, fxp(4) + PAE
would consume insane amounts of bounce pages.
2003-04-07 17:02:44 +00:00
mux
e4566c3ff2 Remove an erroneous htole16(). The byte_count field in the
struct fxp_cb_config is a 6-bit field, not a 16-bit integer
as in struct fxp_cb_tx.
2003-04-07 14:53:30 +00:00
mux
4744a04dfb Move a bus_dmamap_sync() to the correct place. 2003-04-06 23:16:00 +00:00
mux
f11ab00778 Because alpha can't access memory in 16-bit granularity,
we're using an atomic operation to clear the suspend flag
in fxp_start().  Since other architectures may need the
same thing, we want to do it all the time and not only
in the __alpha__ case.  However, we don't want to use
atomic operations on 16-bit integers, because those may
not be available on any architecture.  We're thus faking
a 32-bit atomic operation here.  This patch also deals
with endianness here.
2003-04-06 23:09:57 +00:00
mux
669d8d48a3 Revert the s/u_int/u_int8_t/ changes, we can't really use other
integer types than int with bit-fields in a portable way.

Prodded by:	bde
2003-04-06 21:35:45 +00:00
mux
28332bda3b Use __FBSDID. 2003-04-06 01:27:12 +00:00
mux
8da74262e1 Correct the definition of the link_addr and rbd_addr fields
in struct fxp_rfa.  This should have been committed with my
last endianness fixes.
2003-04-06 01:11:38 +00:00
mux
90f8d39b6c - Instead of rolling our own alignment-safe function, use le32enc()
which deals with both endianness and alignment issues.
- Collect low-hanging fruits for endianness safety.
- Use 0xffffffff instead of -1 where appropriate.
2003-04-06 01:04:17 +00:00
mux
f8837dfb26 - Use __FXP_BITFIELDX macros to make the configuration bitfield
endian safe.
- Change some u_int to u_int8_t which make more sense here since
  we're really defining bytes.  That produces the same code due to
  how bitfields work.
- Add the definition of the vlan_drop_en bit (not used yet).
- Add some useful comments.

Obtained from:	NetBSD
2003-04-05 23:46:58 +00:00
mux
f6dd92222f - Change a FXP_NRFABUFS which would have been a FXP_NTXCB.
- Correct some bus_dmamap_sync() calls.

Submitted by:	jake
2003-04-05 12:43:21 +00:00
mux
5780526be0 Setup our interrupt only at the end of fxp_attach(), when all
other allocations/initializations have been successful.  I kinda
doubt it will fix the recent breakage that some people are seeing,
but this could have caused problems for sure.
2003-04-05 01:27:17 +00:00
mux
d2962d1a1c Remove useless initialization. 2003-04-03 20:39:43 +00:00
mux
9fc72a0ca0 Fix fxp(4), this changed shouldn't have crept in.
Pointy hat to:	mux
Reported by:	Pawel Worach <pawel.worach@nordea.com>
2003-04-03 18:39:48 +00:00
mux
63b6b25833 Remove all the bogus volatile qualifiers from the structs definitions
and associated evil casts to discard them.
2003-04-03 14:08:35 +00:00
mux
fc62ec015b Convert the fxp(4) driver to the busdma API.
This patch is rather big because I had to significantly redesign
the driver to make the busdma conversion possible.  Most notably,
hardware and software structures were carefully splitted to get
rid of all the structs overlapping evilness.

Special thanks to phk and Richard Puga <puga@mauibuilt.com> for
providing me with fxp(4) hardware to do this work.

Thanks to marcel for testing this on ia64, and to Fred Clift
<fclift@verio.net> for testing this on alpha.

Tested on:	i386, ia64, alpha
2003-04-02 16:47:16 +00:00
jdp
c3b6c02e14 Correct names for fxp devices. Sort data by devid in
fxp_ident_table.

PR:		kern/48699
Submitted by:	Sergey A. Osokin <osa@FreeBSD.org.ru>
Obtained from:	NetBSD (the device strings, that is)
MFC after:	4 weeks
2003-03-08 21:44:21 +00:00
peter
fbc7526e8f Finish driving a stake through the heart of netns and the associated
ifdefs scattered around the place - its dead Jim!

The SMB stuff had stolen AF_NS, make it official.
2003-03-05 19:24:24 +00:00