From gandalf@nm.ruhr-uni-bochum.de  Thu Nov 13 03:05:17 2003
Return-Path: <gandalf@nm.ruhr-uni-bochum.de>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 2FE2A16A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 13 Nov 2003 03:05:17 -0800 (PST)
Received: from sunu007.rz.ruhr-uni-bochum.de (sunu007.rz.ruhr-uni-bochum.de [134.147.64.14])
	by mx1.FreeBSD.org (Postfix) with SMTP id 8CFDF43FBF
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 13 Nov 2003 03:05:14 -0800 (PST)
	(envelope-from gandalf@nm.ruhr-uni-bochum.de)
Received: (qmail 21796 invoked by uid 82); 13 Nov 2003 11:05:13 -0000
Received: from gandalf@nm.ruhr-uni-bochum.de by mailhost with qmail-scanner-1.00 (uvscan: v4.2.40/v4303. . Clean. Processed in 1.767222 secs); 13 Nov 2003 11:05:13 -0000
Received: (qmail 21612 invoked from network); 13 Nov 2003 11:05:10 -0000
Received: from server.nm.ruhr-uni-bochum.de (HELO mailhost.nm.ruhr-uni-bochum.de) (134.147.252.40)
  by mailhost.rz.ruhr-uni-bochum.de with SMTP; 13 Nov 2003 11:05:10 -0000
Received: (qmail 12883 invoked by uid 101); 13 Nov 2003 11:05:09 -0000
Received: from pc-o.nm.ruhr-uni-bochum.de (134.147.252.55)
  by server.nm.ruhr-uni-bochum.de with SMTP; 13 Nov 2003 11:05:09 -0000
Received: from pc-o.nm.ruhr-uni-bochum.de (localhost [127.0.0.1])
	by pc-o.nm.ruhr-uni-bochum.de (8.12.8p2/8.12.8) with ESMTP id hADB59XB047953
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 13 Nov 2003 12:05:09 +0100 (CET)
	(envelope-from gandalf@pc-o.nm.ruhr-uni-bochum.de)
Received: (from gandalf@localhost)
	by pc-o.nm.ruhr-uni-bochum.de (8.12.8p2/8.12.8/Submit) id hADB58il047952;
	Thu, 13 Nov 2003 12:05:08 +0100 (CET)
Message-Id: <200311131105.hADB58il047952@pc-o.nm.ruhr-uni-bochum.de>
Date: Thu, 13 Nov 2003 12:05:08 +0100 (CET)
From: Andre Grosse Bley <gandalf@nm.ruhr-uni-bochum.de>
Reply-To: Andre Grosse Bley <gandalf@nm.ruhr-uni-bochum.de>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: 4.9-RELEASE, ACPI Panic with Dell Latitude D600
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         59248
>Category:       i386
>Synopsis:       [panic] 4.9-RELEASE, ACPI Panic with Dell Latitude D600
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    remko
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Nov 13 03:10:17 PST 2003
>Closed-Date:    Sat Apr 01 20:33:10 GMT 2006
>Last-Modified:  Sat Apr 01 20:33:10 GMT 2006
>Originator:     Andre Grosse Bley
>Release:        FreeBSD 4.9-RELEASE i386
>Organization:
Ruhr-Uni-Bochum
>Environment:
System: FreeBSD feap.nm.ruhr-uni-bochum.de 4.9-RELEASE

	Dell Latitude D600, FreeBSD 4.9-RELEASE
>Description:

i am trying to install FreeBSD 4.9-RELEASE on a Dell Latitude D600
notebook. "standard" Kernel without ACPI works fine 
(dmesg at http://www.nm.ruhr-uni-bochum.de/~gandalf/dell/dmesg.noacpi.txt)

Since i need the batterystatus (and the Bios doesnt seem to support APM
anymore) i activated acpi: The machine paniced after detecting the brgphy0.
After removing pcic0/pcic1 from the kernel configuration, i was able to
boot with ACPI (wow!;)
But no batterystatus. Googling found a solution:

http://sandcat.nl/~stijn/freebsd/dell.php

I needed to add
acpi_dsdt_load="YES"
acpi_dsdt_name="/boot/acpi_dsdt.aml"
acpi_dsdt_type="acpi_dsdt"


to /boot/loader.conf

dmesg is at http://www.nm.ruhr-uni-bochum.de/~gandalf/dell/dmesg.acpi.txt

sysctl hw.acpi gives:

hw.acpi.supported_sleep_state: S1 S3 S4 S5 
hw.acpi.power_button_state: S5
hw.acpi.sleep_button_state: S1
hw.acpi.lid_switch_state: S1
hw.acpi.standby_state: S1
hw.acpi.suspend_state: S3
hw.acpi.sleep_delay: 0
hw.acpi.s4bios: 1
hw.acpi.verbose: 1
hw.acpi.disable_on_poweroff: 1
hw.acpi.cpu.max_speed: 8
hw.acpi.cpu.current_speed: 8
hw.acpi.cpu.performance_speed: 8
hw.acpi.cpu.economy_speed: 4
hw.acpi.thermal.min_runtime: 0
hw.acpi.thermal.polling_rate: 30
hw.acpi.thermal.tz0.temperature: 3127
hw.acpi.thermal.tz0.active: -1
hw.acpi.thermal.tz0.thermal_flags: 0
hw.acpi.thermal.tz0._PSV: -1
hw.acpi.thermal.tz0._HOT: -1
hw.acpi.thermal.tz0._CRT: 3752
hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
hw.acpi.acline: 1
hw.acpi.battery.life: 46
hw.acpi.battery.time: -1
hw.acpi.battery.state: 2
hw.acpi.battery.units: 2
hw.acpi.battery.info_expire: 5

My problem: the machine panics when closing the lid, even after
sysctl hw.acpi.lid_switch_state=NONE.

Traceback without the sysctl is as follows:

root at feap:~ $gdb -k /kernel.debug /var/crash/vmcore.1
IdlePTD at phsyical address 0x00470000
initial pcb at physical address 0x003b04e0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x70
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc01b5198
stack pointer           = 0x10:0xc0367b70
frame pointer           = 0x10:0xc0367b94
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = Idle
interrupt mask          = net tty bio cam
trap number             = 12
panic: page fault

syncing disks...

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x30
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc02784d0
stack pointer           = 0x10:0xc0367998
frame pointer           = 0x10:0xc03679a0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = Idle
interrupt mask          = net tty bio cam
trap number             = 12
panic: page fault
Uptime: 4m6s

#0  dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
#1  0xc01b20f7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:316
#2  0xc01b2535 in panic (fmt=0xc035f76c "%s")
    at /usr/src/sys/kern/kern_shutdown.c:595
#3  0xc02fa003 in trap_fatal (frame=0xc0367958, eva=48)
    at /usr/src/sys/i386/i386/trap.c:974
#4  0xc02f9cb1 in trap_pfault (frame=0xc0367958, usermode=0, eva=48)
    at /usr/src/sys/i386/i386/trap.c:867
#5  0xc02f9857 in trap (frame={tf_fs = -1071841264, tf_es = -65520,
      tf_ds = -1070202864, tf_edi = 0, tf_esi = -1036472064,
      tf_ebp = -1070171744, tf_isp = -1070171772, tf_ebx = -1070075364,
      tf_edx = 6866944, tf_ecx = -614904832, tf_eax = 0, tf_trapno = 12,
      tf_err = 0, tf_eip = -1071151920, tf_cs = 8, tf_eflags = 66182,
      tf_esp = -1036472064, tf_ss = -1036472064})
    at /usr/src/sys/i386/i386/trap.c:466
#6  0xc02784d0 in acquire_lock (lk=0xc037f21c)
    at /usr/src/sys/ufs/ffs/ffs_softdep.c:266
#7  0xc027c5d0 in softdep_update_inodeblock (ip=0xc238b100, bp=0xcc94a43c,
    waitfor=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3813
#8  0xc0277605 in ffs_update (vp=0xdb594c00, waitfor=0)
    at /usr/src/sys/ufs/ffs/ffs_inode.c:106
#9  0xc027fa4e in ffs_sync (mp=0xc2318600, waitfor=2, cred=0xc1453680,
    p=0xc03caf20) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1025
#10 0xc01e2e7b in sync (p=0xc03caf20, uap=0x0)
    at /usr/src/sys/kern/vfs_syscalls.c:577
#11 0xc01b1e92 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:235
#12 0xc01b2535 in panic (fmt=0xc035f76c "%s")
    at /usr/src/sys/kern/kern_shutdown.c:595
#13 0xc02fa003 in trap_fatal (frame=0xc0367b30, eva=112)
    at /usr/src/sys/i386/i386/trap.c:974
#14 0xc02f9cb1 in trap_pfault (frame=0xc0367b30, usermode=0, eva=112)
    at /usr/src/sys/i386/i386/trap.c:867
#15 0xc02f9857 in trap (frame={tf_fs = -1070202864, tf_es = -1070465008,
      tf_ds = -1070465008, tf_edi = 0, tf_esi = -1069882148,
      tf_ebp = -1070171244, tf_isp = -1070171300, tf_ebx = 0, tf_edx = 0,
      tf_ecx = 200, tf_eax = 6291968, tf_trapno = 12, tf_err = 0,
      tf_eip = -1071951464, tf_cs = 8, tf_eflags = 66118, tf_esp = 0,
      tf_ss = 274877907}) at /usr/src/sys/i386/i386/trap.c:466
#16 0xc01b5198 in tsleep (ident=0xc03ae4dc, priority=0,
    wmesg=0xc0328583 "acpislp", timo=200) at /usr/src/sys/kern/kern_synch.c:436
#17 0xc017817e in AcpiOsSleep (Seconds=2, Milliseconds=0)
    at /usr/src/sys/dev/acpica/Osd/OsdSchedule.c:256
#18 0xc0157991 in AcpiExSystemDoSuspend (HowLong=2000)
    at /usr/src/sys/contrib/dev/acpica/exsystem.c:257
#19 0xc0153b1e in AcpiExOpcode_1A_0T_0R (WalkState=0xc21f4028)
    at /usr/src/sys/contrib/dev/acpica/exoparg1.c:202
20 0xc0149fc1 in AcpiDsExecEndOp (WalkState=0xc21f4028)
    at /usr/src/sys/contrib/dev/acpica/dswexec.c:516
#21 0xc015f904 in AcpiPsParseLoop (WalkState=0xc21f4028)
    at /usr/src/sys/contrib/dev/acpica/psparse.c:977
#22 0xc015fe01 in AcpiPsParseAml (WalkState=0xc24cd828)
    at /usr/src/sys/contrib/dev/acpica/psparse.c:1258
#23 0xc0160b9e in AcpiPsxExecute (MethodNode=0xc21da4a8, Params=0x0,
    ReturnObjDesc=0xc0367d94) at /usr/src/sys/contrib/dev/acpica/psxface.c:281
#24 0xc015b407 in AcpiNsExecuteControlMethod (MethodNode=0xc21da4a8,
    Params=0x0, ReturnObjDesc=0xc0367d94)
    at /usr/src/sys/contrib/dev/acpica/nseval.c:527
#25 0xc015b2eb in AcpiNsEvaluateByHandle (Handle=0xc21da4a8, Params=0x0,
    ReturnObject=0x0) at /usr/src/sys/contrib/dev/acpica/nseval.c:409
#26 0xc014c484 in AcpiEvAsynchExecuteGpeMethod (Context=0xc21b326c)
    at /usr/src/sys/contrib/dev/acpica/evgpe.c:334
#27 0xc01780ef in AcpiOsExecuteQueue (arg=0xc23d6dc0, pending=1)
    at /usr/src/sys/dev/acpica/Osd/OsdSchedule.c:234
#28 0xc01c0e41 in taskqueue_run (queue=0xc144c600)
    at /usr/src/sys/kern/subr_taskqueue.c:186
#29 0xc01c0e7a in taskqueue_swi_run ()
    at /usr/src/sys/kern/subr_taskqueue.c:202
#30 0xc02ef0e0 in splz_swi ()
#31 0xc02f3b56 in cpu_idle () at /usr/src/sys/i386/i386/machdep.c:1000

>How-To-Repeat:
	Just close the lid :-/
>Fix:



>Release-Note:
>Audit-Trail:

From: Andre Grosse Bley <gandalf@nm.ruhr-uni-bochum.de>
To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Cc:  
Subject: Re: kern/59248: 4.9-RELEASE, ACPI Panic with Dell Latitude D600
Date: Thu, 13 Nov 2003 12:15:02 +0100

 John Baldwin <jhb@FreeBSD.org> said the following on freebsd-hackers:
 
 > Ah, the problem is that ACPI tries to sleep from a task, which is not safe
 > to do.  This is not easy to fix. :(
 
 Actually, it may not be too hard.  In current, ACPI uses its own thread
 to run the tasks in, so stable would need the same sort of thing.
 Basically, ACPI needs to start up a kproc and needs to have its own
 taskqueue again that uses this kproc for its execution context.
State-Changed-From-To: open->feedback 
State-Changed-By: remko 
State-Changed-When: Sun Mar 19 17:47:12 UTC 2006 
State-Changed-Why:  
There were a lot of changes in the ACPI code's, can you tell 
whether this is still applicable to recent releases? 


Responsible-Changed-From-To: freebsd-i386->remko 
Responsible-Changed-By: remko 
Responsible-Changed-When: Sun Mar 19 17:47:12 UTC 2006 
Responsible-Changed-Why:  
Grab the PR so that i can keep track of feedback. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=59248 
State-Changed-From-To: feedback->closed 
State-Changed-By: remko 
State-Changed-When: Sat Apr 1 20:33:00 UTC 2006 
State-Changed-Why:  
Feedback timeout. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=59248 
>Unformatted:
