> -----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  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-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Reply via email to