newbus for referencing device interrupt handlers.
- Move the 'struct intrec' type which describes interrupt sources into
sys/interrupt.h instead of making it just be a x86 structure.
- Don't create 'ithd' and 'intrec' typedefs, instead, just use 'struct ithd'
and 'struct intrec'
- Move the code to translate new-bus interrupt flags into an interrupt thread
priority out of the x86 nexus code and into a MI ithread_priority()
function in sys/kern/kern_intr.c.
- Remove now-uneeded x86-specific headers from sys/dev/ata/ata-all.c and
sys/pci/pci_compat.c.
on the NEC VersaPro NoteBook PC. This 21143 implementation has no LEDs,
and flipping the LED control bits somehow stops it from establishing
a link. We check the subsystem ID and don't flip the LED control
bits for the NEC NIC.
include:
* Mutual exclusion is used instead of spl*(). See mutex(9). (Note: The
alpha port is still in transition and currently uses both.)
* Per-CPU idle processes.
* Interrupts are run in their own separate kernel threads and can be
preempted (i386 only).
Partially contributed by: BSDi (BSD/OS)
Submissions by (at least): cp, dfr, dillon, grog, jake, jhb, sheldonh
bus/slot/function numbers. The old PCI code used other markers or
something, but without it here under the new pci code it is very hard to
tell which device is which (this only affects bootverbose mode).
In the nexus case, there are no ivars for children of nexus devices,
and we were passing data in from before the device existed, hence ivars
are convenient as the softc doesn't really exist yet.
However, for pci->pci bridges, the pcib occupies a pci device itself,
which *does* already have ivars. However, softc is available and stable
at this point since we've been identified and are locating the bus during
attach. So, use softc for this version of pcib devices for storing the
physical bus number in.
the link and activity LED control bits in CSR15 in order for the
controller to drive the LEDs correctly. This was largely done for the
ZNYX multiport cards, but should also work with the DEC DE500-BA
and other non-MII cards.
enable bit hasn't been set in the command register, set the bit and
honour the register. It seems that quite a few lazy BIOS writers
aren't bothering to do this, which upsets the existing code and causes
us to miss out on properly-configured devices.
pcib_set_bus() cannot be used on the new child because it is
meant to be used on the *pci* device (it looks at the parent internally)
not the pcib being added. Bite the bullet and use ivars for the bus
number to avoid any doubts about whether the softc is consistant between
probe and attach. This should not break the Alpha code.
the drivers.
* Remove legacy inx/outx support from chipset and replace with macros
which call busspace.
* Rework pci config accesses to route through the pcib device instead of
calling a MD function directly.
With these changes it is possible to cleanly support machines which have
more than one independantly numbered PCI busses. As a bonus, the new
busspace implementation should be measurably faster than the old one.
laptops. I've checked that this still works with the other cards and
it works with the 3c556 that I have access to, but I want to check that
it works with the 556B mentioned in PR #20878 before I close out the PR
and merge to -stable.
- Modify the driver to poll the link state and positively set the
MAC to full or half duplex as needed. Previously, it was possible
for the MAC to remain in half duplex even though the PHY had negotiated
full duplex with its link partner, which would result in bursty
performance.
- Program some of the NatSemi's registers as specified by the datasheet.
The manual says these are necessary for "optimum perofrmance," though
a couple of them are marked as reserved in the register map. *shrug*
- Select the TX DMA burst size correctly for 10 and 100mbps modes.
Previously I was using 64 bytes in both modes, which worked in
100mbps mode, but resulting in spotty performance in 10mbps.
32 bytes works much better; without this change, the natsemi
chip yields piss poor performance at 10mbps.
With these fixes, the NatSemi chip finally performs to my satisfaction.
I should be merging the support for this controller into -stable shortly.
Phew.
that should be better.
The old code counted references to mbuf clusters by using the offset
of the cluster from the start of memory allocated for mbufs and
clusters as an index into an array of chars, which did the reference
counting. If the external storage was not a cluster then reference
counting had to be done by the code using that external storage.
NetBSD's system of linked lists of mbufs was cosidered, but Alfred
felt it would have locking issues when the kernel was made more
SMP friendly.
The system implimented uses a pool of unions to track external
storage. The union contains an int for counting the references and
a pointer for forming a free list. The reference counts are
incremented and decremented atomically and so should be SMP friendly.
This system can track reference counts for any sort of external
storage.
Access to the reference counting stuff is now through macros defined
in mbuf.h, so it should be easier to make changes to the system in
the future.
The possibility of storing the reference count in one of the
referencing mbufs was considered, but was rejected 'cos it would
often leave extra mbufs allocated. Storing the reference count in
the cluster was also considered, but because the external storage
may not be a cluster this isn't an option.
The size of the pool of reference counters is available in the
stats provided by "netstat -m".
PR: 19866
Submitted by: Bosko Milekic <bmilekic@dsuper.net>
Reviewed by: alfred (glanced at by others on -net)
understand exactly what it is about SMPng that tickles this bug. What I
do know is that the foo_init() routine in most drivers is often called
twice when an interface is brought up. One time is due to the ifconfig(8)
command calling the SIOCSIFFLAGS ioctl to set the IFF_UP flag, and another
is probably due to the kernel calling ifp->if_init at some point. In any
case, the SMPng changes seem to affect the timing of these two events in
such a way that there is a significant delay before any packets are sent
onto the wire after the interface is first brought up. This manifested
itself locally as an SMPng test machine which failed to obtain an address
via DHCP when booting up.
It looks like the second call to fxp_init() is happening faster now than
it did before, and I think it catches the chip while it's in the process
of dealing with the configuration command from the first call. Whatever
the case, a FXP_CSR_SCB_CNA interrupt event is now generated shortly after
the second fxp_init() call. (This interrupt is apparently never generated
by a non-SMPng kernel, so nobody noticed.)
There are two problems with this: first, fxp_intr() does not handle the
FXP_CSR_SCB_CNA interrupt event (it never tests for it or does anything
to deal with it), and second, the meaning of FXP_CSR_SCB_CNA is not
documented in the driver. (Apparently it means "command unit not active.")
Bad coder. No biscuit.
The fix is to have the FXP_CSR_SCB_CNA interrupt handled just like the
FXP_SCB_STATACK_CXTNO interrupt. This prevents the state machine for
the configuration/RX filter programming stuff from getting wedged for
several seconds and preventing packet transmission.
Noticed by: jhb
if you kldload this driver, all the subordinate devices are probed/attached
as expected. But this is not the case when the driver is statically compiled
into the kernel. Since I do most of my testing with modules, I failed to
notice this. I'm not sure if it's intended behavior or not. I think it may
be, but it seems a little counter-intuitive.
with LEDs on some cards being stomped on when clearing the "jabber disable"
bit. Using DC_SETBIT() has an unwanted side effect of setting a write enable
bit in the watchdog timer register which we really want to be cleared when
we do a write.
This is in fact an Intel Orion chipset (82454KX/GX) which has been used
in HP NetServer's LS4 range.
HP Probably relabeled the DID. That's the only explanation I can find
plausible to this `mystery'.
the 12.4.11 firmware with a few changes to the link handling code merged
in from the 12.4.13 release. I'm doing this because the 12.4.13 firmware
doesn't seem to handle 10/100 link settings properly on 1000baseT cards.
Note that the revision codes still identify the firmware as 12.4.13
because both ti_fw2.h and ti_fw.h have to have the same revision values,
and I wanted to keep the 12.4.13 firmware for Tigon 1 cards.
It's nice to have firmware source.
cards. This basically involves switching to the 12.4.13 firmware, plus
a couple of minor tweaks to the driver.
Also changed the jumbo buffer allocation scheme just a little to avoid
'failed to allocate jumbo buffer' conditions in certain cases.
lock up under moderate to heavy load.
The status & command fields share a 32-bit longword. The programming
API of the eepro apparently requires that you update the command field
of a transmit slot that you've already given to the card. This means
the card could be updating the status field of the same longword at
the same time. Since alphas can only operate on 32-bit chunks of
memory, both the status & command fields are loaded from memory &
operated on in registers when the following line of C is executed:
sc->cbl_last->cb_command &= ~FXP_CB_COMMAND_S;
The race is caused by the card DMA'ing up the status at just the wrong
time -- after it has been loaded into a register & before it has been
written back. The old value of the status is written back, clobbering
the status the card just DMA'ed up. The fact that the card has sent
this frame is missed & the transmit engine appears to hang.
Luckily, as numerous people on the freebsd-alpha list pointed out, the
load-locked/store-conditional instructions used by the atomic
functions work with respect changes in memory due to I/O devices. We
now use them to safely update the command field.
Tested by: Bernd Walter <ticso@mail.cicely.de>
3.3volt PCI/cardbus chipsets similar to the 98715 (and they have
512-bit hash tables). Also update the man page to mention the 98727/98732
and the SOHOware SFA110A Rev B4 card with the 98715AEC-C chip.
which differ slightly from the Macronix MX98715AEC chip on the sample
adapter that I have in that the multicast hash table is only 128 bits
wide instead of 512. New adapters are popping up with this chip, and
due to improper handling of the smaller hash table, broadcast packets
were not being received correctly.
ether_ifdetach().
The former consolidates the operations of if_attach(), ng_ether_attach(),
and bpfattach(). The latter consolidates the corresponding detach operations.
Reviewed by: julian, freebsd-net
associated patch to XFree86 allows the X server to work with this chipset
on FreeBSD. Additional work will include porting the Linux 3D driver.
Submitted by: Ruslan Ermilov <ru@FreeBSD.org>
controller chip. This chip is currently being used on the NetGear
FA312-TX adapter, which I guess is a replacement for the FA310-TX
(PNIC-based).
I added support for this chip by modifying the sis driver since
the SiS 900 and the NS DP83815 have almost the same programming
interface (the RX filter programming and PHY access methods are
different, but the general configuration, DMA scheme and register
layout are identical).
I would have had this done a lot sooner, but getting the damn MAC
address out of the EEPROM proved to be more complicated than expected.
the message to indicate that it could also be a disconnected cable, and
return okay from wx_hw_intialize *anyway*. This allows us to contineu to
set the station address and when we do get link up, we're ready to roll.
Force alphas to prefer mem mapping as the default.
Basically, we have a pointer to a function which we can call which will
return us a pointer to firmware for the card we have. We call this function
(if it's non-NULL) with the address of our mdvec f/w pointer.
The way this works is that if ispfw (as a module or a static) is loaded,
it initializes the pointer in isp_pci, so we can call into to it to fetch
a pointer to a f/w set.
If ispfw is MOD_UNLOADed, it's retained a pointer to our mdvec f/w pointers,
which then get zeroed out so we don't have any references to data that's
now gone from kernel memory. Removing the f/w saves ~360KBytes.
Alas, there is no autounload mechanism that works for is here.
tested on Intel BX chipsets only. The other agp minidrivers are totally
untested.
The programming api is a subset of the Linux api and is only intended to
be enough for the X server to use. There is also an in-kernel api for the
use of other kernel modules such as the 3D DRI.
21143 chips, I accidentally removed the DC_MII_REDUCED_POLL flag
for all 21143 cards. This caused problems with timer-instigated
TCP retransmits, which happened to occur at the same time as an
MII poll tick on MII-based cards (e.g. D-Link DFE-570TX). Fixed this,
plus made some other cleanups. The autoneg fixes for the non-MII
cards still work. Also tested the PNIC II now that I have one again.
after autoneg so we make sure to set the link state and duplex mode
correctly.
- Make sure to set the 'ignore pause frames' bit on the XMAC.
- Small linewrap fix.
workalike chips (Macronix 98713A/98715 and PNIC II). Timing is somewhat
critical: you need to bring the link as soon as possible after NWAY
is done, and the old one second polling interval was too long. Now
we poll every 10th of a second until NWAY completes (at which point
we return to the 1 second interval again to keep an eye on the link
state).
I tested all the other cards I had on hand to make sure I didn't bust
any of them and they seem to work (including the MII-based 21143 card).
This should fix some autoneg problems with DE500-BA cards and the
built-in 10/100 ethernet on some alpha systems.
(Now before anyone asks why I never noticed this before, the old code
worked just find with the Intel swich I used for testing back in NY.
Apparently not all switches are as picky about the timing.)
"options COMPAT_OLDPCI". This option already existed, but now also tidies
up the declarations in #include <pci/pci*.h>. It is amazing how much stuff
was using the old pre-FreeBSD 3.x names and going silently undetected.
of the individual drivers and into the common routine ether_input().
Also, remove the (incomplete) hack for matching ethernet headers
in the ip_fw code.
The good news: net result of 1016 lines removed, and this should make
bridging now work with *all* Ethernet drivers.
The bad news: it's nearly impossible to test every driver, especially
for bridging, and I was unable to get much testing help on the mailing
lists.
Reviewed by: freebsd-net
for transmit to the adapter, not when we receive a transmit interrupt
indicating that they were sent. This fix now allows tcpdump to produce
sane results by recording the timestamp at the point where the mbuf was
actually transmitted.
the case where we receive a packet that wraps from the end of the
RX buffer back to the start. This fixes an unaligned access trap on
the alpha with NFS.
<sys/bio.h>.
<sys/bio.h> is now a prerequisite for <sys/buf.h> but it shall
not be made a nested include according to bdes teachings on the
subject of nested includes.
Diskdrivers and similar stuff below specfs::strategy() should no
longer need to include <sys/buf.> unless they need caching of data.
Still a few bogus uses of struct buf to track down.
Repocopy by: peter
not u_long. On i386's with 64-bit longs, returning u_longs indirectly
in (more than) the space reserved for uintptr_t's tended to corrupt the
previous frame pointer in the stack frame, so it was not easy to debug.
The type mismatches are hidden by the bogus cast in DEVMETHOD().
Note that if_aue doesn't strictly depend on usb because it uses the
method interface for calls rather than using internal symbols, and
because it's a child driver of usb and therefore will not try and do
anything unless the parent usb code is loaded at some point. if_aue does
strictly depend on miibus as it will fail to link if it is missing.
- Break out the support for the XMAC II's PHY into an miibus driver.
- Reorganize the probe/attach stuff using newbus. Each XMAC is now
attached to the parent GEnesis controller using newbus. This is
necessary since each XMAC must also have an attached miibus, and
the miibus read/write register routines need to be able to get
at the softc struct for each XMAC, not the one for the parent
controller. This allows me to get rid of the grotty code I added
for selecting the unit numbers for the ifnet interfaces: the unit
numbers are now derived from the newbus-assigned unit numbers,
which should track with the ifnet interface numbers. I think.
At the very least, there should never be any collisions.
- Add support for the SK-9821 and SK-9822 1000baseTX adapters. Special
thanks to SysKonnect for loaning me two adapters for testing.
non-device code.
* Re-implement the method dispatch to improve efficiency. The new system
takes about 40ns for a method dispatch on a 300Mhz PII which is only
10ns slower than a direct function call on the same hardware.
This changes the new-bus ABI slightly so make sure you re-compile any
driver modules which you use.
This don't hurt anything.
PCI/CardBus Bridge -> PCI-CardBus Bridge
Submitted by: Takeshi Shibagaki <sibagaki@lsi.melco.co.jp>
Obtained from: bsd-nomads ML in Japan
- Only call m_pullup() when necessary.
- Check return value from rl_encap() in rl_start() to avoid panic when
we run out of mbufs. (Fixes PR kern/17582)
PR: kern/17582
address size that is different than the standard 6bits. This fixes
support for the Compaq NC3121 card, certain newer Intel Pro/100+
cards, and should also fix integrated NICs on SuperMicro and Compaq
motherboards.
The auto-sizing algorithm was taken from NetBSD (thanks!), which I
think got it from Linux originally.
Thanks also to Andrew Sparrow <spadger@best.com> and Joe Moore
<jomor@ahpcns.com> for supplying me with unworking Compaq and Intel
cards to develop and test the fixes with.
cardbus bridge init routine for all cardbuses. This routine attempts
to compensate for BIOSes that do not setup the cardbus bridge into
legacy mode. Since this is becoming more common, and cardbus pci
cards have appeared on the market, this makes sense.
Do some TI113x specific initialization. This came in as part of the
patch. Report TI1[1234]XX specific config registers protected by
bootverbose.
Minor code cleanup while I'm here. I've also removed the unused code
present in the original patches, and cleaned it up slightly in places
as well.
The original patches supported more than one card, but these patches
support just one. We should likely revisit this in the future.
This makes the Compaq card that Walnut Creek CD purchased for me work
in my bouncer box.
This is a MFC candidate. However, I'd like to get some airtime on
these patches on as many laptops as possible before doing the MFC. It
does change things somewhat. In theory, apart from the minor TI
tweaks, this shouldn't change anything if the bridge is in legacy mode
already.
Submitted by: sanpei@sanpei.org (MIHIRA Yoshiro)
Make the public interface more systematically named.
Remove the alternate method, it doesn't do any good, only ruins performance.
Add counters to profile the usage of the 8 access functions.
Apply the beer-ware to my code.
The weird +/- counts are caused by two repocopies behind the scenes:
kern/kern_clock.c -> kern/kern_tc.c
sys/time.h -> sys/timetc.h
(thanks peter!)
it's options COMPAT_OLDISA and COMPAT_OLDPCI. This is meant to be a
fairly strong incentive to update the older drivers to newbus, but doesn't
(quite) leave anybody hanging with no hardware support. I was talking with
a few folks and I was encouraged to simply break or disable the shims but
that was a bit too drastic for my liking.
platform we're running on so we know how many bits to reserve at the top
end for the 'hose' value. It turns out that there's *just* enough room
to support all possible hoses on TurboLaser.
Reviewed by: gallatin@freebsd.org, dfr@free3bsd.org
from useful drivers such as the 3D DRI drivers I will be porting for
hardware accelerated OpenGL. The hardware will still be reported during
boot using the nomatch system.
Approved by: jkh
the PIRQD bit.
This fixes the problem of uhub0 hanging forever during boot when USB
keyboard support is switched on in the BIOS on motherboards with Intel
chipsets (UHCI).
Approved by: The Sheep
conversion to eliminate the compatability shims without making any
significant changes. This eliminates the shim warnings.
Obtained from: n_himba (tweaked by me, don't blame him for this)
Approved by: jkh
bus_delete_resource.
Fixes a problem when the probe succeeded, but the attach failed. The
release of the resources was done inproperly.
Approved by: jkh
are using an old unconverted driver. Most (if not all) of the drivers
for common hardware are newbus these days. However, we don't want
to encourage people to take the easy way out and write new drivers
using the shims. This is just passive "encouragement".
Reviewed by: phk
the receive code so that it correctly chains receive descriptors together
and handles the case that only a part of a packet is done at the time
we get here.
This is just to make sure we initialize the chip correctly: we need to
make the sure the port select bit in CSR6 is set properly so that we
use the internal PHY for 10/100 support. (The eval boards I have also
include an external HomePNA PHY, but I need to play with that more
before I can support it.)
Collect together the components of several drivers and export eisa from
the i386-only area (It's not, it's on some alphas too). The code hasn't
been updated to work on the Alpha yet, but that can come later.
Repository copies were done a while ago.
Moving these now keeps them in consistant place across the 4.x series
as the newbusification progresses.
Submitted by: mdodd
packets into a single buffer, and set the DC_TX_COALESCE flag for the
Davicom DM9102 chip. I thought I had escaped this problem, but... This
chip appears to silently corrupt or discard transmitted frames when
using scatter/gather DMA (i.e. DMAing each packet fragment in place
with a separate descriptor). The only way to insure reliable transmission
is to coalesce transmitted packets into a single cluster buffer. (There
may also be an alignment constraint here, but mbuf cluster buffers are
naturally aligned on 2K boundaries, which seems to be good enough.)
The DM9102 driver for Linux written by Davicom also uses this workaround.
Unfortunately, the Davicom datasheet has no errata section describing
this or any other apparently known defect.
Problem noted by: allan_chou@davicom.com.tw
makes it a little easier to notice that parity checking an 8bit sram
isn't working.
Turn on scb and internal data-path parity checking for all pci chips types.
We were only doing this for ultra2 chips.
After clearing the parity interrupt status, clear the BRKADRINT. This
avoids seeing a bogus BRKADRINT interrupt after external SCB probing
once normal interrupts are enabled.
controllers will run at U2 speeds until I can complete the U160 support
for this driver.
Correct a termination buglet for the 2940UW-Pro.
Be more paranoid in how we probe and enable external ram, fast external
ram timing and external ram parity checking. We should now work on
20ns and 8bit SRAM parts.
Perform initial setup for the DT feature on cards that support it.
Factorize and clean up code. Use tables where it makes sense, etc.
Add some delays in dealing with the board control logic. I've never
seen this code fail, but with the ever increasing speed of processors,
its better to insert deterministic delays just to be safe. This stuff
is only touched during probe and attach, so the extra delay is of no
concern.
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.
The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).
The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.
This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.
This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.
I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
down, the dc driver and receiver can fall out of sync with one another,
resulting in a condition where the chip continues to receive packets
but the driver never notices. Normally, the receive handler checks each
descriptor starting from the current producer index to see if the chip
has relinquished ownership, indicating that a packet has been received.
The driver hands the packet off to ether_input() and then prepares the
descriptor to receive another frame before moving on to the next
descriptor in the ring. But sometimes, the chip appears to skip a
descriptor. This leaves the driver testing the status word in a descriptor
that never gets updated. The driver still gets "RX done" interrupts but
never advances further into the RX ring, until the ring fills up and the
chip interrupts again to signal an error condition. Sometimes, the
driver will remain in this desynchronized state, resulting in spotty
performance until the interface is reset.
Fortunately, it's fairly simple to detect this condition: if we call
the rxeof routine but the number of received packets doesn't increase,
we suspect that there could be a problem. In this case, we call a new
routine called dc_rx_resync(), which scans ahead in the RX ring to see
if there's a frame waiting for us somewhere beyond that the driver thinks
is the current producer index. If it finds one, it bumps up the index
and calls the rxeof handler again to snarf up the packet and bring the
driver back in sync with the chip. (It may actually do this several times
in the event that there's more than one "hole" in the ring.)
So far the only card supported by if_dc which has exhibited this problem
is a LinkSys LNE100TX v2.0 (82c115 PNIC II), and it only seems to happen
on one particular system, however the fix is general enough and has low
enough overhead that we may as well apply it for all supported chipsets.
I also implemented the same fix for the 3Com xl driver, which is apparently
vulnerable to the same problem.
Problem originally noted and patch tested by: Matt Dillon
