long time, i.e., since the cleanup of the VM Page-queues code done two
years ago.
Reviewed by: Alan Cox <alc at freebsd.org>,
Matthew Dillon <dillon at backplane.com>
This is part 2/2 of fixing autonegotiation on hme(4) using DP83840A PHYs.
It appears to also fix the occasional problems to establish a link on
hme(4) using LU6612 PHYs and shouldn't hurt on those using QS6612 PHYs.
Obtained from: NetBSD
properly. This causes the autonegotiation to e.g. never establish a
100baseTX full-duplex link. The solution to this problem is to manually
write the capabilities from the BMSR to the ANAR every time a media
change occurs, even when already in autonegotiation mode.
The NetBSD way of doing this is to set their MIIF_FORCEANEG flag in the
NIC driver. This causes mii_phy_setmedia() to call mii_phy_auto() (which
will set the ANAR according to the BMSR) even when the PHY alread is in
autonegotiation mode. However, while doing the same on FreeBSD (which
involves porting the MIIF_FORCEANEG flag and converting nsphy.c to use
mii_phy_setmedia()) fixes autonegotiation, using mii_phy_setmedia()
causes this driver to no longer work properly in the other modes.
Another drawback of that approach is that this will also force writing
the ANAR on other PHYs whose drivers use mii_phy_setmedia() and which
are used with a NIC whose driver sets MIIF_FORCEANEG (e.g. hme(4) is
known to be used together with 3 different PHYs while only the DP83840A
require this workaround).
So instead of moving to MIIF_FORCEANEG, just call mii_phy_auto() in
nsphy_service() unconditionally when hanging off of a hme(4) and serving
a media change
This is part 1/2 of fixing autonegotiation on hme(4) using DP83840A PHYs.
pipes, since open pipes are linked off a usbd_interface structure
that is free()'d when the configuration index is changed. Attempting
to close or use such pipes later would access freed memory and
usually crash the system.
The only driver that is known to trigger this problem is if_axe,
which is itself at fault, but it is worth detecting the situation
to avoid the obscure crashes that result from this type of easily
made driver mistakes.
behaviour lost in the change from 4.x style netgraph tee nodes.
Alter the tee node to use the new method. Document the behaviour.
Step the ABI version number... old netgraph klds will refuse to load.
Better than just crashing.
Submitted by: Gleb Smirnoff <glebius@cell.sick.ru>
make the key name matching case-insensitive. There are some drivers
and .inf files that have mismatched cases, e.g. the driver will look
for "AdhocBand" whereas the .inf file specifies a registry key to be
created called "AdHocBand." The mismatch is probably a typo that went
undetected (so much for QA), but since Windows seems to be case-insensitive,
we should be too.
In if_ndis.c, initialize rates and channels correctly so that specify
frequences correctly when trying to set channels in the 5Ghz band, and
so that 802.11b rates show up for some a/b/g cards (which otherwise
appear to have no 802.11b modes).
Also, when setting OID_802_11_CONFIGURATION in ndis_80211_setstate(),
provide default values for the beacon interval, ATIM window and dwelltime.
The Atheros "Aries" driver will crash if you try to select ad-hoc mode
and leave the beacon interval set to 0: it blindly uses this value and
does a division by 0 in the interrupt handler, causing an integer
divide trap.
of this micro-optimization occurs when we call pmap_enter() to wire an
already mapped page. Because of the micro-optimization, we fail to
mark the PTE as wired. Later, on teardown of the address space,
pmap_remove_pages() destroys the PTE before vm_fault_unwire() has
unwired the page. (pmap_remove_pages() is not supposed to destroy
wired PTEs. They are destroyed by a later call to pmap_remove().)
Thus, the page becomes lost.
Note: The page is not lost if the application called munlock(2), only
if it relies on teardown of the address space to unwire its pages.
For the historically inclined, this bug was introduced by a
megacommit, revision 1.182, roughly six years ago.
Leak observed by: green@ and dillon independently
Patch submitted by: dillon at backplane dot com
Reviewed by: tegge@
MFC after: 1 week
correct. Instead, check it against the possible settings (_PRS) when
the link is probed. This is important when using APIC mode but link
devices still have PIC mode settings. This is also what Linux does.
Additional prodding by: Len Brown len dot brown at intel dot com
based on the destination sleep state. Add a method to restore the old
state on resume. This is needed for the case of suspending to a very low
state disabling a GPE (i.e. S4), resuming, and then suspending to a higher
state (i.e. S3). This case should now keep the proper GPEs enabled.
device can wake the system. For example:
dev.root0.nexus0.acpi0.acpi_lid0.wake: 1
dev.root0.nexus0.acpi0.acpi_button0.wake: 1
dev.root0.nexus0.acpi0.pcib0.wake: 0
dev.root0.nexus0.acpi0.sio0.wake: 0
