A preemption could occur in the middle, and we don't want that to happen,
because the context switch would use the partially-constructed fpu state.
The procedure becomes:
splhigh
unbusy the current cpu's fpu
create a new fpu state in memory
install the state on the current cpu's fpu
splx
Disabling preemption also ensures that x86_fpu_eager doesn't change in
the middle.
In LazyFPU mode we drop IPL_HIGH right away.
Add more KASSERTs.
A context switch (preemption) could occur between
fpusave_lwp(l1, true);
and
memcpy(pcb2, pcb1, sizeof(struct pcb));
In this case, l1's FPU state is re-installed on the current CPU, and
pcb1->pcb_fpcpu becomes non NULL. While it's fine to have l1's state
installed, we don't want to indicate l2's state is installed too.
With lazy fpu this was not a problem, because the context-switch would
not re-install the state, so pcb1->pcb_fpcpu was NULL.
Should fix PR/53383.
to use the new device_compatible_match() routine. A pointer to
the matching device_compatible_entry is returned if a match is
found.
- Adjust iic_use_direct_match() accordingly.
- i2c drivers now provide device_compatible_entry tables when performing
direct-config matching.
- In the dsrtc driver, take advantage of this new capability to greatly
simplify model selection.
(I'm coming for you next, of_compat_data...)
to avoid a race condition
According to the locking order of pppoe(4), the access to
pppoe_softc has to follow 5 steps as below.
1. aquire pppoe_softc_list_lock
2. aquire pppoe_softc lock
3. release pppoe_softc_list_lock
4. access to pppoe_softc
5. release pppoe_softc lock
However, pppoe_dispatch_disc_pkt() releases the lock of pppoe_softc
temporarily, and then re-aquires it before step 4 of the adove. So,
it is possible for other contexts to destroy a pppoe_softc in the
interim.
To fix this condition, avoid PPPOE_UNLOCK with the problem.
ok by knakahara@n.o
specification, so those register definitions are not required. Use mii.h's
definitions. Note that E1000_ER_PAR_DETECT_FAULT should be 0x0010 instead of
0x0100(typo).
- Restore code for BMCR_ISO which was removed in makphy.c rev. 1.44
- Whitespace fix.
- Add ANLPAR_XNP bit.
- Add definitions for RF1 and RF2 (for 1000BASE-X) .
- Rename MII_ANNP (Autonegotiation next page transmit) register to MII_ANNPT.
- Add bit definitions for MII_ANNPT and MII_ANLPRNP.
- Remove GTSR_LP_ASM_DIR bit. This is not described in the 802.3 spec now and
no any NetBSD drivers use the definition.
called "device_compatible_entry". It performs a similar function, but
instead of one "compatible" string per entry, it takes an array of
"comaptible" strings per entry. Also included are macros for initializing
an array of these entries and accessing data embedded in them.
hasn't published a list of its affected products, but it appears that Xen
was given this information since they have a specific detection code.
We could just unconditionally enable eager; but on x86_32 eager may have
a greater performance cost than lazy, and we don't want to lose
performance on unaffected (and ~old) CPUs running NetBSD/i386.
So use the same code as Xen: take Family 6, and whitelist certain models.
only if the fpu already has a state. We're fine with getting a DNA, what
we're not fine with is if the DNA is received while the FPU is busy.
I believe (even though I couldn't trigger it) that the panic would
otherwise fire if PT_SETFPREGS is used. And also ACPI sleep/wakeup,
probably.
- Get all of the drivers onto the new match quality constants.
- Introduce a new helper function, iic_use_direct_match(), that has
all of the logic for direct-config matching. If it returns true,
the driver returns the match result (which may be 0). If it returns
false, the driver does indirect-config matching.
- iic_compat_match() now returns a weighted match quality; matches to
lower-indexed "compatible" device property are more-specific matches,
and return a better match quality accordingly.
In addition to the above:
- Add support for direct-config matching this driver based on
"compatible" properties.
- Address-only matching is now done based on the specific addresses
the requested model supports.
- "compatible" property can specify to the driver which model is to
be used, so that using config "flags" directives aren't required
in the direct-config case.
XXX More changes coming that require re-factoring some other code.
- Get all of the drivers onto the new match quality constants.
- Introduce a new helper function, iic_use_direct_match(), that has
all of the logic for direct-config matching. If it returns true,
the driver returns the match result (which may be 0). If it returns
false, the driver does indirect-config matching.
- iic_compat_match() now returns a weighted match quality; matches to
lower-indexed "compatible" device property are more-specific matches,
and return a better match quality accordingly.
XXX This driver is an odd-ball with respect to the hardware device.
See comments in the match routine. Unclear how best to handle it.
- Get all of the drivers onto the new match quality constants.
- Introduce a new helper function, iic_use_direct_match(), that has
all of the logic for direct-config matching. If it returns true,
the driver returns the match result (which may be 0). If it returns
false, the driver does indirect-config matching.
- iic_compat_match() now returns a weighted match quality; matches to
lower-indexed "compatible" device property are more-specific matches,
and return a better match quality accordingly.
jmcneill