POSTWRITE to POSTREAD.
No guarantee that all busdma is usage is perfect, but this change (in
addition to scott's last two commits) makes if_bfe work with > 1GB of
memory in my laptop.
OpenBSD changes. With these changes, PHY part of the driver becomes
functional (it senses media changes and negotiates speed just fine),
previously it just hang with no PHY message, but no data goes through
interface (error message is "can not stop transfer of Tx/Rx descriptor).
Hopefully somebody with more clue/free time will be able to pick up
after me.
Changelog towards if_iwi.c 1.26 (some changes have been committed separately
in the mean time):
- add led support
- add firmware loading on demand
- auto-restart firmware when it crashes
- serialize operations sent to the firmware to reduce firmware crashes
- add power save operation support
- remove incorrect specification of tx power control capability
- add radio on/off switch support
- improve net80211 state machine operation
- recognize and handle beacon miss
- handle authentication and association failures better
- add shared key authentication
- fix ibss mode (many changes)
- fix wme (many changes)
- correct radiotap support (many changes)
- correct bus dma setup of s/g
- correct various locking issues
- fix monitor mode
- fix scanning (many changes)
- recover from wedged scan requests
- respect active channel list
- eliminate cases where interface was marked down on error
- don't treat parity errors as fatal
- reclaim mgt frames immediately from tx queue
- correct interrupt handling, ack early (from NetBSD)
- fix short/long preamble handling
Committed with RELENG_6 compat #if's, should compile in RELENG_6. Requires
net/iwi-firmware-kmod to function.
Much work done by: sam
Tested by: many (freebsd-net), ume, luigi
MFC after: 4 weeks
This driver was generously developed and donated by Highpoint.
It is enabled for i386 only at the moment. I will enable it for amd64
shortly.
Obtained from: HighPoint Technologies, Inc.
- MPSAFE. No more recursive lock required.
- bus_dma(9) conversion. I think it should work on all architectures.
- optimized Rx handler for each normal and jumbo frames. Previously
sk(4) used jumbo frame management code to handle normal sized
frames. As the handler needs an additional lock to protect jumbo
frame management structure from races, it used two lock operations
for each received packet. Now sk(4) uses single lock operation for
normal frame.(Jumbo frame still needs two lock operations as before.)
The hardware supports DMA scatter operations for Rx descriptors such
that it's possible to take advantagee of m_cljget(9) for jumbo frames.
However, due to a unknown reasons it resulted in poor performance on
sparc64. So I dropped m_cljget(9) approach. This should be revisited
since it would reduce one lock operation for jumbo frame handling.
- Tx TCP/Rx IP checksum offload support. According to the data sheet
of SK-NET GENESIS the hardware supports Rx IP/TCP/UDP offload.
But I couldn't make it work on my Yukon hardware. So Rx TCP/UDP was
disabled at the moment. It seems that newer Yukon chips can support
Tx UDP checksum offload too. But I need more documentation first.
- Added more wait time in reading VPD data. It seems that ASUS LOM
takes a very long time to respond VPD read signal.
- Added an additional lock for MII register access callbacks.
- Added more strict received packet validation routine. Previously it
passed corrupted packets to upper layers under certain conditions.
- A new function sk_yukon_tick() to handle auto-negotiation properly.
- Interrupt handler now checks shared interrupt source and protects
the interrupt handler from NULL pointer dereference which was caused
by odd status word value. The status word can returns 0xffffffff if
cable is unplugged while Rx/Tx/auto-negotiation is in progress.
- suspend/resume support(not tested).
- Added Rx/Tx FIFO flush routine for Yukon
- Activate Tx descriptor poll timer in order to protect possible loss
of SK_TXBMU_TX_START command. Previously the driver continuously issued
SK_TXBMU_TX_START when it notices pending Tx descriptors not processed
yet in interrupt handler. That approach would add additional PCI
write access overhead under high Tx load situations and it might fail
if the first SK_TXBMU_TX_START was lost and no interrupt is generated
from the first SK_TXBMU_TX_START command.
- s/printf/if_printf/, s/printf/device_printf/, Axe sk_unit in softc.
- Setting multicast/station address is now safe on strict-alignment
architectures.
- Fix long standing bug in VLAN header length setup.
- Added/corrected register definitions for Yukon.
(Register information from Linux skge driver.)
- Added Rx status definition for Marvell Yukon/XaQti XMAC.
(Rx status register information from Linux skge driver.)
- Update if_oerrors if we encounter watchdog error.
- callout(9) conversion
Special thanks to jkim who let me know RX status differences between
Yukon and XaQti XMAC.
It seems that there is still occasional watchdog timeout error but I
couldn't reproduce it and need more information to analyze it from
users.
Tested by: bz(amd64), me(i386, sparc64), current ML
Frank Behrens frank ! pinky ( sax $ de
Lower the minimum for memory mapped I/O from 32 bytes to 16 bytes.
This fixes bus enumeration on ia64 now that the Diva auxiliary
serial port is attached to.
channel number since we're not ready at the net80211 layer to deal with them;
note this mapping has to match what's done in ieee80211_mhz2ieee
MFC after: 3 days
controller as we use in boot blocks (querying status register until
bit 1 goes off). If that doesn't happed during reasonable period assume
that the hardware doesn't have AT-style keyboard controller. This makes
FreeBSD working almost OOB on MacBook Pro (still there are issues with
putting second CPU core on-line, but since installation CD comes with
UP kernel with this change one should be able to install FreeBSD without
playing tricks with hints). Other legacy-free hardware (e.g. IBM NetVista
S40) should benefit from this as well, but since I don't have any I can't
verify.
It should make no difference on the ordinary i386 hardware (since in
that case that hardware already would be having an issues with A20
routines in boot blocks). I don't know much about AT-style keyboard
controller on other platforms (and don't have dedicated access to one),
therefore, the code is restricted to i386 for now. I suspect that amd64
may need this as well, but I would rather leave this decision to someone
who knows better about the platform(s) in question.
I have tested this change on as many "ordinary i386 boxes" as I can get
my hands on, and it doesn't create any false negatives on hardware with
AT-style keyboard present.
MFC after: 1 month
This allows one to change the behavior of the driver pre-boot.
NOTE: This patch was made for DragonFly BSD by Sepherosa Ziehau.
PR: kern/94833
Submitted by: Devon H. O'Dell
Obtained from: DragonFly
MFC after: 1 month
end for isa(4).
o Add a seperate bus frontend for acpi(4) and allow ISA DMA for
it when ISA is configured in the kernel. This allows acpi(4)
attachments in non-ISA configurations, as is possible for ia64.
o Add a seperate bus frontend for pci(4) and detect known single
port parallel cards.
o Merge PC98 specific changes under pc98/cbus into the MI driver.
The changes are minor enough for conditional compilation and
in this form invites better abstraction.
o Have ppc(4) usabled on all platforms, now that ISA specifics
are untangled enough.
A slight difference of this chip from its previous siblings is that
it need a gentle "wake up" on every (full) DMA buffer completion to
avoid stalled interrupt handler.
Thanks to George Hartzell for permission on doing remote debugging.
Prime MFC candidate for 6.1-RELEASE. Please reply to this commit if
there are any objections (so I won't bug re@), since the changes
are too small and only specific to VT8251.
PR: i386/95949
Tested by: [1] George Hartzel
myself (remotely)
MFC after: 3 days
[1] http://lists.freebsd.org/pipermail/freebsd-multimedia/2006-April/004003.html
Pull in some target mode changes from a private branch.
Pull in some more RELENG_4 compilation changes.
A lot of lines changed, but not much content change yet.
state structure. This field is only for CCBs that are associated with
actions that are occurring on the HBA (i.e., XPT_CONT_IO actions).
This way we also don't get confused when the upstream listener stalls
try and look at a CCB which has already been freed (by CAM).
as pcf_ebus and pcf_isa, they should probably be fixed back to pcf),
and bti2c doesn't exist, bktr has smbus or iicbb as children..
Brought to you by: http://people.FreeBSD.org/~jmg/driver.pdf
if the specified priority is zero. This avoids a race where the calling
thread could read a snapshot of it's current priority, then a different
thread could change the first thread's priority, then the original thread
would call sched_prio() inside msleep() undoing the change made by the
second thread. I used a priority of zero as no thread that calls msleep()
or tsleep() should be specifying a priority of zero anyway.
The various places that passed 'curthread->td_priority' or some variant
as the priority now pass 0.
have not been passed to the h/w yet. This remedies watchdog timeout
of buffered multicast frames in hostap mode.
While here eliminate an extraneous check; ieee80211_beacon_update sets
the tim bit based on ncabq != 0 so there's no reason to check it too.
Noticed by: Christophe Prevotaux
+ Add boatloads of KASSERTs and *really* check out more locking
issues (to catch recursions when we actually go to real locking
in CAM soon). The KASSERTs also caught lots of other issues like
using commands that were put back on free lists, etc.
+ Target mode: role setting is derived directly from port capabilities.
There is no need to set a role any more. Some target mode resources
are allocated early on (ELS), but target command buffer allocation
is deferred until the first lun enable.
+ Fix some breakages I introduced with target mode in that some commands
are *repeating* commands. That is, the reply shows up but the command
isn't really done (we don't free it). We still need to take it off the
pending list because when we resubmit it, bad things then happen.
+ Fix more of the way that timed out commands and bus reset is done. The
actual TMF response code was being ignored.
+ For SPI, honor BIOS settings. This doesn't quite fix the problems we've
seen where we can't seem to (re)negotiate U320 on all drives but avoids
it instead by letting us honor the BIOS settings. I'm sure this is not
quite right and will have to change again soon.
Radeon memmap code, which with a new DDX driver and DRI drivers should fix
long-term stability issues with Radeons. Also adds support for r200's
ATI_fragment_shader, r300 texrect support and texture caching fixes, i915
vblank support and bugfixes, and new PCI IDs.
The real problem was that ioctl handlers needed to call amr_wait_command()
with the list lock held. This not only solves the completion race, it also
prevents bounce buffer corruption that could arise from amr_start() being
called without the proper locks held.
Discussed with: ps
MFC After: 3 days
the completion of the command can occur before tsleep is called and
the command ends up blocking forever since the wakeup has already
been called.
Submitted by: ups
new chips and improves support for already supported ones.
Some details, important for future merges:
- if_em.c merged manually, viewing diff between new vendor
driver and previous one.
- if_em_hw.h dropped in from vendor, and then restored revisions
1.16, 1.17, 1.18.
- if_em_hw.c dropped in from vendor, and then two liner change made,
that restores support for two rare chips.
the NS8250 class driver. The UART has FIFOs if sc_rxfifosz>1, so
test for that instead.
While here properly initialize sc_rxfifosz and sc_txfifosz in the
case the UART doesn't have FIFOs.
There's something strange going on with async events. They seem
to be be treated differently for different Fusion implementations.
Some will really tell you when it's okay to free the request that
started them. Some won't. Very disconcerting.
This is particularily bad when the chip (FC in this case) tells you
in the reply that it's not a continuation reply, which means you
can free the request that its associated with. However, if you do
that, I've found that additional async event replies come back for
that message context after you freed it. Very Bad Things Happen.
Put in a reply register debounce. Warn about out of range context
indices. Use more MPILIB defines where possible. Replace bzero with
memset. Add tons more KASSERTS. Do a *lot* more request free list
auditting and serial number usages. Get rid of the warning about
the short IOC Facts Reply. Go back to 16 bits of context index.
Do a lot more target state auditting as well. Make a tag out
of not only the ioindex but the request index as well and worry
less about keeping a full serial number.
a different register shift and is fed by a different clock than
we use for UltraSPARC hardware. To deal with this, the regshft and
rclk fields in the class structure are removed and bus frontends
now pass the right regshft and rclk to the probe function where
they're put in the BAS and passed in to subordinate drivers.
--------------------
- Seal the fate of long standing memory leak (4 years, 7 months) during
pcm_unregister(). While destroying cdevs, scan / detect possible
children and free its SLIST placeholder properly.
- Optimize channel allocation / numbering even further. Do brute cyclic
checking only if the channel numbering screwed.
- Mega vchan create/destroy cleanup:
o Implement pcm_setvchans() so everybody can use it freely instead
of implementing their own, be it through sysctl or channel auto
allocation.
o Increase vchan creation/destruction resiliency:
+ it's possible to increase/decrease total vchans even during
busy playback/recording. Busy channel will be left alone, untouched.
Abusive test sample:
# play whatever...
#
while : ; do
sysctl hw.snd.pcm0.vchans=1
sysctl hw.snd.pcm0.vchans=10
sysctl hw.snd.pcm0.vchans=100
sysctl hw.snd.pcm0.vchans=200
done
# Play something else, leave above loop running frantically.
+ Seal another 4 years old bug where it is possible to destroy (virtual)
channel even when its cdevs being referenced by other process.
The "First Come First Served" nature of dsp_clone() is the main
culprit of this issue, and usually manifest itself as dangling
channel <-> process association. Ensure that all of its cdevs
are free from being referenced before destroying it (through
ORPHAN_CDEVT() macross).
All these fixes (including previous fixes) will be MFCed, later.
to avoid possible device unregister race (impossible to reproduce, yet
possible).
- Extra sanity check to ensure proper parent channel is being selected.
- Reset parent channel once all of its children gone.
controllers typically have multiple channels and support a number
of serial communications protocols. The scc(4) driver is itself
an umbrella driver that delegates the control over each channel
and mode to a subordinate driver (like uart(4)).
The scc(4) driver supports the Siemens SAB 82532 and the Zilog
Z8530 and replaces puc(4) for these devices.
in the ISR doesn't read the actual socket event register, but instead
reads garbage (usually 0xffffffff, but other times other things).
This totally violates the PCI spec, but happens rarely enough that a
workaround is in order. This adds one test when we have a real
interrupt to service (which is very rare), and doesn't affect the
usualy 'nothing to see here' case at all.
Problem reported by many, but sam@ gave me this workaround after
diagnosing the problem.
some systems were designed so that AML writes to various resources shared
with OS drivers, including the RTC, PIC, PCI, etc. These writes could
collide with writes by the OS and should never be performed. For now, we
print a message if such an access occurs, but do not block it. To block
the access, the tunable "debug.acpi.block_bad_io" can be set to 1. In the
future, we will flip the switch and this will become the default.
Information about this problem was found in Microsoft KB 283649. They
block IO accesses if the BIOS indicates via _OSI that it is Windows 2001
or higher. They always block accesses to the PIC, cascaded PIC, and ELCRs,
no matter how old the BIOS.
systems (blade servers). On most systems, this is implemented as an IO
write to the SMI port and the BIOS generates the actual reset.
PR: kern/94939
Submitted by: dodell@ixsystems.com
Reviewed by: jhb
MFC after: 3 weeks
Saab for helping to track this down. Fix a error with 32bit DMA size
calculation that seemed to be harmless. Add a few micro-optimizations while
I'm here.
mddestroy() only if the file is from a non-MPSAFE VFS.
- No longer unconditionally hold Giant in the md kthread for vnode-backed
kthreads.
- Improve the handling of the thread exit race when destroying an md
device.
a problem with listing large number of md(4) devices. Either 'list' or
'query' mode uses XML.
Additionally, new functionality was introduced. It's possible to pass
multiple devices to -u:
# ./mdconfig -l -u md0,md1
Approved by: cognet (mentor)
Kernel changes:
Inform hwpmc of executable objects brought into the system by
kldload() and mmap(), and of their removal by kldunload() and
munmap(). A helper function linker_hwpmc_list_objects() has been
added to "sys/kern/kern_linker.c" and is used by hwpmc to retrieve
the list of currently loaded kernel modules.
The unused `MAPPINGCHANGE' event has been deprecated in favour
of separate `MAP_IN' and `MAP_OUT' events; this change reduces
space wastage in the log.
Bump the hwpmc's ABI version to "2.0.00". Teach hwpmc(4) to
handle the map change callbacks.
Change the default per-cpu sample buffer size to hold
32 samples (up from 16).
Increment __FreeBSD_version.
libpmc(3) changes:
Update libpmc(3) to deal with the new events in the log file; bring
the pmclog(3) manual page in sync with the code.
pmcstat(8) changes:
Introduce new options to pmcstat(8): "-r" (root fs path), "-M"
(mapfile name), "-q"/"-v" (verbosity control). Option "-k" now
takes a kernel directory as its argument but will also work with
the older invocation syntax.
Rework string handling in pmcstat(8) to use an opaque type for
interned strings. Clean up ELF parsing code and add support for
tracking dynamic object mappings reported by a v2.0.00 hwpmc(4).
Report statistics at the end of a log conversion run depending
on the requested verbosity level.
Reviewed by: jhb, dds (kernel parts of an earlier patch)
Tested by: gallatin (earlier patch)
the error on sparc64 hadn't changed since the last checkin, pass
LINT on other platforms and mpt doesn't work on sparc64 anyway
and the tinderbox build didn't work for me in a cross build case
on my main build machine (which runs RELENG_6). Sigh. Still
need to try harder.
A) Fibre Channel Target Mode support mostly works
(SAS/SPI won't be too far behind). I'd say that
this probably works just about as well as isp(4)
does right now. Still, it and isp(4) and the whole
target mode stack need a bit of tightening.
B) The startup sequence has been changed so that
after all attaches are done, a set of enable functions
are called. The idea here is that the attaches do
whatever needs to be done *prior* to a port being
enabled and the enables do what need to be done for
enabling stuff for a port after it's been enabled.
This means that we also have events handled by their
proper handlers as we start up.
C) Conditional code that means that this driver goes
back all the way to RELENG_4 in terms of support.
D) Quite a lot of little nitty bug fixes- some discovered
by doing RELENG_4 support. We've been living under Giant
*waaaayyyyy* too long and it's made some of us (me) sloppy.
E) Some shutdown hook stuff that makes sure we don't blow
up during a reboot (like by the arrival of a new command
from an initiator).
There's been some testing and LINT checking, but not as
complete as would be liked. Regression testing with Fusion
RAID instances has not been possible. Caveat Emptor.
Sponsored by: LSI-Logic.
is derived from the phrase 'MegaRAID Firmware Interface' used by LSI. This
driver provides a block interface to logical disks on the card and a minimal
management device. It is MPSAFE, INTR_FAST, and 64-bit capable.
Thanks to Dell for providing hardware to test with and IronPort for
sponsoring the work.
Sponsored by: Dell, Ironport
MFC After: 3 days
socket also supports the voltage. Some XV cards have appeared on the
scene (or cards that report they support XV), and in older machines
that have sockets that do not support XV, we were bogusly trying to
power them at XV rather than at 3.3V. Now, power up the card at the
lowest voltage supported by both the card and the socket.
MFC After: 3 days
- [1] Make the driver friendly towards kernel without PREEMPTION.
Use msleep(9) instead of simple unlock-check_variable-lock mechanisme
since the later not really effective in non-preemptible kernel
(especially during codec detection routine).
- Free most driver resources in a sane manner to avoid possible
double free and panics especially during device detach and codec
detection failure.
MFC after: 3 days
[1] http://lists.freebsd.org/pipermail/freebsd-questions/2006-March/116515.html
that have the specified kind, instead of assuming that there is
only one report of the right kind in the report descriptor.
Submitted by: Morten Johansen
Obtained from: NetBSD (indirectly)
PR: usb/77604
o don't send management frames if the IFF_DRV_RUNNING flag is not set.
this prevents the timeout watchdog from being potentially re-armed
when the interface is brought down.
fixes a crash that occurs with RT2661 based adapters.
reported by Arnaud Lacombe.
- Determine open direction using 'flags', not 'mode'. This bug exist since
past 4 years.
- Don't allow opening the same device twice, be it in a same or different
direction.
- O_RDWR is allowed, provided that it is done by a single open (for example
by mixer(8)) and the underlying hardware support true full-duplex operation.
- Do various paranoid checking in case other process/thread trying to hijack
the same device twice (or more).
MFC after: 5 days
transfers. This fixes some cases where the software toggle tracking
was not doing the right thing. For example, a short transfer that
transferred 0 bytes of the requested qTD transfer size does cause
a toggle change, but the existing code was assuming it didn't.
Reported and tested by: pav
MFC after: 2 weeks
debugging message if the flag PMC_F_OLDVALUE was specified in the
PMC_OP_RW request being acted upon. This should fix Coverity bug
CID 671.
Found by: Coverity Prevent
MFC after: 3 weeks
especially for vchans. It turns out that channel numbering always depend
on d->devcount counter (which keep increasing), while PCMMKMINOR() truncate
everything to 8bit length. At some point the truncation cause the newly
created character device overlapped with the existence one, causing erratic
overall system behaviour and panic. Easily reproduce with something like:
(Luckily, only root can reproduce this)
while : ; do
sysctl hw.snd.pcm0.vchans=200
sysctl hw.snd.pcm0.vchans=100
done
- Enforce channel/chardev numbering within 8bit boundary. Return E2BIG
if necessary.
- Traverse d->channels SLIST and try to reclaim "free" counter during channel
creation. Don't rely on d->devcount at all.
- Destroy vchans in reverse order.
Anyway, this is not the fault of vchans. It is just that vchans are so cute
and begging to be abused ;) . Don't blame her.
Old, hidden bugs.. sigh..
MFC after: 3 days
o call firmware_put() early to release the firmware module
o on firmware panics or watchdog timeouts, schedule a task to reinitialize
the interface (we may sleep in iwi_init())
o discard oversized rx frames
flag isn't enough - the filter needs to be set up too, or no multicast frames
are accepted.
Sponsored by: Philips Industrial Applications (indirectly)
MFC after: 3 days
o stop processing interrupts after a firmware fatal error or a radio kill
o clarify the possible values for the 'antenna' sysctl.
o by default, let the firmware do antenna diversity.
the firmware will periodically switch to another antenna to evaluate the
signal quality.
ATA framework. Mainly written to be able to use USB Flash keys.
This is work in progress so use with care :)
Doesn't need CAM and cannot coexist with umass.c
table. Previously, the ddb code knew of each linker set of auxiliary
commands and which explicit command list they were tied to. These changes
add a simple command_table struct that contains both the static list of
commands and the pointers for any auxiliary linker set of additional
commands. This also makes it possible for other arbitrary command tables
to be defined in other parts of the kernel w/o having to edit ddb itself.
The DB_SET macro has also been trimmed down to just creating an entry in
a linker set. A new DB_FUNC macro does what the old DB_SET did which is
to not only add an entry to the linker set but also to include a function
prototype for the function being added. With these changes, it's now also
possible to create aliases for ddb functions using DB_SET() directly if
desired.
generations of 802.11abg chipsets from Ralink Technology.
Get rid of the pccard front-end while I'm here since all adapters are
cardbus ones.
Obtained from: OpenBSD
into a separate module. Accordingly, convert the option into a device
named similarly.
Note for MFC: Perhaps the option should stay in RELENG_6 for POLA reasons.
Suggested by: scottl
Reviewed by: cokane
MFC after: 5 days
to call back for completition and something else is holding the taskqueue
waiting for ATA to return data.
This should clear up the "semaphore timeout !! DANGER Will Robinson !!"
in most situations, and log "taskqueue timeout - completing request directly"
instead, with a delayed "WARNING - freeing taskqueue zombie request" when
the taskqueue finally calls us back with the now stale request.
(It would have been nice if there was a way to remove a scheduled item from
a taskqueue, but that is not currently implemented in the kernel).
A real fix for this is in the works but wont make it to 6.1RELEASE
definite MFC candidate.
- Don't use a common buffer in the softc to store per-command data. Reserve
a buffer in the command itself.
- Don't allocate DMA memory for the kernel command structures when all you
really need is DMA memory for the scratch buffer embedded in them. Instead
allocate a slab for the scratch buffers and divide it up as needed.
- Call bus_dmamap_unload() at the completion of commands.
- Preserve and clear the CAM CCB status flags at completion.
- Reorder some low-level command operations to try to close races.
- Limit the simq to 32 commands for now. There are some serious problems
with the driver under load that are not well understood, so keeping the
simq lower helps avoid this. It has been tested at a higher value, but
this is a safe value that doesn't show much performance degredation.
These changes allow the driver to work reliably with >4GB of memory on i386
and amd64, and also work around deadlocks seen under very high load in
certain situations. The work-around is far from ideal, but without and
documentation it is hard to know what the right fix is.
MFC candidate
