- Improve panic message if we fail to read the PCI bus number from a bridge
device.
- Don't try to lookup a BIOS IRQ for a link unless the link is routed via
an ISA IRQ since BIOSen currently only route PCI link devices via ISA
IRQs.
Tested by: Mathieu Prevot bsdhack at club-internet dot fr
MFC after: 1 week
Instead, re-evaluate _BIF only when we get a notify and use the cached
results. We also still evaluate _BIF once on boot. Also, optimize the
init loop a little by only querying for a particular info if it's not valid.
MFC after: 2 days
the IRQ set by the BIOS in existing devices to actually get the correct
bus number of the child PCI bus. I was not reading the bus number from
the bridge device correctly. The __BUS_ACCESSOR() macros (from which
pcib_get_bus() is built) assume that the passed in argument is a child
device. However, at the time I'm reading the bus there is no child
device yet, so I was passing in the pcib device as the child device.
The parent of the pcib device probably returned an error in the case of
a host bridge, thus resulting in random stack garbage for the bus number.
For PCI-PCI bridges, the bus number being used was actually the subvendor
of the PCI-PCI bridge device itself.
MFC after: 1 week
acpi_resource change was a minor nit offered as an early candidate for
the recent ACPICA import problem and the acpi.c change is one I need to
test still that makes the ordered probing of system devices actually work
as advertised (probe devices in order based on the type of device rather
than in the order we encounter them in the device tree).
entry that is not zero, assume that it is really a hard-wired IRQ (commonly
used for APIC routing) and not a source index. In practice, we've only
ever seen source indices of 0 for legitimate non-hard-wired _PRT entries.
Reviewed by: njl
Tested by: Alex Lyashkov shadow at psoft dot net
MFC after: 2 weeks
- Prefer '_' to ' ', as it results in more easily parsed results in
memory monitoring tools such as vmstat.
- Remove punctuation that is incompatible with using memory type names
as file names, such as '/' characters.
- Disambiguate some collisions by adding subsystem prefixes to some
memory types.
- Generally prefer lower case to upper case.
- If the same type is defined in multiple architecture directories,
attempt to use the same name in additional cases.
Not all instances were caught in this change, so more work is required to
finish this conversion. Similar changes are required for UMA zone names.
immediately, back off to the next higher Cx sleep state. Some machines
with a Via chipset report a valid C3 but a register read doesn't actually
halt the CPU. This would cause the machine to appear unresponsive as it
repeatedly called cpu_idle() which immediately returned. Causing interrupts
(i.e. by pressing the power button) would cause the system to make forward
progress, showing that it wasn't actually hung.
Also, enable interrupts a little earlier. We don't need them disabled
to calculate the delta time for the read.
Reported by: silby
MFC after: 2 weeks
is on AC power (i.e. not a laptop). This allows power_profile to run once
for desktop systems as well, for instance, to set C3 or CPU frequency.
MFC after: 2 weeks
support the CM-battery interface. Smart batteries can eventually be
supported without ACPI via a separate SMBus interface. The ACPI interface
uses the embedded controller for reading/writing to the SMBus, and normal
ASL definitions for locating the battery controller (since SMBus can't be
enumerated.) Also import definitions for the smart battery interface.
This was written by Hans Petter Selasky with minor cleanups from myself.
Submitted by: Hans Petter Selasky <hselasky / c2i.net>
* Use ACPI_BATT_UNKNOWN instead of constants
* Use maxunit instead of a count of devices since we may have sparse
battery devices in the future. Only userland should be using unit
numbers anyway, so provide a translation function. (Kernel use of
batteries should be restricted to looking up a device_t and calling
methods directly.
* Don't check acpi_BatteryIsPresent() in acpi_battery. Leave it up to
the hardware-specific driver (i.e. cmbat) since smart batteries seem
to not report the "battery present" flag.
* Convert mA to mW if the battery uses those units. CM-batteries only
used mW so this deficiency went unnoticed.
* Clean strings reported in the battery info from any control chars.
* Only dereference the unit from ioctl_arg if the full struct is present.
Unit wouldn't have been used later if it wasn't present but this is
cleaner. Translate the unit if it's not ACPI_BATTERY_ALL_UNITS.
* bzero structs before returning them to usermode for future compat.
Most of this work was submitted by Hans Petter Selasky and then majorly
reworked by myself.
Submitted by: Hans Petter Selasky <hselasky / c2i.net>
with some Dell servers that booted w/o a problem[*] on 5.4, but failed
with 6.0-BETA.
On the PCI bus, when we do lazy resource allocation, we narrow the
range requested as we pass through bridges to reflect how the bridges
are programmed and what addresses they pass. However, when we're
doing an allocation on a bus that's directly connected to a host
bridge, no such translation can take place. We already had a fallback
range for memory requests, but none for ioports. As such, provide a
fallback for I/O ports so we don't allocate location 0, which will
have undesired side effects when the resources are actually used.
This fixes a problem with booting a Dell server with usb in the
kernel. However, it is an unsatisfying solution. I don't like the
hard coded value, and I think we should start narrowing the resources
returned to not be in the so-called isa alias area (where the ranage &
0x0300 must be 0 iirc). Doing such filtering will have to wait for
another day.
This may be a good 6 candidate, maybe after its had a chance to be
refined.
Tested by: glebius@
cooling thread which refers psv, tc1, tc2 and tsp. The previous
code made the period where sc->tz_zone.tsp was zero, and it caused
panic at msleep().
Reported by: keramida
Tested by: keramida
effect. since CPU speed is restored by degrees, we cannot use
the facility of saving cpu speed by CPUFREQ_set() effectively.
so, we need to save the value when passive cooling is in effect.
Repoeted by: Kevin Oberman <oberman__at__es.net>
Previously, we used all info (including -1 or "not present") which would
keep the system from reaching 100% when charging.
Reported by: Eric Anderson
MFC after: 2 days
later sum capacities for all batteries, even those that weren't actually
present. We only need to do this for _BST but do it for all of them.
Reported by: Eric Anderson
MFC after: 1 day
(i.e., smart battery) and fix various bugs found during the cleanup.
API changes:
* kernel access:
Access to individual batteries is now via devclass_find("battery").
Introduce new methods ACPI_BATT_GET_STATUS (for _BST-formatted data) and
ACPI_BATT_GET_INFO (for _BIF-formatted data). The helper function
acpi_battery_get_battinfo() now takes a device_t instead of a unit #
argument. If dev is NULL, this signifies all batteries.
* ioctl access:
The ACPIIO_BATT_GET_TYPE and ACPIIO_BATT_GET_BATTDESC ioctls have been
removed. Since there is now no need for a mapping between "virtual" unit
and physical unit, usermode programs can just specify the unit directly and
skip the old translation steps. In fact, acpiconf(8) was actually already
doing this and virtual unit was the same as physical unit in all cases
since there was previously only one battery type (acpi_cmbat). Additionally,
we now map the ACPIIO_BATT_GET_BIF and ACPIIO_BATT_GET_BST ioctls for all
batteries, if they provide the associated methods.
* apm compatibility device/ioctls: no change
* sysctl: no change
Since most third-party applications use the apm(4) compat interface, there
should be very few affected applications (if any).
Reviewed by: bruno
MFC after: 5 days
the driver has unholy private knowledge of its great-*cgrandchildren.
The ACPI allocation routine lacked such knowledge when it tried to do
a default allocation for all descendants, rather than just its
immeidate children, so would access grandchild's ivar in an unsafe
way. This could lead to a panic when devices were present which had
no addresses setup by the BIOS, but which were later allocated in a
lazy manner via pci_alloc_map. As such, only do the default
allocation adjustments for immediate children. The manner that
acpi_sysres_find accesses the resource list, used later in
acpi_alloc_resource, is safe and proper so no additional test is
needed there.
This fixes a panic when probing an disabled ata controller on some
newer intel blades.
Reported by: dwhite
pointer. If kernel malloc(0) returns a valid pointer, it needs to be
freed. If it returns NULL, it's ok to free this also.
Submitted by: pjd
Reviewed by: imp, dfr
Obtained from: Coverity Prevent
of swi. This allows us to use the taskqueue_thread_* functions instead of
rolling our own. It also avoids a double trip through the queue.
Submitted by: njl
Reviewed by: sam
number of task threads to start on boot. Go back to a default of 3
threads to work around lost battery state problems. Users that need
a setting of 1 can set this via the tunable. I am investigating the
underlying issues and this tunable can be removed once they are solved.
MFC after: 2 days
we start turning any of them back on again. This works around a bug in
some BIOSen that alias two different link devices for APIC vs ATPIC modes
onto the same physical hardware link.
Submitted by: njl
Tested by: Antoine Brodin antoine dot brodin at laposte dot net
systems that boot with this value at the lowest setting. Change the
default boot config back to "leave frequency as BIOS set it". Also, fix
buglet where acpi_throttle wouldn't be used if p4tcc was present but
disabled by the user.
MFC after: 1 week
to see what features they may support before calling identify/probe/attach.
This is necessary because the ACPI 3.0 spec requires driver support be
advertised before running any methods. For now, the flags are as specified
in for the _PDC and _OSC methods but we can support private flags as needed.
Add an implementation of this for acpi_cpu. It checks all its children
(notably cpufreq drivers) and calls the _PDC method to report the results.
acpi_bus_alloc_gas() to delete the resource it set if alloc fails. Then,
change acpi_perf to delete the resource after releasing it if alloc fails.
This should make probe and attach both fully restartable if either fails.
may help with various interdependencies between subsystems. More testing
is needed to understand what the underlying issues are here.
Tested by: Juho Vuori
MFC after: 2 days
count of valid frequencies and use that as the final package count, don't
give up when the first invalid state is found. Also, add 0x9999 and expand
our upper check to >= 0xffff Mhz [2].
Submitted by: Bruno Ducrot, Jung-uk Kim [2]
(like an EC/SMbus controller) to access the EC address space. Access
is synchronized by the EcLock/Unlock routines in EcSpaceHandler().
Tested by: Hans Petter Selasky
same value as the previous ioctls so no binary change. Also, make a few
style changes to reduce diffs to my tree.
Loosely based on code from: Hans Petter Selasky
- Fix a bug in the same condition where we forgot to drop the ACPI pcib
lock. This fixes hangs after the pcib0 attach on some machines.
Tested by: sos (2)
modulating the STPCLK# pin based on the duty cycle. Since p4tcc uses the
same mechanism (but internal to the CPU), we triggered a hang on some
systems at low frequencies when both were in use. Now, disable
acpi_throttle when p4tcc is also present.
Tested by: Kevin Oberman
SMP systems. It appears all drivers except ichss should attach to each
CPU and that settings should be performed on each CPU. Add comments about
this. Also, add a guard for p4tcc's identify method being called more than
once.
IRQ 0 and not an ExtINT pin. The MADT enumerators ignore the PC-AT flag
and ignore overrides that map IRQ 0 to pin 2 when this quirk is present.
- Add a block comment above the quirks to document each quirk so that we
can use more verbose descriptions quirks.
MFC after: 2 weeks
modes, systems may take longer. If the status values don't match, try
matching just the lowest 8 bits if no bits above 8 are set in the desired
value. The IBM R32 has other bits set in the status register that are
irrelevant to the expected value.
the switch. Other interim tests (i.e., for minimum runtime) could
invalidate the start time. This fixes transitions to cooler states in that
now they go to the next active state (_AC0 -> _AC1) instead of going
straight to off (_AC0 -> off).
Submitted by: Alexandre "Sunny" Kovalenko (Alex.Kovalenko / verizon.net)
locks held, specify the ACPI_ISR flag to keep it from acquiring any more
mutexes (which could potentially sleep.) This should fix "could sleep"
warning messages on the following path:
msleep()
AcpiOsWaitSemaphore()
AcpiUtAcquireMutex()
AcpiDisableGpe()
EcGpeHandler()
AcpiEvGpeDispatch()
AcpiEvGpeDetect()
AcpiEvGpeDetect()
AcpiEvSciXruptHandler()
driver. This used to be handled by cpufreq_drv_settings() but it's
useful to get the type/flags separately from getting the settings.
(For example, you don't have to pass an array of cf_setting just to find
the driver type.)
Use this new method in our in-tree drivers to detect reliably if acpi_perf
is present and owns the hardware. This simplifies logic in drivers as well
as fixing a bug introduced in my last commit where too many drivers attached.
are not added to the list(s) of available settings. However, other drivers
can call the CPUFREQ_DRV_SETTINGS() method on those devices directly to
get info about available settings.
Update the acpi_perf(4) driver to use this flag in the presence of
"functional fixed hardware." Thus, future drivers like Powernow can
query acpi_perf for platform info but perform frequency transitions
themselves.
throttling, neglecting to do this kept the sysctls from appearing.
Attach an acpi_throttle device to each CPU that supports it.
Don't add a device if the P_BLK is invalid or if _PTC is not present.
This removes extraneous probe/attach failure messages on some machines.
Make the cpu throttle state local to the softc to account for partial
successes when changing the clock rate on MP machines.
doing it in the cpu driver. The previous code was incorrect anyway since
this value controls Px states, not throttling as the comment said. Since
we didn't support Px states before, there was no impact. Also, note that
we delay the write to SMI_CMD until after booting is complete since it
sometimes triggers a change in the frequency and we want to have all
drivers ready to detect/handle this.
devclass. As pointed out by dfr@, devclasses don't have to share the same
linkage if multiple drivers have the same name. Newbus should match the
devclasses based on name and allocate non-conflicting unit numbers.
the PERF_CTRL register in our probe method so that we can tell earlier
that another driver should handle this device due to FFixedHW. This avoids
scaring users when attach failed when we really wanted probe to fail.
type. This is needed if the resource is to be released later. The RID is
still also present, though less necessary since rman_get_rid() can be used
to obtain it from the resource.
settings as exported via the ACPI _PSS method. OEMs use this interface
to encapsulate chipset or processor-specific methods (e.g., SpeedStep or
Powernow) and export their settings in a standard way. On systems that
have valid ACPI Performance states and a hardware-specific driver (e.g.,
ichss), acpi_perf(4) is preferred.
producers rather than consumers as new-bus resources only handle consumed
resources. We already do this for the other ACPI resource types that
support the producer/consumer attribute.
object (/) rather than the pci bus object when walking the _PRT to force
attach devices. We already look up relative to the root object when doing
interrupt routing.
Suggested by: njl
For such devices, we require _PRS to exist and we warn if any of the
resources in _PRS are not IRQ resources (since we'll have no way of knowing
which of those resources to use without a working _CRS). When it does
come time to set resources, we build up a resource buffer from scratch
as we do for devices with _CRS that only have IRQ resources.
- Fix a bug with setting extended IRQ resources where we set the IRQ value
in the wrong resource structure meaning that whichever IRQ was listed in
_PRS was used instead. This might fix some weird issues on certain boxes
where IRQs > 16 don't seem to work when using ACPI.
- Fix a bug with how we walked the resource buffer after _SRS to call
config_intr() in that the 'end' variable was not properly updated, so we
could either terminate the loop early or loop after the end of the
buffer.
Tested by: pjd
place device objects in \ (in this case, PCI links.) Work around this by
starting our probe from \. To avoid attaching system scope objects,
explicitly skip them. (I think it's an ACPI-CA bug that \_SB and \_TZ have
device and thermal object types.) Thanks to pjd@ for testing.
MFC after: 2 weeks
multiple IRQs (which is nonsense for _CRS) when the link hasn't been
programmed. Before, this was a KASSERT. A ServerWorks system was
seen returning IRQs of 0, 2 in response to _CRS before link setup.
Thanks to sam@ for quick testing and turnaround on this.
Tested by: sam
If we are resuming non-MPSAFE drivers, they need Giant held for them.
This may fix some obscure suspend/resume problems. It has fixed keyrate
setting problems that were triggered by cardbus (MPSAFE) changing the
ordering for syscons resume (non-MPSAFE). Also, add some asserts that
Giant is held in our suspend/resume and shutdown methods.
Found by: iedowse
MFC after: 2 days
non-standard BIOSen. We used to implement this in local patches but
now that ACPI-CA has merged/re-implemented most of our fixes, they were
no longer needed and we just needed to turn this knob on. Also, remove
an unnecessary cast.
Tested by: phk
back on again in resume. Override the default of D3 with the value the
BIOS specifies in _SxD, if present. Skip serial devices (PNP05xx) since
they seem to hang when set to D3 and may require special driver support.
Also, skip non-type 0 PCI devices (i.e., bridges) since our we don't yet
save/restore their config space and that seems to be necessary.
If this gives you trouble with suspend/resume, you can disable the new
ACPI and PCI power behavior separately with these tunables & sysctls:
debug.acpi.do_powerstate
hw.pci.do_powerstate
Approved by: imp (pci)
Tested by: acpi@ (numerous)
in the _PRS or _CRS of link devices. If faced with multiple DPFs in a
_PRS, we just use the first one. We assume that if _CRS has DPF tags they
only contain a single set since multiple DPFs wouldn't make any sense. In
practice, the only DPFs I've seen so far for link devices are that the one
IRQ resource is surrounded by a DPF tag pair for no apparent reason, and
this should handle that case fine now.
- Only allocate link structures for IRQ resources for link devices rather
than allocating a link structure for every resource.
Reviewed by: njl
Tested by: phk
@sys/dev/acpica/acpi_pci_link.c:153" panic by backing out rev 1.37 in the SMP
case. It appears that on a dual-proc machine the assertions in the rev 1.37
commit log hold true.
resource lists. It used to be sized based only on _CRS, hence _PRS could
perform an out-of-bounds access if it was larger (i.e., when there are
dependent functions). Add asserts to detect this case. Note, this is
only a temporary fix and I believe _PRS and _CRS should have separate
arrays.
Also, fix a typo where the wrong irq was being check for the APIC case.
Submitted by: tegge
- Use a new-bus device driver for the ACPI PCI link devices. The devices
are called pci_linkX. The driver includes suspend/resume support so that
the ACPI bridge drivers no longer have to poke the links to get them
to handle suspend/resume. Also, the code to handle which IRQs a link is
routed to and choosing an IRQ when a link is not already routed is all
contained in the link driver. The PCI bridge drivers now ask the link
driver which IRQ to use once they determine that a _PRT entry does not
use a hardwired interrupt number.
- The new link driver includes support for multiple IRQ resources per
link device as well as preserving any non-IRQ resources when adjusting
the IRQ that a link is routed to.
- The entire approach to routing when using a link device is now
link-centric rather than pci bus/device/pin specific. Thus, when
using a tunable to override the default IRQ settings, one now uses
a single tunable to route an entire link rather than routing a single
device that uses the link (which has great foot-shooting potential if
the user tries to route the same link to two different IRQs using two
different pci bus/device/pin hints). For example, to adjust the IRQ
that \_SB_.LNKA uses, one would set 'hw.pci.link.LNKA.irq=10' from the
loader.
- As a side effect of having the link driver, unused link devices will now
be disabled when they are probed.
- The algorithm for choosing an IRQ for a link that doesn't already have an
IRQ assigned is now much closer to the one used in $PIR routing. When a
link is routed via an ISA IRQ, only known-good IRQs that the BIOS has
already used are used for routing instead of using probabilities to
guess at which IRQs are probably not used by an ISA device. One change
from $PIR is that the SCI is always considered a viable ISA IRQ, so that
if the BIOS does not setup any IRQs the kernel will degenerate to routing
all interrupts over the SCI. For non ISA IRQs, interrupts are picked
from the possible pool using a simplistic weighting algorithm.
Tested by: ru, scottl, others on acpi@
Reviewed by: njl
after boot so that PCI is initialized and we can probe for the problem
chipsets. Note that while probed but unusable states are disabled, they
aren't freed yet. In the future, it may make sense to detach them.
Tested by: Adam K Kirchoff <adamk at voicenet com>
MFC after: 2 days
i386 to dev/acpi_support. In theory, these devices could be found
other than in i386 machines only as amd64 becomes more popular. These
drivers don't appear to do anything i386 specific, so move them to
dev/acpi_support. Move config lines to files so that those
architectures that don't support kernel modules can build them into
the kernel. At the same time, rename acpi_snc to acpi_sony to follow
the lead of all the other specialty devices.
isn't worth adding to the modules lists that we have to hard code for
this to work. Since we print PID right away, we have a trace point
already.
Minor knf while I'm here.
the tree. Small tweaks were made by myself to eliminate unnecessary
includes and some other minor issues. Last time I asked takawata-san
about this driver, he suggested I commit it.
Submitted by: takawata
a bridge without a _PRT were a _PRT was needed. Instead, the warning in
dmesg is a false warning and only serves to cause unnecessary concern.
MFC after: 1 week
* Fix a bug where caches were flushed on non-C3 transitions.
* Be sure a working flush cache instruction is present before using it.
* Disable C3 completely if it isn't present.
may want to shut down here but the chance of BIOS vendors getting this
wrong is high. They're only supposed to announce this when all batteries
hit their critical level but past experience indicates we should be
conservative about this for now.
with acpi but the timer runs twice as fast. Note that the main problem
(system doesn't work properly with acpi disabled) should be fixed separately.
Changes:
* Add a quirk to disable the timer
* Merge the P5A and P5A-B quirks since they appear to be based on the
same ASL.
PR: i386/72450
Tested by: Kevin Oberman <oberman es.net>
MFC after: 3 days
allocate unallocated memory resources from the top 32MB of the address
space rather than the top 2GB. While the latter works on some
chipsets, it fails badly on others. 32MB is more conservative and
matches what cheap harware from this era is hardwired to pass.
table. acpidump(8) concatenates the body of the DSDT and SSDTs so an
edited ASL will contain all the necessary information. We can't use a
completely empty table since ACPI-CA reports this as a problem.
MFC after: 3 days
