| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
keep the locking and solve the real problem.
|
|
|
|
|
|
| |
@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.
|
|
|
|
|
| |
anyway and for some reason, witness seems confused about what's already
locked and triggers a false panic.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
that they are equivalent.
|
|
|
|
| |
several of my systems.
|
|
|
|
| |
- Sort function prototypes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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.
|
|
|
|
| |
defined.
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
switching. Don't initialize variables in their declaration. Reduce stack
usage for device names. Minor style cleanups.
MFC after: 1 week
|
|
|
|
| |
take up only one line.
|
|
|
|
|
|
|
| |
hw.pci.host_mem_start tunable. Add comments to TUNABLE_INT and
TUNABLE_QUAD recommending against their use.
MFC after: 3 weeks
|
| |
|
| |
|
|
|
|
| |
MFC after: 1 day
|
|
|
|
| |
MFC after: 1 day
|
|
|
|
|
|
| |
* 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.
|
|
|
|
|
|
| |
introduce hw.{pci,acpi}.host_mem_start tunable to change this.
MFC: ASAP
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
C3. Instead, flush caches before entering C3. This may be slower but
provides good power savings.
|
|
|
|
|
|
| |
This removes the last MD portion of acpi_cpu.c.
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
MFC if: no problems
|
|
|
|
|
| |
an ACPI _ADR value and use that rather than inlining the same shifts and
masks everywhere.
|
|
|
|
|
|
|
| |
but that function has been removed. This avoids a potential unnecessary
fan switch on boot. Also remove some commented out code.
MFC after: 3 days
|
|
|
|
| |
may help with double panics.
|
|
|
|
|
| |
because of links left enabled while in APIC mode. A large scale rework of
irq links is underway by jhb@ which should fix this eventually.
|
|
|
|
|
|
| |
covered by other printfs under ACPI_DEBUG and is not a failure case.
MFC after: 3 days
|
|
|
|
| |
wrap a long line.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
would turn off all fans when initializing a zone. However, the HP Omnibook
500 generates a notify saying the zone needs to be re-evaluated whenever
its fan is switched on or off. This produced an infinite loop. Also, note
that running _SCP can generate the same notify.
Since we need to make sure old fan references are turned off when getting
new ones, run acpi_tz_monitor() first. This will turn off any unneeded
fans. Then, check for new settings. After that, run acpi_tz_monitor()
again to turn on/off any fans referenced by the new settings.
Tested by: brooks
|
|
|
|
|
|
|
| |
returned and then infer the state from calls to _ON/_OFF. This works
around a problem in systems that don't correctly report the state (i.e.
the HP Omnibook 500 reports "on" for its fan always after it has been
turned on once).
|
|
|
|
|
|
| |
unless ACPI_DEBUG is defined. Users don't typically care about errant
breakpoint instructions. The HP Pavilion 7915 has this in its PCI0
_INI method for rev 0x6040000 of the RSDT.
|
|
|
|
|
|
| |
should only affect current resources, it seems best to wait until all
configuration is done before disabling it. If this fixes any problems, it
is a MT5 candidate.
|
|
|
|
| |
sysctl tool to print a more readable value for temperatures.
|
|
|
|
| |
Tested by: gj
|
|
|
|
| |
it succeeded. However, we also need to set the status to AE_OK.
|
|
|
|
|
|
|
|
| |
operation for some users with pure GPE lid switches (vs. embedded
controller.)
Tested by: Anish Mistry <mistry.7_at_osu.edu>
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hold its own values, pass them up to the parent (acpi0) and merge/uniq them
on the way. After the namespace evaluation, acpi will reserve these
resources and manage them via rman before bus_generic_probe() and
bus_generic_attach(). This is necessary because some systems specify
conflicting resources in separate sysresource objects. It's also cleaner
in that the interface between sysresource and acpi is now merely the parent's
resource list. This code handles the following cases:
1. Unique resource: add it to the parent via bus_set_resource().
2. New wholly contained in old: discard new.
3. New tail overlaps old head: grow old head downward.
AND/OR
4. New head overlaps old tail: grow old tail upward.
Tested by: Pawel Worach <sajd_at_telia.com>
Tested by: Radek Kozlowski <radek_at_raadradd.com>
MFC after: 5 days
|
|
|
|
|
|
|
| |
match, inverting which links actually got resumed.
Submitted by: Hiroyuki Aizu <eyes_at_navi.org>
MFC after: 3 days
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
systems that have overlapping regions specified in their sysresource
objects. This patch fixes ATA DMA and acpi_timer allocation for such
sysctems. It should eventually be moved to resource_list_add() if it is
a valid generalized approach. The minimal approach for 5.3 is:
"Loop through all current resources to see if the new one overlaps
any existing ones. If so, the old one always takes precedence and
the new one is adjusted (or rejected). We check for three cases:
1. Tail of new resource overlaps head of old resource: truncate the
new resource so it is contiguous with the start of the old.
2. New resource wholly contained within the old resource: error.
3. Head of new resource overlaps tail of old resource: truncate the
new resource so it is contiguous, following the old."
Tested by: Radek Kozlowski <radek_at_raadradd.com>
Discussed with: imp
MFC after: 4 days
|
|
|
|
|
| |
single-entry irq links even though it uses an APIC. It appears that it
ignores _SRS when in APIC mode but returns a valid irq at other times.
|