Commit Graph

2363 Commits

Author SHA1 Message Date
Marius Strobl
22e5ade048 - Revert the parts of the previous revision which reloaded the watchdog
timer in xl_txeof()/xl_txeof_90xB(); xl_poll_locked() unconditionally
  invokes xl_txeof()/xl_txeof_90xB(), effectively circumventing that
  the watchdog ever fires in the DEVICE_POLLING case as its timer is
  constantly reloaded.
- Remove the banal and pedantically outdated comment regarding setting
  xl_wdog_timer to 0 in xl_txeof().

Pointed out by:	bde
2006-12-08 03:18:16 +00:00
Marius Strobl
3541d6d881 - Use the xl_stats_update() callout instead of if_slowtimo() for
driving xl_watchdog() in order to avoid races accessing if_timer.
  While at it relax the watchdog a bit by reloading it in xl_txeof()/
  xl_txeof_90xB() if there are still packets enqueued.
- Use bus_get_dma_tag() so xl(4) works on platforms requiring it.
- Don't bother to set if_mtu to ETHERMTU, ether_ifattach() does that.
2006-12-06 02:18:41 +00:00
Ruslan Ermilov
4a67956ec4 if_watchdog -> rl_watchdog 2006-12-01 21:52:07 +00:00
Marius Strobl
3961cd0d76 - Clear the PCN_MISC_ASEL bit so the media port can be actually set
via the PCN_CSR_MODE register. Along with sys/dev/mii/nsphy.c 1.26
  this fixes the case of certain Am79c971-based HP cards and on-board
  ones in IBM machines reporting link but not actually passing any
  traffic. [1]
- Add support for the internal 10baseT PHY, which actually is used on
  at least said HP cards (together with an external DP83840A in a
  multiple PHYs configuration). With cards that don't make use of this
  internal PHY it'll also show up in FreeBSD but not cause any harm.
  This is still missing support for multiple PHYs configuration using
  the internal 100baseTX and/or HomePNA PHYs together with external
  PHYs or multiple external PHYs though.
- In pcn_ifmedia_upd() call pcn_reset() as otherwise the Am79C971 of
  at least said HP cards can wedge when switching from the internal
  10baseT PHY to the external PHY. This means that we need to also
  initialize and possibly start the chip again in pcn_ifmedia_upd(),
  which isn't that bad though as for setting the media port the chip
  has to be powered down or stopped anyway and unlike documented
  doesn't take effect until the next initialization.

PR:		27995, 25959, 72966 (likely) [1]
MFC after:	2 weeks
2006-11-28 01:33:17 +00:00
Pyun YongHyeon
dc74159da6 Add TSO support.
Tested by:	wilko,  Pieter de Goeje < pieter AT degoeje DOT nl >
2006-11-21 04:40:30 +00:00
Pyun YongHyeon
73bb8603b3 Use #ifndef __NO_STRICT_ALIGNMENT rather than
#if !defined(__i386__) && !defined(__amd64__) for architectures
with alignment constraints.
2006-11-21 04:11:31 +00:00
Marius Strobl
2d58d44651 - Don't bother to include IDs of PCnet chips which are not supported
by this driver and largely are not even PCI devices in pcn_chipid.
- Use device_printf(9)/if_printf(9) rather than implementing their
  functionality with printf(9).
- Sprinkle some const.
2006-11-07 19:44:41 +00:00
Matt Jacob
bd3fd815a7 2nd and final commit that moves us to CAM_NEW_TRAN_CODE
as the default.

Reviewed by multitudes.
2006-11-02 00:54:38 +00:00
Marius Strobl
9e264172bd Remove <sys/types.h>; including both <sys/param.h> and <sys/types.h>
violates style(9).
2006-11-02 00:05:15 +00:00
Matt Jacob
fa9ed86506 The first of 3 major steps to move the CAM layer forward to using
the CAM_NEW_TRAN_CODE that has been in the tree for some years now.

This first step consists solely of adding to or correcting
CAM_NEW_TRAN_CODE pieces in the kernel source tree such
that a both a GENERIC (at least on i386) and a LINT build
with CAM_NEW_TRAN_CODE as an option will compile correctly
and run (at least with some the h/w I have).

After a short settle time, the other pieces (making
CAM_NEW_TRAN_CODE the default and updating libcam
and camcontrol) will be brought in.

This will be an incompatible change in that the size of structures
related to XPT_PATH_INQ and XPT_{GET,SET}_TRAN_SETTINGS change
in both size and content. However, basic system operation and
basic system utilities work well enough with this change.

Reviewed by:	freebsd-scsi and specific stakeholders
2006-10-31 05:53:29 +00:00
Marius Strobl
c9c9e0f2da Wrap code optimized for architectures without alignment constraints
in #ifdef __NO_STRICT_ALIGNMENT rather than #if defined(__i386__) ||
defined(__amd64__). Currently this change is cosmetic only though.
While at it, fix a nearby style(9) bug and remove a no longer used
header.
2006-10-29 20:19:41 +00:00
Alan Cox
2a53696fb8 The page queues lock is no longer required by vm_page_busy() or
vm_page_wakeup().  Reduce or eliminate its use accordingly.
2006-10-22 21:18:48 +00:00
Ruslan Ermilov
dfa8edfec6 Older incarnations of the device used non-standard BARs.
Reported by:	Andriy Gapon
Confirmed by:	many (including lm-sensors-2.10.1)
MFC after:	3 days
2006-10-17 10:26:11 +00:00
Seigo Tanimura
7370bc7770 Fix the wraparound of memsize >=2GB. 2006-10-15 05:04:06 +00:00
Jung-uk Kim
2a9dc1317c Fix style(9) nits. 2006-10-09 20:26:32 +00:00
Jung-uk Kim
b5d9e49dcc Fix 32-bit PTE in the GART table.
Noticed by:	jmg
2006-10-09 20:24:49 +00:00
Eric Anholt
30e14d656c Add support for 945G/GM AGP chipsets.
The key problem was that the aperture size detection using the MSAC bit
doesn't work -- the bit appears to be set even when it shouldn't be.  Linux
takes a different approach, testing for a bit of the GMADR (PCIR_BAR(2)) being
set.  However, as I don't think that's a safe way to test aperture size, we
just allocate the resource and check its size.  This also pointed out that
agp_generic_attach hadn't been allocating our aperture resource, which may
have caused problems in some cases.

Also corrected is a minor copy-and-pasteo in an error case.

PR:		kern/103079
Submitted by:	mnag
Tested on:	i945GM, i915GM
MFC after:	2 weeks
2006-09-27 06:38:54 +00:00
Ruslan Ermilov
aaf10c46c7 Whitespace nits. 2006-09-15 11:01:23 +00:00
Gleb Smirnoff
cc4c1b6971 Consistently use if_printf() only in interface methods: if_start,
if_ioctl, if_watchdog, etc, or in functions that are used by
these methods only. In all other cases use device_printf().

This also fixes several panics, when if_printf() is called before
softc->ifp was initialized.

Submitted by:	Alex Lyashkov <umka sevcity.net>
2006-09-15 10:40:54 +00:00
John Baldwin
fcf43477b8 intpm(4) meet style(9). style(9) meet intpm(4). 2006-09-13 18:56:39 +00:00
John Baldwin
9d042fe7aa Trim some unneeded includes. 2006-09-12 15:01:19 +00:00
John Baldwin
7048a99c30 Minor overhaul of SMBus support:
- Change smbus_callback() to pass a void * rather than caddr_t.
- Change smbus_bread() to pass a pointer to the count and have it be an
  in/out parameter.  The input is the size of the buffer (same as before),
  but on return it will contain the actual amount of data read back from
  the bus.  Note that this value may be larger than the input value.  It
  is up to the caller to treat this as an error if desired.
- Change the SMB_BREAD ioctl to write out the updated struct smbcmd which
  will contain the actual number of bytes read in the 'count' field.  To
  preserve the previous ABI, the old ioctl value is mapped to SMB_OLD_BREAD
  which doesn't copy the updated smbcmd back out to userland.  I doubt anyone
  actually used the old BREAD anyway as it was rediculous to do a bulk-read
  but not tell the using program how much data was actually read.
- Make the smbus driver and devclass public in the smbus module and
  push all the DRIVER_MODULE()'s for attaching the smbus driver to
  various foosmb drivers out into the foosmb modules.  This makes all
  the foosmb logic centralized and allows new foosmb modules to be
  self-contained w/o having to hack smbus.c everytime a new smbus driver
  is added.
- Add a new SMB_EINVAL error bit and use it in place of EINVAL to return
  an error for bad arguments (such as invalid counts for bread and bwrite).
- Map SMB bus error bits to EIO in smbus_error().
- Make the smbus driver call bus_generic_probe() and require child drivers
  such as smb(4) to create device_t's via identify routines.  Previously,
  smbus just created one anonymous device during attach, and if you had
  multiple drivers that could attach it was just random chance as to which
  driver got to probe for the sole device_t first.
- Add a mutex to the smbus(4) softc and use it in place of dummy splhigh()
  to protect the 'owner' field and perform necessary synchronization for
  smbus_request_bus() and smbus_release_bus().
- Change the bread() and bwrite() methods of alpm(4), amdpm(4), and
  viapm(4) to only perform a single transaction and not try to use a
  loop of multiple transactions for a large request.  The framing and
  commands to use for a large transaction depend on the upper-layer
  protocol (such as SSIF for IPMI over SMBus) from what I can tell, and the
  smb(4) driver never allowed bulk read/writes of more than 32-bytes
  anyway.  The other smb drivers only performed single transactions.
- Fix buffer overflows in the bread() methods of ichsmb(4), alpm(4),
  amdpm(4), amdsmb(4), intpm(4), and nfsmb(4).
- Use SMB_xxx errors in viapm(4).
- Destroy ichsmb(4)'s mutex after bus_generic_detach() to avoid problems
  from child devices making smb upcalls that would use the mutex during
  their detach methods.

MFC after:	1 week
Reviewed by:	jmg (mostly)
2006-09-11 20:52:41 +00:00
Eric Anholt
c88bc907e7 Add support for another ATI IGP 340M (RS200M) AGP bridge.
PR:		kern/100958
Submitted by:	Kazuo Dohzono <dohzono@axion-software.com>
MFC after:	1 week
2006-09-01 02:22:17 +00:00
Jung-uk Kim
668e25a26c Use aperture base address from north bridge. Some BIOS does not encode
misc. control registers correctly and it is inconsistent with north bridge.
In fact, there are too many broken BIOS implementations out there and we
cannot fix every possible combination but at least it is consistent with
what we advertise with ioctl(2).
2006-08-21 19:10:58 +00:00
Ruslan Ermilov
8dcf2a96c8 Add more nForce4 SMBus 2.0 PCI IDs. 2006-08-18 19:56:40 +00:00
Pyun YongHyeon
87bd40393c Don't reset Tx threshold value whenever xl_init_locked() is called.
Instead the threshould is initialized in device attach. Later the
threshold could be increased in Tx underrun error and the new
threshold should be used in xl_init_locked().
2006-08-12 02:05:13 +00:00
Pyun YongHyeon
005e7722ba Make sure to check frames in Tx queue are empty before clearing
watchdog timer.
2006-08-12 01:55:51 +00:00
Jung-uk Kim
98935c581c Explicitly set v3 mode only when it is requested. Don't bother otherwise. 2006-08-11 19:16:50 +00:00
Yaroslav Tykhiy
776fc0e90e Commit the results of the typo hunt by Darren Pilgrim.
This change affects documentation and comments only,
no real code involved.

PR:		misc/101245
Submitted by:	Darren Pilgrim <darren pilgrim bitfreak org>
Tested by:	md5(1)
MFC after:	1 week
2006-08-04 07:56:35 +00:00
Bill Paul
0fc4974f79 Another small update to the re(4) driver:
- Change the workaround for the autopad/checksum offload bug so that
  instead of lying about the map size, we actually create a properly
  padded mbuf and map it as usual. The other trick works, but is ugly.
  This approach also gives us a chance to zero the pad space to avoid
  possibly leaking data.

- With the PCIe devices, it looks issuing a TX command while there's
  already a transmission in progress doesn't have any effect. In other
  words, if you send two packets in rapid succession, the second one may
  end up sitting in the TX DMA ring until another transmit command is
  issued later in the future. Basically, if re_txeof() sees that there
  are still descriptors outstanding, it needs to manually resume the
  TX DMA channel by issuing another TX command to make sure all
  transmissions are flushed out. (The PCI devices seem to keep the
  TX channel moving until all descriptors have been consumed. I'm not
  sure why the PCIe devices behave differently.)

  (You can see this issue if you do the following test: plug an re(4)
  interface into another host via crossover cable, and from the other
  host do 'ping -c 2 <host with re(4) NIC>' to prime the ARP cache,
  then do 'ping -c 1 -s 1473 <host with re(4) NIC>'. You're supposed
  to see two packets sent in response, but you may only see one. If
  you do 'ping -c 1 -s 1473 <host with re(4) NIC>' again, you'll
  see two packets, but one will be the missing fragment from the last
  ping, followed by one of the fragments from this ping.)

- Add the PCI ID for the US Robotics 997902 NIC, which is based on
  the RTL8169S.

- Add a tsleep() of 1 second in re_detach() after the interrupt handler
  is disconnected. This should allow any tasks queued up by the ISR
  to drain. Now, I know you're supposed to use taskqueue_drain() for
  this, but something about the way taskqueue_drain() works with
  taskqueue_fast queues doesn't seem quite right, and I refuse to be
  tricked into fixing it.
2006-08-01 17:18:25 +00:00
Bill Paul
498bd0d326 Fix the following bugs in re(4)
- Correct the PCI ID for the 8169SC/8110SC in the device list (I added
  the macro for it to if_rlreg.h before, but forgot to use it.)

- Remove the extra interrupt spinlock I added previously. After giving it
  some more thought, it's not really needed.

- Work around a hardware bug in some versions of the 8169. When sending
  very small IP datagrams with checksum offload enabled, a conflict can
  occur between the TX autopadding feature and the hardware checksumming
  that can corrupt the outbound packet. This is the reason that checksum
  offload sometimes breaks NFS: if you're using NFS over UDP, and you're
  very unlucky, you might find yourself doing a fragmented NFS write where
  the last fragment is smaller than the minimum ethernet frame size (60
  bytes). (It's rare, but if you keep NFS running long enough it'll
  happen.) If checksum offload is enabled, the chip will have to both
  autopad the fragment and calculate its checksum header. This confuses
  some revs of the 8169, causing the packet that appears on the wire
  to be corrupted. (The IP addresses and the checksum field are mangled.)
  This will cause the NFS write to fail. Unfortunately, when NFS retries,
  it sends the same write request over and over again, and it keeps
  failing, so NFS stays wedged.

  (A simple way to provoke the failure is to connect the failing system
  to a network with a known good machine and do "ping -s 1473 <badhost>"
  from the good system. The ping will fail.)

  Someone had previously worked around this using the heavy-handed
  approahch of just disabling checksum offload. The correct fix is to
  manually pad short frames where the TCP/IP stack has requested
  checksum offloading. This allows us to have checksum offload turned
  on by default but still let NFS work right.

- Not a bug, but change the ID strings for devices with hardware rev
  0x30000000 and 0x38000000 to both be 8168B/8111B. According to RealTek,
  they're both the same device, but 0x30000000 is an earlier silicon spin.
2006-07-30 23:25:21 +00:00
Bill Paul
e6e13c3cb6 Properly detect the RTL8168(B?) again. RealTek sent me a bunch of sample
cards: the chips are all marked "RTL8111B", but they put stickers on the
back that say "RTL8168B/8111B". The manual says there's only one HWREV code
for both the 8111B and 8168B devices, which is 0x30000000, but the cards
they sent me actually report HWREV of 0x38000000. Deciding to trust the
hardware in front of me rather than a possibly incorrect manual (it wouldn't
be the first time the HWREVs were incorrectly documented), I changed the
8168 revision code. It turns out this was a mistake though: 0x30000000
really is a valid for the 8168.

There are two possible reasons for there to be two different HWREVs:

1) 0x30000000 is used only for the 8168B and 0x38000000 is only for
   the 8111B.
2) There were 8111/8168 rev A devices which both used code 0x30000000,
   and the 8111B/8168B both use 0x38000000.

The product list on the RealTek website doesn't mention the existence of
any 8168/8111 rev A chips being in production though, and I've never seen
one, so until I get clarification from RealTek, I'm going to assume that
0x30000000 is just for the 8168B and 0x38000000 is for the 8111B only.

So, the HWREV code for the 8168 has been put back to 0x30000000,
a new 8111 HWREV code has been added, and there are now separate
entries for recognizing both devices in the device list. This will
allow all devices to work, though if it turns out I'm wrong I may
need to change the ID strings
2006-06-28 16:04:54 +00:00
Eric Anholt
806baa6401 Fix breakage of CHIP_I855 in the last revision.
Submitted by:	Ted Faber <faber@ISI.EDU>
2006-06-27 14:05:11 +00:00
Bill Paul
ed510fb04f Add support for the RealTek 8169SC/8110SC and RTL8101E devices. The
latter is a PCIe 10/100 chip.

Finally fix the EEPROM reading code so that we can access the EEPROMs on all
devices. In order to access the EEPROM, we must select 'EEPROM programming'
mode, and then set the EEPROM chip select bit. Previously, we were setting
both bits simultaneously, which doesn't work: they must be set in the
right sequence.

Always obtain the station address from the EEPROM, now that EEPROM
reading works correctly.

Make the TX interrupt moderation code based on the internal timer
optional and turned off by default.

Make the re_diag() routine conditional and off by default. When it is
on, only use it for the original 8169, which was the only device that
that really needed it.

Modify interrupt handling to use a fast interrupt handler and fast
taskqeueue.

Correct the rgephy driver so that it only applies the DSP fixup for
PHY revs 0 and 1. Later chips are fixed and don't need the fixup.

Make the rgephy driver advertise both 1000_FD and 1000_HD bits in
autoneg mode. A couple of the devices don't autoneg correctly unless
configured this way.
2006-06-26 20:31:32 +00:00
Eric Anholt
92d4d9230c Replace the three copies of the list of pci ids with a single centralized list.
Add the i945 PCI IDs commented out -- I think it should just work, but it hasn't
been tested yet.
2006-06-25 14:44:43 +00:00
Jung-uk Kim
08945e887f Move SiS 760 to where it belongs.
PR:		98094
Submitted by:	Mike M < mmcgus at yahoo dot com >
2006-05-30 18:41:26 +00:00
Gleb Smirnoff
16a67f532d Rename device name in the last commit. According to PR, the ID is
more likely to belong to chips of 8168 family.

PR:		kern/96734
Submitted by:	Sven Petai <hadara bsd.ee>
2006-05-24 11:55:25 +00:00
Eric Anholt
b78e627466 Add support for allocating one larger than page-sized contiguous block of memory
with a physical address.  This is used for hardware ARGB cursor support on newer
chipsets.
2006-05-16 16:19:48 +00:00
Poul-Henning Kamp
c40da00ca3 Since DELAY() was moved, most <machine/clock.h> #includes have been
unnecessary.
2006-05-16 14:37:58 +00:00
Marius Strobl
8fcd3fd881 Replace references to lnc(4) with references to le(4) (so far the notes
still apply to le(4)) now that lnc(4) is removed and le(4) is going to
replace it.
2006-05-15 20:07:24 +00:00
John Baldwin
73dbd3da73 Remove various bits of conditional Alpha code and fixup a few comments. 2006-05-12 05:04:46 +00:00
Pyun YongHyeon
288292463f The sk(4) driver has moved to /sys/dev/sk 2006-04-27 00:14:02 +00:00
Gleb Smirnoff
e72f58bbd9 Add support for RTL8111B chip, that can be found on some mainboards,
for example ASUS P5PL2.

Tested by:	Vadim Frolov <vadim uch.net>
2006-03-22 07:33:03 +00:00
Warner Losh
38637d7d9d Remove de driver from old location. 2006-02-26 17:52:51 +00:00
Eric Anholt
14b4fdc4d6 Add support for the Intel E7205 chipset.
PR:		kern/91315
Submitted by:	Joerg Pulz <Joerg.Pulz@frm2.tum.de>
2006-02-17 01:40:46 +00:00
Gleb Smirnoff
23033eebf4 Do not touch ifp->if_baudrate in miibus aware drivers. 2006-02-14 12:44:56 +00:00
John Baldwin
cb46523df0 Don't add an agp child in vgapci's attach routine if the PCIY_AGP
capability is present as not all devices supported by the agp_i810 driver
(such as i915) have the AGP capability.  Instead, add an identify routine
to the agp_i810 driver that uses the PCI ID to determine if it should
create an agp child device.
2006-02-01 15:45:29 +00:00
Gleb Smirnoff
8d6b240b0d Check ifp before dereferencing it in xl_detach(). xl_detach() can be called
from xl_attach(), when ifp is not defined yet.

Found with:	Coverity Prevent(tm)
2006-01-18 09:42:21 +00:00
John Baldwin
2971d7ab9b Fix a memory leak I introduced with the hostb/vgapci stuff.
Reported by:	Coverity (via dfr's clue-bat)
2006-01-17 17:02:45 +00:00
Pyun YongHyeon
e0078c6436 The number of ticks per usec for YUKON_EC is 125. 2006-01-17 06:58:25 +00:00