Commit Graph

61 Commits

Author SHA1 Message Date
Jung-uk Kim
e7bb9ab605 Add a forgotten change from the previous commit. 2010-11-05 20:24:26 +00:00
Jung-uk Kim
9fe3e6c023 Fix a use-after-free bug for extended IRQ resource[1]. When _PRS buffer is
copied as a template for _SRS, a string pointer for descriptor name is also
copied and it becomes stale as soon as it gets de-allocated[2].  Now _CRS is
used as a template for _SRS as ACPI specification suggests if it is usable.
The template from _PRS is still utilized but only when _CRS is not available
or broken.  To avoid use-after-free the problem in this case, however, only
mandatory fields are copied, optional data is removed, and structure length
is adjusted accordingly.

Reported by:	hps[1]
Analyzed by:	avg[2]
Tested by:	hps
2010-11-05 19:50:09 +00:00
Jung-uk Kim
129d3046ef Import ACPICA 20090521. 2009-06-05 18:44:36 +00:00
John Baldwin
e71f249b66 Don't return an error from resume() if execution of _DIS fails for some
reason (not all BIOSen have _DIS methods for all link devices for example).
This matches the behavior of attach() with respect to _DIS as well.

Submitted by:	njl
2007-10-27 22:14:17 +00:00
John Baldwin
2445af1a8a Don't always re-route IRQs on resume. If this link hasn't been used, then
disable it with _DIS rather than assigning it an IRQ on resume.

MFC after:	1 week
2007-10-27 13:12:29 +00:00
Jung-uk Kim
2be4e4713a Catch up with ACPI-CA 20070320 import. 2007-03-22 18:16:43 +00:00
John Baldwin
67b712deec Reformat the bootverbose messages that dump out the status of pci_link
devices during attach to be more compact.

MFC after:	1 week
2006-11-09 18:01:20 +00:00
John Baldwin
0cdba3b7e5 When a user uses a hint to specify the IRQ for a link device, accept IRQs
that aren't listed as valid in the link device's set of possible IRQs.
This allows the hints to be used to work around broken BIOSes that don't
specify the correct ste of possible IRQs.  A warning is issued in the
dmesg in this case to be consistent with the $PIR handling code.

MFC after:	1 week
2006-08-07 19:52:30 +00:00
John Baldwin
8dc0e02023 Be a little more forgiving of lame BIOS writers. If a link device that
doesn't have any actual interrupts is listed in a _PRT entry, only print
a warning rather than panic'ing when we walk the _PRT's to build up count
of entries that reference a given link (the counts are used as weights so
that we can attempt to balance the load across IRQs used by link devices).
Instead, only panic if we attempt to use the _PRT entry to route an
interrupt for a device.

PR:		i386/89545
Tested by:	anders
2006-01-06 16:14:32 +00:00
John Baldwin
8294689115 Release the pci_link acpi serial lock if a link device has no actual links.
MFC after:	3 days
2006-01-03 20:19:34 +00:00
John Baldwin
f9959468bb If pci_link has been disabled via the acpi_disable tunable, then bail
immediately from acpi_pci_link_route_interrupt() since we aren't going
to have a valid pci_link device to talk to try to route interrupts.  This
fixes a page fault if you disable just pci_link.  Note that trying to use
ACPI without pci_link is probably not advised however.

MFC after:	1 week
Tested by:	Eugene Grosbein eugen at kuzbass dot ru
2005-12-05 19:50:00 +00:00
John Baldwin
ef2cda76c0 - Quiet the pci_link(4) devices so that they don't show up in dmesg now.
- 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
2005-11-23 16:36:13 +00:00
John Baldwin
a4104d1c3b Fix the code to look up the BIOS IRQ for a given link device by reading
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
2005-11-21 22:01:16 +00:00
Jung-uk Kim
e8d472a7af Catch up with ACPI-CA 20051021 import 2005-11-01 22:44:08 +00:00
Robert Watson
5bb84bc84b Normalize a significant number of kernel malloc type names:
- 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.
2005-10-31 15:41:29 +00:00
David E. O'Brien
2a191126de Canonize the include of acpi.h. 2005-09-11 18:39:03 +00:00
John Baldwin
b88076fede Correct the order of some if tests so that we don't complain about being
unable to route an IRQ when we do route an IRQ ok but bootverbose is off.

Reported by:	Ben Kaduk minimarmot at gmail dot com
2005-07-27 15:21:32 +00:00
John Baldwin
94b3af82c1 - Add support for link devices where _CRS just outright fails to execute.
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
2005-01-18 20:18:46 +00:00
Nate Lawson
2f3f3112c8 Minor cleanup: Reduce stack usage in probe method. Outdent probe. Use
TRUE/FALSE instead of 1/0 for booleans.  Remove trailing and extra whitespace.
2004-12-27 05:42:32 +00:00
Nate Lawson
8c702862e4 Only use the current value if there's one IRQ. Some systems return
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
2004-12-20 10:46:56 +00:00
Nate Lawson
6c69283ca8 Re-enable link programming on resume. It appears the previous bounds
error had caused the hang and it has been corrected now.
2004-12-13 06:59:34 +00:00
John Baldwin
7e1f562e2a - Do a better job of handling any Dependent Functions (aka DPFs) that appear
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
2004-12-01 21:05:02 +00:00
Nate Lawson
ba1c3b5304 Completely back out 1.37. Something else is going on and John wants to
keep the locking and solve the real problem.
2004-12-01 05:49:26 +00:00
David E. O'Brien
0297d51ea3 Fix "Lock ACPI PCI link not exclusively locked
@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.
2004-12-01 04:34:08 +00:00
Nate Lawson
06faf06ac5 Don't bother locking in attach(). At boot time, we're single-threaded
anyway and for some reason, witness seems confused about what's already
locked and triggers a false panic.
2004-11-30 17:48:10 +00:00
Nate Lawson
ad71daf0cb Make sure the link array is big enough to hold both _CRS and _PRS
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
2004-11-30 06:55:43 +00:00
Nate Lawson
4a29e1698c Temporarily disable programming IRQ links on resume. The new code hangs
several of my systems.
2004-11-26 23:31:59 +00:00
John Baldwin
5e1ba6d4ae Rework the ACPI PCI link code.
- 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
2004-11-23 22:26:44 +00:00
Nate Lawson
6e1151b6ab Allow routing to the SCI even if it's not in the list of valid IRQs.
MFC if:		no problems
2004-09-25 06:15:56 +00:00
John Baldwin
e0a9358679 Add a couple of macros to extract the PCI slot (device) and function from
an ACPI _ADR value and use that rather than inlining the same shifts and
masks everywhere.
2004-09-22 15:46:16 +00:00
Nate Lawson
520467d3ba Record a problem we can't workaround for now regarding duplicate interrupts
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.
2004-09-20 05:56:01 +00:00
Nate Lawson
ad7b13796e Don't print a warning message if the _CRS value is empty. This is already
covered by other printfs under ACPI_DEBUG and is not a failure case.

MFC after:	3 days
2004-09-16 17:19:16 +00:00
Nate Lawson
0c601400a3 Disable links after getting the possible resources. Even though _DIS
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.
2004-09-01 17:59:29 +00:00
Nate Lawson
85cdc19d00 Always set the status and move a printf under bootverbose.
Tested by:	gj
2004-08-27 00:53:11 +00:00
Nate Lawson
59506cd39a If getting the current setting after modifying the link failed, we assume
it succeeded.  However, we also need to set the status to AE_OK.
2004-08-26 17:14:36 +00:00
Nate Lawson
85bafe5ec3 Fix PCI link irq programming on resume. A logic bug prevented a device
match, inverting which links actually got resumed.

Submitted by:	Hiroyuki Aizu <eyes_at_navi.org>
MFC after:	3 days
2004-08-21 18:18:32 +00:00
Nate Lawson
7ecd49c463 If _CRS fails, assume that it succeeded. The ASUS K8V (and others) defines
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.
2004-08-18 16:39:59 +00:00
Nate Lawson
c2c373f9a0 Fix building for the ACPI_DEBUG case. 2004-08-13 19:27:21 +00:00
Nate Lawson
86b697a70b MPSAFE locking
* Serialize access to acpi_pci_link_config(), acpi_pci_find_prt(),
  acpi_pci_link_route(), and acpi_pci_link_resume().
* Add lock assertions to all functions called by them.
2004-08-13 06:22:03 +00:00
Nate Lawson
56a7639b91 Skip dependent functions when finding the resource from _PRS to use for
later calls to _SRS.  Add note that this code should be centralized at
some point.

Bug from:	Jiawei Ye <leafy7382_AT_gmail.com>
2004-08-12 17:06:05 +00:00
Nate Lawson
310953d935 Fix the PRT entry code in acpi_pci_link to always add the entry, even if
there is no irq link.  Since we now use the stored copy of PRT, not the
one that used to be passed into acpi_pcib_route_interrupt(), we need it in
the list. [1]

Fix a bug in acpi_pci_find_prt() where we weren't checking the bus, thus
choosing the wrong PRT entry to use for routing the link.  Also, add a
printf for the case where the PRT entry is not found as this should not
happen.

Tested by:	marcel [1]
2004-08-12 02:06:19 +00:00
Nate Lawson
8f24713075 Add some more verbose warning/error messages to help with users reporting
problems with irq routing.
2004-08-11 20:37:24 +00:00
Nate Lawson
e4116e931c Re-work ACPI PCI IRQ routing (_PRT, link devices). The old approach was
incomplete in that the PRT routing was not aware of link programming.
Fix this by doing all routing through the link devices.  The new algorithm
for setting up links is:

1. Read _CRS to get current setting.  If invalid (not in _PRS), then set
   to 0.
2. Attempt to call _DIS on the link.  If successful, mark the link as not
   routed.  Otherwise, assume it still is.

Then when a routing request occurs:

3. Update weights for all IRQs
4. Attempt to route the initial IRQ if valid
5. If that fails, walk through the sorted list, attempting to route IRQs.
6. Configure the trigger/polarity based on _PRS.

Other changes:
* Add acpi_pci_find_prt() to look up the PRT entry for a given device and
  acpi_pci_link_route() to select/route the best IRQ for it.
* Remove duplicated code in acpi_pcib_route_interrupt() that picked the
  first IRQ from _PRS.
* Remove unneeded arguments from acpi_pcib_resume() and friends.
* Ignore _STA on link devices but report if it seems strange.
* Add a prt_source handle to the PRT structure since the ACPI struct
  ACPI_PCI_ROUTING_TABLE uses a fixed-size entry for it.  We'll need to
  dynamically size this object if we want to use it the same way ACPI-CA
  does.  Null-terminate the source.

Tested by:	Luo Hong <luohong99_at_mails.tsinghua.edu.cn>,
		Jeffrey Katcher <jmkatcher_at_yahoo.com>
Info from:	jhb, Len Brown (Intel)
2004-08-11 14:52:50 +00:00
Nate Lawson
85524256ea Refine updates to PCI irq routing. Check _STA and _CRS but only print a
message if they are incorrect.  Also, remove the hack of allowing the
initial irq setting to not be in _PRS.  As before, the old behavior can be
regained by defining ACPI_OLD_PCI_LINK.
2004-08-06 04:50:56 +00:00
Nate Lawson
298e3d15d7 Work around non-compliant BIOS PCI link devices. Some systems have the
following behavior:

* Link devices return invalid status (_STA) values.  The results are very
  unreliable -- sometimes never present.  Just ignore the status and pick
  the best configuration from _PRS.

* Link devices return invalid current settings (_CRS).  Even after setting
  the link value, many systems still return a different setting for _CRS.
  When setting an IRQ, don't bother to check _CRS to see if we succeeded.
  Note that we still check _CRS before routing and this should be addressed
  as well.

Since this is a sensitive area, leave the old behavior accessible via
uncommenting the define for ACPI_OLD_PCI_LINK at the top of the file.  Once
this has been thoroughly tested, this option and the code it covers will
be removed.

Thanks to Len Brown at Intel for informing us of these issues as he worked
around them in Linux.
2004-08-05 06:54:16 +00:00
John Baldwin
522542cc9c Revert the removal of the initial_irq hack for now as this code is more
broken than I thought and doesn't do a good job of routing virgin
interrupts at all.
2004-06-14 18:54:14 +00:00
John Baldwin
91c14f698c Don't assume that the current setting (_CRS) of a PCI link device is
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
2004-05-28 17:31:32 +00:00
Nate Lawson
ea6b2bc923 Style and printf message cleanups. 2004-04-14 03:34:11 +00:00
John Baldwin
1aa9b61068 Use getenv_int() rather than reimplementing it. 2004-01-20 21:38:48 +00:00
Peter Wemm
8070ad52a1 Don't use NULL (pointer) when we're testing for a count of 0 (integer). 2003-12-23 02:29:46 +00:00