LOR in Jan16 -CUR, ACPI related possibly

[Ketrien I. Saihr-Kenchedra]

Apologies for the lack of debug, but the workspace around here is really
a disaster area, and console's acting up. I tried to get a dump, no go
even w/call doadump. kgdb's not working again either, go figure. (I have
related work that gave occasion to find this LOR.)

Sorry for the seeming lack of detail; I really have no way to accurately
transcribe this at the moment. It is 100% reproducible at least, but does
not panic() the system. It's as simple as kldload if_pcn,
kldunload if_pcn, LOR.

1st pcn (Network driver) sys/pci/if_pcn.c:1385
2nd ACPI root bus sys/dev/acpica/acpi.c:1050

witness_checkorder
_sx_xlock
acpi_release_resource
bus_generic_release_resource
bus_release_resource
pcn_detach
device_detach
devclass_delete_driver
driver_module_handler
module_unload
linker_file_unload
kern_kldunload
syscall
Xint0x80_syscall

Now, on a similar note, I'm currently working on the pcn(4) driver, and
encountered a not-dissimilar LOR versus ACPI again, this on load. I was
able to debug that one somewhat, but not scribble much down. This LOR
does panic() the system.

1st pcn  2nd ACPI root bus
pcn_attach
device_attach
pci_driver_added
devclass_add_driver
driver_module_handler
module_register_init
linker_load_module

My code uses mdodd@'s changes to probe(), which, contrary to wording,
does still lock out of necessity, but has not exhibited LOR before. The
flow is unchaged up to the LOR occurance, which appears to occur at 
ether_ifattach(). I'm still rooting around to see if it _is_ occuring
earlier, but it doesn't look like it. This one, I can't reproduce so
well, due to a panic in uma that keeps popping up.

Afraid I'm a little stuck on this one; I'm still trying to get gdb 
working without success. Any chance someone could take a look at this?
Thanks, as usual.

-Ketrien I. Saihr-Kenchedra
<Scythe> caps lock is not your friend.
<Scythe> In fact, it is your mortal enemy and it made very
          disparaging remarks about your mother.