"FSS_UNLINK_ON_CREATE" to unlink the backing store before
the snapshot gets created.
With this change dump(8) no longer dumps the zero-sized, but named
snapshot it is working on. Same applies to fsck_ffs(8).
code. Patrick Welche says that this patch fixes the problem that he
reported on current-users@.
BTW, sc_dev is initialized in radioattach(), but I do not see where it
is used.
on a patch from fire crow on tech-net with additional bpf & detach fixes,
module support, and a match for 8152 v2.0 devices.
alc0 at pci3 dev 0 function 0: Attansic/Atheros L1C/L2C Ethernet
alc0: ioapic0 pin 17
alc0: Ethernet address 00:26:6c:9e:d4:c1
ukphy0 at alc0 phy 0: L2 10/100 PHY (OUI 0x00c82e, model 0x0002), rev. 5
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
object noted in the revision 1.40, there is only one C-state on the machine,
yet the BIOS define its type as C2. Thus, instead of relying on the BIOS
data, sequentially count the parsed C-states.
the revision 1.38. As noted in the specification (ACPI 4.0, p. 314):
The platform must expose a _CST object for either all or none of its
processors. If the _CST object exists, OSPM uses the C state information
specified in the _CST object in lieu of P_LVL2 and P_LVL3 registers
defined in P_BLK and the P_LVLx_LAT values defined in the FADT.
The _CST is seemingly valid on the system under consideration:
Name (_CST, Package (0x02)
{
0x01,
Package (0x04)
{
ResourceTemplate ()
{
Register (SystemIO,
0x08, // Bit Width
0x00, // Bit Offset
0x000000000000F800, // Address
0x01, // Access Size
)
},
0x02,
0x0064,
0x00000000
}
})
The check was also unnecessary in the sense that ACPI doesn't use bus_space(9).
object address is valid. Some systems define the Processor() as:
Scope (_PR)
{
Processor (C000, 0x00, 0x00000410, 0x06) {}
Processor (C001, 0x01, 0x00000000, 0x00) {}
Processor (C002, 0x02, 0x00000000, 0x00) {}
Processor (C003, 0x03, 0x00000000, 0x00) {}
}
This may be typical to AMD systems that do not seem to use _CST, but instead
operate with HLT (and C1E for the C3-state). The same check is already done
in acpicpu_cstate_fadt(). Note that it is unclear whether this violates the
specification, given:
"PBlockAddress provides the system I/O address for the processors
register block. Each processor can supply a different such address.
PBlockLength is the length of the processor register block, in bytes and
is either 0 (for no P_BLK) or 6. With one exception, all processors are
required to have the same PBlockLength. The exception is that the boot
processor can have a non-zero PBlockLength when all other processors
have a zero PBlockLength. It is valid for every processor to have a
PBlockLength of 0. (ACPI 4.0, p. 626)"
1. Remove the AcpiEnableGpe() call. This was wrong.
2. Only call _PSW or _DSW for devices that are scheduled for wake.
This was an old bug.
3. Only enable wake GPEs during suspend. Disabling these for
devices not setup for wake was causing problems.
4. No wake GPEs should be enabled at runtime.
Unconditionally disable these during resume.
This should make the wake-device code work again. Note that waking via
pckbd(4) has always been unreliable; the _PRW object is not typically located
under the PC keyboard object, but in the parent of it (e.g. the LPC bridge).
100 % duty cycle) had control value of zero, as in the IA32 clock modulation
MSR. As the access may be based on I/O, it is unclear if a strict validation
like this was correct. Should fix the problem reported by Hisashi T Fujinaka
on current users.
Completed the major overhaul of the GPE support code that was begun in July
2010. Major features include: removal of _PRW execution in ACPICA (host
executes _PRWs anyway), cleanup of "wake" GPE interfaces and processing,
changes to existing interfaces, simplification of GPE handler operation, and
a handful of new interfaces:
AcpiUpdateAllGpes
AcpiFinishGpe
AcpiSetupGpeForWake
AcpiSetGpeWakeMask
ACPICA 20100702:
Implemented several updates to the recently added GPE reference count
support. The model for "wake" GPEs is changing to give the host OS complete
control of these GPEs. Eventually, the ACPICA core will not execute any _PRW
methods, since the host already must execute them. Also, additional changes
were made to help ensure that the reference counts are kept in proper
synchronization with reality. Rafael J. Wysocki.
1) Ensure that GPEs are not enabled twice during initialization.
2) Ensure that GPE enable masks stay in sync with the reference count.
3) Do not inadvertently enable GPEs when writing GPE registers.
4) Remove the internal wake reference counter and add new AcpiGpeWakeup
interface. This interface will set or clear individual GPEs for wakeup.
5) Remove GpeType argument from AcpiEnable and AcpiDisable. These interfaces
are now used for "runtime" GPEs only.
Fixed a problem with the prototype for AcpiOsReadPciConfiguration.
The prototype in acpiosxf.h had the output value pointer as a (void *).
It should be a (UINT64 *). This may affect some host OSL code.
Removed the AcpiOsDerivePciId OSL interface. The various host
implementations of this function were not OS-dependent and are now obsolete
and can be removed from all host OSLs. This function has been replaced by
AcpiHwDerivePciId, which is now part of the ACPICA core code.
AcpiHwDerivePciId has been implemented without recursion. Adds one new
module, hwpci.c. ACPICA BZ 857.
Increase the delay between setting the command register and reading the
status register. Reset the smbus controller if it has timed out.
Tested on an IBM eServer x335.
yamt