RE: 9-Stable panic: resource_list_unreserve: can't find resource

2012-11-08 Thread Tom Lislegaard 

 -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

(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 Address 0x1 out of bounds) 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.c:423
#20 0x802e35ed in acpi_BatteryIsPresent (dev=0xfe0005378c00) at 
/usr/src/sys/dev/acpica/acpi.c:2064
#21 0x802e66e1 in acpi_battery_get_battinfo (dev=0x0, 
battinfo=0x80a4ba70) at /usr/src/sys/dev/acpica/acpi_battery.c:176
#22 0x802e6a44 in acpi_battery_sysctl

Re: 9-Stable panic: resource_list_unreserve: can't find resource

2012-11-08 Thread Andriy Gapon 
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  0x804441f4 in kern_reboot (howto=260) at 
 /usr/src/sys/kern/kern_shutdown.c:448
 #2  0x804446dc in panic (fmt=0x1 Address 0x1 out of bounds) 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

RE: 9-Stable panic: resource_list_unreserve: can't find resource

2012-11-08 Thread Tom Lislegaard 


 -Original Message-
 From: Andriy Gapon [mailto:a...@freebsd.org]
 Sent: 8. november 2012 11: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 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?

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 Address 0x1 out of bounds)
  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

RE: 9-Stable panic: resource_list_unreserve: can't find resource

2012-11-06 Thread Tom Lislegaard 


 -Original Message-
 From: Andriy Gapon [mailto:a...@freebsd.org]
 Sent: 5. november 2012 18:08
 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 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-stable@FreeBSD.org; freebsd-a...@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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 9-Stable panic: resource_list_unreserve: can't find resource

2012-11-06 Thread Andriy Gapon 
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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: 9-Stable panic: resource_list_unreserve: can't find resource

2012-11-05 Thread Tom Lislegaard 
 -Original Message-
 From: Andriy Gapon [mailto:a...@freebsd.org]
 Sent: 2. november 2012 13:39
 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 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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 9-Stable panic: resource_list_unreserve: can't find resource

2012-11-05 Thread Andriy Gapon 
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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: 9-Stable panic: resource_list_unreserve: can't find resource

2012-11-05 Thread Tom Lislegaard 


 -Original Message-
 From: Andriy Gapon [mailto:a...@freebsd.org]
 Sent: 5. november 2012 11:58
 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 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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 9-Stable panic: resource_list_unreserve: can't find resource

2012-11-05 Thread Andriy Gapon 
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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: 9-Stable panic: resource_list_unreserve: can't find resource

2012-11-05 Thread Tom Lislegaard 


 -Original Message-
 From: Andriy Gapon [mailto:a...@freebsd.org]
 Sent: 5. november 2012 15:21
 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 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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 9-Stable panic: resource_list_unreserve: can't find resource

2012-11-05 Thread Andriy Gapon 
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-stable@FreeBSD.org; freebsd-a...@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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: 9-Stable panic: resource_list_unreserve: can't find resource

2012-11-02 Thread Tom Lislegaard 


 -Original Message-
 From: Andriy Gapon [mailto:a...@freebsd.org]
 Sent: 1. november 2012 23:05
 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 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-stable@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 Address 0x1 out of bounds) 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 
  taskqueue_thread_loop,
  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' repeats 47 times, 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

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

Re: 9-Stable panic: resource_list_unreserve: can't find resource

2012-11-02 Thread Andriy Gapon 
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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: 9-Stable panic: resource_list_unreserve: can't find resource

2012-11-01 Thread Tom Lislegaard 


 -Original Message-
 From: Andriy Gapon [mailto:a...@freebsd.org]
 Sent: 31. oktober 2012 19:51
 To: Tom Lislegaard
 Cc: 'freebsd-stable@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 Address 0x1 out of bounds) 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 
  taskqueue_thread_loop,
 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?
 
 --
 Andriy Gapon

(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, c
 pu_cx_supported = C1/1 C2/59 C3/87, '\0' repeats 47 times, cpu_rid = 3323}

-tom

___
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

Re: 9-Stable panic: resource_list_unreserve: can't find resource

2012-11-01 Thread Andriy Gapon 
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-stable@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 Address 0x1 out of bounds) 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 
 taskqueue_thread_loop,
 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' repeats 47 times, 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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

9-Stable panic: resource_list_unreserve: can't find resource

2012-10-31 Thread Tom Lislegaard 
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 Address 0x1 out of bounds) 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 
taskqueue_thread_loop, 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
#15 0x in ?? ()
#16 0x in ?? ()
#17 0x in ?? ()
#18 0x in ?? ()
#19 0x in ?? ()
#20 0x in ?? ()
#21 0x in ?? ()
#22 0x in ?? ()
#23 0x in ?? ()
#24 0x in ?? ()
#25 0x in ?? ()
#26 0x in ?? ()
#27 0x in ?? ()
#28 0x in ?? ()
#29 0x in ?? ()
#30 0x in ?? ()
#31 0x in ?? ()
#32 0x in ?? ()
#33 0x in ?? ()
#34 0x in ?? ()
#35 0x in ?? ()
#36 0x in ?? ()
#37 0x in ?? ()
#38 0x in ?? ()
#39 0x00ff in ?? ()
#40 0x in ?? ()
#41 0xfe00051e5920 in ?? ()
#42 0xfe00051e5920 in ?? ()
#43 0xff80002cd740 in ?? ()
#44 0xff80002cd6e8 in ?? ()
#45 0xfe00051c1490 in ?? ()
#46 0x8044e9b9 in sched_switch (td=0x80469320, 
newtd=0x80a20cc8, flags=Variable flags is not available.
) at /usr/src/sys/kern/sched_ule.c:1913
Previous frame inner to this frame (corrupt stack?)

Hardware details are as follows

Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.1-PRERELEASE #3: Mon Oct 29 16:11:35 CET 2012
tl@stingray:/usr/obj/usr/src/sys/stingray amd64
CPU: Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz (2591.64-MHz K8-class CPU)
  Origin = GenuineIntel  Id = 0x306a9  Family = 0x6  Model = 0x3a  Stepping = 
9
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  
Features2=0x7fbae3ffSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND
  AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM
  AMD Features2=0x1LAHF
  TSC: P-state invariant, performance statistics
real memory  = 8589934592 (8192 MB)
avail memory = 8166604800 (7788 MB)
Event timer LAPIC quality 600
ACPI APIC Table: DELL   CBX3   
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  2
 cpu3 (AP): APIC ID:  3
 cpu4 (AP): APIC ID:  4
 cpu5 (AP): APIC ID:  5
 cpu6 (AP): APIC ID:  6
 cpu7 (AP): APIC ID:  7
ioapic0 Version 2.0 irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: DELL CBX3on motherboard
acpi0: Power Button (fixed)
cpu0: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
cpu2: ACPI CPU on acpi0
cpu3: ACPI

Re: 9-Stable panic: resource_list_unreserve: can't find resource

2012-10-31 Thread Andriy Gapon 
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 Address 0x1 out of bounds) 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 
 taskqueue_thread_loop, 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?

-- 
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