Commit Graph

39 Commits

Author SHA1 Message Date
Warner Losh
5fb99dcabe Bring in support for SUGOI LAN GIGA NIC made by System TALKS, Inc from
a RealTek 8169SB.

PR: 74262
Submitted by: Yoshikazu GOTO-san

# Submitter notes that he's unsure of the revision string for 8169SB
2005-01-22 22:40:53 +00:00
Warner Losh
098ca2bda9 Start each of the license/copyright comments with /*-, minor shuffle of lines 2005-01-06 01:43:34 +00:00
Olivier Houchard
328b4b876f Disable checksum offloading by default. It seems to produce corrupted packets
with some revisions of the chip (particularly when using multiple TX
descriptors).

MFC after:	1 week
2005-01-05 00:06:15 +00:00
Olivier Houchard
1861b3421b In re_detach(), remove an extra call to ether_ifdetach().
This fixes a panic that occurs when unloading the kernel module.

MFC after:	3 days
2005-01-02 01:37:21 +00:00
John-Mark Gurney
22a11c9657 fix jumbo frames as much as they can be fixed for re. We now cap the MTU
to 7422 since it appears that the 8169S can't transmit anything larger..
The 8169S can receive full jumbo frames, but we don't have an mru to let
the upper layers know this...

add fixup so that this driver should work on alignment constrained platforms
(!i386 && !amd64)

MFC after:	5 days
2004-09-28 18:22:24 +00:00
John-Mark Gurney
aedd16d964 trim trailing white space..
call the re mutex by it's name..

MFC after:	3 days
2004-09-20 06:33:37 +00:00
John-Mark Gurney
6102153685 spell RX correctly
don't call re_rxeof a second time when we've already done the work
pull common code out from if and else clauses

MFC after:	3 days
2004-09-19 17:51:41 +00:00
John-Mark Gurney
80a2a305b2 pass in pointer to m_head to re_encap because m_defrag could free the
original mbuf causing a free'd mbuf passed to bpf later and panic'ing the
system..  This should only effect jumbo frames.

MFC after:	5 days
2004-09-18 18:08:28 +00:00
Ruslan Ermilov
0187838b3b Fixed build with DEVICE_POLLING defined. 2004-09-04 07:54:05 +00:00
John-Mark Gurney
97b9d4baf5 merge in if_rl locking because if_re was originally based upon if_rl.
This essentially merges revs 1.143-1.1445 of sys/pci/if_rl.c.
This now marks the interrupt MPSAFE along with making the mutex non-recursive.

Looked over by:	bms
2004-09-03 16:41:41 +00:00
MIHIRA Sanpei Yoshiro
ea263191fd Add support Corega CG-LAPCIGT Gigabit Ethernet(8169S)
PR:		[FreeBSD-users-jp 80667]
Submitted by:	FUJIMOTO Kou <fujimoto@j.dendai.ac.jp>
MFC after:	1 week
2004-08-28 10:59:02 +00:00
Bruce M Simpson
a11e2f18d9 Eliminate unneeded return keywords. 2004-07-06 02:48:29 +00:00
Bruce M Simpson
59b5d93482 Whitespace pass 2004-07-06 02:46:53 +00:00
Warner Losh
922a60559a Remove code to slam the config space on transition to d0. 2004-06-28 20:09:02 +00:00
Christian Weisgerber
0e939c0cea Replace handrolled CRC calculation with ether_crc32_[lb]e(). 2004-06-09 14:34:04 +00:00
Poul-Henning Kamp
fe12f24bb0 Add missing <sys/module.h> includes 2004-05-30 20:08:47 +00:00
John Baldwin
9930009eb6 Wrap the code to save/restore PCI config registers on suspend/resume in
#ifndef BURN_BRIDGES.

Noticed by:	phk
2004-05-24 19:39:23 +00:00
Yaroslav Tykhiy
25fbb2c38c A handler for ioctl(SIOCSIFCAP) should not alter a bit in
if_capenable unless the interface driver is actually able
to toggle the respective capability on and off.

Reviewed by:	ru
2004-05-23 21:05:08 +00:00
Maxime Henrion
866a788cc2 We don't need to initialize if_output, ether_ifattach() does it
for us.
2004-05-23 16:11:53 +00:00
Ruslan Ermilov
f4ab22c94a Implemented per-interface polling(4) control. 2004-04-11 20:34:08 +00:00
Nate Lawson
5f96beb9e0 Convert callers to the new bus_alloc_resource_any(9) API.
Submitted by:	Mark Santcroos <marks@ripe.net>
Reviewed by:	imp, dfr, bde
2004-03-17 17:50:55 +00:00
Matthew N. Dodd
e3bbbec2ca Announce ethernet MAC addresss in ether_ifattach(). 2004-03-14 07:12:25 +00:00
David E. O'Brien
a55a017f42 Don't use caddr_t in mchash(). Also use C99 spellings over BSD ones.
Requested by:	bde,imp
2003-12-08 07:54:15 +00:00
Warner Losh
347934fa63 Sometimes cardbus attachments don't attach, so while we track down
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@)
2003-11-28 05:28:29 +00:00
Sam Leffler
5120abbfb4 Drop the driver lock around calls to if_input to avoid a LOR when
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
2003-11-14 19:00:32 +00:00
David E. O'Brien
4dc52c32bf Remove duplicate FBSDID's, move others to their right place. 2003-11-14 17:16:58 +00:00
David E. O'Brien
aa8255025a Try to create some sort of consistency in how the routings to find the
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).
2003-11-13 20:55:53 +00:00
Doug Rabson
0be389f3ca Remove explicit cardbus attachments from drivers where this is identical
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
2003-11-03 09:22:18 +00:00
Brooks Davis
9bf40ede4a Replace the if_name and if_unit members of struct ifnet with new members
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)
2003-10-31 18:32:15 +00:00
Bill Paul
edd033746c Remove the dual-address cycle stuff. DAC is used to allow a bus master
device to access 64-bit addresses from a 32-bit PCI bus. While the
RealTek manual says you can set this bit and the chip will perform
DAC only if you give it a DMA address with any of the upper 32
bits set, this appears not to be the case. If I turn on the DAC
bit, the chip sets the 'system error' bit in the status register
when I to do a DMA on my Athlon test box with 32-bit PCI bus (VIA
chipset) even though I only have 128MB of physical memory, and thus
can never give the chip a 64-bit address.

Obviously, I can't just set it and forget it, so until I figure
out the right rule for when it's safe/necessary to enable it, keep
it turned off.
2003-09-20 21:18:27 +00:00
Bill Paul
6110675fd6 Remove jumbo buffer #defines that I ended up not needing. 2003-09-19 02:35:03 +00:00
Bill Paul
7cae6651cf In re_diag(), there's no need for us to call re_start() ourselves:
IF_HANDOFF() does it for us behind the scenes. Remove the extra call
to re_start() otherwise we try to transmit twice.

In re_encap(), fix the code that guards against consuming too many
descriptors in the TX ring so that it actually works. With the
new 8169S chip, I was able to hit a corner case that drained the
free descriptor count all the way to 0. This is not supposed to
be possible.
2003-09-18 18:32:15 +00:00
Bill Paul
c2c6548b3a Teach the re(4) driver about the CFG2 register, which tells us whether
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.
2003-09-13 23:51:35 +00:00
Bill Paul
804af9a1af Toggle the interface on and off before starting the diag test. This
seems to be necessary for the 8139C+ under certain circumstances, and
doesn't appear to hurt the other chips. (In the failure case, the
packet would be sent through the TX DMA ring but not get echoed
back. I suspect this has something to do with the link state changing
unexpectedly.)
2003-09-11 07:54:16 +00:00
Bill Paul
abc8ff44d3 - For the 8169 chips, read the station address by forcing an EEPROM
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.
2003-09-11 06:56:46 +00:00
Bill Paul
9bac70b851 Add a PHY driver to support the built-in gigE PHY in the 8169S/8110S
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).
2003-09-11 03:53:46 +00:00
Bill Paul
4ee1666125 Fix bug in re_gmii_writewreg(): we don't need to be screening out certain
PHY addresses here. (The chip will only let you talk to one PHY anyway.)
2003-09-10 15:14:46 +00:00
Bill Paul
69a6b7fb50 Update hardware revision table. 0x04000000 appears to be the revision
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.)
2003-09-10 07:21:43 +00:00
Bill Paul
a94100fa9b Take the support for the 8139C+/8169/8169S/8110S chips out of the
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).
2003-09-08 02:11:25 +00:00