- 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)
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).
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().
- 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.
- 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.
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
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.
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.
if we need a valid MAC address (for probing the media for example) before
ether_ifattach() has been called since IF_LLADDR() is NULL then.
Tested by: tisco
the addition of pci_find_extcap().
- Change the drm drivers to attach to vgapci. This is #ifdef'd so the
code can be shared across branches.
- Use pci_find_extcap() to look for AGP and PCIE capabilities in drm.
- GC all the drmsub stuff for i810/i830/i915. The agp and drm devices are
now both children of vgapci.
attach to the hostb driver instead. This means that agp can now be loaded
at runtime (in theory at least). Also, the drivers no longer have to
explicity call device_verbose() to cancel out any earlier calls to
device_quiet() by the hostb(4) driver (this shows a limitation in new-bus,
drivers really shouldn't be doing device_quiet() until they know they are
going to drive that device, i.e. in attach).
drivers already map sections into KVA as needed anyway. Note that this
will probably break the nvidia driver, but I will coordinate to get that
fixed.
MFC after: 2 weeks
AMD-8111 SMBus 2.0 controller) are all SMBus 2.0 controllers,
and need another implementation of SMBus access methods, while
this driver supports AMD-756 SMBus 1.0 controller and clones,
including AMD-8111 SMBus 1.0 controller.
Tested by: Vladimir Timofeev (0x006410de),
mezz (0x008410de),
ru (0x00d410de)
All of us got the same(!) nonsense when running ``mbmon -S'',
repeated every four rows.
SMBus 1.0 and not SMBus 2.0.
AMD-8111 hub (datasheet is publically available) implements both SMBus
2.0 (a separate PCI device) and SMBus 1.0 (a subfunction of the System
Management Controller device with the base I/O address is accessible
through the CSR 0x58). This driver only supports AMD-756 SMBus 1.0
compatible devices.
With the patched sysutils/xmbmon port (to also fix PCI ID and to enable
smb(4) support), I now get:
pciconf:
none0@pci0:7:2: class=0x0c0500 card=0x746a1022 chip=0x746a1022 rev=0x02 hdr=0x00
vendor = 'Advanced Micro Devices (AMD)'
device = 'AMD-8111 SMBus 2.0 Controller'
class = serial bus
subclass = SMBus
amdpm0@pci0:7:3: class=0x068000 card=0x746b1022 chip=0x746b1022 rev=0x05 hdr=0x00
vendor = 'Advanced Micro Devices (AMD)'
device = 'AMD-8111 ACPI System Management Controller'
class = bridge
dmesg:
amdpm0: <AMD 756/766/768/8111 Power Management Controller> port 0x10e0-0x10ff at device 7.3 on pci0
smbus0: <System Management Bus> on amdpm0
# mbmon -A -d
Summary of Detection:
* SMB monitor(s)[ioctl:AMD8111]:
** Winbond Chip W83627HF/THF/THF-A found at slave address: 0x50.
** Analog Dev. Chip ADM1027 found at slave address: 0x5C.
* ISA monitor(s):
** Winbond Chip W83627HF/THF/THF-A found.
I think the confusion comes from the fact that nobody really tried
SMBus with xmbmon :-), since sysutils/xmbmon port doesn't come with
SMBus support enabled, neither in FreeBSD 4, nor in later versions,
so mbmon(1) was just showing the values from the Winbond sensors
accessible through the ISA I/O method (mbmon -I), for me anyway.
On my test machine, the amdpm(4) didn't even attach due to I/O port
allocation failure (who knows what the hell it read from CSR 0x58
of the SMBus 2.0 device :-), which isn't in the CSR space).
I've also checked that lm_sensors.org uses correct PCI ID for SMBus
1.0 of AMD-8111:
i2c-amd756.c: {PCI_VENDOR_ID_AMD, 0x746B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AMD8111 },
This driver is analogous to our amdpm.c which supports SMBus 1.0
AMD-756 and compatible devices, including SMBus 1.0 on AMD-8111.
i2c-amd8111.c: { 0x1022, 0x746a, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
This driver is analogous to nForce-2/3/4, i2c-nforce2.c, which
supports SMBus 2.0, and which our amdpm.c does NOT support
(SMBus 2.0 uses a different, ACPI-unified, API to talk to SMBus).
At least I know for sure it doesn't work with my nForce3. :-)
(The xmbmon port will be fixed to correct the PCI ID too and to
enable the smb(4) support.)
SMBus busses. Because of limitations in smbus_if.m, the second smbus is
attached to an amdpm1 device that is a child of amdpm0.
Submitted by: Artemiev Igor ai (at) bmc dot brk dot ru
and some fixes from Motomichi Matsuzaki. Testing involved many people, but the
final, successful testing was from rwatson who endured several rounds of "it
crashes at XYZ stage" "oh, please correct this typo and try again." The Linux
driver, and to a small extent the limited specs, were both used as a reference
for how to program the chipset.
PR: kern/80396
Submitted by: Martin Mersberger
- Don't call tulip_addr_filter() to reset the RX address filter in
tulip_reset() since that gets called before ether_ifattach(). Just
call it in tulip_init_locked().
- Use be16dec() and le16dec() to parse MAC addresses when programming
the RX filter.
- Let ether_ioctl() handle SIOCSIFMTU since we were doing the exact same
thing with the added bonus that we leaked the driver lock if the MTU
was > ETHERMTU in the homerolled version. This part will be MFC'd.
Clue from: wpaul (1)
Stolen from: marcel (2 via patch for dc(4))
MFC after: 1 week
rather than in ifindex_table[]; all (except one) accesses are
through ifp anyway. IF_LLADDR() works faster, and all (except
one) ifaddr_byindex() users were converted to use ifp->if_addr.
- Stop storing a (pointer to) Ethernet address in "struct arpcom",
and drop the IFP2ENADDR() macro; all users have been converted
to use IF_LLADDR() instead.
PCI-ISA bridge. Thus, when viapm0 or viapropm0 attaches, isab0 dosen't
attach so there is no isa0 bus hung off of that bridge. In the non-ACPI
case, legacy0 will add an isa0 anyway as a fail-safe, but ACPI assumes that
any ISA bus will be enumerated via a bridge. To fix this, call
isab_attach() to attach an isa0 ISA child bus device if the pm or propm
device we are probing is a PCI-ISA bridge. Both drivers now have to
implement the bus_if interface via the generic methods for resource
allocation, etc. to work. Also, we now add 2 new ISA bus drivers that
attach to viapm and viapropm devices.
PR: kern/87363
Reported by: Oliver Fromme olli at secnetix dot de
Tested by: glebius
MFC after: 1 week
With this change, the driver tests good (at least on i386):
wb0: <Winbond W89C840F 10/100BaseTX> port 0xb800-0xb87f mem 0xe6800000-0xe680007f irq 12 at device 10.0 on pci0
miibus1: <MII bus> on wb0
amphy0: <Am79C873 10/100 media interface> on miibus1
amphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
wb0: Ethernet address: 00:00:e8:18:2a:02
wb0: link state changed to DOWN
wb0: link state changed to UP
- Add locked variants of init() and start().
- Use callout_*() to manage callout.
- Test IFF_DRV_RUNNING rather than IFF_UP in wb_intr() to see if we are
still active when an interrupt comes in.
I couldn't find any of these cards anywhere to test on myself, and google
turns up references to FreeBSD and OpenBSD manpages for this driver when
trying to locate a card that way. I'm not sure anyone actually uses these
cards with FreeBSD.
Tested by: NO ONE (despite repeated requests)
I had to initialize the ifnet a bit earlier in attach so that the
if_printf()'s in vr_reset() didn't explode with a page fault.
- Use M_ZERO with contigmalloc() rather than an explicit bzero.
cards and teach the re(4) driver to attach to revision 3 cards.
Submitted by: Fredrik Lindberg fli+freebsd-current at shapeshifter dot se
MFC after: 2 weeks
Reviewed by: imp, mdodd
based on XMAC II chip should be ready for this in their initial
mode of operation, and Yukon-based NICs are configured so by
the driver.
PR: kern/79998
MFC after: 1 month
opt_device_polling.h
- Include opt_device_polling.h into appropriate files.
- Embrace with HAVE_KERNEL_OPTION_HEADERS the include in the files that
can be compiled as loadable modules.
Reviewed by: bde
o Axe poll in trap.
o Axe IFF_POLLING flag from if_flags.
o Rework revision 1.21 (Giant removal), in such a way that
poll_mtx is not dropped during call to polling handler.
This fixes problem with idle polling.
o Make registration and deregistration from polling in a
functional way, insted of next tick/interrupt.
o Obsolete kern.polling.enable. Polling is turned on/off
with ifconfig.
Detailed kern_poll.c changes:
- Remove polling handler flags, introduced in 1.21. The are not
needed now.
- Forget and do not check if_flags, if_capenable and if_drv_flags.
- Call all registered polling handlers unconditionally.
- Do not drop poll_mtx, when entering polling handlers.
- In ether_poll() NET_LOCK_GIANT prior to locking poll_mtx.
- In netisr_poll() axe the block, where polling code asks drivers
to unregister.
- In netisr_poll() and ether_poll() do polling always, if any
handlers are present.
- In ether_poll_[de]register() remove a lot of error hiding code. Assert
that arguments are correct, instead.
- In ether_poll_[de]register() use standard return values in case of
error or success.
- Introduce poll_switch() that is a sysctl handler for kern.polling.enable.
poll_switch() goes through interface list and enabled/disables polling.
A message that kern.polling.enable is deprecated is printed.
Detailed driver changes:
- On attach driver announces IFCAP_POLLING in if_capabilities, but
not in if_capenable.
- On detach driver calls ether_poll_deregister() if polling is enabled.
- In polling handler driver obtains its lock and checks IFF_DRV_RUNNING
flag. If there is no, then unlocks and returns.
- In ioctl handler driver checks for IFCAP_POLLING flag requested to
be set or cleared. Driver first calls ether_poll_[de]register(), then
obtains driver lock and [dis/en]ables interrupts.
- In interrupt handler driver checks IFCAP_POLLING flag in if_capenable.
If present, then returns.This is important to protect from spurious
interrupts.
Reviewed by: ru, sam, jhb
the softc.
- Use callout_init_mtx() and rather than timeout/untimeout in both rl(4)
and re(4).
- Fix locking for ifmedia by locking the driver in the ifmedia handlers
rather than in the miibus functions. (re(4) didn't lock the mii stuff
at all!)
- Fix some locking in re_ioctl().
Note: the two drivers share the same softc declared in if_rlreg.h, so they
had to be change simultaneously.
MFC after: 1 week
Tested by: several on rl(4), none on re(4)
control register and AGP bridge seems to be inconsistent with some BIOS.
Instead of relying on BIOS settings, we just take the initial aperture size
and encode them for both miscellaneous control register and AGP bridge.
Some idea was borrowed from agp_nvidia.c.
- Add preliminary ULi M1689 chipset support. The idea was taken from Linux
because hardware and documentation are unavailable. Not tested.
- Add more VIA chipset PCI IDs taken from Linux driver.
Approved by: anholt (mentor)
Tested by: Adam Gregoire <ebola at psychoholics dot org>
Ganael Laplanche <ganael.laplanche at martymac dot com>
K Wieland <kwieland at wustl dot edu>
replacement and has additional features which make it superior.
Discussed on: -arch
Reviewed by: thompsa
X-MFC-after: never (RELENG_6 as transition period)
- Remove sis_unit and use device_printf() and if_printf() instead.
- Use callout_init_mtx() for the callout.
- Remove spls.
- Fix locking for ifmedia to happen in the ifmedia handlers rather than in
sis_ioctl().
- Log an error message if we fail to allocate any resources. Perform
cleanup if we fail to allocate any resources so that we don't leave
a mutex hanging around.
Tested by: Jason Tsai jason dot tsai at newcyberian dot com (1-4)
MFC after: 3 days
the Linux driver, since specs are unavailable. Many thanks to Adam Kirchhoff
for multiple useful testing cycles, and Ralf Wostrack for the final fix to get
it working.
PR: i386/75251
Submitted by: anholt
9200 according to one responder. The primary issue was not setting some bits
to say that the entries were active, but also fix one place where some memory
wasn't being used as volatile as it should. While here, change some use of ffs
to a relatively short case statement, to make it more obvious what's going on.
PR: kern/71638, kern/72372, kern/71547?
Submitted by: Andrew J. Caines <A.J.Caines@halplant.com>,
Robin Schoonover <end@endif.cjb.net>,
Jason Henson <jason@ec.rr.com>
attempts to deallocate busdma tags and resources that haven't been
allocated yet, causing a panic every time a dc interface fails to
attach. Fix by checking that we really have something to dealloc
before calling bus_dma*() functions.
Approved by: jhb
MFC after: 1 week
- Use callout_init_mtx() and static callouts rather than timeout().
- m_getcl() in one place to simplify the code.
Tested by: Gavin Atkinson gavin dot atkinson at ury dot york dot ac dot uk
MFC after: 1 week
- Add locked variants of start(), init(), ifmedia_upd(), and poll() and stop
recursing on the driver lock.
- Add locking to ifmedia_upd() and ifmedia_sts().
- Use callout_*() instead of timeout/untimeout.
- Fix locking in ioctl().
Tested by: Bob Bishop rb at gid dot co dot uk
MFC after: 3 days
tulip_mbuf_compress(). If we fail to allocate a new mbuf to copy the
data into, put the mbuf back in the driver's send queue so that we can
retry it later rather than throwing the packet away.
- Use m_devget() instead of doing it inline ourselves in the
TULIP_COPY_RXDATA case. If we fail to allocate an mbuf to copy the data
into, don't forget about the original mbuf cluster. The old code would
lose the pointer and leak the cluster in that case. Now it doesn't lose
it but always sticks the original rx buffer back into the receive ring
after trying to copy the data out and send it up the stack. Also, if we
fail to allocate a new mbuf to copy the data into, log an input error.
Also, don't combine the priming case with the received-a-packet case to
make the code flow a bit clearer and easier to follow.
- Remove form feed characters.
- Fixup style of function declarations.
- Assume that an mbuf cluster is big enough to hold an ethernet frame.
(This should really be using m_defrag(), but this diff is just simple
changes for now.)
- Allocate arrays of metadata for the descriptors in the rx and tx rings
and change the ring pointers to walk the metadata array rather than the
actual descriptor rings. Each metadata object contains a pointer to its
descriptor, a pointer to any associated mbuf, and a pointer to the
associated bus_dmamap_t in the bus_dma case. The mbuf pointers replace
the tulip_txq and tulip_rxq local ifqueue's in the softc.
- Add lots of KTR trace entries using a local KTR_TULIP level which
defaults to 0, but can be changed to KTR_DEV at the top of the file
when debugging.
- Rename tulip_init(), tulip_start(), tulip_ifinit(), and tulip_ifstart()
to tulip_init_locked(), tulip_start_locked(), tulip_init(), and
tulip_start(), respectively, to match the convention in other drivers.
- Add a TULIP_SP_MAC() macro to encode two bytes of the MAC address into
the setup buffer and use that in place of lots of BYTE_ORDER #ifdef's.
Also, remove an incorrect XXX comment I added earlier, the driver was
correct (at least it does the same thing dc(4) does). TULIP_SP_MAC
was shamelessly copied from DC_SP_MAC() in dc(4).
- Remove the #ifdef'd NetBSD bus-dma code and replace it with FreeBSD
bus-dma code that not only compiles but even works at runtime.
- Use callout_init_mtx() instead of just callout_init().
- Correct the various wrapper macros for bus_dmamap_sync() for the rx
and tx buffers to only ask for the sync ops that they actually need.
- Tidy the #ifdef TULIP_COPY_RXDATA code by expanding an #ifdef a bit
so it becomes easier to read at the expense of a couple of duplicated
lines of code. Also, use m_getcl() to get an mbuf cluster rather than
MGETHDR() followed by MCLGET().
- Maintain the ring free (ri_free) count for the rx ring metadata since
we no longer have tulip_rxq.ifq_len around to indicate how many mbuf's
are currently in the rx ring.
- Add code to teardown bus_dma resources when attach fails and generally
fixup attach to do a better job of cleaning up when it fails. This
gets us a good bit closer to possibly having a detach method someday
and making this driver an unloadable module.
- Add some functions that can be called from ddb to dump the state of
a descriptor ring and to dump the state of an individual descriptor.
- Various comment grammer and spelling fixes.
I have bus-dma turned on by default, but I've left the non-bus-dma code
around so that it can be turned off to aid in debugging should any problems
turn up later on. I'll be removing the non-bus-dma code in a subsequent
commit.
- Remove a lot of superfluous locking during attach. There is no need
to lock access to the driver until some other thread has a way of getting
to it. For ethernet drivers the other ways include registering an
interrupt handler via bus_setup_intr(), calling ether_ifattach() to hook
into the network stack, and kicking off a callout-driven timer via
callout_reset().
- Use callout_* rather than timeout/untimeout.
- Break out of xl_rxeof() if IFF_DRV_RUNNING is clear after ifp->if_input
returns to handle the case where the interface was stopped while we were
passing a packet up the stack. Don't call xl_rxeof() in xl_rxeof_task()
unless IFF_DRV_RUNNING is set. With these fixes in place, any
outstanding task will gracefully terminate as soon as it gets a chance to
run after the interface has been stopped via xl_stop(). As a result,
taskqueue_drain() is no longer required in xl_stop(). The task is still
drained in detach() however to make sure that detach() can safely destroy
the driver mutex at the end of the function.
- Lock the driver lock in the ifmedia callouts and don't lock across
ifmedia_ioctl() in xl_ioctl().
Note: glebius came up with most of (3) as well independently. I took a
rather roundabout way of arriving at the same conclusion.
MFC after: 3 days
- Add locked versions of start and init. The SRM_MEDIA code in dc_init()
stayed in dc_init() instead of moving to dc_init_locked() to make the
locking saner.
- Use callout_init_mtx().
- Fixup locking in detach and ioctl.
- Lock the driver in the ifmedia callouts.
- Don't recurse on the driver lock.
- De-spl.
MFC after: 3 days
- Add locked variants of start, init, and ifmedia_upd.
- Use callout_* instead of timeout/untimeout.
- Don't recurse on the driver lock.
- Fixup locking in ioctl.
- Lock the driver lock in the ifmedia handlers rather than across
ifmedia_ioctl().
Tested by: brueffer
MFC after: 3 days
- Don't set IFF_ALLMULTI in our ifnet's if_flags if we end up allowing
all multicast due to limits in the MAC receive filters in hardware.
Requested by: rwatson (2)
