to properly configure the right interface to use.
Also call the mediachg function when we set flags UP and are already
running. If this were a pure ifmedia driver, we'd not need to do this
since we'd be ignoring the linkX flags.
This reduces the number of ifdefs to support sub-devices a little as a
nice side effect. It also reduces the number of hpp interfaces
exposed by 33%.
man page that the ifconfig option link2 is used to disable the AUI
transceiver on the 3com boards (should also say HP PC Lan+). This
makes the connection clearer.
Add a note about why we set this flag prior to attaching the device.
We never set or clear the flag later, only test it. There can be no
races here, but this might be asthetically displeasing to some. Also
note that we may no longer need to have this knob at all as we may be
able to do it with the more sophisticated rc.d scripts we have today I
think the only reason it is there is because we didn't used to allow
its proper setting when configured to get the IP address via DHCP.
I'll note that this would be better handled by using ifmedia for all
ed cards, not just those with a miibus...
This is important with MegaLib, when issuing a GET_REBUILD_PROG since
it returns an error if the drive is not in rebuild state.
This will be MFC'ed shortly.
Submitted by: ps
Reviewed by: scottl
Found by: ambrisko
system LED on or off. Unlike the EBus LED AUXIO register where the
remaining bits are unused the upper bits of the SBus AUXIO register
are used to control other things like the link test enable pin of
the on-board NIC which we don't want to change as a side-effect.
- Remove the superfluous bzero()'ing of the softc obtained from
device_get_softc().
Reviewed by: yongari
MFC after: 3 days
Linux LSI MegaRaid tools can run on FreeBSD until Linux emulation.
Add in the Linux IOCTL shim and create the megadev0 device so
Linux LSI MegaRaid tools can run on FreeBSD until Linux emulation.
Add glue to build the modules but don't tie it into the build
yet until I test it from the CVS repo. via the mirror on an
amd64 machine.
Tie this into the Linux32 emulation on amd64 so the tools can
run on amd64 kernel.
Cleaned up by: ps (amr_linux.c)
side effect that legacy ATA controllers at irq14 and irq15 cannot share
interrupts with anything else without major problems.
This fixes the ATAPI DMA problems some systems/devices have seen.
(1) Fix DMA alignment, based on bytes per sample.
feeder_rate.c:
Handle strayed bytes (mostly caused by #1) better.
This DMA alignment issues are extremely hard to reproduce unless
the user happen to have a 32bit capable soundcards (ATI IXP) and
knowledgeable enough to force it to operate under pure 32bit
operations on both record and play directions.
up to date. Principle changes for this reelase is to support 2K Port Login
firmware. This allows us to support the 2322 (and 2422 4Gb) cards which only
come with the 2K Port Login firmware. The 2322 should now work- but we don't
have firmware sets for it in ispfw (as the change to load 2K Port Login f/w
hasn't been made- that f/w is so big it has to be loaded in more than one
chunk).
Other changes are the beginnings of cleaning up some long standing target
mode issues. The next changes here will incorporate a lot of bug fixes
from others.
Finally, some copyright cleanup and attempts to make the parts of the
driver that are FreeBSD specific start conforming more to FreeBSD style.
MFC after: 1 month
feeder.h:
feeder.c:
- Implement scoring mechanisme to select best format for conversion.
This is actually part of newer format chaining procedures which
will be commited someday. Confusion during chaining process solved
by this scoring since it will try to reduce list of from/to formats
to a single, best format.
Related PR: kern/91683
channel.c:
- Simplify feeder building process since we have smarter format
chaining.
feeder_fmt.c:
- Add few more sign conversion feeders for 24 and 32 bit format.
feeder_rate.c:
- Force buffer / bytes allignment. Unaligned buffer may cause
panics during recording on pure 32bit sample format if it
involves feeder_rate as part of feeders chain.
Tested on: ATI IXP, force 32bit recording.
MFC after: 5 days
o fix contention window
o silently discard received frames that are too short
o simplify lookup of 802.11a channels (we know they exist)
o fix short preamble support
o add short slot support
o fix eifs settings
o many consistency tweaks
share devclass pointers, a mistake I've encouraged in the past) and
move the declaration of the pci_driver kobj class from cardbus.c to
pci_private.h so that other drivers can inherit from pci_driver.
hacking:
- Remove all spaces at eol.
- Improve style(9) in most frequently edited functions.
- In em_encap() push variables for 82544 workaround in the block
where they are only used.
- In em_get_buf() remove unused variable.
as input/output interface errors.
- Keep values of rx/tx discards & tx collisions inside struct bge_softc.
So we can keep statistic across ifconfig down/up runs (cause bringing
bge up will reset chip).
Approved by: glebius (mentor)
MFC after: 1 week
ATI EHCI controllers exhibit simmilar stall issues and require
this dropped interrupts workaround. Be verbose about it.
ehci.c:
ehcivar.h:
Slight change in comments to note about issues surrounding both
VIA and ATI EHCI controllers.
Approved by: iedowse
an interrupt appears to occur before the transfer has been marked
as completed. This caused umass transfers to get stuck, especially
when writing large files. The workaround sets up a timer that
rechecks for missed completed transfers if some operations are still
pending. Other suggested workarounds, such as performing a PCI read
immediately after acknowledging the interrupts, do not appear to
help.
Obtained from: OpenBSD
same behavior to be controlled by the sysctls, hw.syscons.kbd_kbdkey
and hw.syscons.kbd_reboot respectively.
Apologies to the submitter for taking so long to commit this simple
change.
PR: kern/72728
Submitted by: Luca Morettoni <morettoni at libero dot it>
MFC After: 3 days
taskqueue_start_threads(struct taskqueue **, int count, int pri,
const char *name, ...);
This allows the creation of 1 or more threads that will service a single
taskqueue. Also rework the taskqueue_create() API to remove the API change
that was introduced a while back. Creating a taskqueue doesn't rely on
the presence of a process structure, and the proc mechanics are much better
encapsulated in taskqueue_start_threads(). Also clean up the
taskqueue_terminate() and taskqueue_free() functions to safely drain
pending tasks and remove all associated threads.
The TASKQUEUE_DEFINE and TASKQUEUE_DEFINE_THREAD macros have been changed
to use the new API, but drivers compiled against the old definitions will
still work. Thus, recompiling drivers is not a strict requirement.
- Add support for adjusting the fan speed if the fan control mode is manual
Documentation for the relevant embedded controller register was obtained from
http://www.thinkwiki.org/wiki/Patch_for_controlling_fan_speed
Tested on: R51 by Fabian Keil
T41p by markus
Requested by: many
Approved by: philip
MFC after: 1 week
2) use more robust way of link state handling for BCM5700 rev.B2 chip
3) workaround bug of some BCM570x chips which cause spurious "link up" messages
4) fix bug: some BCM570x chips was unable to detect link state changes after
ifconfig down/up sequence until any 'non-link related' interrupt generated.
(this happened due to pending internal link state attention which blocked
interrupt generation)
Approved by: glebius (mentor)
MFC after: 1 week
the the interface has been configured. I'm not sure how this could ever
have worked before, but it should be fixed now. Also break out the interrupt
degresitration function into it's own step.
before. The symptom is that the battery inform us its charge and discharge
at the same time...
* fix bst.rate to correctly output the (dis)charging rate. We'll use
the current average over one minute command and not the at_rate command.
Note that this method is not correct if the capacity_mode is set, but
since we don't set it ourself, it is not a problem.
The at_rate do not give the actual rate but is used to compute the
estimated time for (dis)charging a battery. We should actually
write an estimation of the actual rate using at_rate cmd and then
perform a read to the various estimators.
Approved by: njl
MFC after: 2 days
The minimum / maximum speed was way too low / high!
minspeed = 2000 - is this for real ?
maxspeed = 767999 - is this for real ?????
Wrap everything into 8000 - 48000 boundary, just to be safe.
MFC after: 3 days
- Mark MPSAFE since most of the locking procedures already implemented.
- Turn on inverted external amplifier sense flag for selected boards.
Tested by: bland
MFC after: 1 week
- Only update the rx ring consumer pointer after running through the rx loop,
not with each iteration through the loop.
- If possible, use a fast interupt handler instead of an ithread handler. Use
the interrupt handler to check and squelch the interrupt, then schedule a
taskqueue to do the actual work. This has three benefits:
- Eliminates the 'interrupt aliasing' problem found in many chipsets by
allowing the driver to mask the interrupt in the NIC instead of the
OS masking the interrupt in the APIC.
- Allows the driver to control the amount of work done in the interrupt
handler. This results in what I call 'adaptive polling', where you get
the latency benefits of a quick response to interrupts with the
interrupt mitigation and work partitioning of polling. Polling is still
an option in the driver, but I consider it orthogonal to this work.
- Don't hold the driver lock in the RX handler. The handler and all data
associated is effectively serialized already. This eliminates the cost of
dropping and reaquiring the lock for every receieved packet. The result
is much lower contention for the driver lock, resulting in lower CPU usage
and lower latency for interactive workloads.
The amount of work done in the taskqueue is controlled by the sysctl
dev.em.N.rx_processing_limit
and tunable
hw.em.rx_process_limit
Setting these to -1 effectively removes the limit.
The fast interrupt and taskqueue can be disabled by defining NO_EM_FASTINTR.
This work has been shown to increase fast-forwarding from ~570 kpps to
~750 kpps (note that the same NIC hardware seems unable to transmit more than
800 kpps, so this increase appears to be limited almost solely by the
hardware). Gains have been shown in other workloads, ranging from better
performance to elimination of over-saturation livelocks.
Thanks to Andre Opperman for his time and resources from his network
performance project in performing much of the testing. Thanks to Gleb
Smirnoff and Danny Braniss for their help in testing also.
Instead of dragging the entire ICH4/82801DB into this mess, select
only few boards based on pci subdevice / subvendor.
Tested by: Daisuke Orikasa <luxury-acura-3.5rl at nifty.com>
MFC after: 3 days
This is based on MCPC USB mobile phone guide line (MCPC-GL005)
Some other 3G system or so will work with this driver.
Kyocera PHS terminal (a.k.a. Kyopon) is known to work, which
is now supported by umodem(4) driver.
o record tsf in tx+rx frames
o switch from raw rssi to dbm for signal data and record both
signal and noise floor data (hacked for now to assume a fixed
noise floor; is correct with new hal)
o add monpass sysctl to control which rx'd frames are passed
up with errors; especially useful to see frames with CRC errors
o mark 'd packets w/ a CRC error with radiotap's BADFCS flag
Also add placeholder code for calibrating the noise floor when
using newer hals.
Reviewed by: avatar
MFC after: 1 week
