Re: 5.3-BETA5 panics when inserting dc0 carbus card (only with ACPI enabled) enabled)

[cc Nate since he made a commit that might be involved]

On Wed, Sep 22, 2004 at 18:20 (+0200), Adrian Steinmann wrote:
> 
> I can confirm that this has been happening on my Thinkpad T20
...
> since mid June.
> 
> When I build a kernel with date 20040613, I'm ok, then for 20040615
> I have this probe problem, i.e.:
> 
>     cvs -qR -d /usr/cvs co -D20040615UTC sys - bad
>     cvs -qR -d /usr/cvs co -D20040613UTC sys - good

Using these dates and looking at the diffs, my guess is that this commit
----
njl         2004-06-13 22:52:31 UTC

  FreeBSD src repository

  Modified files:
    sys/dev/acpica       acpi.c acpi_acad.c acpi_button.c 
                         acpi_cmbat.c acpi_ec.c acpi_isab.c 
                         acpi_lid.c acpi_pcib_acpi.c 
                         acpi_resource.c acpivar.h 
  Log:
  Add support to ACPI to manage its own resources.  Previously, resource
  allocation was passed up to nexus.  Now, we probe sysresource objects and
  manage the resources they describe in a local rman pool.  This helps
  devices which attach/detach varying resources (like the _CST object) and
  module loads/unloads.  The allocation/release routines now check to see if
  the resource is described in a child sysresource object and if so,
  allocate from the local rman.  Sysresource objects add their resources to
  the pool and reserve them upon boot.  This means sysresources need to be
  probed before other ACPI devices.
  
  Changes include:
  * Add ordering to the child device probe.  The current order is:  system
  resource objects, embedded controllers, then everything else.
  * Make acpi_MatchHid take a handle instead of a device_t arg.
  * Replace acpi_{get,set}_resource with the generic equivalents.
  
  Revision  Changes    Path
  1.159     +137 -52   src/sys/dev/acpica/acpi.c
  1.27      +1 -1      src/sys/dev/acpica/acpi_acad.c
  1.27      +6 -4      src/sys/dev/acpica/acpi_button.c
  1.30      +2 -2      src/sys/dev/acpica/acpi_cmbat.c
  1.52      +1 -1      src/sys/dev/acpica/acpi_ec.c
  1.8       +3 -1      src/sys/dev/acpica/acpi_isab.c
  1.23      +1 -1      src/sys/dev/acpica/acpi_lid.c
  1.35      +1 -1      src/sys/dev/acpica/acpi_pcib_acpi.c
  1.25      +91 -37    src/sys/dev/acpica/acpi_resource.c
  1.71      +3 -1      src/sys/dev/acpica/acpivar.h
----
is involved somehow. That is not to say that there is anything wrong
with this commit, but something more might need to be fixed.

I have not tried to verify if this is the offending commit, nor have I 
tried to revert this commit alone since I guess that would fail missirably.

Nate, do you think this commit might be the cause of our problem
and if so is there any information we can provide.

/Johan K

--
Johan Karlsson		mailto:johan_at_FreeBSD.org