DragonFly kernel List (threaded) for 2005-04
Re: [PR] acpi module related bug in 1.2.0R
On Sun, Apr 10, 2005 at 01:02:32PM +0800, Sepherosa Ziehau wrote:
> when 1) acpi is enabled
> 2) network application is invoked (ping, ssh ...)
> following messages popped up continuously, also the watchdog timeout
> caused my NIC completely choked and the high interrupted rate caused my
> card bus dock hissing :-(.
> intr 3 at 80049 hz, livelocked! limiting at 20000 hz
> xl0: watchdog timeout
> intr 3 at 1893 hz, removing livelock limit
> intr 3 is associated with cbb0 and shared with cbb1.
> I orignally suspected the change of sys/dev/pccard/pccbb/pccbb.c (1.3 ->
> 1.4) caused the problem, but after I reverted it back, the above messages
> continued. After acpi is disabled, everything works fine. So I think the
> problem lies within acpi module.
> attachment are
> 1) dmesg (boot verbose) with acpi enabled
> 2) dmesg without acpi enabled
I hope you posted dmesg messages from the same kernel/modules, rather than
from GENERIC and custom one, but it's OK. What you're seeing is probably
something similar to this one(Cc'd to the original poster):
I think that the problem here is probably because acpi_probe_child()
inserts a placeholder device during ACPI namespace scan in a way which
confuses PCI code and prevent it from initializing the cardbus devices
(or interrupt routing) properly.
There's a kernel environment variable named debug.acpi.disabled to name
ACPI subdrivers to disable at boot time. To use it, drop into the boot
loader prompt and type as follows("OK" is boot loader prompt):
OK set debug.acpi.disabled="cmbat children"
OK boot -v
There's also a variable named debug.acpi.avoid to avoid portions
of ACPI namespace rather than all sub-buses(use this instead of
OK set debug.acpi.avoid="_SB.PCI0.PCIE.CRD0 _SB.PCI0.PCIE.CRD1"
If your ACPI module is compiled with ACPI_DEBUG, you can use the
following variables to see how children are scanned:
OK set debug.acpi.layer="ACPI_BUS"
OK set debug.acpi.level="ACPI_LV_OBJECTS"