everytime softintr_schedule() is called. They don't have the same semantics
when called multiple times before the callback is triggered.
Should avoid huge numbers of si_callbacks being created when a machine is
overloaded.
XXX the fix certainly applies to the atari port, too.
1) Rather than build an array of the pci->intr mappings, build a proplib
tree.
2) add a SIMPLEQ of device properties to the pci_chipset_tag to hold the
proplib trees of each bus.
3) Move the interrupt routing code from pci_conf_interrupt to pci_map_intr()
4) Deal properly with non-native PCI bridge chips that are not recognized
by the prep firmware, and therefore are not noted in the residual data.
The major win of this restructure is #4. Hopefully I haven't broken
anything. Tested on a 7248-100, 7043-140 and 7024-E20.
Keep track of the average RSSI using an Exponential Moving Average (EMA).
Use it to dynamically tune radio receive sensitivity.
The idea is simple:
- increase sensitivity when the RSSI is bad to optimize throughput on
long distance to the AP, and
- decrease sensitivity when the RSSI is good to reduce noise level and
optimize throughput on short distance to the AP
The EMA allows to smooth RSSI variations so we don't end up changing the
sensitivity too frequently. We check if it would be worth updating the
sensitivity every one second.
RSSI thresholds were taken from the Ralink Tech. Linux driver.
- struct timeval time is gone
time.tv_sec -> time_second
- struct timeval mono_time is gone
mono_time.tv_sec -> time_uptime
- access to time via
{get,}{micro,nano,bin}time()
get* versions are fast but less precise
- support NTP nanokernel implementation (NTP API 4)
- further reading:
Timecounter Paper: http://phk.freebsd.dk/pubs/timecounter.pdf
NTP Nanokernel: http://www.eecis.udel.edu/~mills/ntp/html/kern.html
USB input and output buffer sizes; the previous values were fine for
dialup modems, but seriously limited the speed of some high-speed
wireless devices that appear to the system as a umodem.
In these cases, passing NULL for it solves a problem on AMD64 where the bus
tag is an integer rather than uintptr_t. (I.e. fix the cast warning on
amd64.)
rename them like azalia_mixer_foo() to generic_mixer_foo()
* enable codec-specific code to hook any mixer operations such
as creating mixer items, or special handling for a specific
item.
* provide a custom mixer table specific to ALC260
* provide a custom mixer table specific to Fujitsu LOOX
New HAL includes some driver changes to register accesses.
Adds support for WLAN devices on AR5312 family devices.
Adds support 32-bit SPARC ath devices (untested).
ath enabled in SPARC64 GENERIC builds.
This HAL is tested and known to work for i386 PCI devices, SPARC64 PCI devices,
and AR5312 WiSoC devices. MIPS PCI devices appear to be busted (possibly only
on Alchemy hardware, unconfirmed), and cardbus support is untested due to
lack of test hardware.
Please report any new problems with this import to garrett@.
from FreeBSD/OpenBSD that supersedes ral*.[ch].
Not yet enabled because I don't have a CardBus controller to test and it
will most likely crash during detach.
I tried to include our modifications, but if something is missing please
tell me or add it.
Special thanks to minipci.biz for the donation of one PCI RT2661 and
one CardBus RT2661.
case:
<driver>_ioctl(ifp, SIOCSIFADDR, struct ifreq *)
where it should be calling:
<driver>_ioctl(ifp, SIOCSIFADDR, struct ifaddr *)
and "Bad Things Happen (TM)"
Returning an error is good enough because none of the drivers handle INET6.
The problem here is that handling SIOCSIFADDR is a kludge. The ioctl gets
passed a struct ifreq * from userland, but then in the control routines
SIOCSIFADDR is handled "specially", and we call:
ifp->if_ioctl(ifp, SIOCSIFADDR, struct ifaddr *)
directly with the ifaddr we computed for that interface. It would be nice
if we called the ioctl routine if the original struct ifreq, and computed
the ifaddr, or passed it directly. This way all the ioctls would be treated
the same way, and we would not have the problem of pointer overloading.
if readdisklabel() returned an error.
sdopen(): Return an error if sdgetdisklabel() returns an error. This prevents
a crash in spec_open() (and possibly elsewhere) if a sd device is detached in
the middle of sdopen().
1. Instead of enabling the buffer manager hardware-FSM only on
pre-5705 devices, initialize the buffer manager on all bge devices.
Modelled on the Broadcom-authored Linux driver.
2. Instead of enabling the memory arbiter hardware-FSM only on
pre-5705 devices, initialize the memory arbiter on all bge devices.
Modelled on the Broadcom-authored Linux driver.
3. Ditto the second copy of code which enables the memory arbiter.
Also, add an XXX asking, why taunt the chip this way a second time?
(The most plausible explanatoin is that enabling the memory arbiter
twice is my own darn fault, likely a cut-and-paste glitch I made many
moons ago, when re-ordering hardware enables to match the Linux drivers.)
attached via PCI-Express:
The previous code first checked that the bge ASIC-revision matched the
5750 ASIC-revisoin (the bcm5721 has the same ASIC revision). However, the
bcm5752 is also a PCI-Express device, but has a different ASIC revision.
Thus, we were setting sc->bge_pcie to zero for bcm5752s, which in turn
causes bge_reset() to not perform required PCI-Express setup.
The test for a 5750 ASIC revision may (or may not) have been carried
across from the FreeBSD bge(4) driver. FreeBSD's bge(4) does not
properly detect or handle post-5750 bge devices. Instead, FreeBSD's
bge(4) keeps a sofc copy of the ASIC revision, and for post-5750
devices (5752, 5714, ...) overwrites that softc copy of the
ASIC-revision with the 5750 ASIC revision. Thus, the test (mutatis
mutandis, using FreeBDS's softc asic-revision field), was correct for
FreeBSD; but manifestly incorrect for NetBSD.
Mark Davies (mark at mcs.vuw.ac..nz) has confirmed via private email
that this change fixes PR kern/kern/33509: his bcm5752 now works.
- move ICU interrupt stuff from pci/pcib.h to cobalt/machdep.c
because ICU should be initialized before pcib is attached
- initialize ICU more properly
- check interrupt types and set ELCR (edge/level control registers)
accordingly in icu_intr_establish()
- check requested IRQ line and call only a necessary hander in icu_intr()
- use specific EOI to ack interrupts rather than AEOI
- use macro defined in <dev/ic/i8259reg.h>
proper pcipnp structure file to read them rather than magical array offsets.
Add more complete decoding of the VPD, including extendedvpd, and TLB. While
I was here, fix a bug where we never printed the L1 cache data properly.
spawn new pseudo-device and wskbd instances.
XXX: The logic for exclusive use needs to be thought out better, but
for now this should at least prevent scores of new hpf1275a/wskbd
being attached if you accidentally set this line discipline on your
serial console.
#define TULIP_TXTIMER 4
in
u_int32_t tulip_txtimer : 2; /* transmission timer */
gcc4 appears to be right. "tulip_txtimer" is purely used by software,
so give it the full integer.
(Appearently the txtimer could never work.)
will change "struct ntptimeval", so some translation would be necessary.
ntp_gettine is considered dispensable, the only userland program known
to use it is "ntptime".
specially. In Xen, the system is already in virtual mode when the kernel is
started, so the old behavior of setting physical address to virtual address
was actually correct, and the previous change made NetBSD/Xen kernels
unbootable.
Pointed out, explained and tested by <bouyer>.
HYPERVISOR_yield() cause a domain to busy-wait for some work to do (so
using HYPERVISOR_yield doen't fix the problem for dom0, and makes things much
worse for domU).
require it. On most archs this does not change anything, but on sparc{,64}
it allows linking of kernels that have machfb as the only framebuffer.
Solution suggested by Quentin.
because of the jitter caused by the serial console), which is not only
cosmetic but is bad for clock accuracy. Introducing a 1s delay before reading
Xen's idea of the CPU frequency fixes this.
After revision 1.135 of scsipi_base.c, it's a big no-no to set
XS_STS_DONE before calling scsipi_done(). Besides, scsipi_done()
sets XS_STS_DONE itself after checking that it's not already set.
This puts this driver back in working order; before this change
the probe of the logical drives would cause a hang.
it has to change the mbuf chain. I experience hard hang on a Xen2 domU after
TCP connections have been closed, and a crash has been reported which may be
caused by this too.
models. This code was made possible by assistance from Cory Bajus.
Add code that asks the PCI bridge what it's config base address is, and
use that when wiring up an indirect bridge type.
Move prep's user segment register to 10, because the 7025's PCI config
address is at 11, where the user segment used to be.
Add a battable entry for 0xbf800000 for machines with RS6K bridges.
There is still probably work left to be done before a 7025-F40 is fully
supported.
Use config_stdsubmatch() instead of our own submatch function.
Use "__inline" in header files and "inline" in .c files.
Make some local function static.
As we want some control on the name the backend driver will have we
can't use autoconf(9) here. Instead backend drivers registers to
xenbus, which will call a create callback when a new device is there.
Backend devices won't have a "struct device" in xenbus, use a void pointer
instead.
Use __builtin_va_* instead of hand written code in va-sh.h that uses
LHS casts. Slightly worse code is generated by gcc 3.3.3, but LHS
casts are outlawed in gcc 3.3.6 and gcc 4.
Build-tested on hpcsh (le) and mmeye (be), run-tested on hpcsh.
/sys/net/if_spppvar.h says:
"Lower layer drivers that are always ready to communicate
(like hardware HDLC) can shortcut pp_up from pp_tls,
and pp_down from pp_tlf."
When I follow those instructions, I get a kernel stack
overflow as soon as I open the HDLC device.
Here is the loop:
sppp_ioctl calls sppp_lcp_open
sppp_lcp_open calls sppp_open_event
sppp_open_event calls sppp_lcp_tls
sppp_lcp_tls calls pp_tls
pp_tls is the SHORTCUT to sppp_lcp_up
sppp_lcp_up calls spp_lcp_open
...and around we go until the stack overflows.
The fix is to reverse the order of the action (tls)
and the state change (from INITIAL to STARTING) in
sppp_open_event.
There is a similar loop during closing:
sppp_ioctl calls sppp_lcp_close
sppp_lcp_close calls sppp_close_event
spp_close_event calls sppp_lcp_tlf
sppp_lcp_tlf calls pp_tlf
pp_tlf is the SHORTCUT to sppp_lcp_down
sppp_lcp_down calls sppp_lcp_close
...and around we go until the stack overflows.
The fix is to reverse the order of the action (tlf)
and the state change (from STARTING to INITIAL) in
sppp_close_event.
Separately, while I was discovering this, I noticed
that pp_tlf was being called unconditionally rather
than first checking to see if it is NULL. pp_tlf
is a callout from sppp to the hdlc device driver.
Elsewhere in sppp, this is always checked for NULL
before calling it, and the comments in if_spppvar.h
imply that filling it in is optional.
From spppvar.h:
"These functions need to be filled in by the lower layer
(hardware) drivers if they request notification from the
PPP layer whether the link is actually required."
This clearly says that pp_tlf and pp_tls are optional
and so sppp must check before calling them.
