on 08/11/2012 11:06 Tom Lislegaard said the following: > >> -----Original Message----- >> From: Andriy Gapon [mailto:a...@freebsd.org] >> Sent: 6. november 2012 19:53 >> To: Tom Lislegaard >> Cc: freebsd-stable@FreeBSD.org; freebsd-a...@freebsd.org >> Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource >> >> on 06/11/2012 10:50 Tom Lislegaard said the following: >>> No problem, I'm happy to assist in debugging this. >>> >>> Enabling the acpi debugging quickly fills the kernel message buffer, >>> but it seems to be the same set of messages repeating again and again >>> so I think this is representative >>> >>> https://dl.dropbox.com/u/13263820/debug_dmesg.txt >> >> This didn't clarify things as much as I hoped, but I am inclined to think >> that it is polling from >> userland that triggers all the processor notifications. >> >> In any case, here is a patch to try: >> http://people.freebsd.org/~avg/acpi_cpu-stable.diff >> >> Please disable all the tunings added to loader.conf during debugging when >> testing this patch. >> >> The patch is a combination of two changes: >> >> 1. >> Do not needlessly use ever-increasing resource IDs. >> Rather use the IDs that are tied to Cx level IDs. >> Also, release previous resources upon _CST change. >> >> 2. >> Bind a thread that processes a processor _CST change notification to the >> target processor and perform >> _CST processing in a critical section. These should ensure the following: >> - the CPU doesn't enter an idle state and doesn't try to use Cx level >> parameters >> while they are being changed >> - Cx level parameters are never concurrently modified when multiple >> notifications >> fire in a rapid succession and multiple ACPI task threads are configured >> sched_bind is a heavy- >> weight operation, but it is OK in this context because processor >> notifications should not occur too >> often >> > > Thanks. I applied the patch yesterday, but found this morning the machine had > crashed during the night with a page fault
This looks like an unrelated / new / different problem. Could you please poke around frame 7? BTW, what version of FreeBSD do you use? What ACPICA version is there (debug.acpi.acpi_ca_version) ? It seems like somewhat similar panics were reported in the past: http://lists.freebsd.org/pipermail/freebsd-current/2012-March/032637.html http://lists.freebsd.org/pipermail/freebsd-acpi/2012-January/007406.html > (kgdb) bt > #0 doadump (textdump=Variable "textdump" is not available. > ) at pcpu.h:229 > #1 0xffffffff804441f4 in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:448 > #2 0xffffffff804446dc in panic (fmt=0x1 <Address 0x1 out of bounds>) at > /usr/src/sys/kern/kern_shutdown.c:636 > #3 0xffffffff806f234d in trap_fatal (frame=0xfffffe00089264a0, eva=Variable > "eva" is not available. > ) at /usr/src/sys/amd64/amd64/trap.c:878 > #4 0xffffffff806f2668 in trap_pfault (frame=0xffffff82450401b0, usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:794 > #5 0xffffffff806f29ec in trap (frame=0xffffff82450401b0) at > /usr/src/sys/amd64/amd64/trap.c:463 > #6 0xffffffff806dc5ff in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:228 > #7 0xffffffff802d1bdd in AcpiOsAcquireObject (Cache=0xfffffe00052bac60) at > /usr/src/sys/contrib/dev/acpica/utilities/utcache.c:316 > #8 0xffffffff802d6883 in AcpiUtAllocateObjectDescDbg > (ModuleName=0xffffffff8074c3f0 "dsutils", LineNumber=703, > ComponentId=Variable "ComponentId" is not available. > ) at /usr/src/sys/contrib/dev/acpica/utilities/utobject.c:437 > #9 0xffffffff802d6a1d in AcpiUtCreateInternalObjectDbg > (ModuleName=0xffffffff8074c3f0 "dsutils", LineNumber=703, ComponentId=64, > Type=1) at /usr/src/sys/contrib/dev/acpica/utilities/utobject.c:112 > #10 0xffffffff802a71e8 in AcpiDsCreateOperand (WalkState=0xfffffe0008a3bc00, > Arg=0xfffffe0005366800, ArgIndex=0) at > /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:703 > #11 0xffffffff802a7587 in AcpiDsCreateOperands (WalkState=0xfffffe0008a3bc00, > FirstArg=0xfffffe0005366800) at > /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:798 > #12 0xffffffff802a856e in AcpiDsExecEndOp (WalkState=0xfffffe0008a3bc00) at > /usr/src/sys/contrib/dev/acpica/dispatcher/dswexec.c:567 > #13 0xffffffff802c9441 in AcpiPsParseLoop (WalkState=0xfffffe0008a3bc00) at > /usr/src/sys/contrib/dev/acpica/parser/psloop.c:1249 > #14 0xffffffff802ca8dd in AcpiPsParseAml (WalkState=0xfffffe0008a3bc00) at > /usr/src/sys/contrib/dev/acpica/parser/psparse.c:525 > #15 0xffffffff802cb981 in AcpiPsExecuteMethod (Info=0xfffffe01a2143100) at > /usr/src/sys/contrib/dev/acpica/parser/psxface.c:368 > #16 0xffffffff802c2287 in AcpiNsEvaluate (Info=0xfffffe01a2143100) at > /usr/src/sys/contrib/dev/acpica/namespace/nseval.c:193 > #17 0xffffffff802d3f56 in AcpiUtEvaluateObject > (PrefixNode=0xfffffe00052f6540, Path=0xffffffff807538f6 "_STA", > ExpectedReturnBtypes=1, ReturnDesc=0xffffff8245040660) at > /usr/src/sys/contrib/dev/acpica/utilities/uteval.c:102 > #18 0xffffffff802d428f in AcpiUtExecute_STA (DeviceNode=0xfffffe00052f6540, > Flags=0xfffffe01cc0d1e18) at > /usr/src/sys/contrib/dev/acpica/utilities/uteval.c:276 > #19 0xffffffff802c7e47 in AcpiGetObjectInfo (Handle=Variable "Handle" is not > available. > ) at /usr/src/sys/contrib/dev/acpica/namespace/nsxfname.c:423 > #20 0xffffffff802e35ed in acpi_BatteryIsPresent (dev=0xfffffe0005378c00) at > /usr/src/sys/dev/acpica/acpi.c:2064 > #21 0xffffffff802e66e1 in acpi_battery_get_battinfo (dev=0x0, > battinfo=0xffffffff80a4ba70) at /usr/src/sys/dev/acpica/acpi_battery.c:176 > #22 0xffffffff802e6a44 in acpi_battery_sysctl (oidp=0xfffffe0008785600, > arg1=Variable "arg1" is not available. > ) at /usr/src/sys/dev/acpica/acpi_battery.c:428 > #23 0xffffffff8044e057 in sysctl_root (oidp=Variable "oidp" is not available. > ) at /usr/src/sys/kern/kern_sysctl.c:1513 > #24 0xffffffff8044e335 in userland_sysctl (td=Variable "td" is not available. > ) at /usr/src/sys/kern/kern_sysctl.c:1623 > #25 0xffffffff8044e84a in sys___sysctl (td=0xfffffe0008c6c920, > uap=0xffffff8245040a70) at /usr/src/sys/kern/kern_sysctl.c:1549 > #26 0xffffffff806f1c40 in amd64_syscall (td=0xfffffe0008c6c920, traced=0) at > subr_syscall.c:135 > #27 0xffffffff806dc8e7 in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:387 > #28 0x00000008026587ec in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > -tom > -- Andriy Gapon _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
