Re: My system hang with ACPI kernel thread
From: Takanori Watanabe [EMAIL PROTECTED] Date: Thu, 28 Sep 2000 13:38:57 +0900 ::With the addition of ACPI kernel thread, my system hangs in about ::10 miniutes use after boot up. By disabling kernel thread, system ::runs just fine. :: ::Do you have any idea where to look at? ::I'll try and see what I can do myself. :: ::Please set debug.aml_debug and debug.acpi_debug to 1 and ::see what will happen. I'm sorry, there was a fault on my side. I had old /modules directory (Pre SMPng patch), and for some reason if enabled ACPI kernel thread, system hang. I've removed everything under /modules and system seems to be happy! So sorry for the false alarm. Haro =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103-8310, Japan Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My system hang with ACPI kernel thread
Currently kernel thread seems broken, so mallocing storage in
acpi_queue_event() never be freed. I think number of events at a
point of tme is limited and we can have static storage for the events.
The implementaion of sys/i386/apm/apm.c:apm_record_event() (it's for apmd)
would be a good example.
I have a megapatch for acpi.c that I am nearly ready to commit which
converts it to use bus resources for all I/O allocations. I'll fix this
in there, if you like.
I'm interested in your patch. Can I see it?
Sure. I'm not 100% sure it's going to work right, so please feel free
to tell me I've broken something...
I've just tried the patch, GREAT! it seems working for me perfectly w/o
any functional changes, much better than before. I'll do testing more.
I have some comments;
# most of them is not related with your patch :-) but I'd like to
# consult with you.
Can we separate the code which uses FreeBSD specific APIs and structs
into a other file or arrange them at one place?
Because I'm going to merge NetBSD porting effort, I want to avoid having
too many #ifdef __FreeBSD__. The patch is available at
http://www.imou.to/~AoiMoe/UNIX-at-Random/acpi/acpi-freebsd-netbsd-changes-2000-09-24.diff.gz
Because of above reason,
/*
* Debugging, console output
*
* XXX this should really be using device_printf
*/
extern int acpi_debug;
#define ACPI_DEVPRINTF(args...) printf("acpi0: " args)
I don't use device_printf() here.
# Also we don't have more than 2 instances of acpi :-)
static void
acpi_trans_sleeping_state(acpi_softc_t *sc, u_int8_t state)
:
/* XXX should be MI */
/* XXX should always be called with interrupts enabled! */
ef = read_eflags();
disable_intr();
for this, I referred the comments in ACPI spec 7.5.2.
// Required environment: Executing on the system boot
// processor. All other processors stopped. Interrupts --
// disabled. All Power Resources (and devices) are in
// corresponding device state to support NewState.
I don't know much about IA64, I'm not sure {read|write}_eflags()
inline functions will be available on IA64. Should we replace them
with save_intr() and restore_intr() ? because seems more general.
Also we need to consider SMP. There is no hack for it so far.
# I think APM BIOS Call need to be executed on the system boot
# processor too.
acpi_soft_off(void *data, int howto)
:
/* XXX Disable GPE intrrupt,or power on again in some machine */
acpi_io_gpe0_enable(sc, ACPI_REGISTER_OUTPUT, vala);
acpi_io_gpe1_enable(sc, ACPI_REGISTER_OUTPUT, vala);
This still give no effect on my PORTEGE. I think this should be done
in earlier phase. Maybe we'd better to have acpi_disable_events() and
call this at shutdown_pre_sync (or some such) for shutdown -p, also
call this in acpi_set_sleeping_state() for power button/acpiconf -s 5.
acpi_intr(void *data)
:
#if 0
/* Clear interrupt status */
val = enable; /* XXX */
acpi_io_gpe0_status(sc, ACPI_REGISTER_OUTPUT, val);
/* Re-enable interrupt */
acpi_io_gpe0_enable(sc, ACPI_REGISTER_OUTPUT, enable);
acpi_debug = 0; /* Shut up again */
#endif
GPE1 too, right? :-)
acpi_attach(device_t dev)
:
sc-iores[i].rsc = bus_alloc_resource(dev, SYS_RES_IOPORT,
sc-iores[i].rid,
0, ~0, 1, RF_ACTIVE);
^^
I didn't understand clearly for long time, but this give us more
flexibility w/o problems if we call bus_set_resource() and set count
correctly, right?
#ifndef ACPI_NO_ENABLE_ON_BOOT
acpi_enable_disable(sc, 1);
acpi_enable_events(sc);
acpi_intr((void *)sc);
#endif
Should we remove them and have acpi_enalbe="YES" in /etc/rc.conf just line APM ?
And last thing, how about header file name and location?
some poeple suggested that
/sys/dev/acpi/acpi.h should be renamed to acpivar.h. And
/sys/sys/acpi.h should be moved to /sys/dev/acpi.h (installed in
/usr/include/dev/acpi/acpi.h). We didn't care and are not interested
in this matter at all so far, but it seems quite reasonable for me and
doesn't hurt anything.
And *real* last thing :-)
msmith the code in machdep.c. Everything will move to acpi_machdep.c I'll also
msmith be deleting machine/acpi.h, as it's not necessary (and never was).
I think better to wait deleting until IA64 porting. I'm not sure if
this file really unnecessary or not.
Thanks!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: My system hang with ACPI kernel thread
With the addition of ACPI kernel thread, my system hangs in about 10 miniutes use after boot up. By disabling kernel thread, system runs just fine. Do you have any idea where to look at? I'll try and see what I can do myself. Please set debug.aml_debug and debug.acpi_debug to 1 and see what will happen. It wouldn't surprise me if the system wasn't running out of kernel memory. Right now we just keep mallocing storage to queue ACPI events (bad idea). The entire event/Notify stuff needs to be somewhat rethought (eg. I think we need an event filter). -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My system hang with ACPI kernel thread
In message [EMAIL PROTECTED], Munehiro Matsuda wrote: With the addition of ACPI kernel thread, my system hangs in about 10 miniutes use after boot up. By disabling kernel thread, system runs just fine. Do you have any idea where to look at? I'll try and see what I can do myself. Please set debug.aml_debug and debug.acpi_debug to 1 and see what will happen. I could find a couple of possibilities from VersaProNX.asl; lack of SleepOp or EC I/O. If the former, I can try to write it as well as StallOp tonight, of course Intel ACPICA compatible one. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My system hang with ACPI kernel thread
Please set debug.aml_debug and debug.acpi_debug to 1 and see what will happen. It wouldn't surprise me if the system wasn't running out of kernel memory. Right now we just keep mallocing storage to queue ACPI events (bad idea). The entire event/Notify stuff needs to be somewhat rethought (eg. I think we need an event filter). Currently kernel thread seems broken, so mallocing storage in acpi_queue_event() never be freed. I think number of events at a point of tme is limited and we can have static storage for the events. The implementaion of sys/i386/apm/apm.c:apm_record_event() (it's for apmd) would be a good example. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My system hang with ACPI kernel thread
Please set debug.aml_debug and debug.acpi_debug to 1 and see what will happen. It wouldn't surprise me if the system wasn't running out of kernel memory. Right now we just keep mallocing storage to queue ACPI events (bad idea). The entire event/Notify stuff needs to be somewhat rethought (eg. I think we need an event filter). Currently kernel thread seems broken, so mallocing storage in acpi_queue_event() never be freed. I think number of events at a point of tme is limited and we can have static storage for the events. The implementaion of sys/i386/apm/apm.c:apm_record_event() (it's for apmd) would be a good example. I have a megapatch for acpi.c that I am nearly ready to commit which converts it to use bus resources for all I/O allocations. I'll fix this in there, if you like. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My system hang with ACPI kernel thread
Currently kernel thread seems broken, so mallocing storage in acpi_queue_event() never be freed. I think number of events at a point of tme is limited and we can have static storage for the events. The implementaion of sys/i386/apm/apm.c:apm_record_event() (it's for apmd) would be a good example. I have a megapatch for acpi.c that I am nearly ready to commit which converts it to use bus resources for all I/O allocations. I'll fix this in there, if you like. I'm interested in your patch. Can I see it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My system hang with ACPI kernel thread
Currently kernel thread seems broken, so mallocing storage in
acpi_queue_event() never be freed. I think number of events at a
point of tme is limited and we can have static storage for the events.
The implementaion of sys/i386/apm/apm.c:apm_record_event() (it's for apmd)
would be a good example.
I have a megapatch for acpi.c that I am nearly ready to commit which
converts it to use bus resources for all I/O allocations. I'll fix this
in there, if you like.
I'm interested in your patch. Can I see it?
Sure. I'm not 100% sure it's going to work right, so please feel free
to tell me I've broken something...
Index: conf/files
===
RCS file: /host/fs/local0/cvs/src/sys/conf/files,v
retrieving revision 1.416
diff -u -r1.416 files
--- conf/files 2000/09/23 22:21:39 1.416
+++ conf/files 2000/09/27 10:17:04
@@ -75,7 +75,8 @@
#dev/aac/aac_debug.c optional aac
dev/aac/aac_disk.c optional aac
dev/aac/aac_pci.c optional aac pci
-dev/acpi/acpi.ccount acpi
+dev/acpi/acpi.coptional acpi
+dev/acpi/acpi_io.c optional acpi
dev/acpi/acpi_powerres.c optionalacpi
dev/acpi/aml/aml_amlmem.c optionalacpi
dev/acpi/aml/aml_common.c optionalacpi
Index: dev/acpi/acpi.c
===
RCS file: /host/fs/local0/cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.14
diff -u -r1.14 acpi.c
--- dev/acpi/acpi.c 2000/09/27 05:43:53 1.14
+++ dev/acpi/acpi.c 2000/09/28 17:56:57
@@ -52,7 +52,6 @@
#include sys/rman.h
#include sys/acpi.h
-
#include dev/acpi/acpi.h /* for softc */
#include dev/acpi/aml/aml_amlmem.h
@@ -63,8 +62,6 @@
#include dev/acpi/aml/aml_parse.h
#include dev/acpi/aml/aml_memman.h
-#include machine/acpi_machdep.h /* for ACPI_BUS_SPACE_IO */
-
/*
* ACPI pmap subsystem
*/
@@ -93,8 +90,7 @@
static struct ACPIaddr acpi_addr;
struct ACPIrsdp *acpi_rsdp;
-static int acpi_port;
-static int acpi_irq;
+struct FACPbody acpi_init_facp;
/* Character device */
@@ -121,31 +117,8 @@
-1
};
-/*
- * ACPI register I/O
- */
-#defineACPI_REGISTER_INPUT 0
-#defineACPI_REGISTER_OUTPUT1
-static void acpi_register_input(u_int32_t ioaddr,
- u_int32_t *value, u_int32_t size);
-static void acpi_register_output(u_int32_t ioaddr,
-u_int32_t *value, u_int32_t size);
-static void acpi_enable_disable(acpi_softc_t *sc, boolean_t enable);
-static void acpi_io_pm1_status(acpi_softc_t *sc, boolean_t io,
- u_int32_t *a, u_int32_t *b);
-static void acpi_io_pm1_enable(acpi_softc_t *sc, boolean_t io,
- u_int32_t *a, u_int32_t *b);
-static void acpi_io_pm1_control(acpi_softc_t *sc, boolean_t io,
- u_int32_t *a, u_int32_t *b);
-static void acpi_io_pm2_control(acpi_softc_t *sc, boolean_t io, u_int32_t *val);
-static void acpi_io_pm_timer(acpi_softc_t *sc, boolean_t io, u_int32_t *val);
-static void acpi_io_gpe0_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val);
-static void acpi_io_gpe0_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val);
-static void acpi_io_gpe1_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val);
-static void acpi_io_gpe1_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val);
-
/*
- * Miscellous utility functions
+ * Miscellaneous utility functions
*/
static int acpi_sdt_checksum(struct ACPIsdt * sdt);
static void acpi_handle_dsdt(acpi_softc_t *sc);
@@ -164,8 +137,7 @@
/*
* ACPI events
*/
-static void acpi_process_event(acpi_softc_t *sc,
- u_int32_t status_a, u_int32_t status_b,
+static void acpi_process_event(acpi_softc_t *sc, u_int32_t status_e,
u_int32_t status_0, u_int32_t status_1);
static void acpi_intr(void *data);
static void acpi_enable_events(acpi_softc_t *sc);
@@ -187,9 +159,9 @@
/* for debugging */
#ifdef ACPI_DEBUG
-static int acpi_debug = 1;
+intacpi_debug = 1;
#else /* !ACPI_DEBUG */
-static int acpi_debug = 0;
+intacpi_debug = 0;
#endif /* ACPI_DEBUG */
SYSCTL_INT(_debug, OID_AUTO, acpi_debug, CTLFLAG_RW, acpi_debug, 1, "");
@@ -303,364 +275,8 @@
}
/*
- * ACPI Register I/O
+ * Miscellaneous utility functions
*/
-void
-acpi_gpe_enable_bit(acpi_softc_t *sc, u_int32_t bit, boolean_t on_off)
-{
- int x;
- u_int32_t pos, value;
- void(*GPEx_EN[])(acpi_softc_t *, boolean_t, u_int32_t *) = {
- acpi_io_gpe0_enable,
- acpi_io_gpe0_enable
- };
-
- x = -1;
- pos = bit;
- if (bit sc-facp_body-gpe0_len * 4) {
- x = 0;
- } else {
- /* should we check gpe1_len too? */
-
Re: My system hang with ACPI kernel thread
Hi,
In message [EMAIL PROTECTED], Munehiro Matsuda wrote:
With the addition of ACPI kernel thread, my system hangs in about
10 miniutes use after boot up. By disabling kernel thread, system
runs just fine.
Do you have any idea where to look at?
I'll try and see what I can do myself.
Please set debug.aml_debug and debug.acpi_debug to 1 and
see what will happen.
I could find a couple of possibilities from VersaProNX.asl; lack of
SleepOp or EC I/O. If the former, I can try to write it as well as
StallOp tonight, of course Intel ACPICA compatible one.
Ok, I've just wrote Stall() and Sleep() operators. Differences
between them are short-term or long-term, not relinquish CPU or
relinquish CPU. I used DELAY() for StallOp and tsleep() for SleepOp.
BTW, is timeout parameter of tsleep broken for now? I had to call
wakeup() explicitly, otherwise it won't return from tsleep :-(
Index: dev/acpi/acpi.c
===
RCS file: /home/ncvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.14
diff -u -r1.14 acpi.c
--- dev/acpi/acpi.c 2000/09/27 05:43:53 1.14
+++ dev/acpi/acpi.c 2000/09/28 19:10:52
@@ -1707,5 +1707,51 @@
SYSINIT(acpi, SI_SUB_KTHREAD_IDLE, SI_ORDER_ANY, acpi_start_threads, 0);
+/*
+ * System service interface
+ */
+
+#include sys/proc.h
+
+#if 1
+/* XXX tsleep timeout broken? */
+static void
+acpi_sleep_end(void *chan)
+{
+ wakeup(chan);
+}
+#endif
+int
+acpi_sleep(u_int32_t micro)
+{
+ int x, error;
+ static u_int8_t count = 0;
+
+ x = error = 0;
+
+ if (micro == 0) {
+ return (1);
+ }
+
+ if (curproc == NULL) {
+ return (2);
+ }
+
+#if 1
+/* XXX tsleep timeout broken? */
+ timeout(acpi_sleep_end, (caddr_t)acpi_sleep + count,
+ (hz * micro) / 100L);
+#endif
+ error = tsleep((caddr_t)acpi_sleep + count, PWAIT, "acpislp",
+ (hz * micro) / 100L);
+ if (error != 0 error != EWOULDBLOCK) {
+ return (2);
+ }
+ x = splhigh();
+ count++;
+ splx(x);
+
+ return (0);
+}
Index: dev/acpi/acpi.h
===
RCS file: /home/ncvs/src/sys/dev/acpi/acpi.h,v
retrieving revision 1.10
diff -u -r1.10 acpi.h
--- dev/acpi/acpi.h 2000/09/27 05:43:54 1.10
+++ dev/acpi/acpi.h 2000/09/28 19:25:37
@@ -163,4 +163,9 @@
#define ACPI_DEVPRINTF(args...)printf("acpi0: " args)
#define ACPI_DEBUGPRINT(args...) do { if (acpi_debug) ACPI_DEVPRINTF(args);}
while(0)
+/*
+ * System service interface
+ */
+extern int acpi_sleep(u_int32_t micro);
+
#endif /* !_DEV_ACPI_ACPI_H_ */
Index: dev/acpi/aml/aml_common.h
===
RCS file: /home/ncvs/src/sys/dev/acpi/aml/aml_common.h,v
retrieving revision 1.2
diff -u -r1.2 aml_common.h
--- dev/acpi/aml/aml_common.h 2000/09/20 01:01:27 1.2
+++ dev/acpi/aml/aml_common.h 2000/09/28 18:17:27
@@ -47,11 +47,15 @@
printf(fmt, args); \
} while(0)
#define AML_DEBUGGER(x, y) /* no debugger in kernel */
+#define AML_STALL(micro) DELAY(micro)
+#define AML_SLEEP(sec, milli) OsdSleep(sec, milli)
#else /* !_KERNEL */
#define AML_SYSASSERT(x) assert(x)
#define AML_SYSABORT() abort()
#define AML_SYSERRX(eval, fmt, args...)errx(eval, fmt, args)
#define AML_DEBUGGER(x, y) aml_dbgr(x, y)
+#define AML_STALL(m) /* not required in userland */
+#define AML_SLEEP(s, m)/* not required in userland */
#endif /* _KERNEL */
union aml_object;
Index: dev/acpi/aml/aml_parse.c
===
RCS file: /home/ncvs/src/sys/dev/acpi/aml/aml_parse.c,v
retrieving revision 1.3
diff -u -r1.3 aml_parse.c
--- dev/acpi/aml/aml_parse.c2000/09/20 22:53:39 1.3
+++ dev/acpi/aml/aml_parse.c2000/09/28 11:40:44
@@ -55,6 +55,8 @@
#include "debug.h"
#else /* _KERNEL */
#include sys/systm.h
+#include machine/acpica_osd.h
+#include machine/clock.h
#endif /* !_KERNEL */
static int findsetleftbit(int num);
@@ -1484,14 +1486,18 @@
aml_parse_termobj(env, indent);
AML_DEBUGPRINT(")");
break;
- case 0x21: /* StallOp *//* XXX Not yet */
+ case 0x21: /* StallOp */
AML_DEBUGPRINT("Stall(");
- aml_parse_termobj(env, indent);
+ num1 = aml_objtonum(env, aml_eval_name(env,
+ aml_parse_termobj(env, indent)));
AML_DEBUGPRINT(")");
+ AML_STALL(num1);
break;
- case 0x22: /* SleepOp *//* XXX Not yet */
+ case 0x22:
Re: My system hang with ACPI kernel thread
In message [EMAIL PROTECTED], Munehiro Matsuda wrote: With the addition of ACPI kernel thread, my system hangs in about 10 miniutes use after boot up. By disabling kernel thread, system runs just fine. Do you have any idea where to look at? I'll try and see what I can do myself. Please set debug.aml_debug and debug.acpi_debug to 1 and see what will happen. Takanori Watanabe a href="http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html" Public Key/a Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
