RE: 9-Stable panic: resource_list_unreserve: can't find resource
> -Original Message- > From: Andriy Gapon [mailto:a...@freebsd.org] > Sent: 8. november 2012 11:53 > To: Tom Lislegaard > Cc: freebsd-sta...@freebsd.org; freebsd-acpi@FreeBSD.org > Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource > > 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-sta...@freebsd.org; freebsd-acpi@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? I've put up some more info https://dl.dropbox.com/u/13263820/vmcore_7.txt > BTW, what version of FreeBSD do you use? Version is RELENG_9 checked out ~3 days ago > What ACPICA version is there (debug.acpi.acpi_ca_version) ? debug.acpi.acpi_ca_version: 20110527 -tom > > 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 0x804441f4 in kern_reboot (howto=260) at > > /usr/src/sys/kern/kern_shutdown.c:448 > > #2 0x804446dc in panic (fmt=0x1 ) > > at /usr/src/sys/kern/kern_shutdown.c:636 > > #3 0x806f234d in trap_fatal (frame=0xfe00089264a0, > > eva=Variable "eva" is not available. > > ) at /usr/src/sys/amd64/amd64/trap.c:878 > > #4 0x806f2668 in trap_pfault (frame=0xff82450401b0, > > usermode=0) at /usr/src/sys/amd64/amd64/trap.c:794 > > #5 0x806f29ec in trap (frame=0xff82450401b0) at > > /usr/src/sys/amd64/amd64/trap.c:463 > > #6 0x806dc5ff in calltrap () at > > /usr/src/sys/amd64/amd64/exception.S:228 > > #7 0x802d1bdd in AcpiOsAcquireObject > > (Cache=0xfe00052bac60) at > > /usr/src/sys/contrib/dev/acpica/utilities/utcache.c:316 > > #8 0x802d6883 in AcpiUtAllocateObjectDescDbg > > (ModuleName=0x8074c3f0 "dsutils", > LineNumber=703, ComponentId=Variable "ComponentId" is not available. > > ) at /usr/src/sys/contrib/dev/acpica/utilities/utobject.c:437 > > #9 0x802d6a1d in AcpiUtCreateInternalObjectDbg > > (ModuleName=0xf
Re: 9-Stable panic: resource_list_unreserve: can't find resource
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-sta...@freebsd.org; freebsd-acpi@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 0x804441f4 in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:448 > #2 0x804446dc in panic (fmt=0x1 ) at > /usr/src/sys/kern/kern_shutdown.c:636 > #3 0x806f234d in trap_fatal (frame=0xfe00089264a0, eva=Variable > "eva" is not available. > ) at /usr/src/sys/amd64/amd64/trap.c:878 > #4 0x806f2668 in trap_pfault (frame=0xff82450401b0, usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:794 > #5 0x806f29ec in trap (frame=0xff82450401b0) at > /usr/src/sys/amd64/amd64/trap.c:463 > #6 0x806dc5ff in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:228 > #7 0x802d1bdd in AcpiOsAcquireObject (Cache=0xfe00052bac60) at > /usr/src/sys/contrib/dev/acpica/utilities/utcache.c:316 > #8 0x802d6883 in AcpiUtAllocateObjectDescDbg > (ModuleName=0x8074c3f0 "dsutils", LineNumber=703, > ComponentId=Variable "ComponentId" is not available. > ) at /usr/src/sys/contrib/dev/acpica/utilities/utobject.c:437 > #9 0x802d6a1d in AcpiUtCreateInternalObjectDbg > (ModuleName=0x8074c3f0 "dsutils", LineNumber=703, ComponentId=64, > Type=1) at /usr/src/sys/contrib/dev/acpica/utilities/utobject.c:112 > #10 0x802a71e8 in AcpiDsCreateOperand (WalkState=0xfe0008a3bc00, > Arg=0xfe0005366800, ArgIndex=0) at > /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:703 > #11 0x802a7587 in AcpiDsCreateOperands (WalkState=0xfe0008a3bc00, > FirstArg=0xfe0005366800) at > /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:798 > #12 0x802a856e in AcpiDsExecEndOp (WalkState=0xfe0008a3bc00) at > /usr/src/sys/contrib/dev/acpica/dispatcher/dswexec.c:567 > #13 0x802c9441 in AcpiPsParseLoop (WalkState=0xfe0008a3bc00) at > /usr/src/sys/contrib/dev/acpica/parser/psloop.c:1249 > #14 0x802ca8dd in AcpiPsParseAml (WalkState=0xfe0008a3bc00) at > /usr/src/sys/
RE: 9-Stable panic: resource_list_unreserve: can't find resource
> -Original Message- > From: Andriy Gapon [mailto:a...@freebsd.org] > Sent: 6. november 2012 19:53 > To: Tom Lislegaard > Cc: freebsd-sta...@freebsd.org; freebsd-acpi@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 (kgdb) bt #0 doadump (textdump=Variable "textdump" is not available. ) at pcpu.h:229 #1 0x804441f4 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0x804446dc in panic (fmt=0x1 ) at /usr/src/sys/kern/kern_shutdown.c:636 #3 0x806f234d in trap_fatal (frame=0xfe00089264a0, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:878 #4 0x806f2668 in trap_pfault (frame=0xff82450401b0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:794 #5 0x806f29ec in trap (frame=0xff82450401b0) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0x806dc5ff in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #7 0x802d1bdd in AcpiOsAcquireObject (Cache=0xfe00052bac60) at /usr/src/sys/contrib/dev/acpica/utilities/utcache.c:316 #8 0x802d6883 in AcpiUtAllocateObjectDescDbg (ModuleName=0x8074c3f0 "dsutils", LineNumber=703, ComponentId=Variable "ComponentId" is not available. ) at /usr/src/sys/contrib/dev/acpica/utilities/utobject.c:437 #9 0x802d6a1d in AcpiUtCreateInternalObjectDbg (ModuleName=0x8074c3f0 "dsutils", LineNumber=703, ComponentId=64, Type=1) at /usr/src/sys/contrib/dev/acpica/utilities/utobject.c:112 #10 0x802a71e8 in AcpiDsCreateOperand (WalkState=0xfe0008a3bc00, Arg=0xfe0005366800, ArgIndex=0) at /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:703 #11 0x802a7587 in AcpiDsCreateOperands (WalkState=0xfe0008a3bc00, FirstArg=0xfe0005366800) at /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:798 #12 0x802a856e in AcpiDsExecEndOp (WalkState=0xfe0008a3bc00) at /usr/src/sys/contrib/dev/acpica/dispatcher/dswexec.c:567 #13 0x802c9441 in AcpiPsParseLoop (WalkState=0xfe0008a3bc00) at /usr/src/sys/contrib/dev/acpica/parser/psloop.c:1249 #14 0x802ca8dd in AcpiPsParseAml (WalkState=0xfe0008a3bc00) at /usr/src/sys/contrib/dev/acpica/parser/psparse.c:525 #15 0x802cb981 in AcpiPsExecuteMethod (Info=0xfe01a2143100) at /usr/src/sys/contrib/dev/acpica/parser/psxface.c:368 #16 0x802c2287 in AcpiNsEvaluate (Info=0xfe01a2143100) at /usr/src/sys/contrib/dev/acpica/namespace/nseval.c:193 #17 0x802d3f56 in AcpiUtEvaluateObject (PrefixNode=0xfe00052f6540, Path=0x807538f6 "_STA", ExpectedReturnBtypes=1, ReturnDesc=0xff8245040660) at /usr/src/sys/contrib/dev/acpica/utilities/uteval.c:102 #18 0x802d428f in AcpiUtExecute_STA (DeviceNode=0xfe00052f6540, Flags=0xfe01cc0d1e18) at /usr/src/sys/contrib/dev/acpica/utilities/uteval.c:276 #19 0x802c7e47 in AcpiGetObjectInfo (Handle=Variable "Handle" is not available. ) at /usr/src/sys/contrib/dev/acpica/namespace/nsxfname.
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 > And, btw, thanks for your efforts. Thank you for all the excellent debugging and testing! P.S. I still believe that BIOS/ACPI on the machine behaves sub-optimally. -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
RE: 9-Stable panic: resource_list_unreserve: can't find resource
> -Original Message- > From: Andriy Gapon [mailto:a...@freebsd.org] > Sent: 5. november 2012 18:08 > To: Tom Lislegaard > Cc: freebsd-sta...@freebsd.org; freebsd-acpi@FreeBSD.org > Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource > > on 05/11/2012 16:52 Tom Lislegaard said the following: > > > > > >> -Original Message- > >> From: Andriy Gapon [mailto:a...@freebsd.org] > >> Sent: 5. november 2012 15:21 > >> To: Tom Lislegaard > >> Cc: freebsd-sta...@freebsd.org; freebsd-acpi@FreeBSD.org > >> Subject: Re: 9-Stable panic: resource_list_unreserve: can't find > >> resource > >> > >> on 05/11/2012 15:54 Tom Lislegaard said the following: > >>> Here's the distribution from running devd over 40 minutes > >>> > >>> 589 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU0 > >>> notify=0x81' > >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU1 > >>> notify=0x81' > >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU2 > >>> notify=0x81' > >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU3 > >>> notify=0x81' > >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU4 > >>> notify=0x81' > >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU5 > >>> notify=0x81' > >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU6 > >>> notify=0x81' > >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU7 > >>> notify=0x81' > >>> 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE > >>> cdev=dsp4.1' > >>> 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE > >>> cdev=pts/2' > >>> 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE > >>> cdev=vboxdrv0' > >>> 1 Processing event '!system=DEVFS subsystem=CDEV type=DESTROY > >>> cdev=dsp4.1' > >>> 1 Processing event '!system=DEVFS subsystem=CDEV type=DESTROY > >>> cdev=vboxdrv0' > >>> > >>> Any use in running it over a longer period of time? > >> > >> Very interesting. > >> So the processors get _CST change notifications rather frequently, > >> but there is no obvious source/cause for them... > >> > >> Could you please send to me acpidump -dt output or upload it somewhere and > >> post a link? > > > > Here you go > > > > https://dl.dropbox.com/u/13263820/acpidump.txt > > So, ACPI platform on your machine sends 0x81 notification for processors > objects each time "_PSR" > method of AC Adapter / Power Source device is queried. > There could be a number of reason to invoke the method - either AC line > status queries from userland > (some battery / line monitoring program/applet) or internal ACPI > notifications. > > Are you willing to go as far as recompiling your kernel with 'options > ACPI_DEBUG' > to get to the bottom of this issue? > If yes, then please do that and also add the following lines to loader.conf: > debug.acpi.layer="ACPI_EVENTS ACPI_AC_ADAPTER" > debug.acpi.level="ACPI_LV_INFO" > I would be interested in all periodically occurring ACPI debug messages > (after boot is finished). > 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 And, btw, thanks for your efforts. -tom > I suspect that the ACPI platform and/or embedded controller send too many > notifications when they are > not strictly necessary. > Maybe there is a BIOS update for your machine? > > In any case, I am starting to work on a patch that should fix this problem > without resorting to any > special configuration. > -- > Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: 9-Stable panic: resource_list_unreserve: can't find resource
on 05/11/2012 16:52 Tom Lislegaard said the following: > > >> -Original Message- >> From: Andriy Gapon [mailto:a...@freebsd.org] >> Sent: 5. november 2012 15:21 >> To: Tom Lislegaard >> Cc: freebsd-sta...@freebsd.org; freebsd-acpi@FreeBSD.org >> Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource >> >> on 05/11/2012 15:54 Tom Lislegaard said the following: >>> Here's the distribution from running devd over 40 minutes >>> >>> 589 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU0 >>> notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU1 >>> notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU2 >>> notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU3 >>> notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU4 >>> notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU5 >>> notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU6 >>> notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU7 >>> notify=0x81' >>> 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE >>> cdev=dsp4.1' >>> 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=pts/2' >>> 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE >>> cdev=vboxdrv0' >>> 1 Processing event '!system=DEVFS subsystem=CDEV type=DESTROY >>> cdev=dsp4.1' >>> 1 Processing event '!system=DEVFS subsystem=CDEV type=DESTROY >>> cdev=vboxdrv0' >>> >>> Any use in running it over a longer period of time? >> >> Very interesting. >> So the processors get _CST change notifications rather frequently, but there >> is no obvious >> source/cause for them... >> >> Could you please send to me acpidump -dt output or upload it somewhere and >> post a link? > > Here you go > > https://dl.dropbox.com/u/13263820/acpidump.txt So, ACPI platform on your machine sends 0x81 notification for processors objects each time "_PSR" method of AC Adapter / Power Source device is queried. There could be a number of reason to invoke the method - either AC line status queries from userland (some battery / line monitoring program/applet) or internal ACPI notifications. Are you willing to go as far as recompiling your kernel with 'options ACPI_DEBUG' to get to the bottom of this issue? If yes, then please do that and also add the following lines to loader.conf: debug.acpi.layer="ACPI_EVENTS ACPI_AC_ADAPTER" debug.acpi.level="ACPI_LV_INFO" I would be interested in all periodically occurring ACPI debug messages (after boot is finished). I suspect that the ACPI platform and/or embedded controller send too many notifications when they are not strictly necessary. Maybe there is a BIOS update for your machine? In any case, I am starting to work on a patch that should fix this problem without resorting to any special configuration. -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
RE: 9-Stable panic: resource_list_unreserve: can't find resource
> -Original Message- > From: Andriy Gapon [mailto:a...@freebsd.org] > Sent: 5. november 2012 15:21 > To: Tom Lislegaard > Cc: freebsd-sta...@freebsd.org; freebsd-acpi@FreeBSD.org > Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource > > on 05/11/2012 15:54 Tom Lislegaard said the following: > > Here's the distribution from running devd over 40 minutes > > > > 589 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU0 > > notify=0x81' > > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU1 > > notify=0x81' > > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU2 > > notify=0x81' > > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU3 > > notify=0x81' > > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU4 > > notify=0x81' > > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU5 > > notify=0x81' > > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU6 > > notify=0x81' > > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU7 > > notify=0x81' > > 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE > > cdev=dsp4.1' > > 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=pts/2' > > 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE > > cdev=vboxdrv0' > > 1 Processing event '!system=DEVFS subsystem=CDEV type=DESTROY > > cdev=dsp4.1' > > 1 Processing event '!system=DEVFS subsystem=CDEV type=DESTROY > > cdev=vboxdrv0' > > > > Any use in running it over a longer period of time? > > Very interesting. > So the processors get _CST change notifications rather frequently, but there > is no obvious > source/cause for them... > > Could you please send to me acpidump -dt output or upload it somewhere and > post a link? > > -- > Andriy Gapon Here you go https://dl.dropbox.com/u/13263820/acpidump.txt -tom ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: 9-Stable panic: resource_list_unreserve: can't find resource
on 05/11/2012 15:54 Tom Lislegaard said the following: > Here's the distribution from running devd over 40 minutes > > 589 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU0 > notify=0x81' > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU1 > notify=0x81' > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU2 > notify=0x81' > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU3 > notify=0x81' > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU4 > notify=0x81' > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU5 > notify=0x81' > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU6 > notify=0x81' > 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU7 > notify=0x81' > 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=dsp4.1' > 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=pts/2' > 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE > cdev=vboxdrv0' > 1 Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=dsp4.1' > 1 Processing event '!system=DEVFS subsystem=CDEV type=DESTROY > cdev=vboxdrv0' > > Any use in running it over a longer period of time? Very interesting. So the processors get _CST change notifications rather frequently, but there is no obvious source/cause for them... Could you please send to me acpidump -dt output or upload it somewhere and post a link? -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
RE: 9-Stable panic: resource_list_unreserve: can't find resource
> -Original Message- > From: Andriy Gapon [mailto:a...@freebsd.org] > Sent: 5. november 2012 11:58 > To: Tom Lislegaard > Cc: freebsd-sta...@freebsd.org; freebsd-acpi@FreeBSD.org > Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource > > on 05/11/2012 12:26 Tom Lislegaard said the following: > >> -Original Message- > >> From: Andriy Gapon [mailto:a...@freebsd.org] I see. Could you please > >> try setting debug.acpi.max_threads=1 in /boot/loader.conf, reboot and > >> see if that makes any difference? > > > > It does make a difference. I've had the machine running over the week-end, > > and haven't had a crash > in 56 hours. > > > > After applying the setting I get some errors on reboot, no idea if they are > > harmful in any way (none > that I have notced): > > > > AcpiOsExecute: failed to enqueue task, consider increasing the > > debug.acpi.max_tasks tunable ACPI Error: Method parse/execution failed > > [\\PNOT] (Node 0xfe00052e6400), AE_NO_MEMORY > > (20110527/psparse-560) ACPI Error: Method parse/execution failed > > [\\_SB_.AC__._PSR] (Node 0xfe00052f57c0), AE_NO_MEMORY > > (20110527/psparse-560) > > > > The same messages repeats 6 times > > Thank you for the test! > Try to set debug.acpi.max_tasks to 128 or even higher to get rid of the new > ACPI errors. > > Additionally I would like to ask you to do the following test. > Please stop devd and then run it (as root) from command line as such devd -D > -d. > Please check what event are reported by devd. In particular I am interested > in ACAD events, but all > high frequency events are important. > > Thanks! > -- > Andriy Gapon Here's the distribution from running devd over 40 minutes 589 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU0 notify=0x81' 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU1 notify=0x81' 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU2 notify=0x81' 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU3 notify=0x81' 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU4 notify=0x81' 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU5 notify=0x81' 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU6 notify=0x81' 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU7 notify=0x81' 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=dsp4.1' 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=pts/2' 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=vboxdrv0' 1 Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=dsp4.1' 1 Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=vboxdrv0' Any use in running it over a longer period of time? -tom ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: 9-Stable panic: resource_list_unreserve: can't find resource
on 05/11/2012 12:26 Tom Lislegaard said the following: >> -Original Message- >> From: Andriy Gapon [mailto:a...@freebsd.org] >> I see. Could you please try setting debug.acpi.max_threads=1 in >> /boot/loader.conf, reboot and see if >> that makes any difference? > > It does make a difference. I've had the machine running over the week-end, > and haven't had a crash in 56 hours. > > After applying the setting I get some errors on reboot, no idea if they are > harmful in any way (none that I have notced): > > AcpiOsExecute: failed to enqueue task, consider increasing the > debug.acpi.max_tasks tunable > ACPI Error: Method parse/execution failed [\\PNOT] (Node 0xfe00052e6400), > AE_NO_MEMORY (20110527/psparse-560) > ACPI Error: Method parse/execution failed [\\_SB_.AC__._PSR] (Node > 0xfe00052f57c0), AE_NO_MEMORY (20110527/psparse-560) > > The same messages repeats 6 times Thank you for the test! Try to set debug.acpi.max_tasks to 128 or even higher to get rid of the new ACPI errors. Additionally I would like to ask you to do the following test. Please stop devd and then run it (as root) from command line as such devd -D -d. Please check what event are reported by devd. In particular I am interested in ACAD events, but all high frequency events are important. Thanks! -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
RE: 9-Stable panic: resource_list_unreserve: can't find resource
> -Original Message- > From: Andriy Gapon [mailto:a...@freebsd.org] > Sent: 2. november 2012 13:39 > To: Tom Lislegaard > Cc: freebsd-sta...@freebsd.org; freebsd-acpi@FreeBSD.org > Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource > > on 02/11/2012 11:56 Tom Lislegaard said the following: > > The machine is usually connected to a docking station and I believe the > > power is very stable. I > sometimes take it home and connect it to a different powersupply and sees the > same behavior with > panics there. Panics can occur while I'm at the machine working, or if I > leave the machine idle for > some time I find it has paniced/rebooted when I come back. > > The time of panic seems totally random and I can't correlate this to any > > particular activity like > cronjobs, etc. > > I see. Could you please try setting debug.acpi.max_threads=1 in > /boot/loader.conf, reboot and see if > that makes any difference? > > -- > Andriy Gapon It does make a difference. I've had the machine running over the week-end, and haven't had a crash in 56 hours. After applying the setting I get some errors on reboot, no idea if they are harmful in any way (none that I have notced): AcpiOsExecute: failed to enqueue task, consider increasing the debug.acpi.max_tasks tunable ACPI Error: Method parse/execution failed [\\PNOT] (Node 0xfe00052e6400), AE_NO_MEMORY (20110527/psparse-560) ACPI Error: Method parse/execution failed [\\_SB_.AC__._PSR] (Node 0xfe00052f57c0), AE_NO_MEMORY (20110527/psparse-560) The same messages repeats 6 times -tom ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: 9-Stable panic: resource_list_unreserve: can't find resource
on 02/11/2012 11:56 Tom Lislegaard said the following: > The machine is usually connected to a docking station and I believe the power > is very stable. I sometimes take it home and connect it to a different > powersupply and sees the same behavior with panics there. Panics can occur > while I'm at the machine working, or if I leave the machine idle for some > time I find it has paniced/rebooted when I come back. > The time of panic seems totally random and I can't correlate this to any > particular activity like cronjobs, etc. I see. Could you please try setting debug.acpi.max_threads=1 in /boot/loader.conf, reboot and see if that makes any difference? -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
RE: 9-Stable panic: resource_list_unreserve: can't find resource
> -Original Message-
> From: Andriy Gapon [mailto:a...@freebsd.org]
> Sent: 1. november 2012 23:05
> To: Tom Lislegaard
> Cc: freebsd-sta...@freebsd.org; freebsd-acpi@FreeBSD.org
> Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource
>
> on 01/11/2012 11:45 Tom Lislegaard said the following:
> >
> >
> >> -Original Message-
> >> From: Andriy Gapon [mailto:a...@freebsd.org]
> >> Sent: 31. oktober 2012 19:51
> >> To: Tom Lislegaard
> >> Cc: 'freebsd-sta...@freebsd.org'
> >> Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource
> >>
> >> on 31/10/2012 12:14 Tom Lislegaard said the following:
> >>> Hi
> >>>
> >>> I'm running
> >>> FreeBSD stingray 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #3: Mon Oct 29
> >>> 16:11:35 CET 2012
> >> tl@stingray:/usr/obj/usr/src/sys/stingray amd64
> >>> on a new Dell laptop and keep getting these panics (typically once or
> >>> twice per day)
> >>>
> >>> (kgdb) set pagination off
> >>> (kgdb) bt
> >>> #0 doadump (textdump=Variable "textdump" is not available.
> >>> ) at pcpu.h:229
> >>> #1 0x80425e64 in kern_reboot (howto=260) at
> >>> /usr/src/sys/kern/kern_shutdown.c:448
> >>> #2 0x8042634c in panic (fmt=0x1 ) at
> >> /usr/src/sys/kern/kern_shutdown.c:636
> >>> #3 0x8045773e in resource_list_unreserve (rl=Variable "rl" is
> >>> not available.
> >>> ) at /usr/src/sys/kern/subr_bus.c:3338
> >>> #4 0x802c3ee4 in acpi_delete_resource (bus=0xfe00052c1100,
> >>> child=0xfe00052c1500,
> >> type=4, rid=3323) at /usr/src/sys/dev/acpica/acpi.c:1405
> >>> #5 0x802c62bc in acpi_bus_alloc_gas (dev=0xfe00052c1500,
> >>> type=0xfe00052b786c,
> >> rid=0xfe00052b7978, gas=Variable "gas" is not available.
> >>> ) at /usr/src/sys/dev/acpica/acpi.c:1450
> >>> #6 0x802d1663 in acpi_PkgGas (dev=0xfe00052c1500,
> >>> res=Variable "res" is not
> available.
> >>> ) at /usr/src/sys/dev/acpica/acpi_package.c:120
> >>> #7 0x802cbf6b in acpi_cpu_cx_cst (sc=0xfe00052b7800) at
> >> /usr/src/sys/dev/acpica/acpi_cpu.c:782
> >>> #8 0x802cc3a4 in acpi_cpu_notify (h=Variable "h" is not
> >>> available.
> >>> ) at /usr/src/sys/dev/acpica/acpi_cpu.c:1050
> >>> #9 0x802a3fca in AcpiEvNotifyDispatch (Context=0x0) at
> >> /usr/src/sys/contrib/dev/acpica/events/evmisc.c:283
> >>> #10 0x802c26c3 in acpi_task_execute (context=0xfe00051d6800,
> >>> pending=Variable
> "pending"
> >> is not available.
> >>> ) at /usr/src/sys/dev/acpica/Osd/OsdSchedule.c:134
> >>> #11 0x804683c4 in taskqueue_run_locked (queue=0xfe00052bc100)
> >>> at
> >> /usr/src/sys/kern/subr_taskqueue.c:308
> >>> #12 0x80469366 in taskqueue_thread_loop (arg=Variable "arg" is
> >>> not available.
> >>> ) at /usr/src/sys/kern/subr_taskqueue.c:497
> >>> #13 0x803f762f in fork_exit (callout=0x80469320
> >>> ,
> >> arg=0x80a20cc8, frame=0xff80002cdb00) at
> >> /usr/src/sys/kern/kern_fork.c:992
> >>> #14 0x806be6be in fork_trampoline () at
> >>> /usr/src/sys/amd64/amd64/exception.S:602
> >>
> >> Could you please provide *sc from frame 7?
> >
> > (kgdb) up 7
> > #7 0x802cbf6b in acpi_cpu_cx_cst (sc=0xfe00052b7800) at
> /usr/src/sys/dev/acpica/acpi_cpu.c:782
> > 782 acpi_PkgGas(sc->cpu_dev, pkg, 0, &cx_ptr->res_type,
> > &sc->cpu_rid,
> > (kgdb) print *sc
> > $1 = {cpu_dev = 0xfe00052c1500, cpu_handle = 0xfe00052e7a80,
> > cpu_pcpu = 0x80aa6a80,
> cpu_acpi_id = 1, cpu_p_blk = 1040, cpu_p_blk_len = 6, cpu_cx_states =
> {{p_lvlx = 0xfe0196f0e380,
> type = 1, trans_lat = 1, power = 1000, res_type = 4}, {p_lvlx = 0x0, type =
> 3, trans_lat = 87, power =
> 200, res_type = 4}, {p_lvlx = 0x0, type = 3, trans_lat = 87, power = 200,
> res_type = 4}, {p_lvlx =
> 0x0, type = 0, trans_lat = 0, power = 0, res_type = 0}, {p_lvlx = 0x0, type =
> 0, trans_lat = 0, power
> = 0, res_type = 0}, {p_lvlx = 0x0, type = 0, trans_lat = 0, power = 0,
> res_type = 0}, {p_lvlx = 0x0,
Re: 9-Stable panic: resource_list_unreserve: can't find resource
on 01/11/2012 11:45 Tom Lislegaard said the following:
>
>
>> -Original Message-
>> From: Andriy Gapon [mailto:a...@freebsd.org]
>> Sent: 31. oktober 2012 19:51
>> To: Tom Lislegaard
>> Cc: 'freebsd-sta...@freebsd.org'
>> Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource
>>
>> on 31/10/2012 12:14 Tom Lislegaard said the following:
>>> Hi
>>>
>>> I'm running
>>> FreeBSD stingray 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #3: Mon Oct 29
>>> 16:11:35 CET 2012
>> tl@stingray:/usr/obj/usr/src/sys/stingray amd64
>>> on a new Dell laptop and keep getting these panics (typically once or twice
>>> per day)
>>>
>>> (kgdb) set pagination off
>>> (kgdb) bt
>>> #0 doadump (textdump=Variable "textdump" is not available.
>>> ) at pcpu.h:229
>>> #1 0x80425e64 in kern_reboot (howto=260) at
>>> /usr/src/sys/kern/kern_shutdown.c:448
>>> #2 0x8042634c in panic (fmt=0x1 ) at
>> /usr/src/sys/kern/kern_shutdown.c:636
>>> #3 0x8045773e in resource_list_unreserve (rl=Variable "rl" is not
>>> available.
>>> ) at /usr/src/sys/kern/subr_bus.c:3338
>>> #4 0x802c3ee4 in acpi_delete_resource (bus=0xfe00052c1100,
>>> child=0xfe00052c1500,
>> type=4, rid=3323) at /usr/src/sys/dev/acpica/acpi.c:1405
>>> #5 0x802c62bc in acpi_bus_alloc_gas (dev=0xfe00052c1500,
>>> type=0xfe00052b786c,
>> rid=0xfe00052b7978, gas=Variable "gas" is not available.
>>> ) at /usr/src/sys/dev/acpica/acpi.c:1450
>>> #6 0x802d1663 in acpi_PkgGas (dev=0xfe00052c1500, res=Variable
>>> "res" is not available.
>>> ) at /usr/src/sys/dev/acpica/acpi_package.c:120
>>> #7 0x802cbf6b in acpi_cpu_cx_cst (sc=0xfe00052b7800) at
>> /usr/src/sys/dev/acpica/acpi_cpu.c:782
>>> #8 0x802cc3a4 in acpi_cpu_notify (h=Variable "h" is not available.
>>> ) at /usr/src/sys/dev/acpica/acpi_cpu.c:1050
>>> #9 0x802a3fca in AcpiEvNotifyDispatch (Context=0x0) at
>> /usr/src/sys/contrib/dev/acpica/events/evmisc.c:283
>>> #10 0x802c26c3 in acpi_task_execute (context=0xfe00051d6800,
>>> pending=Variable "pending"
>> is not available.
>>> ) at /usr/src/sys/dev/acpica/Osd/OsdSchedule.c:134
>>> #11 0x804683c4 in taskqueue_run_locked (queue=0xfe00052bc100) at
>> /usr/src/sys/kern/subr_taskqueue.c:308
>>> #12 0x80469366 in taskqueue_thread_loop (arg=Variable "arg" is not
>>> available.
>>> ) at /usr/src/sys/kern/subr_taskqueue.c:497
>>> #13 0x803f762f in fork_exit (callout=0x80469320
>>> ,
>> arg=0x80a20cc8, frame=0xff80002cdb00) at
>> /usr/src/sys/kern/kern_fork.c:992
>>> #14 0x806be6be in fork_trampoline () at
>>> /usr/src/sys/amd64/amd64/exception.S:602
>>
>> Could you please provide *sc from frame 7?
>
> (kgdb) up 7
> #7 0x802cbf6b in acpi_cpu_cx_cst (sc=0xfe00052b7800) at
> /usr/src/sys/dev/acpica/acpi_cpu.c:782
> 782 acpi_PkgGas(sc->cpu_dev, pkg, 0, &cx_ptr->res_type,
> &sc->cpu_rid,
> (kgdb) print *sc
> $1 = {cpu_dev = 0xfe00052c1500, cpu_handle = 0xfe00052e7a80, cpu_pcpu
> = 0x80aa6a80, cpu_acpi_id = 1, cpu_p_blk = 1040, cpu_p_blk_len = 6,
> cpu_cx_states = {{p_lvlx = 0xfe0196f0e380, type = 1, trans_lat = 1, power
> = 1000, res_type = 4}, {p_lvlx = 0x0, type = 3, trans_lat = 87, power = 200,
> res_type = 4}, {p_lvlx = 0x0, type = 3, trans_lat = 87, power = 200, res_type
> = 4}, {p_lvlx = 0x0, type = 0, trans_lat = 0, power = 0, res_type = 0},
> {p_lvlx = 0x0, type = 0, trans_lat = 0, power = 0, res_type = 0}, {p_lvlx =
> 0x0, type = 0, trans_lat = 0, power = 0, res_type = 0}, {p_lvlx = 0x0, type =
> 0, trans_lat = 0, power = 0, res_type = 0}, {p_lvlx = 0x0, type = 0,
> trans_lat = 0, power = 0, res_type = 0}}, cpu_cx_count = 2, cpu_prev_sleep =
> 619, cpu_features = 31, cpu_non_c3 = 1, cpu_cx_stats = {390, 0, 0, 0, 0, 0,
> 0, 0}, cpu_sysctl_ctx = {tqh_first = 0xfe00088931a0, tqh_last =
> 0xfe0008893228}, cpu_sysctl_tree = 0x0, cpu_cx_lowest = 0,
> cpu_cx_lowest_lim = 0,
!
cpu_cx_s
upported = "C1/1 C2/59 C3/87", '\0' , cpu_rid = 3323}
Thank you.
Did this crash occur at the time when you plugged or unplugged AC line?
Do you plug and unplug the line often?
Do you think that the line could have any problems like flaky contacts or some
such?
--
Andriy Gapon
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
