Re: APM related panic

[Mitsuru IWASAKI]

# sorry to break the thread, I'm a digest reader...

Hi,

> > apm0:  on motherboard
> > apm: APM BIOS version 0102
> > apm: Code16 0xc00f, Data 0xc00fdfa0
> > apm: Code entry 0x8010, Idling CPU enabled, Management enabled
> > apm: CS_limit=0x0, DS_limit=0x0
> 
> These limits look pretty suspect, although the code segment below looks 
> OK.

I suspect too, especially ds limit.
I've seen such bogus 1.2 APM BIOSes before.  I hope attached patch
help you (for /sys/i386/apm/apm.c).

P.S.
Thank you for enhanced APM code, mike.  I had enjoy last week end to
study the new code.  Some of my concerns about APM gone :-)

--- apm.c-  Mon Aug  2 21:31:20 1999
+++ apm.c   Mon Aug  2 21:49:52 1999
@@ -773,6 +773,30 @@
sc->bios.seg.code16.limit = 0x;
sc->bios.seg.data.limit = 0x;
}
+
+   /*
+* Segment limits fixup:
+* Some bogus APM V1.1 (even if V1.2) BIOSes do not return 
+* any size limits in the registers they are supposed to.
+* if we see zero limits here, we assume that means they 
+* should be 64k.
+*/
+
+   /* code segment (16 bit) */
+   if (sc->bios.seg.code16.limit == 0) {
+#ifdef APM_DEBUG
+   printf("apm_probe: APM bios gave zero len code16, pegged to 64K\n");
+#endif
+   sc->bios.seg.code16.limit = 0x;
+   }
+   /* data segment */
+   if (sc->bios.seg.data.limit == 0) {
+#ifdef APM_DEBUG
+   printf("apm_probe: APM bios gave zero len data, tentative 64K\n");
+#endif
+   sc->bios.seg.data.limit = 0x;
+   }
+
return(0);
 }
 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: recent apm changes

[Mitsuru IWASAKI]

Hi,

> In message <[EMAIL PROTECTED]> Eric Hodel writes:
> : I've got a -current machine (no cvsups in a few months) that wakes up
> : immediately after suspending.  (sleeps 0 seconds)
> 
> Hmmm, some laptops will wakeup on a keyboard interrupt.  The interrupt 
> that is waking you up may be the key up from the return you hit to
> make the event happen.
> 
> PAO has a small sleep in the apm driver, while -current didn't the
> last time I looked.

OK, I'll work on this.  

To Peter Mutsaers:
Could you try following command to suspend and see any improvements?
 % sleep 3 && apm -z &



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: recent apm changes

[Mitsuru IWASAKI]

plm> In contract, if I suspend in Linux of Windows, the computer shuts up
plm> immediateley and is quiet. Only sometimes there is a (not too loud)
plm> little fan (I think it is the CPU fan) running for a few more minutes.

I've read Linux code (v2.2.9) closely, noticed they put cli 
before APM BIOS call and save & restore segment registers.
I suspect these two (or only cli?) affect the suspending state.
To clarify, could you try attached patches (for sys/i386/i386/bioscall.s) 
one by one?

# This is a shell archive.  Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file".  Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
#   bioscall-1
#   bioscall-2
#   bioscall-3
#
echo x - bioscall-1
sed 's/^X//' >bioscall-1 << 'END-of-bioscall-1'
X--- i386/i386/bioscall.s.org   Mon Aug  9 17:51:31 1999
X+++ i386/i386/bioscall.s   Mon Aug  9 17:53:07 1999
X@@ -64,9 +64,16 @@
X   movl12(%ebp),%edx
X   movl16(%ebp),%esi
X   movl20(%ebp),%edi
X+#if 1 /* cli hack */
X+  pushfl
X+  cli
X+#endif
X   pushl   %ebp
X   lcall   _bioscall_vector
X   popl%ebp
X+#if 1 /* cli hack */
X+  popfl
X+#endif
X   movl%eax,0(%ebp)
X   movl%ebx,4(%ebp)
X   movl%ecx,8(%ebp)
END-of-bioscall-1
echo x - bioscall-2
sed 's/^X//' >bioscall-2 << 'END-of-bioscall-2'
X--- i386/i386/bioscall.s.org   Mon Aug  9 17:51:31 1999
X+++ i386/i386/bioscall.s   Mon Aug  9 18:01:36 1999
X@@ -64,9 +64,17 @@
X   movl12(%ebp),%edx
X   movl16(%ebp),%esi
X   movl20(%ebp),%edi
X+#if 1 /* segment regs hack */
X+  pushl   %fs
X+  pushl   %gs
X+#endif
X   pushl   %ebp
X   lcall   _bioscall_vector
X   popl%ebp
X+#if 1 /* segment regs hack */
X+  popl%gs
X+  popl%fs
X+#endif
X   movl%eax,0(%ebp)
X   movl%ebx,4(%ebp)
X   movl%ecx,8(%ebp)
END-of-bioscall-2
echo x - bioscall-3
sed 's/^X//' >bioscall-3 << 'END-of-bioscall-3'
X--- i386/i386/bioscall.s.org   Mon Aug  9 17:51:31 1999
X+++ i386/i386/bioscall.s   Mon Aug  9 18:00:07 1999
X@@ -64,9 +64,20 @@
X   movl12(%ebp),%edx
X   movl16(%ebp),%esi
X   movl20(%ebp),%edi
X+#if 1 /* cli + segment regs hack */
X+  pushfl
X+  cli
X+  pushl   %fs
X+  pushl   %gs
X+#endif
X   pushl   %ebp
X   lcall   _bioscall_vector
X   popl%ebp
X+#if 1 /* cli + segment regs hack */
X+  popl%gs
X+  popl%fs
X+  popfl
X+#endif
X   movl%eax,0(%ebp)
X   movl%ebx,4(%ebp)
X   movl%ecx,8(%ebp)
END-of-bioscall-3
exit



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: recent apm changes

[Mitsuru IWASAKI]

Hi,

> MI> I've read Linux code (v2.2.9) closely, noticed they put cli
> MI> before APM BIOS call and save & restore segment registers.  I
> MI> suspect these two (or only cli?) affect the suspending state.
> MI> To clarify, could you try attached patches (for
> MI> sys/i386/i386/bioscall.s) one by one?
> 
> I've tried them all. They don't make a difference alas.
> 
> In doing so, to my surprise I found out that when I suspend my computer
> in FreeBSD, it isn't suspended at all!
> 
> I have an ATX case with an Asus P2B motherboard. When I suspend my
> computer, the power led starts flashing (and keeps doing so).
> 
> When I suspend my computer in Linux or Windows, as mentioned, the
> computer gets quiet (HDD spins down etc). The led flashes.

Hmmm, the CLI call is not useful in this case... I also had 
another kind of problem about CLI, my box froze sometimes 
when suspending.  It shouldn't be put CLI in here as Nate mentioned.

Segment regisers also wasn't related with the problem.  I watched 
%fs before & after BIOS call using ddb, the value didn't change on 
my box. I guess Linux code only expects some BIOSes manipulate 
segment registers.

Another possibility is *delay mechanism* on suspend (and standby).
AFAIK, Linux, NetBSD and PAO has this but CURRENT.  I'll make patch 
tonight based on PAO APM code.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: recent apm changes

[Mitsuru IWASAKI]

> Another possibility is *delay mechanism* on suspend (and standby).
> AFAIK, Linux, NetBSD and PAO has this but CURRENT.  I'll make patch 
> tonight based on PAO APM code.

Please try this patch.
If it still fails, it's worth to try increasing APM_SUSPEND_DELAY, 
something like:
#define APM_SUSPEND_DELAY 3

plm> or with the suspend button or through the BIOS timer), the led starts

Oh, do you have suspend button on your box? Cool.
On my poor experience, suspeding by hot-keys easier to 
success than by zzz(8).

BTW, have you tried apmd too?

Index: apm.c
===
RCS file: /home/ncvs/src/sys/i386/apm/apm.c,v
retrieving revision 1.98
diff -u -r1.98 apm.c
--- apm.c   1999/08/02 18:46:34 1.98
+++ apm.c   1999/08/10 14:05:43
@@ -63,8 +63,10 @@
int initialized, active, bios_busy;
int always_halt_cpu, slow_idle_cpu;
int disabled, disengaged;
+   int standby_countdown, suspend_countdown;
u_int   minorversion, majorversion;
u_int   intversion, connectmode;
+   u_int   standbys, suspends;
struct bios_args bios;
struct apmhook sc_suspend;
struct apmhook sc_resume;
@@ -431,7 +433,68 @@
 
 static u_int apm_op_inprog = 0;
 
+/* This is no good :( This should be SYSCTLized. */
+#ifndef APM_STANDBY_DELAY
+#define APM_STANDBY_DELAY 1
+#endif
+
+#ifndef APM_SUSPEND_DELAY
+#define APM_SUSPEND_DELAY 1
+#endif
+
 static void
+apm_do_suspend(void)
+{
+   struct apm_softc *sc = &apm_softc;
+   int error;
+
+   if (!sc)
+   return;
+
+   apm_op_inprog = 0;
+   sc->suspends = sc->suspend_countdown = 0;
+
+   if (sc->initialized) {
+   error = DEVICE_SUSPEND(root_bus);
+   /*
+* XXX Shouldn't ignore the error like this, but should
+* instead fix the newbus code.  Until that happens,
+* I'm doing this to get suspend working again.
+*/
+   if (error)
+   printf("DEVICE_SUSPEND error %d, ignored\n", error);
+   apm_execute_hook(hook[APM_HOOK_SUSPEND]);
+   if (apm_suspend_system(PMST_SUSPEND) == 0)
+   apm_processevent();
+   else
+   /* Failure, 'resume' the system again */
+   apm_execute_hook(hook[APM_HOOK_RESUME]);
+   }
+}
+
+static void
+apm_do_standby(void)
+{
+   struct apm_softc *sc = &apm_softc;
+
+   if (!sc)
+   return;
+
+   apm_op_inprog = 0;
+   sc->standbys = sc->standby_countdown = 0;
+
+   if (sc->initialized) {
+   /*
+* As far as standby, we don't need to execute 
+* all of suspend hooks.
+*/
+   apm_default_suspend(&apm_softc);
+   if (apm_suspend_system(PMST_STANDBY) == 0)
+   apm_processevent();
+   }
+}
+
+static void
 apm_lastreq_notify(void)
 {
struct apm_softc *sc = &apm_softc;
@@ -478,29 +541,27 @@
 apm_suspend(int state)
 {
struct apm_softc *sc = &apm_softc;
-   int error;
 
-   if (!sc)
+   switch (state) {
+   case PMST_SUSPEND:
+   if (sc->suspends)
+   return;
+   sc->suspends++;
+   sc->suspend_countdown = APM_SUSPEND_DELAY;
+   break;
+   case PMST_STANDBY:
+   if (sc->standbys)
+   return;
+   sc->standbys++;
+   sc->standby_countdown = APM_STANDBY_DELAY;
+   break;
+   default:
+   printf("apm_suspend: Unknown Suspend state 0x%x\n", state);
return;
-
-   apm_op_inprog = 0;
-
-   if (sc->initialized) {
-   error = DEVICE_SUSPEND(root_bus);
-   /*
-* XXX Shouldn't ignore the error like this, but should
-* instead fix the newbus code.  Until that happens,
-* I'm doing this to get suspend working again.
-*/
-   if (error)
-   printf("DEVICE_SUSPEND error %d, ignored\n", error);
-   apm_execute_hook(hook[APM_HOOK_SUSPEND]);
-   if (apm_suspend_system(state) == 0)
-   apm_processevent();
-   else
-   /* Failure, 'resume' the system again */
-   apm_execute_hook(hook[APM_HOOK_RESUME]);
}
+
+   apm_op_inprog++;
+   apm_lastreq_notify();
 }
 
 void
@@ -625,6 +686,12 @@
if (apm_op_inprog)
apm_lastreq_notify();
 
+   if (sc->standbys && sc->standby_countdown-- <= 0)
+   apm_do_standby();
+
+   if (sc->suspends && sc->suspend_countdown-- <= 0)
+   apm_do_suspend();
+
if (!sc->bios_busy)
apm_processevent();
 
@@ -826,7 +893,7 @@
  

Re: recent apm changes

[Mitsuru IWASAKI]

Hi,

> > Oh, do you have suspend button on your box? Cool.
> > On my poor experience, suspeding by hot-keys easier to 
> > success than by zzz(8).
> 
> On this point I can report the oppposite experience, on my
> machine (a no name special) the trackpad tends to lock up if touched
> between power on and resume finishing. The best indicator of safety is
> apm -z returning, if I use the button I have to guess.

Ahh, I've seen this kind of behavior on some laptops.  I guess this is
related with some sort of time limits on communication with APM BIOS.

APM Spec. v1.2 Appendix D - APM Driver Considerations -
When an APM connection exists, the APM BIOS transitions into System
Standby and System Suspend states only when directed to do so by a
call from the APM Driver. The calls to change system states are
invoked by the APM Driver only after the APM BIOS indicates that the
state transition should be made, and the APM Driver has checked with
all APM-aware applications to make sure that it is an appropriate time
to change system states. However, there are three cases where the APM
BIOS may make the system state transition itself. The first case is if
the APM Driver does not pick up a posted Standby Request, Suspend
Request or Critical Suspend Notification event within the 2 second
   ~~~
(one second plus one second grace period) time limit. The second is
when the APM Driver, after picking up the event, does not respond to a
Standby Request, Suspend Request or Critical Suspend Notification
event with an appropriate Set Power State call within 5 seconds of
   
receiving the event. The last situation is when the APM Driver has
responded to an event with a Request Processing Set Power call and
does not reply again within another 5 seconds.The CPU is power managed
according to CPU Idle and CPU Busy calls made by the APM Driver to the
APM BIOS.


Last time, we didn't have `Last Request Processing Notification' to
APM BIOS at all for the second case.
After adding this hack in PAO, we saw greate improvements about system
suspending transition (standby also) on a lot of laptops :)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: recent apm changes

[Mitsuru IWASAKI]

Hi, Nate.

I'm sorry if my poor english troubled you.

> We should have no problems responding in this amount of time in FreeBSD,
> since we don't (didn't used to?) have any code that should cause
> significant delay in responding.

My understanding on system suspend code in FreeBSD is that once APM
driver get a system suspend request event from the BIOS, the driver is
hurry to put system into suspend state (execute suspend hooks and call
set power state function for suspend) as soon as possible without any
responses to the BIOS.
I think that this style is cool, I like, and no response to the BIOS
is not violating the APM specification at all, but there are many
BIOSes expecting response from driver.  In Linux and NetBSD, they have
last request processing notification to the BIOS before transition into
suspend state. I guess they obtained the same conclusion to support
various BIOS implementations including buggy and bogus BIOSes.
That's why `suspending on Linux is OK, but on FreeBSD' like phenomenon
is there  I'd like solve this if possible and need your help or
support.

>From Linux code:
static void do_apm_timer(unsigned long unused)
{
int err;

static int  pending_count = 0;

if (((standbys_pending > 0) || (suspends_pending > 0))
&& (apm_bios_info.version > 0x100)
&& (pending_count-- <= 0)) {
pending_count = 4;

err = apm_set_power_state(APM_STATE_BUSY);
if (err)
apm_error("busy", err);
}

>From NetBSD code:
static void
apm_event_handle(sc, regs)
struct apm_softc *sc;
struct bioscallregs *regs;
{
int error;
struct bioscallregs nregs;

switch(regs->bx) {
case APM_USER_STANDBY_REQ:
DPRINTF(APMDEBUG_EVENTS, ("apmev: user standby request\n"));
if (apm_do_standby) {
if (apm_record_event(sc, regs->bx))
apm_userstandbys++;
apm_op_inprog++;
(void)apm_set_powstate(APM_DEV_ALLDEVS,
APM_LASTREQ_INPROG);
} else {
(void)apm_set_powstate(APM_DEV_ALLDEVS,
APM_LASTREQ_REJECTED);
/* in case BIOS hates being spurned */
apm_powmgt_enable(1);
}
break;

> > Last time, we didn't have `Last Request Processing Notification' to
> > APM BIOS at all for the second case.
> 
> Huh?  I don't see any mention of 'last request processing notification'
> anywhere above.  Also, I don't believe the APM driver responds with a

Ah, details are described in `4. Advanced Power Managerment Software
Interface - 4.6.8 Set Power State'.  `an appropriate Set Power State
call' includes 'last request processing notification' too.
They say:
Set Power State entry codes of CX=0004h and CX=0005h are used by the
APM Driver to respond to requests from the system BIOS for the
global Standby and Suspend states. The APM Driver uses the Last
Request Processing Notification (0004h) to indicate that it is
currently in the process of determining whether or not to reject the
request. This notification must be sent at least once every five
seconds after the APM driver receives the request by calling Get
Power Management Event. The APM driver must eventually end this
"busy" state by accepting the request, (calling Set Power State with
the appropriate state) or by rejecting the request using CX=0005h.

Thanks.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: recent apm changes

[Mitsuru IWASAKI]

Hi,

> MI> Please try this patch.
> MI> If it still fails, it's worth to try increasing APM_SUSPEND_DELAY, 
> MI> something like:
> MI> #define APM_SUSPEND_DELAY 3
> 
> Alas, it doesn't make a difference.

H. OK, I'll buy new mather board same one as yours and investigate
what's happend on it.  Could you tell me which M/B are you using?  And
I'd like to have your dmesg output from kernel with APM_DEBUG option.
# In your kernel config file:
#  options APM_DEBUG

Also, I'll send you few more patches before I purchase new one if I
get new ideas.

> Anyway thanks for you efforts so far.

Not at all.  I never give up :)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: recent apm changes

[Mitsuru IWASAKI]

Hi,

I got ASUS P2B M/B & ATX case and assembled new box yesterday.  With
my patch, new box successfully transit into suspend state.  There is
no sounds from CPU fun, chassis fun and IDE HDD spin (powered down by 
BIOS setting, Power management setup -> PM Timers -> HDD Power Down: 
1 Min.).  The power led keeps flashing during suspending.

Without the patch, suspending system is never successful (standby
also), message `slept 00:00:00' comes up :-(
The key release event seems prevent suspend, so some sort of delay
mechanism would be necessary such as my patch.

Now I'm wondering why your PC doesn't get quite.  I suspect that
hardware configuration different from yours (I have no SCSI HD on new
box).  Any suggestions?

I attached my dmesg output FYI.

Thanks.

> > MI> Please try this patch.
> > MI> If it still fails, it's worth to try increasing APM_SUSPEND_DELAY, 
> > MI> something like:
> > MI> #define APM_SUSPEND_DELAY 3
> > 
> > Alas, it doesn't make a difference.
> 
> H. OK, I'll buy new mather board same one as yours and investigate
> what's happend on it.  Could you tell me which M/B are you using?  And
> I'd like to have your dmesg output from kernel with APM_DEBUG option.
> # In your kernel config file:
> #  options APM_DEBUG

Copyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-CURRENT #4: Tue Aug 17 00:16:46 JST 1999
[EMAIL PROTECTED]:/usr/src/sys/compile/CELERON
Timecounter "i8254"  frequency 1193182 Hz
CPU: Celeron (367.50-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x660  Stepping = 0
  
Features=0x183f9ff
real memory  = 134205440 (131060K bytes)
avail memory = 126779392 (123808K bytes)
Preloaded elf kernel "kernel" at 0xc033d000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc033d09c.
VESA: v1.2, 4096k memory, flags:0x0, mode table:0xc00c4ead (c0004ead)
VESA: S3 Incorporated. Vision968
Pentium Pro MTRR support enabled
Probing for PnP devices:
npx0:  on motherboard
npx0: INT 16 interface
apm0:  on motherboard
apm: APM BIOS version 0102
apm: Code16 0xc00f, Data 0xc00fdbf0
apm: Code entry 0x7870, Idling CPU disabled, Management enabled
apm: CS_limit=0x, DS_limit=0x
apm: Engaged control enabled
apm: found APM BIOS v1.2, connected at v1.2
apm: Slow Idling CPU disabled
Add hook "default suspend"
Add hook "default resume"
pcib0:  on motherboard
pci0:  on pcib0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
isab0:  at device 4.0 on pci0
ide_pci0:  at device 4.1 on pci0
uhci0:  irq 5 at device 4.2 on pci0
usb0:  on uhci0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
chip1:  at device 4.3 on pci0
vx0: <3COM 3C590 Etherlink III PCI> irq 10 at device 11.0 on pci0
utp[*utp*]: disable 'auto select' with DOS util! address 00:a0:24:38:b7:0b
Warning! Defective early revision adapter!
vga-pci0:  irq 11 at device 12.0 on pci0
isa0:  on motherboard
fdc0:  at port 0x3f0-0x3f7 irq 6 drq 2 on isa0
wdc0 at port 0x1f0-0x1f7 irq 14 on isa0
wdc0: unit 0 (wd0): 
wd0: 8693MB (17803440 sectors), 17662 cyls, 16 heads, 63 S/T, 512 B/S
atkbdc0:  at port 0x60-0x6f on isa0
atkbd0:  irq 1 on atkbdc0
psm0:  irq 12 on atkbdc0
psm0: model GlidePoint, device ID 0
vga0:  at port 0x3b0-0x3df iomem 0xa-0xb on isa0
sc0:  on isa0
sc0: VGA <16 virtual consoles, flags=0x200>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: apm problems.

[Mitsuru IWASAKI]

Hi,

My understanding on your problems is:
1. Standby by PM timer in BIOS setting fails with the system activity.
2. No new process can be started after resume.
Is it correct?

1. My laptops also fails if the console or window is updating by the
   output from running commands.  But standby on other unused console
   (ttyv1 or something), monitor blanks.  Standby usually never stop 
   disk activities.

2. Do you have `calcru: negative time' messages after resume?  One of
   my laptops has this problem, doesn't restore the countdown register of
   i8254 on resume.  After resume, my laptop is getting very slooow,
   takes 2 mins to shutdown...  If your problem is the same as mine,
   hack in PAO (i8254_restore() in /sys/i386/apm/apm.c and
   /sys/i386/isa/clock.c) would be helpful for you.
   Another possibility is apmd configuration.  Is it correctly configured?
   Please try to disable apmd to make it clear whether apmd causes
   your problem.

> Apm does not seem to be behaving correctly on my computer (running
> yesterday's CURRENT)

Is this first time for you?  Have you met the problems before or just
recently?

> if more info is needed, just let me know what to do. Thanks =).

I'd like to have your dmesg output.  Are you using desktop PC, right?



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: apm problems.

[Mitsuru IWASAKI]

Hi, sorry to late.

> > 1. Standby by PM timer in BIOS setting fails with the system activity.
> 
> If by fails you mean enters standby mode, then yes the computer enters
> standby mode while the system is active, after the period of time set in
> the bios, as long as no keys have been pressed on the keyboard during
> that time.

Ah, If you want to reject the standby request from BIOS while the
system is active, then apmd would be useful. You can configure it like
this:
in /etc/apmd.conf:
apm_event PMEV_STANDBYREQ {
reject;
}

or

apm_event PMEV_STANDBYREQ {
exec "/etc/rc.standby_with_system_activity";
}

with /etc/rc.standby_with_system_activity:
#!/bin/sh
if [ some_script_to_check_system_is_active ]
then
# apmd will reject the event...
exit 1
fi

> > 2. No new process can be started after resume.
> > Is it correct?
> 
> Yes, although this doesn't happen every time, sometimes everything is ok
> after a resume.
> This seems to be very repeatable following these steps.
> 
> cd /usr/bin
> cp * /tmp &
> sleep 1 && apm -z (while copy is still in progress)
> [hit a key]
> any new process started freezes, nothing happens (including logins in
> getty, halt etc).

I tried these steps many times, but I couldn't see the problem.
I guess your disks are still in a SLEEP after a resume or 
I/O interrupts were lost during suspend/resume or something.
Anyone suggestions?

> ata0: master: setting up WDMA2 mode on PIIX3/4 chip OK
> ad0:  ATA-? disk at ata0 as master
> ad0: 1222MB (2503872 sectors), 2484 cyls, 16 heads, 63 S/T, 512 B/S
> ad0: piomode=4, dmamode=2, udmamode=-1
> ad0: 16 secs/int, 0 depth queue, DMA mode

If your problem is related with disks, have you tried wd device driver
instead of ata?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: recent apm changes

[Mitsuru IWASAKI]

plm> If I use 'zzz', I have to do the known 'sleep 1; zzz' trick. This is
plm> the difference.

I'll commit the patch for `key release event prevent suspend' problem 
if no objections.

Thanks a lot!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: recent apm changes

[Mitsuru IWASAKI]

Sorry to late...

plm> Now suspend works. However still the disks keep spinning until they
plm> reach their BIOS timeout. In Linux & Windows, there is some hook when
plm> going to suspend mode that spins down the (IDE) disks. This is nice,
plm> since it is well possible that you go to suspend but do not set a disk
plm> spindown timeout.

I read linux source code closely again, I found their hack in 
IDE device driver.  Does anyone know this could make differences on
suspending?

>From linux/drivers/block/ide.c   Version 6.18  August 16, 1998:

void ide_intr (int irq, void *dev_id, struct pt_regs *regs)
{
unsigned long flags;
ide_hwgroup_t *hwgroup = (ide_hwgroup_t *)dev_id;
ide_hwif_t *hwif;
ide_drive_t *drive;
ide_handler_t *handler;

__cli();/* local CPU only */
spin_lock_irqsave(&hwgroup->spinlock, flags);
hwif = hwgroup->hwif;
if ((handler = hwgroup->handler) == NULL || hwgroup->poll_timeout != 0) {
/*
 * Not expecting an interrupt from this drive.
 * That means this could be:
 *  (1) an interrupt from another PCI device
 *  sharing the same PCI INT# as us.
 * or   (2) a drive just entered sleep or standby mode,
 *  and is interrupting to let us know.
 * or   (3) a spurious interrupt of unknown origin.
 *
 * For PCI, we cannot tell the difference,
 * so in that case we just ignore it and hope it goes away.
 */
#ifdef CONFIG_BLK_DEV_IDEPCI
if (IDE_PCI_DEVID_EQ(hwif->pci_devid, IDE_PCI_DEVID_NULL))
#endif  /* CONFIG_BLK_DEV_IDEPCI */
{
/*
 * Probably not a shared PCI interrupt,
 * so we can safely try to do something about it:
 */
(void)ide_ack_intr(hwif->io_ports[IDE_STATUS_OFFSET], 
hwif->io_ports[IDE_IRQ_OFFSET]);
unexpected_intr(irq, hwgroup);
}
spin_unlock_irqrestore(&hwgroup->spinlock, flags);
return;
}

... but I've seen this kind of hack in wd device driver before.

How about spin down from userland (apmd) using camcontrol(8) like tool?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: if_de.c breakage ?

[Mitsuru IWASAKI]

Hi, my mentor :-)

phk> Am I the only one to see these ?

Me too. I found it other files as well.
It seems that adding following line is required in some source code.

#include 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: fix for apm.4

[Mitsuru IWASAKI]

> the patch makes apm.4 consistent with LINT ("isa?"->"nexus?").

Committed. Thanks!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: APM still ignoring DEVICE_SUSPEND errors

[Mitsuru IWASAKI]

> On Mon, 24 Jan 2000, Warner Losh wrote:
> 
> > In message  Nick Hibma writes:
> > : The following patch fixes two things: First, DEVICE_SUSPEND errors are
> > : no longer ignored. Since we have defaults for methods we should no
> > : longer ignore these errors. Also, DEVICE_RESUME wasn't done when the
> > : apm_suspend_system event failed.
> > 
> > I had similar patches that workede several months ago, but they have
> > since been lost.
> > 
> > : Second, in the ordering of DEVICE_* and apm_hook_* is not symmetric for
> > : suspend and resume. The patch reverses the resume case as well to be
> > : 
> > :   apm_hook_resume(...)
> > :   DEVICE_RESUME(root)
> > : 
> > : Send me some feedback on this. I've mailed the people mentioned in the
> > : head of the file, but so far got no response. I would like to make sure
> > : we get this right when USB devices are used. Some of them don't suspend
> > : and the suspend should be refused in that case.
> > 
> > Any reason to not shoot the apm_hook_{suspend,resume} in the head and
> > just use newbus suspend/resume everywhere?
> 
> Are there any non-newbus devices which need suspend/resume?  I think the
> i386 clock uses the apm hooks but I might be misremembering.

No, it just reloads the countdown register of i8254 in
apm_default_resume() for now.  But once the PIT become an ordinary
device like any other, this is planned to be the device's resume
method.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: followup to apm problems.

[Mitsuru IWASAKI]

Hi,

I'd like to have full output of dmesg to investigate hardware
interference in apm.  Could you send me it later?

> 'apm -Z' for standby jumps into standby mode for like.. an instant, then
> comes right back out (while playing mp3)
[snip]
> 'zzz' or 'apm -z' for suspend jumps into suspend mode, and just the same
> way, comes right back out (while playing mp3s again)
> it should be noted that the cpu fan does turn off momentarily for both
> of these events, and the mp3 that is playing stops, then starts up again
> where it left off.
> Even without playing anything through the sound device, it does the same
> thing.

I have more questions and requests :)

When did this problem appear?  Have you put your PC in suspend/standby
state successfully before?

Did you try it on other OS? (Win, Linux, etc.)

How about executing zzz on console (non X)?

Is cli-hack helpful in your case?
  
http://www.freebsd.org/cgi/getmsg.cgi?fetch=56429+60225+/usr/local/www/db/text/1999/freebsd-current/19990815.freebsd-current+raw
  Message-Id: <[EMAIL PROTECTED]>


Could you try following script and send me the output?

#!/bin/sh
iostat -c 3
echo SUSPENDING
zzz
echo RESUMING
iostat -c 3
---

> If i leave the thing on with no activity, while running apmd, it goes
> into suspend or standby (depending on the timers set in the bios) every
> now and again, but jumps back out as soon as it does.
> Also, all the PM timer interrupts are disabled.
> 
> Motherboard is an Abit BH-6

I'm not familiar with Abit BH-6... Could you tell me current
configuration of PM related BIOS setting (and BIOS version if you
know)?

Sorry for too many questions and my poor english :)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: followup to apm problems.

[Mitsuru IWASAKI]

[ CC'ed current again.]

> > I suspect some devices generate interrupt during suspending state,
> > especially PS/2 mouse.  Disabling the device driver or disconnecting
> > the device from PC might solve the problem.  Could you try one by one?
> > 
> > > psm0:  irq 12 on atkbdc0
> 
> > I had the same problem with Logitech Cordless Mouse. It seems the
> > receiver is genetating intr time to time and wake my PC up from
> > suspend.  I reconnect it to COM1 as serial mouse, then the problem was
> > gone.
> 
> I yanked the cord then rebooted, and it seemed to make a little
> difference..
> but it still came back after a while (2-3 mins)

OK.  Probably `slept 00:00:00 - 00:00:40' problem was caused by PS/2
mouse, I think.  Do we need something to do with psm on suspending as
well as resuming?

And it seems there still are other devices which wake your PC up in
2-3 mins time.
Hmmm, anyone has ideas?

> > > ed1:  irq 3 at device 9.0 on pci0
> > 
> > Is your PC connected to network?  Receiving packets might cause
> > resuming...
> 
> Heh, thats hardly acceptable.. I want to use the network too! :)

Ahh, I meant just unplug cable tentatively to confirm.
# and uninstall NIC if possible :)
After the problem analyzed, we just try to fix it in proper place.

> Ill try disabling the other devices at a later date, its getting late

Please, please :)

> > Using apmd, it could be possible something like this;
> > /etc/apmd.conf:
> > apm_event SUSPENDREQ {
> > exec "sync && sync && sync";
> > exec "sleep 1";
> > exec "camcontrol stop [device id]";
> > exec "apm -Z";
> > }
> > 
> > apm_event NORMRESUME {
> > exec "camcontrol start [device id]";
> > exec "/etc/rc.resume";
> > }
> 
> Yep, that works well, except the device that /, /usr, /var, /usr/home is
> mounted on, spins right back up after spinning down.. (which i assume is
> supposed to happen?) is there a way around that?

At least, apm is in /usr/sbin/, apm -z touches /dev/apm and apmd
writes log on /var/log/ via syslog :)
Using `sysctl -w machdep.apm_suspend_delay=30 (or enough time for
spinning down)' and moving `camcontrol stop' to the end of command
list would be success.  Otherwise, please forgive me. :)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Experimental ACPI driver.

[Mitsuru IWASAKI]

Hi, there.

> We wrote experimental ACPI driver for 4.0-CURRENT.

This was just one week work so its functionallity is very very poor :-)
but I think it is good idea to start with this for developping ACPI
driver for FreeBSD because it is enough small to understand it.

If someone already started wriring ACPI devive driver, please let us
know.  We'd like to merge them and would be happy in collaboration
with you.

> If you have question please ask me or [EMAIL PROTECTED] .

BTW, I've just start leaning a week ago, my knowledge is still little
on ACPI :-)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Experimental ACPI driver.

[Mitsuru IWASAKI]

Hi, Mike.
# I'm very happy because of your reply :)

> > > We wrote experimental ACPI driver for 4.0-CURRENT.
> > 
> > This was just one week work so its functionallity is very very poor :-)
> > but I think it is good idea to start with this for developping ACPI
> > driver for FreeBSD because it is enough small to understand it.
> 
> I'm not sure this is the right way to go about it, although I haven't 
> looked at your code yet.  APCI is a big animal, and I think it's going 
> to take a proper design to get it right.

Indeed.  Also I think that this project cannot be achieved easily by
only one/two person's efforts.  I believe having this kind of prototype
makes our discussion easier.  We are going to prepare the materials
for our further discussion.

> The key components would appear to be a full AML parser, an object 
> manager to manage the ACPI namespace, and an AML interpreter to run the 
> AML methods.

Yes, Yes.

> > If someone already started wriring ACPI devive driver, please let us
> > know.  We'd like to merge them and would be happy in collaboration
> > with you.
> 
> Both Doug Rabson and myself have been tinkering with this, and there's 
> someone that's been looking at an AML parser/interpreter in the last 
> couple of weeks.  At this point in time, the parser and object manager 
> are the most vital components.

Now we got new friends :) Mr. Watanabe is going FreeBSDCon
(unfortunately I cannot), you can discuss this matter with him.
I think the time has come to start!

Thank you very much.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ACPI project started in Japan

[Mitsuru IWASAKI]

Just FYI,

We launched ACPI project in Japan today, but the activities haven't
detailed yet in this project.  We'd like to contribute something from
this project to FreeBSD main stream developing some sort of prototype
but don't want to make duplicated efforts anyway. So please let us
know if you are doing something on ACPI.
Suggestions, questions and requests are very appreciated.
Please see
http://www.jp.FreeBSD.org/acpi/
For more info.

Mr. watanabe, on behalf of the project :), made some survey at
FreeBSDCon.  Doug Rabson, Mike smith and Warner Losh are interested in
this area, and already some code was written.  We'd like to keep
consulting and cooperating with them.
For the time being, we will make clean our experimental ACPI device
deriver up, and may implement S5 Soft Off State transition by ACPI.

And, we are going to make this kind of project report in English from
time to time.
# sorry for our poor English ;)

Thanks!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ACPI project progress report - Nov.

[Mitsuru IWASAKI]

Hi, here is the Nov. progress report from ACPI project in Japan.

1. Summary of our activities in this month:
 - setup CVS repository and CVSup collection for developing
   environment (jp-acpi collection on cvsup.jp.FreeBSD.org).
 - improve device driver (S1 and S5 state transition are supportted
   on several machines).
 - gather ASL code and DSDT data (not so many, but still useful to
   design AML interpreter).
 - start AML interpreter developing (now it is in the userland, then
   move it to kernel space later).

2.ACPI CVS repository and CVSup
To CVSup acpi development source tree, please try this configuration.
---
*default host=cvsup.jp.FreeBSD.org
*default base=/usr
*default prefix=/home/cvs
*default release=cvs 
*default delete use-rel-suffix

jp-acpi
#jp-all
---
Other CVSup servers (such as cvsup2.jp.FreeBSD.org) are also available.

3. ACPI device driver progress:
 - detect ACPI BIOS and install the interrupt handler.
 - experimental support S1 (sleeping state 1) and S5 (soft off).
 - have abilities to detect and handle power/sleep button press event.
 - add builtin PTS (prepare to sleep) control method for several
   machines. this is temporary until finish AML interpreter development.
 - set sleeping state via ioctl.

  Yes, now it's possible that shutdown and power machine off by power
button, but only work for the limited number of supported machines.
Difficulty is to get value of \_Sx package and parse/execute \_PTS
method, so our tentative solution is to have builtin PTS functions for
the machines using bogos macros :-)  Stupid? yes I think so too.
  We've started discussing AML interpreter implementation.

4. ASL code and DSDT data collection
  We are gathering them for further design and implementation.
CVSup ACPI source tree, compile ACPI/util/ tools, then 
  % cd ACPI/util/dfr/acpitest/
  % ./acpitest >foo.asl

  % cd ACPI/util/takawata/acpi/
  % ./acpitblrd foo.dsdt.dat
  >^D
  %

and finally send them to [EMAIL PROTECTED]
Submitted data will be stored in ACPI CVS repository.

5. AML interpreter implementation
  We've just started based on Doug Rabson's acpitest program, but
parsing AML and managing objects in the name space are almost
finished.  We're going to make configuration utility first with AML
interpreter in the userland, then move it to kernel space after brush
it out.
Please see
http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/util/acpiconf?cvsroot=freebsd-jp


In the beginning of this project, we thought merging them to
4.0-RELEASE would be very much exciting, but it seems the codes are
still young to merge and 4.0-RELEASE feature freeze is comming soon.
We will try another chance, hopefully we have AML interpreter in
kernel space at that time.

Attached diffs are the latest acpi device driver against -current.

# cd /usr/src
# mkdir sys/i386/acpi
# patch < this_patch

Suggestions, ideas, patches, bug reports, rewriting the codes, offer
of cooperation/volunteers and others are very appreciated.

Thanks!


begin 644 acpi-sys-19991129.diff.gz
M'XL(")N40C@``V%C<&DM94[M5IMF\XE<[H@?[<]0IJD\?#!U)K5!MDKUEMOGGSDGSXL+.W_Z*VLT=>D+8?
MW(?N]30F9:?"P(EIW]B>'[KDTHYMSQY3\CZ&JEOX^A!-W8D]M4.[60]FMD?C
M>N2X]1M_3&N+NNW4_QT<%Z&]<.-H$2Z(?MDR6K_IY+U[:T?VC?OA-*3TQ.C4
M_?":=V[-9H1UCDA((QHNZ:2.#:QQ2"=N%(?N>!&[P+#M3<@BHL3U2.0O0H>R
MFK'KV>$]N?+#>50EMVX\)7[(_O87,4,S]R?NE>O8B*1*[)"2@(9S-X[IA`2A
MOW0G4(BG=@R_*"":S?Q;U[LFCN]-7.P4,338<4[C=^RC65^A+B+^E23+\2<`
MNHABX"FV@5S$:X_])38)83$L\./YL>O0*H"X$9D!0L23CLQ8S)(%HSHSVYW3
MD$F*'*R3`D,J8I&D`*^3!9#W)U%#.*,2U<1W%G-0>5O.W3Y,BP\`(9G;,0U=
M>Q:EXF?SAIA51E)-,,]U@QC]4_.R-=0(E`?#_D>]HW7(R6=HU$AK9)[WAZ35
MZY!VOV<.]9.1V1\:Y%__:AD`_[>_81/7N-YGHGT:##7#(-!#OQAT=<`#B(>M
MGJEK1I7HO79WU-%[9U4":$BO;Y*N?J&;`&;VJS@>P[3>E?1/R84V;)_#9^M$
M[^KF9T;2J6[V<+Q3))$,6D-3;X^ZK2$9C(:#OL'1(6<=W6AW6_J%UJD3(`.&
M)MI'K6<2X[S5[:J&
MJ9LC4R-G_7['8+A@`$,;?M3;FG%(NGV#"6UD:%48Q6PQ`@`-2`R:H7PR,G0F
M.[UG:L/A:&#J_5Z%83KO7X)P@-X6=.\P0?=[C&V04W_X&1&C3-@\5,GEN0;U
M0Q0KDUP+Q6&`!-LF0Z>`PK@@5%/AE_2TLZY^IO7:&K;V$=.E;F@5F#;=0`"=
M#WW9^LS9'#$1X(P!=;RHZ'"5S2O13TFK\U%'\@4PJ(.A"]7IGS)4QJA]+J8@
M71%_%:;TK_BUO[/WD^LYLP78G5T_B"VV34QWE>KWN(\$8,WG]>GQ6GWH.SG5
M\'^S6N8VV!.5BE8SO>7JZ-#73"W@Y7:
MN>U,78_N.X#DIJ!M/K&6]BJULC&BUVBJHJ+F>&*'UP6-<534;3G/D[=L#9S]
ML>L7]856/H>95C>R]P,O"&D1,>-%$4+87=GFE"/]34USV\NI7A\&:V&?N&+5
MZ')PD]8>Z`0GC$2+,6H3G4MUG=`K((M!6,9%:V!=M#Y9AOY_&F$_S3>(!K:"
MA1,S('LR"A2Z-#^!0@V%):SBW_ZBJBL167`ML:VQ$]7*U?
M9NLC][\4:O$O5K6P`/_+`ZB*[P-6]9W$Y,LZF5^A[?LA)Q*V.((*9K$Y`7@B`]SZJ^@GU)_"@UC?W+/&RPLYO6:9+%!+P/G%#NI6LEI
M8GIO(??4"FSGQKZF)*_R4&AW*=.H"!E53N'3BJ50VNBF.^!4"9F#3!80O63$
M/K'\@'I",;!XJ#2!Y8RH:&-EM='UP9R+1E96&^>H8;P-BX?ITFYWM(^P7/X.
MV^5!L[$Z_0Y0&MUR;D3YB$T<`7Z0/*`^(;4JZAEILH%]R):0VA-L@&`&2K+V
M-G1CRJM94=8S+B0>]B%;`G!L>0\A_R2K9X]9X/O
M8K?=!)?];ZQ,I2,;)HMYP!%A*2$(39.@"(NR_FIF7T=8WY`U8X&YUI26"2HO
MP#VGL+DN(@(N]`[WYE$_76Y$/C-;8Y0CA(SJ$/M3#?`JS,LO3<8F:5&83MX4PC0S-++!J80
MMLZH!7$#_KU&<)6,?1_L*VH^!UTUQJR'ZX.M;+(EMX@V(G%]%'A)V2K`2E6)
M\C7>-`*G

Re: ACPI project progress report - Nov.

[Mitsuru IWASAKI]

Hi,

Doug Rabson wrote:
> > Please see
> > http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/util/acpiconf?cvsroot=freebsd-jp
> 
> This sounds very promising. I will check out the code soon and try to give
> feedback. Creating the ACPI namespace is a necessary first step before its
> possible to do full AML interpreting.

Thanks!  I'm now preparing also own memory management subsystem to
avoid memory leakage in kernel space and to utilize VM efficiently.
I believe it should be also one of the important things.

> > In the beginning of this project, we thought merging them to
> > 4.0-RELEASE would be very much exciting, but it seems the codes are
> > still young to merge and 4.0-RELEASE feature freeze is comming soon.
> > We will try another chance, hopefully we have AML interpreter in
> > kernel space at that time.
> 
> I think we should aim to do most of the work in 5.0 after we branch off
> 4.0. Perhaps some of it can be back-ported after it become stable in 5.0.

OK, we'll do best we can do aiming merge into 5.0-CURRENT.

Warner Losh wrote:
> Cool.  This is indeed good news.  Keep up the good reports.
> 
> iwasaki-san to acpi-jp wa domo arigato gozaimasu.

We will!  We shall keep the reports periodically (maybe monthly? of
course depending on our progress).  I think that we, folks in Japan,
learned enough communications won't hurt anything.
# Dou itasimasite :-)

Doug Rabson and Warner Losh, thanks for your valuable advice and words
of encouragement.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

HEADS UP: new pccard.conf scheme, please test!

[Mitsuru IWASAKI]

HI, all.

I've just committed new feature for pccardd, but default pccard
configuration file is still /etc/pccard.conf.sample because I'd like
to see how things go and test them more for about a week.  Test
version of /etc/defaults/pccard.conf, /etc/pccard.conf are available at

http://www.freebsd.org/~iwasaki/pccard/pccard.conf.tar.gz

and, patches against the files under src/etc and src/share are
available at

http://www.freebsd.org/~iwasaki/pccard/pccardd-etc.diff

You might need to copy /etc/defaults/pccard.conf to src/etc/defauts/
for make world until src/etc/defauts/pccard.conf is created.

Please test them and report your problem to [EMAIL PROTECTED]
if anything wrong.

Thanks!

> iwasaki 2000/03/30 08:01:39 PST
> 
>   Modified files:
> usr.sbin/pccard/pccardd cardd.h file.c pccard.conf.5 pccardd.8 
> pccardd.c 
>   Log:
>   - default config file changed from /etc/pccard.conf to
> /etc/defaults/pccard.conf in pccardd. But system default pccardd
> config file is still /etc/pccard.conf.sample specified in /etc/rc.conf
> for the testing this changes.
>   - improved `include' keyword function for error handling.
>   - now that resource pool (io, irq, mem) can be overridden.
>   - pccard config entries is searched following the first match rule if
> there are more than two entries which have the same card identifier.
>   
>   Note that the /etc/defaults/pccard.conf related files is not committed
>   at this time, will come a week later.  I'll prepare the test version
>   of /etc/defaults/pccard.conf, /etc/pccard.conf and other files soon.
>   
>   Reviewed by:imp and nomads in Japan.
>   
>   Revision  ChangesPath
>   1.19  +3 -1  src/usr.sbin/pccard/pccardd/cardd.h
>   1.25  +116 -41   src/usr.sbin/pccard/pccardd/file.c
>   1.13  +18 -4 src/usr.sbin/pccard/pccardd/pccard.conf.5
>   1.18  +10 -4 src/usr.sbin/pccard/pccardd/pccardd.8
>   1.7   +3 -2  src/usr.sbin/pccard/pccardd/pccardd.c
> 
> 
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Patch to allow TSC with APM

[Mitsuru IWASAKI]

Hi,

> I'd like to recommend the following patches.  Adding the option
> "CLK_USE_TSC_ANYWAY" allows my laptop to use the TSC even though it
> is "flakey".  This option should not be set by default.

I saw the same kind of patches and my laptop has this w/o any problems
for long time.
I'd like to commit submitted patch 2 or 3 days later if no objections.

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

SMP + APM = panic -> fixed!

[Mitsuru IWASAKI]

Hi,

We're having this problem for long time (from the old 4.0-CURRENT
days), but Mr. SUMITANI discovered a bug and fixed it.
The problem was that we got worng gdt pointer for the current cpu,
then panic...
The followings is a patch to fix the problem.  Thanks a lot, SUMITANI-san!
Please test this and I'll commit & MFC this if we have no problem with
this fix.
I love to have APM enabled SMP system with 4.1-RELEASE.

Index: bios.c
===
RCS file: /home/ncvs/src/sys/i386/i386/bios.c,v
retrieving revision 1.32
diff -u -r1.32 bios.c
--- bios.c  2000/05/17 19:44:16 1.32
+++ bios.c  2000/06/06 16:47:46
@@ -262,7 +262,7 @@
 union descriptor *p_gdt;
 
 #ifdef SMP
-p_gdt = &gdt[cpuid];
+p_gdt = &gdt[cpuid * NGDT];
 #else
 p_gdt = gdt;
 #endif


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP + APM = panic -> fixed!

[Mitsuru IWASAKI]

> > Please test this and I'll commit & MFC this if we have no problem with
> > this fix.
> 
> I don't have an SMP + APM system around at the moment, but the
> fix does look correct to me, go ahead and commit it.  Thanks for
> tracking this down!

Thank you for reviewing this.  I'm going to comit tomorrow night
(JST), then MFC on early next week if no problems are reported.

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP + APM = panic -> fixed!

[Mitsuru IWASAKI]

Hi,

> On Wed, 7 Jun 2000, Mitsuru IWASAKI wrote:
> 
> > We're having this problem for long time (from the old 4.0-CURRENT
> > days), but Mr. SUMITANI discovered a bug and fixed it.
> > The problem was that we got worng gdt pointer for the current cpu,
> > then panic...
> > The followings is a patch to fix the problem.  Thanks a lot, SUMITANI-san!
> 
>   Yes, this fixes panic and even 'halt -p' works as expected. 'zzz'

OK, I think many people will be happy with poweroff on SMP system, so
I'd like to commit this first.  Then I'll track it down and try to fix later
in order to support suspend/resume SMP system.

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ACPI project progress report

[Mitsuru IWASAKI]

Hi, here is the latest report on our ACPI project's progress.

Current status:
  The aml interpreter development is going on and we've ported it to
kernel simultaneously.  Now that we can build ACPI namespace and
search any named objects from there in kernel space.
  The aml interpreter code can be compiled and executed in both
userland (using I/O simulator) and kernel space so that we can
continue development even we ported the code in kernel.
  Next step would be implementation of the accessing facility for
system memory, ioport and so on, then simple method (eg _PTS with 1 or
5 and _WAK) must be able to executed soon.  This is our goal of
prototype development.

TODO:
 - combine sys/isa/pnpparse.c with interpreter.
 - support S2, S3, S4 (hibernation) sleeping transition.  S4 sleep
   require some hack in boot loader needs help.
 - implement serialization and synchronization mechanism.
 - migrate to Intel ACPICA? (but that's too large to understand.  I'm
   not sure whether this has licencing issue or welcome to import it into
   our repository in terms of licencing policy... ours?  Yes, it's BSD
   Licence. No problem at all :-)
 - and many.

Obtaining source code:
To get ACPI project repository, please try CVSup with;
---
*default host=cvsup.jp.FreeBSD.org
*default base=/usr
*default prefix=/home/cvs
*default release=cvs 
*default delete use-rel-suffix
jp-acpi
---

cvsweb is also available at;
http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/?cvsroot=freebsd-jp>.

usr.sbin/acpi/amldb would be a good toy for you :-)

% ./amldb ../../../util/takawata/acpi/3110CT.dsdt.dat 
Loading ../../../util/takawata/acpi/3110CT.dsdt.dat...done
AML>r _PTS
Method: Arg 1 From 0x280f36ce To 0x280f3775
  Enter argument values (ex. number 1 / string foo). 'q' to quit.
  Arg0 ? n 1
 Running _PTS. 
AML>h
s   Single step
n   Step program
c   Continue program being debugged
q   Quit method execution
t   Show local name space tree and variables
i   Toggle region input prompt
o   Toggle region output prompt
m   Show memory management statistics
r   Run specified method
f   Find named objects from namespace.
h   Show this messsage
AML>


BTW, I (iwasaki) am going to USENIX 6/21 - 23, I'll happy to give a
demonstration on ACPI device driver and AML interpreter debugger if
anybody ask me to do it.

Here's the dmesg output from kernel with AML interpreter on TOSHIBA
PORTEGE 3110CT.  It's not fake :-)
There are 1735 times memory allocation here, but we couldn't find a
lowering of performance because of own memory management system.
95% of memory allocation is covered by pre-allocated memory storage
which is compiled in the interpreter module.

Thanks!

ACPI: Found ACPI BIOS data at 0xc00f0170 (, RSDT@3fe)
acpi0:  on motherboard
acpi0: ADDR RANGE 3fe 1 (mapped 0xc5774000)
acpi0: ADDR RANGE 100b6e00 200 (mapped 0xc5784e00)
acpi0: RSDT have 1 entries
acpi0: RSDT entry0 FACP
acpi0:  FACP found
acpi0:  DSDT found Size=17865 bytes
\\  
  IRQS  Method: Arg 2 From 0xc57783bf To 0xc5778691
  IRQR  Method: Arg 1 From 0xc57781de To 0xc57783b7
  CRSL  Method: Arg 1 From 0xc5778165 To 0xc57781d6
  PRSL  Method: Arg 1 From 0xc57780d3 To 0xc577815d
  STAL  Method: Arg 1 From 0xc577808c To 0xc57780cb
  PSC_  Method: Arg 1 From 0xc5778054 To 0xc5778084
  WPSX  Method: Arg 4 From 0xc5777fd7 To 0xc577804d
  PS3_  Method: Arg 1 From 0xc5777f70 To 0xc5777fcf
  PS0_  Method: Arg 1 From 0xc5777f09 To 0xc5777f68
  DIS_  Method: Arg 1 From 0xc5777e7c To 0xc5777f01
  SRS_  Method: Arg 2 From 0xc5777dde To 0xc5777e74
  PRS_  Method: Arg 1 From 0xc5777d07 To 0xc5777dd6
  CRS_  Method: Arg 1 From 0xc5777c30 To 0xc5777cff
  STA_  Method: Arg 1 From 0xc5777b93 To 0xc5777c28
  SMBR  Method: Arg 5 From 0xc5777b2e To 0xc5777b8b
  TRAP  Method: Arg 1 From 0xc5777b1d To 0xc5777b26
  _WAK  Method: Arg 1 From 0xc5777869 To 0xc5777b16
  _PTS  Method: Arg 1 From 0xc5ba To 0xc5777861
  _GPE  
_L00  Method: Arg 0 From 0xc598 To 0xc5b2
_L1E  Method: Arg 8 From 0xc581 To 0xc591
_L19  Method: Arg 8 From 0xc52f To 0xc57a
_L18  Method: Arg 8 From 0xc577765b To 0xc527
_L0C  Method: Arg 8 From 0xc5777608 To 0xc5777653
_L0B  Method: Arg 8 From 0xc5777188 To 0xc5777600
_L08  Method: Arg 8 From 0xc5777139 To 0xc5777180
  _TZ_  
THRM  Thermalzone
  _TSP  Num:0x708
  _TC2  Num:0x2
  _TC1  Num:0x9
  _CRT  Method: Arg 0 From 0xc5777103 To 0xc5777113
  _PSL  Package:elements 1 
  _PSV  Method: Arg 0 From 0xc57770da To 0xc57770ea
  _AL1  Package:elements 1 
  _AL0  Package:elements 1 
  _AC1  Method: Arg 0 From 0xc577709f To 0xc57770af
  _AC0  Method: Arg 0 From 0xc5777088 To 0xc5777098
  _TMP  Method: Arg 0 From 0xc5777023 To 0xc5777081
FAN_  Device
  _PR0  Package:elements 1 
  _HID  Num:0xb0cd041
PFAN  PowerResource:Level 0 Order 0

Re: ACPI project progress report

[Mitsuru IWASAKI]

Hi,

> "Daniel C. Sobral" wrote:
> > 
> > Mitsuru IWASAKI wrote:
> > >
> > >  - support S2, S3, S4 (hibernation) sleeping transition.  S4 sleep
> > >require some hack in boot loader needs help.
> > 
> > I thought hibernation was entirely controlled by kernel? What do you
>^^
> Err, BIOS.
> 
> > need?

Yes, we need to consider both.  In ACPI spec. 1.0b 9.1.4 S4 Sleeping
State, this is described that S4 supports two entry mechanisms: OS
initiated and BIOS initiated.

From: Intel, Microsoft, Toshiba
Subject: Advanced Configuration and Power Interface Specification 1.0b
Date: Tue, 2 Feb 1999 07:55:24 +0900
> In the OS-initiated S4 sleeping state, the OS is responsible for
> saving all system context. Before entering the S4 state, the OS will
> save context of all memory. Upon awakening, the OS will then restore
> the system context.  When the OS re-enumerates buses coming out of the
> S4 sleeping state, it will discover any devices that have come and
> gone, and configure devices as they are turned on.

I think OS-initiated S4 (hibernation) in FreeBSD has enough advantages
because we can do `Save-to-Disk' anywhere even on non-laptop machines
which BIOS doesn't support hibernation.
FreeBSD supports crash dump facility here, so I'm expecting that
`Save-to-Disk' by kernel would not be so difficult. We might need
dedicated swap partition for OS-initiated S4 because used swap areas
need to be protected for the system oprerations after awakening.
The boot loader is the best place for restoring the system context in
FreeBSD I think.

Unfortunately I don't have enough knowledge on crash dump and boot
loader to implement OS-initiated S4 transition (actually, this is not
related with ACPI at all).
I love to see someone say `hey!  I'll take this one!' :-)

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI project progress report

[Mitsuru IWASAKI]

Hi,

From: Bjoern Fischer <[EMAIL PROTECTED]>
Subject: Re: ACPI project progress report
Date: Mon, 19 Jun 2000 07:01:44 +0200
Message-ID: <[EMAIL PROTECTED]>

> Just a moment. You talk about doing a `Save-to-Disk' (incl. system halt),
> turning power off, maybe adding some hardware or moving the machine
> to another location, then switching on again, restoring the system context,
> and the machine will proceed as if nothing had happened, do you?

Yes, exactly.  My rough idea is like this;
 - do preparation for sleeping state transition for each devices and 
   _PTS (prepare to sleep) control method.
 - stop all of processes, other sub-system (eg filesystem, memory...)
   and write contents of memory to dedicated swap partition for
   "Save-to-Disk" and save system context.
 - turning power off by manipulating ACPI registers (or just halt the
   system and user will turning power off).
 - upon turning power on, BIOS built ACPI tables again if hardware
   configuration changed during sleeping. Any important device (eg
   disk controller) configuration changes will cause the restoring 
   system context to fail.
 - after POST, BIOS passes control to the boot loader in normal case.
 - load will check whether S4 transition occurred, then restore system
   context and memory from swap partition.
 - do _WAK (wakeup) control method, wakeup processes for each devices
   and re-enable them.

Maybe I'm wrong because of lack of my understanding on crush dump and
loader.  Please help us :-)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI project progress report

[Mitsuru IWASAKI]

imp> In message <[EMAIL PROTECTED]> Mitsuru IWASAKI writes:
imp> : Hi, here is the latest report on our ACPI project's progress.
imp> 
imp> As I told you on the Train in Tokyo:  Cool!  Way Cool!  ACPI should
imp> enable us to properly put the chipsets in laptops to sleep and then
imp> wake them up again.  Right now pccard insert/removal can be missed
imp> when you put a laptop to sleep...

Yes, many of today's laptop BIOS are expecting that OS shouldn handle
this kind of things by executing the AML.  Good news, recently I wrote
accessing ioport stuff (roughly :-) and experimental code for
executing _PTS & _WAK method in kernel space.  On P2B based system, it
seems working fine :-)
Next step is implement accessing other bus spaces, physical memory
will be the target (and PCI config, SMBus...).  Can anybody help us on this?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev and APM. Not working together?

[Mitsuru IWASAKI]

> I think I found the problem, and being able to work around it. 
> But, I don't know how to realy fix it.

I noticed this when I saw your last message :-)

>  2)Randomdev Loaded: Probe & attach will happen in the order -
>(1)acpi0, (2)apm0, (3)nxp0 .NG
> 
>Because acpi0 access the BIOS first, APM support in BIOS seems to
>get turned off. :-(

Yes, current acpi driver is doing this for testing purpose in
attach().  We need to handle this matter soon so that we could have
both of apm and acpi in our kernel.  Could you disable this line in
sys/i386/acpi/acpi.c:acpi_attach() and enable acpi later with acpiconf -e ?

acpi_enable_disable(sc, 1);

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

CFR: pccard.conf entries from PAO (130 entries!)

[Mitsuru IWASAKI]

Hi,

We, PAO folks in Japan, have prepared the patch for
etc/defaults/pccard.conf CURRENT (rev. 1.121) merging more that one
hundred of PCCard entries from PAO3.  We'd be happy if we could use
various cards on the installation.

http://people.freebsd.org/~iwasaki/pccard/pccard.conf-MFPAO

We'd like you to test them and see if there are any problems on the
patch.  Of course, You could test on STABLE system bringing
etc/defaults/pccard.conf from CURRENT and replace with it.  Because of
too many entries to be added, please report your problems only to
[EMAIL PROTECTED] and [EMAIL PROTECTED]

 - We are not sure that the card would be supported which has cardio line
   and just replaced with iosize line or other reasons. Those are marked as
   # XXX NOT SURE SUPPORTED
   and disabled.  If you have this kind of cards, please enable the entry
   and test it.

IBM Portable 4X Speed CD-ROM Drive CD-400
IBM CD-20XSeries(IDE PC Card)
CitiDISK & Addonics PocketZIP
SONY Memory Stick PC Card Adaptor
Xircom CompactCard Ethernet 10 (CFE-10)
TDK Multifunctioon Card (as Modem)
Toshiba Modem/LAN card IPC5001B
Toshiba 10/100 Ethernet PC Card IPC5008A

 - We are sure that some kind of cards wouldn't be supported and marked as
   # XXX NOT SUPPORTED YET
   and disabled because of driver porting issue.  But we could be wrong, 
   so please check them.
   cnw, fe, gp, hss, joy, ncv, nsp, opl, scc, stg and wlp drivers

 - Please test other kind of generic cards which use ata, ed, ep, sio, 
   sn and xe drivers if you have.  We're not sure whether card would
   work correctly if the entry has ether line.

We are going to MFC this patch with following schedule.  We would very
much appreciate your cooperations.

7/13nomads, current ML review
7/16CURRENT commit
7/19MFC
7/20RELENG_4 freeze

Thanks!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

multicast + PCCard NIC = kernel panic? (was Re: small bug inpcic.c)

[Mitsuru IWASAKI]

[CC'ed -current and -mobile]

> BTW, there is one more problem during detach the pccard nic.  When I
> detach my pccard nic, my kernel is panic.  I tried this with Melco
> Airconnect WLI-PCM-L11 and COREGA FastEther PCC-TX, and it occured
> with either card.
> I made a quick hack to avoid this problem.  I don't know if this fix
> is correct.
> I sent it to -current, -net and -mobile.  But, my message seems
> disappeared.  I don't know why.

This is a critical problem especially for IPv6 laptop users right?
The patch seems good enough for emergency workaround, If we don't have
enough time for the regular reviewing process before 4.1R out,
however, you are the right person to commit the patch since I know
that you've tested enough it for days :-)

> Index: sys/net/rtsock.c
> diff -u sys/net/rtsock.c.orig sys/net/rtsock.c
> --- sys/net/rtsock.c.orig Sun Feb 13 12:31:56 2000
> +++ sys/net/rtsock.c  Sat Jul 22 08:53:16 2000
> @@ -828,7 +828,10 @@
>  
>   bzero((caddr_t)&info, sizeof(info));
>   ifaaddr = ifma->ifma_addr;
> - ifpaddr = ifp->if_addrhead.tqh_first->ifa_addr;
> + if (ifp && ifp->if_addrhead.tqh_first)
> + ifpaddr = ifp->if_addrhead.tqh_first->ifa_addr;
> + else
> + ifpaddr = NULL;
>   /*
>* If a link-layer address is present, present it as a ``gateway''
>* (similarly to how ARP entries, e.g., are presented).



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

CFR: apm debug print cleanup and display on/off improvement

[Mitsuru IWASAKI]

Hi,

I worked apm debug print cleanup to avoid re-build kernel with
APM_DEUG (this kernel option seems unavailable for now) for obtaining
debug messages on apm.

http://people.freebsd.org/~iwasaki/apm/apm-debug.diff

The debug flag can be controlled by sysctl interface and loader
setting "debug.apm_debug=1" with this.  This patch also includes some
enhancements from linux on display control by apm -d.  I'm expecting
that we can see some improvements on some laptops where apm -d doesn't
work correctly so far.

I'll commit this comming week end if no objections.

Thanks

# Yes, I just want to finish apm related work before we concentrate
# on ACPI stuff :-)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI project progress report (final?)

[Mitsuru IWASAKI]

> In message <[EMAIL PROTECTED]> Mitsuru IWASAKI writes:
> : Hi, here is the latest (and maybe final?) report on our ACPI project's
> : progress.
> : 
> : We are ready now to merge our work on ACPI into main source tree!
> 
> Bravo!  Wonderful work!

Thanks.  I think we need to implement power management features by ACPI
replacing APM at least before BIOS w/o APM become majority...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ACPI project progress report (final?)

[Mitsuru IWASAKI]

Hi, here is the latest (and maybe final?) report on our ACPI project's
progress.

We are ready now to merge our work on ACPI into main source tree!

Our prototype development is going to finish.  AML interpreter
development is almost completed, region access facility (SystemMemory,
SystemIO and PCI_Config) is almost completed, device major number is
officialy assigned, source code cleanup is finished.  Also some of us
are committers of freefall to work on it.
Of cause we still have a lot of things should be done to complete this
project, but we think it's good enough as a prototype and want to work
together with you, many people who are interested in ACPI
implementation.  Folks, there are a lot of exciting and cool things,
like Processor and Device Power State Control, Thermal Management,
Replacement PnP system, OS initiated hibernation and many :-)
I think now is the time to start open and development, not only in Japan,
for FreeBSD ACPI support!

At USENIX 2000, I luckily had a discussion with Mike Smith, John Baldwin, 
Doug Rabson, Peter Wemm and some people.  I very much appreciate very useful
suggestions from them (especially Mike, thanks a lot).

Once merge happened, we will stop maintaining our ACPI CVS repository
except for DSDT/ASL data collection.  Discussions in Japanese
mailing-list will be continued but it will be just for some people who
want to get information in Japanese.  Most of Japanese ACPI developers
will work based on CURRENT.

Recently we imported CURRENT sys tree as of 2000/8/4 into our ACPI
repository and prepared diffs against CURREN at;
http://people.FreeBSD.org/~iwasaki/acpi/acpi-sys-2804.diff.gz

and snapshot of userland tools is available at;
http://people.FreeBSD.org/~iwasaki/acpi/acpi-usr.sbin-2804.tar.gz

Please get and taste them, we are going to merge them into CURRENT
sometime around end of this month.

How to use:
 # cd /usr/src
 # gzip -dc < /somewhere/acpi-sys-2804.diff.gz | patch
 # tar xzpvf /somewhere/acpi-usr.sbin-2804.tar.gz
 # cp sys/sys/acpi.h /usr/include/sys/
 # cd /usr/src/usr.sbin/acpi
 # make obj depend all install
 # mknod /dev/acpi c 152 0
 # cd /usr/src/sys/i386/conf
 # echo 'device acpi' >> MYKERNEL
 # echo 'options ACPI_DEBUG' >> MYKERNEL
 # echo 'options AML_DEBUG' >> MYKERNEL
 # config -r MYKERNEL
 # cd ../../compile/MYKERNEL
 # make depend; make all install
 # shutdown -r now
 (reboot...)
 # acpiconf -s 5
 (sleeping state 5, shutdown & power off)
 or press Power button to shutdown if supported.

Directory tour:
 - kernel space side
src/sys/i386/i386/machdep.c
getmemsize() try to get ACPI related memory range from SMAP.

src/sys/i386/i386/bios.c
bios32_init() try to find RSD PTR signature (probe ACPI BIOS).

src/sys/sys/acpi.h
The acpi related structs and function declaration.  This need
to be installed in /usr/include/sys/ to compile acpi userland
tools.

src/sys/dev/acpi/acpi.c
acpi device driver.

src/sys/dev/acpi/aml/
AML interpreter code.
aml_parse.c was originally developed based on dfr's AML
disassembler program.  These files can be compiled and work in
both of kernel/userland side.

src/sys/i386/conf/NOTES
sample configration and possible options for acpi driver.

src/sys/i386/i386/acpi_machdep.c
i386 dependent implementations to be added here.

src/sys/i386/include/acpica_osd.h
ACPICA interface implementation (part of OS-dependent code).

src/sys/conf/{files|options}
src/sys/conf/files.i386
file and option configuration for ACPI.

 - userland side
src/usr.sbin/acpi/acpiconf
enabler/disabler and sleeping state transition ioctl
requests generator.

src/usr.sbin/acpi/acpidump
ASL and AML dump tool (modified dfr's tool a bit).
src/usr.sbin/acpi/amldb
The debugger for AML interpreter.

 - device file
/dev/acpi
major/minor should be 152, 0 (officially assigned).
You need to create this file like
# mknod /dev/acpi c 152 0
to use userland tools.

ACPI device driver:
This driver has
 - ACPI memory range management
 - The pmap stuff for ACPI
 - ACPI registers manipulation stuff
 - ACPI tables handlers *
 - System sleeping state stuff
 - AML interpreter callers for special control methods; _PTS and _WAK *
 - Event handler (power/sleep button for now)
 - Interrupt handler (for general purpose events maybe incomplete)
 - Event enabler (PM1 only, GPE not yet)
 - Device file manipulation stuff
 - The new-bus dependent code

*: acpi_handle_dsdt() and acpi_execute_{pts|wak}() invoke AML interpreter.

AML interpreter source files:
 - aml_amlmem.c memory manager instance for AML 

Re: ACPI project progress report (final?)

[Mitsuru IWASAKI]

> >Folks, there are a lot of exciting and cool things, like Processor
> >and Device Power State Control, Thermal Management, Replacement
> >PnP system, OS initiated hibernation and many :-)  I think now is
> >the time to start open and development, not only in Japan, for
> >FreeBSD ACPI support!
> 
> This all sounds very useful!  Glad to see it's merging into the
> current branch!

Thanks!  I know that we need to have a lot of developers to implement
these things :-)
# We are a very small team in Japan and capabilities is also limited...

Now we got very fundamental facility of ACPI here, I hope that
many people will have fun hacking them and be involved in the projects.

Thanks.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI project progress report (final?)

[Mitsuru IWASAKI]

> > It is related with quite wide areas, not only for power management.
> > # I'm interested in power management part personally for the first step
> > # though.
> 
> Do I understand correctly that things like monitoring cooling fans etc is
> also possible? I guess the people running (lots of) servers will be
> interested in those features too.

Yes, of course :-)  ACPI covers the thermal management also.
I could imagine that there are quite big needs in this area for server computing.

I think this is what you are interested in, from ACPI 1.0b spec. contents;
12. THERMAL MANAGEMENT
12.1 Thermal Control
12.1.1 Active, Passive, and Critical Policies
12.1.2 Dynamically Changing Cooling Temperatures
12.1.3 Hardware Thermal Events
12.1.4 Active Cooling Strength
12.1.5 Passive Cooling Equation
12.1.6 Critical Shutdown

You can get ACPI spec. documents from
http://www.teleport.com/~acpi/spec.htm

# I haven't checked ACPI spec 2.0 yet though :-)

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI project progress report (final?)

[Mitsuru IWASAKI]

> I'm not quite sure what it does, but it seems to work fine here on my
> ASUS CUSL2, at least the shutdown part.

Thank you for your report.  It would be helpful to check
http://www.teleport.com/~acpi/whatis1.htm
and it's links.

It is related with quite wide areas, not only for power management.
# I'm interested in power management part personally for the first step
# though.

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

panic on current ACPI

[Mitsuru IWASAKI]

Hi,  I've noticed that the recent CURRENT got panic on some machines
if we have `device acpica' in kernel config.


ACPI debug layer 0x0  debug level 0x0
Copyright (c) 1992-2001 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #8: Sat Sep  1 20:02:07 JST 2001
root@tp1620:/usr/obj/usr/CURRENT/src/sys/TP1620
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 597407237 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (597.41-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x686  Stepping = 6
  
Features=0x383f9ff
real memory  = 402587648 (393152K bytes)
avail memory = 385839104 (376796K bytes)
Preloaded elf kernel "kernel" at 0xc05a5000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc05a509c.
Preloaded elf module "acpi.ko" at 0xc05a50ec.
can't re-use a leaf (acpi_debug_layer)!
can't re-use a leaf (acpi_debug_level)!
can't re-use a leaf (acpi_timecounter)!
can't re-use a leaf (acpi_timer_freq)!
can't re-use a leaf (acpi_wakeup)!
Warning: module nexus/acpi already exists
Warning: module acpi/acpi_acad already exists
Warning: module acpi/acpi_button already exists
Warning: module acpi/acpi_cmbat already exists
Warning: module acpi/acpi_cpu already exists
Warning: module acpi/acpi_ec already exists
Warning: module acpi/acpi_lid already exists
Warning: module acpi/acpi_pcib already exists
Warning: module acpi/acpi_sysresource already exists
Warning: module acpi/acpi_tz already exists
Warning: module acpi/acpi_timer already exists
Warning: module pci/acpi_timer_pci already exists
Pentium Pro MTRR support enabled
WARNING: Driver mistake: destroy_dev on 154/0
Using $PIR table, 11 entries at 0xc00fdee0
acpi0:  on motherboard
acpi0: power button is handled as a fixed feature programming model.
Timecounter "ACPI"  frequency 3579545 Hz
acpi_timer1: couldn't allocate I/O resource (port 0x1008)
acpi_timer1 port 0x1008-0x100b on acpi0
acpi_cpu0:  on acpi0
acpi_tz0:  on acpi0
acpi_lid0:  on acpi0
acpi_button0:  on acpi0
acpi_pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on acpi_pcib0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
pci1:  at 0.0 (no driver attached)
isab0:  at device 7.0 on pci0
isa0:  on isab0
atapci0:  port 0x1800-0x180f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x28
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc058ed3c
stack pointer   = 0x10:0xc05c6be0
frame pointer   = 0x10:0xc05c6be0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
kernel: type 12 trap, code=0
Stopped at  acpi_timer_get_timecount+0x08:  movl0x28(%eax),%edx


I think that this is because acpi_timer device is identified twice,
so I've just made a quick fix for this so that acpi_timer_identify()
is called only once.

I hope more proper fixes would be made...

Thanks

Index: acpi_timer.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_timer.c,v
retrieving revision 1.10
diff -u -r1.10 acpi_timer.c
--- acpi_timer.c5 Aug 2001 23:20:32 -   1.10
+++ acpi_timer.c1 Sep 2001 12:04:14 -
@@ -55,7 +55,7 @@
 #define _COMPONENT ACPI_SYSTEM
 MODULE_NAME("TIMER")
 
-static device_tacpi_timer_dev;
+static device_tacpi_timer_dev = NULL;
 struct resource*acpi_timer_reg;
 #define TIMER_READ bus_space_read_4(rman_get_bustag(acpi_timer_reg),   \
 rman_get_bushandle(acpi_timer_reg),\
@@ -122,6 +122,9 @@
return_VOID;
 
 if (AcpiGbl_FADT == NULL)
+   return_VOID;
+
+if (acpi_timer_dev != NULL)
return_VOID;
 
 if ((dev = BUS_ADD_CHILD(parent, 0, "acpi_timer", 0)) == NULL) {


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: panic in EcWaitEventIntr?(Re: HEADS UP: ACPI CHANGES AFFECTINGMOST -CURRENT USERS)

[Mitsuru IWASAKI]

> Hi.  My MPC-206 made panic with -current GENERIC kernel.
> It can boot normaly with 'unset acpi_load'.
> 'dmesg' results as follows:

Hi, This problem is reported already. Pls try to find a quick fix in
acpi-jp ML archive;
[acpi-jp 1227] Fix? acpica-unix-20010816

Thanks

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: newer buildkernel failure

[Mitsuru IWASAKI]

Hi,

> The patch committed just 20 mins ago to fix the breakage causes this 
> now, unless I caught it in the middle of a commit.
>  
> 
> perl @/kern/makeobjops.pl -h @/dev/pci/pcib_if.m
> perl @/kern/makeobjops.pl -h @/isa/isa_if.m
> make -f /usr/src/sys/modules/acpi/../../i386/acpica/Makefile  
> MAKESRCPATH=/usr/src/sys/modules/acpi/../../i386/acpica
> cc -nostdinc -O -pipe -march=k6 -march=k6   
 ^
Because of -nostdinc option, I think.  Does following patch
solve the problem?


Index: Makefile
===
RCS file: /home/ncvs/src/sys/i386/acpica/Makefile,v
retrieving revision 1.1
diff -u -r1.1 Makefile
--- Makefile20 Jul 2001 06:07:31 -  1.1
+++ Makefile2 Sep 2001 07:55:41 -
@@ -9,6 +9,7 @@
 MAKESRCPATH= ${.CURDIR}
 CLEANFILES= acpi_wakecode.h acpi_wakecode.bin acpi_wakecode.o
 .endif
+CFLAGS+=   -I.
 
 all: acpi_wakecode.h
 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: [acpi-jp 1246] ACPI and PS/2 mouse problem

[Mitsuru IWASAKI]

Thanks Yokota-san for tracking down the problem.

> As reported in this list by several people, you may be seeing that
> your PS/2 mouse is not detected after the recent ACPI update.
> 
> This seems to be caused by ACPI in some BIOS assigns IRQ 12 (mouse
> interrupt) to both the PS/2 mouse device node and the system reserved
> resource node.

And if such a problem was found, please send ACPI data with the
report.  This is very useful info. for our debugging.
To get ACPI data, 
 # acpidump -o foo.dsdt > foo.asl
and send both files to acpi-jp@.  See also acpidump(8).

> To see if this is to be your case, put the following line in
> /boot/device.hints and reboot.
> 
> debug.acpi.disable="sysresource"

I personally, don't have enough time to hack the code for now (sorry),
but I think that newly added `placeholders' code causes the problem
for my first impression.

for (i = 0; i < 100; i++) {
rid = i;
res = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, 0, ~0, 1, 0);
rid = i;
res = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, 0, ~0, 1, 0);
rid = i;
res = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, 0);
}

Mike, do you have any idea on this?

Anyway, Yokota-san thank you very much for finding a workaround.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI kills my current-box frequently.

[Mitsuru IWASAKI]

Hi, NAKAJI-san.  Thank you for reporting.

> Just after rebooting with this kernel and installworld, this host reboots
> frequently, about every 10 minutes. /var/log/messages shows that

Could you describe your hardware?  I'd like see boot -v dmesg and ACPI
data.  Please send them to acpi-jp ML.
Also could you try adjust loader variable `debug.acpi.disable' and
see if which component is causing the problem?
Possible values to debug.acpi.disable are;
bus, children, button, cpu, ec, lid, pci, sysresource, thermal and timer.
You can specify them in loader, like;
ok set debug.acpi.disable="cpu ec lid pci sysresource thermal timer"
See also acpi(4).

Thanks

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: [acpi-jp 1255] Re: ACPI and PS/2 mouse problem

[Mitsuru IWASAKI]

Hi,

> I have the same laptop but a different problem, with today kernel. The
> following is copied by hand, no serial console at home:
> wait:
> 
> panic: free: address 0xcbf5e5fe
> 
> db> trace
> panic(...) at panic+0xb6
> free(...) at free+0x32
> AcpiOsFree(...) at AcpiOsFree+0x11
> AcpiExCopyStringToString(...) at AcpiExCopyStringToString+0x4d

Yes, this is already analyzed in
http://home.jp.FreeBSD.org/cgi-bin/showmail/acpi-jp/1239

Try following patch.  This fix will be appear in next Intel ACPICA
snapshot release.

Index: dsobject.c
===
RCS file: /home/ncvs/src/sys/contrib/dev/acpica/dsobject.c,v
retrieving revision 1.1.1.9
diff -u -r1.1.1.9 dsobject.c
--- dsobject.c  26 Aug 2001 22:28:16 -  1.1.1.9
+++ dsobject.c  3 Sep 2001 11:45:49 -
@@ -558,6 +558,7 @@
 break;
 }
 
+ObjDesc->Common.Flags |= AOPOBJ_STATIC_POINTER;
 return (AE_OK);
 }
 

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: [acpi-jp 1258] ACPI Data for a Dell Inspiron 8000 Laptop

[Mitsuru IWASAKI]

Hi, thanks for your report.  I'll add submitted ACPI data to our collection.

>   Find attached some data to help out with getting ACPI running smoothly.
> Many features work with this laptop but the most annoying complaint is
> the lack of console display being restored after a suspend/resume.

Are you using APM suspend/resume on ACPI enabled system?  I know that
some machines can support both at the same time, but many machines cannnot.
Please try to use acpiconf(8) under ACPI instead of apm(8)/zzz(8), then
report the problems to acpi-jp ML if exists.

Thanks!

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: How can I turn off acpi 100%?

[Mitsuru IWASAKI]

Hi,

> was comming.  Mistake.  It comes up fine, I think because all I can see are:
> 
> acpi_cmbat0: bif size changed 0 
> 
> at what looks like several per second.  In single user I am getting:
> 
> acpi-ec0: evaluation of CPE query method _Q3F failed - AE_NOT_FOUND

Hmm, I think these two problems are the same; i.e. Embedded Controller problem.
Could you get ACPI data from your machine, like
 # acpidump -o Compaq_1700.dsdt > Compaq_1700.asl
and send them (plus boot -v dmesg) to [EMAIL PROTECTED] ?

> How can I turn all this off?  Can I send any info that might help someone else?

It's very easy to disable ACPI, but I think we had better to improve our
ACPI implementation :-)
Because newer Intel-based machines (not only Laptops) have become
strongly depending on ACPI.

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ThinkPad, ACPI, and PS/2 mouse

[Mitsuru IWASAKI]

Hi, yokota-san thank you very much.

> It now appears that some IBM ThinkPad models assign a distinct PnP ID
> to the PS/2 mouse port.
> 
> If you have ThinkPad and its pointing device is not recognized when
> ACPI is loaded in the latest -current system, please do the following
> 
> 1. Disable ACPI and boot
>   unset acpi_load
>   boot -v
> 2. Send the entire dmesg output to me. Don't forget to tell me
>the model name of your ThinkPad too.
> 
> ThinkPad models currently known to have this behavior:
> 
> model PnP ID for the PS/2 mouse port
> 
> ThinkPad 570E IBM3780

I also have a ThinkPad i1620 (PS/2 mouse PnP ID = 0x80374d24) here and
now that the mouse is recognized correctly with ACPI module by your
last commit.

Thanks again

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ThinkPad, ACPI, and PS/2 mouse

[Mitsuru IWASAKI]

Hi, I've just noticed strange behavior of psm probing (w/ and w/o acpi).

> > It now appears that some IBM ThinkPad models assign a distinct PnP ID
> > to the PS/2 mouse port.
> > 
> > If you have ThinkPad and its pointing device is not recognized when
> > ACPI is loaded in the latest -current system, please do the following
> > 
> > 1. Disable ACPI and boot
> > unset acpi_load
> > boot -v
> > 2. Send the entire dmesg output to me. Don't forget to tell me
> >the model name of your ThinkPad too.
> > 
> > ThinkPad models currently known to have this behavior:
> > 
> > model PnP ID for the PS/2 mouse port
> > 
> > ThinkPad 570E IBM3780
> 
> I also have a ThinkPad i1620 (PS/2 mouse PnP ID = 0x80374d24) here and
> now that the mouse is recognized correctly with ACPI module by your
> last commit.

This is not a ThinkPad, but FIVA 206VL (PS/2 mouse PnP ID = 0x130fd041;
normal one), the psm is no longer recognized if USB is not compiled (or
USB module is not loaded at loader).

Here is difference between dmesgs of kernel w/o and w/ usb module.

--- dmesg-nousb Mon Sep 17 01:24:17 2001
+++ dmesg-usb   Mon Sep 17 01:26:47 2001
@@ -3,7 +3,7 @@
The Regents of the University of California. All rights reserved.
 FreeBSD 5.0-CURRENT #52: Mon Sep 17 01:16:21 JST 2001
 root@fivavl:/usr/obj/usr/CURRENT/src/sys/FIVA
-Calibrating clock(s) ... TSC clock: 597277464 Hz, i8254 clock: 1193158 Hz
+Calibrating clock(s) ... TSC clock: 597277748 Hz, i8254 clock: 1193162 Hz
 CLK_USE_I8254_CALIBRATION not specified - using default frequency
 Timecounter "i8254"  frequency 1193182 Hz
 CLK_USE_TSC_CALIBRATION not specified - using old calibration method
@@ -16,16 +16,17 @@
 real memory  = 251592704 (245696K bytes)
 Physical memory chunk(s):
 0x1000 - 0x0009afff, 630784 bytes (154 pages)
-0x0049f000 - 0x0efe7fff, 246714368 bytes (60233 pages)
-avail memory = 240271360 (234640K bytes)
+0x004be000 - 0x0efe7fff, 246587392 bytes (60202 pages)
+avail memory = 240144384 (234516K bytes)
 bios32: Found BIOS32 Service Directory header at 0xc00f82a0
 bios32: Entry = 0xfd770 (c00fd770)  Rev = 0  Len = 1
 pcibios: PCI BIOS entry at 0xfd770+0x11e
 pnpbios: Found PnP BIOS data at 0xc00f82f0
 pnpbios: Entry = f:a965  Rev = 1.0
 Other BIOS signatures found:
-Preloaded elf kernel "/boot/kernel/kernel" at 0xc0478000.
-Preloaded elf module "/boot/kernel/logo_saver.ko" at 0xc04780b4.
+Preloaded elf kernel "/boot/kernel/kernel" at 0xc0497000.
+Preloaded elf module "/boot/kernel/logo_saver.ko" at 0xc04970b4.
+Preloaded elf module "/boot/kernel/usb.ko" at 0xc0497164.
 null: 
 mem: 
 random: 
@@ -117,11 +118,11 @@
 pcm0: ac97 codec id 0x41445348 (Analog Devices AD1881A)
 pcm0: ac97 codec features headphone, 6 bit master volume, Analog Devices Phat Stereo
 pcm0: ac97 primary codec extended features variable rate PCM
-pcm: setmap 50e000, 1000; 0xc15fa000 -> 50e000
-pcm: setmap 4f1000, 1000; 0xc15fd000 -> 4f1000
-pcm: setmap 4f3000, 1000; 0xc15ff000 -> 4f3000
-pcm: setmap 4d5000, 1000; 0xc1601000 -> 4d5000
-pcm: setmap 4d7000, 1000; 0xc1603000 -> 4d7000
+pcm: setmap 514000, 1000; 0xc160 -> 514000
+pcm: setmap 4f7000, 1000; 0xc1603000 -> 4f7000
+pcm: setmap 4f9000, 1000; 0xc1605000 -> 4f9000
+pcm: setmap 51b000, 1000; 0xc1607000 -> 51b000
+pcm: setmap 51d000, 1000; 0xc1609000 -> 51d000
 isab0:  at device 7.0 on pci0
 isa0:  on isab0
 pci0:  at device 9.0 (no driver attached)
@@ -285,7 +286,13 @@
 ata1: iobase=0x0170 altiobase=0x0376 bmaddr=0x1808
 ata1: at 0x170 irq 15 on atapci0
 pci0:  at device 17.0 (no driver attached)
-pci0:  at device 20.0 (no driver attached)
+ohci0:  mem 0xd-0xd0fff irq 11 at 
+device 20.0 on pci0
+usb0: OHCI version 1.0, legacy support
+usb0: SMM does not respond, resetting
+usb0:  on ohci0
+usb0: USB revision 1.0
+uhub0: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
+uhub0: 2 ports with 2 removable, self powered
 ex_isa_identify()
 ata-: ata0 already exists, using ata2 instead
 ata-: ata1 already exists, using ata3 instead
@@ -370,7 +377,10 @@
 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d
 atkbd1: unable to allocate IRQ
 psm0: current command byte:0047
-psm0: the aux port is not functioning (-1).
+psm0:  irq 12 on atkbdc0
+psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons
+psm0: config:, flags:, packet size:3
+psm0: syncmask:c0, syncbits:00
 bt0 failed to probe on isa0
 cs0 failed to probe at port 0x300 on isa0
 ed0 failed to probe at port 0x280-0x29f iomem 0xd8000 irq 10 on isa0
@@ -430,10 +440,8 @@
 unknown:  failed to probe at port 0x61 on isa0
 unknown:  can't assign resources
 unknown:  at iomem 0xd8000-0xdbfff on isa0
-psmcpnp0:  at irq 12 on isa0
-atkbd1: unable to allocate IRQ
-psm0: current command byte:0047
-psm0: the aux port is not functioning (-1).
+unknown:  can't assign resources
+unknown:  at irq 12 on isa0
 fdc1: cannot reserve I/O port range (1 ports)
 unknown: 

Re: ACPI, PS/2 and USB (was: Re: ThinkPad, ACPI, and PS/2 mouse)

[Mitsuru IWASAKI]

> >This is not a ThinkPad, but FIVA 206VL (PS/2 mouse PnP ID = 0x130fd041;
> >normal one), the psm is no longer recognized if USB is not compiled (or
> >USB module is not loaded at loader).
> 
> I have never heard of this type of error before!

Me too!  I was surprised when I noticed this.

> I cannot think of a reason why the presence or absence of the usb
> module affects the behavior of the motherboard keyboard
> controller...
> 
> I must say this is the most arcane error.

Yes, very odd.  But I think I was lucky to find a workaround...

> Ok, this is strictly the psm and usb modules' problem, then.
> 
> Do you remember when your PS/2 mouse was detected correctly without
> the usb module?

I'm not sure, but I think I used compile USB stuff in my kernel all
the time.  Then I noticed this strange behavior when I tried to remove
USB stuff from kernel config.

BTW, I've found that this appear on 4-STABLE too.  I attached dmesg diffs.

And I heard that some Acer Labs Inc. PCI South Bridge chips has
support for integrated controllers including USB and PS/2.
Perhaps Ali specific problem?
# If so, is anyone already working on this?
The following is pciconf -lv output on this laptop (FIVA 206VL).

Thanks

hostb0@pci0:0:0:class=0x06 card=0x02951279 chip=0x03951279 rev=0x00 
hdr=0x00
vendor   = 'Transmeta Corp.'
device   = 'LongRun Northbridge'
class= bridge
subclass = HOST-PCI
none0@pci0:0:1: class=0x05 card=0x02951279 chip=0x03961279 rev=0x00 hdr=0x00
vendor   = 'Transmeta Corp.'
device   = 'SDRAM Controller'
class= memory
subclass = RAM
none1@pci0:0:2: class=0x05 card=0x02951279 chip=0x03971279 rev=0x00 hdr=0x00
vendor   = 'Transmeta Corp.'
device   = 'BIOS scratchpad'
class= memory
subclass = RAM
pcm0@pci0:4:0:  class=0x040100 card=0x01001265 chip=0x545110b9 rev=0x01 hdr=0x00
vendor   = 'Acer Labs Inc.'
device   = 'ALI M5451 PCI AC-Link Controller Audio Device'
class= multimedia
subclass = audio
isab0@pci0:7:0: class=0x060100 card=0x153310b9 chip=0x153310b9 rev=0x00 hdr=0x00
vendor   = 'Acer Labs Inc.'
device   = 'M1533 PCI South Bridge'
class= bridge
subclass = PCI-ISA
none2@pci0:9:0: class=0x03 card=0x0712126f chip=0x0712126f rev=0xa0 hdr=0x00
vendor   = 'Silicon Motion'
device   = 'SM712 LynxEM+'
class= display
subclass = VGA
pcic0@pci0:10:0:class=0x060700 card=0x chip=0xac51104c rev=0x00 
hdr=0x02
vendor   = 'Texas Instruments'
device   = 'PCI1420 PC card Cardbus Controller'
class= bridge
subclass = PCI-CardBus
pcic1@pci0:10:1:class=0x060700 card=0x chip=0xac51104c rev=0x00 
hdr=0x02
vendor   = 'Texas Instruments'
device   = 'PCI1420 PC card Cardbus Controller'
class= bridge
subclass = PCI-CardBus
none3@pci0:11:0:class=0x0c0010 card=0x8011104c chip=0x8020104c rev=0x00 
hdr=0x00
vendor   = 'Texas Instruments'
device   = 'OHCI Compliant FireWire Controller'
class= serial bus
subclass = FireWire
rl0@pci0:12:0:  class=0x02 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00
vendor   = 'Realtek Semiconductor'
device   = 'RT8139 (A/B/C/8130) Fast Ethernet Adapter'
class= network
subclass = ethernet
atapci0@pci0:15:0:  class=0x0101a4 card=0x chip=0x522910b9 rev=0xc3 
hdr=0x00
vendor   = 'Acer Labs Inc.'
device   = 'M1543 Southbridge EIDE Controller'
class= mass storage
subclass = ATA
none4@pci0:17:0:class=0x068000 card=0x chip=0x710110b9 rev=0x00 
hdr=0x00
vendor   = 'Acer Labs Inc.'
device   = 'M7101 Power Management Controller'
class= bridge
subclass = PCI-unknown
ohci0@pci0:20:0:class=0x0c0310 card=0x chip=0x523710b9 rev=0x03 
hdr=0x00
vendor   = 'Acer Labs Inc.'
device   = 'ALI M5237 USB Host Controller'
class= serial bus
subclass = USB


--- dmesg-4-nousb   Mon Sep 17 22:41:14 2001
+++ dmesg-4-usb Mon Sep 17 22:41:14 2001
@@ -1,12 +1,12 @@
 Copyright (c) 1992-2001 The FreeBSD Project.
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
-FreeBSD 4.4-STABLE #3: Mon Sep 17 18:16:17 JST 2001
-root@fivavl:/usr/STABLE/src/sys/compile/FIVA
-Calibrating clock(s) ... TSC clock: 597298266 Hz, i8254 clock: 1360243 Hz
-1360243 Hz differs from default of 1193182 Hz by more than 1%
+FreeBSD 4.4-STABLE #4: Mon Sep 17 18:43:25 JST 2001
+iwasaki@fivavl:/usr/STABLE/src/sys/compile/FIVA
+Calibrating clock(s) ... TSC clock: 597300672 Hz, i8254 clock: 1276722 Hz
+1276722 Hz differs from default of 1193182 Hz by more than 1%
 Timecounter "i8254"  frequency 1193182 Hz
-CPU: Transmeta(tm) Crusoe(tm) Processor TM5600 (573.41-MHz 586-class CPU)
+CPU: Transmeta(tm) Crusoe(tm) Processor TM5600 (597.30-MHz 586-class CPU)
   Origin = "GenuineTMx86"  Id = 0x543
   Proc

Re: ACPI: problem with fdc resource allocation

[Mitsuru IWASAKI]

Hi, I've just made a workaround for this.  Intel folks, could you review
it as always?

> The problem is here, right?
> > can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_BUFFER_LIMIT
> 
> I'm sure _SB_.PCI0.ISA_.FDC0._CRS (Current Resource Settings) have some
> problems (not sure in BIOS or ACPICA yet).  I could reproduce the problem
> which you reported.  Trace attached in this mail.
[snip]
> dsopcode-0677 [09] DsEvalBufferFieldOpera: Field size 208 exceeds Buffer size 192 
>(bits)
> PsExecute: method failed - \_SB_.PCI0.ISA_.FDC0._CRS (0x8098fa8)
> Execution of \_SB_.PCI0.ISA_.FDC0._CRS failed with status AE_AML_BUFFER_LIMIT

This method is like this;
Method(_CRS) {
Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
   0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0,
   0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 0x0 })
CreateByteField(BUF0, 0x2, IOLO)
CreateByteField(BUF0, 0x3, IOHI)
CreateByteField(BUF0, 0x4, IORL)
CreateByteField(BUF0, 0x5, IORH)
CreateByteField(BUF0, 0x19, IRQL)
CreateByteField(BUF0, 0x1c, DMAV)
Return(BUF0)
}

The problem is that this AML is trying to create a field at exceeded
position (0x19) of the Buffer (size is 0x18).
I couldn't find how AML interprepter treat this in ACPI Spec. so I'm
not sure wether AWRDACPI violates the Spec. or ACPICA can have a workaround
for this.
Anyway, I made a patch to reallocate a large enough buffer for the
requested operation.

Thanks

Index: dsopcode.c
===
RCS file: /home/ncvs/src/sys/contrib/dev/acpica/dsopcode.c,v
retrieving revision 1.1.1.10
diff -u -r1.1.1.10 dsopcode.c
--- dsopcode.c  7 Sep 2001 01:22:24 -   1.1.1.10
+++ dsopcode.c  1 Oct 2001 18:58:41 -
@@ -615,11 +615,24 @@
 if ((BitOffset + BitCount) >
 (8 * (UINT32) SrcDesc->Buffer.Length))
 {
+UINT32  Length;
+UINT8   *Pointer;
+
 ACPI_DEBUG_PRINT ((ACPI_DB_ERROR,
 "Field size %d exceeds Buffer size %d (bits)\n",
  BitOffset + BitCount, 8 * (UINT32) SrcDesc->Buffer.Length));
-Status = AE_AML_BUFFER_LIMIT;
-goto Cleanup;
+Length = ((BitOffset + BitCount) / 8) +
+ (((BitOffset + BitCount) % 8) ? 1 : 0);
+Pointer = ACPI_MEM_CALLOCATE (Length);
+if (!Pointer)
+{
+Status = AE_NO_MEMORY;
+goto Cleanup;
+}
+MEMCPY (Pointer, SrcDesc->Buffer.Pointer, SrcDesc->Buffer.Length);
+ACPI_MEM_FREE (SrcDesc->Buffer.Pointer);
+SrcDesc->Buffer.Pointer = Pointer;
+SrcDesc->Buffer.Length = Length;
 }
 
 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI and APM interoperability?

[Mitsuru IWASAKI]

Hi,

> On Mon, Oct 01, 2001 at 10:50:17AM +0200, Georg-W. Koltermann wrote:
> > Hi,
> > 
> > I'm wondering how I should handle APM now that ACPI has basically
> > taken over power management responsibility.
> 
> APM and ACPI are mutually exclusive from what I understand.  You should
> remove the apm device from your kernel config.

Yes, some older machines w/ ACPI can support both of them at the same time,
but most modern machines don't.

> > It seems I still need to configure APM so that /dev/apm is there and
> > battery monitoring utilities like the GNOME battery_applet can work.
> 
> Battery, temp, etc, can be monitored via the hw.acpi sysctl tree.
> Someone will have to do the required conversion to the various APM
> utilities is GNOME and whatever else.

Yes, you can get battery info. in C code like;
sysctlbyname("hw.acpi.battery.time", &percent, &len, NULL, 0);
Note that these MIBs maybe change in future...

Generalized power-management interface API to have compatibility with
APM and ACPI also is suggested long time ago;
http://www.freebsd.org/cgi/getmsg.cgi?fetch=403390+406841+/usr/local/www/db/text/2001/freebsd-current/20010114.freebsd-current

Device node for ACPI is discussed bofore too; having only one /dev/acpi
or having generalized nodes for each device types such as /dev/battery0
but we couldn't reach the conclusion, now discussion stops...

Any suggestions on it?  Once we get the conclusion, we can start developing
API and convert userland tools.

> > I also was able to suspend and resume my machine (DELL Inspiron 7500)
> > with APM being configured (and ACPI being active by default).  Sound
> > is dead after a resume,
> 
> What sound card?
> 
> > PCMCIA is dead after a couple of resumes,
> 
> Resource leak?  Warner?

Is yours similar to any data at there (Dell_I7500*) ?
http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/?cvsroot=freebsd-jp

I guess CardBus controllers are _SB_.PCI0.CB1_ and _SB_.PCI0.CB2_
but I didn't see any sleep/wakeup hack for them...

Thanks

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI: problem with fdc resource allocation

[Mitsuru IWASAKI]

Hi,

> > I'm not sure exactly what's the problem you are having, but it's too
> > little information to track it down...
> > Could you send [EMAIL PROTECTED] ;
> >  - acpidump output; like
> ># acpidump -o your_machine_name.dsdt > your_machine_name.dsdt.asl
> >   I'll add them to
> >   http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/?cvsroot=freebsd-jp
> >  - dmesg output of kernel boot -v
> 
> Just sent it to you privately. After hiting sed button I've realised that 
>machine_name that
> you have requested != host_name. Since it isn't a brandname model you can identify 
>it after
> the mainboard name - Tyan-S1590.

Thanks, I've just add them to 
http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Tyan-S1590.asl?cvsroot=freebsd-jp

The problem is here, right?
> can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_BUFFER_LIMIT

I'm sure _SB_.PCI0.ISA_.FDC0._CRS (Current Resource Settings) have some
problems (not sure in BIOS or ACPICA yet).  I could reproduce the problem
which you reported.  Trace attached in this mail.
I'll try to make a workaround tomorrow or next, sorry.
# Here in Japan, it's midnight...

Thanks

% acpicadb Tyan-S1590.dsdt
Parsing Methods:...
55 Control Methods found and parsed (259 nodes total)
ACPI Namespace successfully loaded at root 0x8087414
- f FDC0
\_SB_.PCI0.ISA_.FDC0 (0x8098da8) - Device
- debug _SB_.PCI0.ISA_.FDC0._CRS
Executing \_SB_.PCI0.ISA_.FDC0._CRS
0 #0008 [00]  Name BUF0  (Path \)
[00]  (
5 #0011 [01]  Buffer
[01]  (
7 #000A [02]  (UINT8)  0x18,
9 #0033 [02]  ByteList  (Length 0x0018)  
[02]  }
[01]  }

% 
ArgObj:0x80acfa8  Integer 0018
00021 #008C [00]  CreateByteField
[00]  (
00022 #002D [01]  BUF0,  (Path 
00026 #000A [01]  (UINT8)  0x02,
00028 #002D [01]  IOLO  (Path 
[01]  }

% 
ArgObj:0x80acf28 Name BUF0 Type-Buffer
ArgObj:0x80af1a8  Integer 0002
ArgObj:0x80af0a8 Name IOLO Type-BuffField
0002C #008C [00]  CreateByteField
[00]  (
0002D #002D [01]  BUF0,  (Path 
00031 #000A [01]  (UINT8)  0x03,
00033 #002D [01]  IOHI  (Path 
[01]  }

% 
ArgObj:0x80acf28 Name BUF0 Type-Buffer
ArgObj:0x80af328  Integer 0003
ArgObj:0x80af228 Name IOHI Type-BuffField
00037 #008C [00]  CreateByteField
[00]  (
00038 #002D [01]  BUF0,  (Path 
0003C #000A [01]  (UINT8)  0x04,
0003E #002D [01]  IORL  (Path 
[01]  }

% 
ArgObj:0x80acf28 Name BUF0 Type-Buffer
ArgObj:0x80af4a8  Integer 0004
ArgObj:0x80af3a8 Name IORL Type-BuffField
00042 #008C [00]  CreateByteField
[00]  (
00043 #002D [01]  BUF0,  (Path 
00047 #000A [01]  (UINT8)  0x05,
00049 #002D [01]  IORH  (Path 
[01]  }

% 
ArgObj:0x80acf28 Name BUF0 Type-Buffer
ArgObj:0x80af628  Integer 0005
ArgObj:0x80af528 Name IORH Type-BuffField
0004D #008C [00]  CreateByteField
[00]  (
0004E #002D [01]  BUF0,  (Path 
00052 #000A [01]  (UINT8)  0x19,
00054 #002D [01]  IRQL  (Path 
[01]  }

% 
ArgObj:0x80acf28 Name BUF0 Type-Buffer
ArgObj:0x80af7a8  Integer 0019
ArgObj:0x80af6a8 Name IRQL Type-BuffField
dsopcode-0677 [09] DsEvalBufferFieldOpera: Field size 208 exceeds Buffer size 192 
(bits)
PsExecute: method failed - \_SB_.PCI0.ISA_.FDC0._CRS (0x8098fa8)
Execution of \_SB_.PCI0.ISA_.FDC0._CRS failed with status AE_AML_BUFFER_LIMIT



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI: problem with fdc resource allocation

[Mitsuru IWASAKI]

Hi,

> Maxim Sobolev wrote:
> 
> > Maxim Sobolev wrote:
> >
> > > "Andrey A. Chernov" wrote:
> > >
> > > > On Mon, Sep 17, 2001 at 16:26:20 +0300, Maxim Sobolev wrote:
> > > > > Hi,
> > > > >
> > > > > Finally decided to upgrade my current box to the post-ACPI/KSE and found
> > > > > that I'm having problem with resource allocation for floppy disk controller.
> > > > > I'm sure somebody already reported this some time ago, but the problems seems
> > > > > still here, so I would like to see it resolved.
> > > >
> > > > > fdc0: cannot reserve I/O port range (1 ports)
> > > >
> > > > It seems that here is conflict with your device.hints, try to remove fdc
> > > > from the hints.
> > > >
> > > > As I already write, it is very bad thing that ACPI is in conflicts with
> > > > default hints file correctly describing devices used. ACPI must ignore
> > > > duplicate devices from the hints.
> > > >
> > > > The problem with floppy is harder, because floppy controller present in
> > > > ACPI but the floppy itself not present (on my motherboard at least), so
> > > > in current situation fdc0 must not be in hints, but fd0 must be, it makes
> > > > whole thing even more cryptic.
> > >
> > > Doesn't work, exactly the same problem - see attached device.hints.
> >
> > Knock, knock... Is anybody home?
> 
> Hmm, it is very sad to see that acpi code is totally unsupported, especially in the
> spite of recent "how to attract people to test -current" thread. The problem is still
> here, as of today's kernel.

I'm not sure exactly what's the problem you are having, but it's too
little information to track it down...
Could you send [EMAIL PROTECTED] ;
 - acpidump output; like
   # acpidump -o your_machine_name.dsdt > your_machine_name.dsdt.asl
  I'll add them to
  http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/?cvsroot=freebsd-jp
 - dmesg output of kernel boot -v

Mike, anything add to this?

Thanks

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: [acpi-jp 1363] Re: ACPI: problem with fdc resource allocation

[Mitsuru IWASAKI]

Hi, Maxim.  Thanks for reporting and reminding us.

I think this is very difficult to fix, because;
 1. Basically, this is a bug in BIOS, should be reported to vendor.
 2. ACPI CA is developed by Intel.  We'd like to have less local
workaround changes as possible.
 3. I'm not sure whether suggested patches (buffer size dynamicaly expanding)
in [acpi-jp 1315] is correct fix, maybe not.  Probably another approach
can be considered (e.g. just ignore AE_AML_BUFFER_LIMIT and continue
interpreter execution).

I'll describe again the problem.  This method is like this;
Method(_CRS) {
Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
   0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0,
   0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 0x0 })
CreateByteField(BUF0, 0x2, IOLO)
CreateByteField(BUF0, 0x3, IOHI)
CreateByteField(BUF0, 0x4, IORL)
CreateByteField(BUF0, 0x5, IORH)
CreateByteField(BUF0, 0x19, IRQL)
CreateByteField(BUF0, 0x1c, DMAV)
Return(BUF0)
}

The problem is that this AML is trying to create a field at exceeded
position (0x19) of the Buffer (size is 0x18).
And strangely, this method just return the buffer w/o any changes
after CreateByteField operations. I guess that BIOS writer forgotten to
delete CreateByteField statements, or change the buffer size.

Now that we have DSDT override patches;
http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1347
or
http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1349

and AML disassembler (acpidump), and ASL compiler (iasl) in
ports/devel/acpicatools/.

Maxim, could you apply the following patches and try DSDT overriding?

Thanks

--- Tyan-S1590.asl.org  Wed Oct 24 22:00:44 2001
+++ Tyan-S1590.asl  Wed Oct 24 22:02:09 2001
@@ -884,12 +884,14 @@
 }
 Method(_CRS) {
 Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3, 0x0, 
0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0, 0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 
0x0 })
+/*
 CreateByteField(BUF0, 0x2, IOLO)
 CreateByteField(BUF0, 0x3, IOHI)
 CreateByteField(BUF0, 0x4, IORL)
 CreateByteField(BUF0, 0x5, IORH)
 CreateByteField(BUF0, 0x19, IRQL)
 CreateByteField(BUF0, 0x1c, DMAV)
+*/
 Return(BUF0)
 }
 Name(_PRS, Buffer(0x1a) {0x30, 0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3, 0x0, 
0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0, 0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x38, 
0x79, 0x0 })

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: [acpi-jp 1371] Re: ACPI: problem with fdc resource allocation

[Mitsuru IWASAKI]

# Congratulations, Maxim!

> On Thu, Oct 25, 2001 at 05:13:56PM +0300, Maxim Sobolev wrote:
> > 
> > 6. And finally I've put back corrected ACPI table back into
> > BIOS image using CBROM.EXE, flashed resulting BIOS image and
> > voila - the ACPI problem gone. :)
> > 
> 
> Way cool. :)

Yeah, Maxim is maniac :)

Thanks

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: how to make acpi go away.

[Mitsuru IWASAKI]

Hi,

> > >   try adding a line
> > > 
> > > hint.acpi.0.disable="1"
> > > 
> > >   to /boot/device.hints, or disable it at boot time
> > > 
> > > unset acpi_load
> > > 
> > >   then boot as usual.
> > 
> > Thank you, that fixed everything.
> 
> Also, this works too:
> echo "NO_MODULES=yes" >> /etc/make.conf; rm /boot/kernel/acpi.ko
> 
> :-)

Also, it's good idea.
echo "device acpi" >> /sys/i386/conf/GENERIC; cd /usr/src; make kernel
# then try debugging hard together :-)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: [acpi-jp 1343] Re: ACPI panic at boot time in -current

[Mitsuru IWASAKI]

Hi, Intel folks.  I've just found the bug in rsutils.c which double
free(); AcpiUtRemoveReference() and ACPI_MEM_FREE().  Here is a fix.

Index: rsutils.c
===
RCS file: /home/ncvs/src/sys/contrib/dev/acpica/rsutils.c,v
retrieving revision 1.1.1.7
diff -u -r1.1.1.7 rsutils.c
--- rsutils.c   4 Oct 2001 23:12:13 -   1.1.1.7
+++ rsutils.c   14 Oct 2001 15:23:13 -
@@ -490,7 +490,6 @@
  */
 Cleanup:
 
-ACPI_MEM_FREE (ByteStream);
 return_ACPI_STATUS (Status);
 }


I suspect that this should be removed in ACPICA 20010831-to-20010920
changes.

Matsuda-san, thanks.  I missed the original mail in current ML written
by brian.

Thanks

> Hi all,
> 
> From: Brian Somers <[EMAIL PROTECTED]>
> Date: Fri, 12 Oct 2001 01:15:38 +0100
> ::Hi,
> ::
> ::I was wondering if anybody has any suggestions about why this might 
> ::be happening in -current:
> 
> ::pccbb1:  irq 0 at device 10.1 on pci0
> ::pccbb1: PCI Memory allocated: 10001000
> ::acpi_pcib0: possible interrupts:  9
> ::panic: free: multiple freed item 0xc14f75f0
> ::Debugger("panic")
> ::Stopped at  Debugger+0x44:  pushl   %ebx
> ::db> t 
> 
> I also get the same kind of panic, after import of ACPICA 20010920 snapshot. 
> If I boot very current kernel with old acpi.ko based on 20010831 snapshot,
> system boots up just fine.
> 
> Panic message from current kernel with acpi.ko based on 20010920 snapshot:
> -8<-8<-8<-8<-8<-8<-8<
> uhci0:  port 0xfc60-0xfc7f at device 7.
> 2 on pci0
> acpi_pcib0: possible interrupts:  9
> panic: free: multiple freed item 0xc13843d0
> Debugger("panic")
> Stopped at  Debugger+0x44:  pushl   %ebx
> db>
> -8<-8<-8<-8<-8<-8<-8<
> 
> Related dmesg from the same kernel with old acpi.ko based on 20010831 snapshot:
> -8<-8<-8<-8<-8<-8<-8<
> uhci0:  port 0xfc60-0xfc7f at device 7.2 on 
>pci0
> acpi_pcib0: matched entry for 0.7.INTD (source \\_SB_.LNKD)
> acpi_pcib0: possible interrupts:  9
> acpi_pcib0: routed interrupt 9 via \\_SB_.LNKD
> usb0:  on uhci0
> usb0: USB revision 1.0
> uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> uhub0: 2 ports with 2 removable, self powered
> uhub1: Philips Semiconductors hub, class 9/0, rev 1.10/1.10, addr 2
> uhub1: 3 ports with 3 removable, self powered
> -8<-8<-8<-8<-8<-8<-8<
> 
> Hope this helps,
>   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: [acpi-jp 1150] HEADS UP: ACPI update - thermal management

[Mitsuru IWASAKI]

Hi, mike.

> This is just a heads-up to let folks know that I've committed some early 
> code to handle thermal management under ACPI.  This should DTRT with 
> active cooling (fans, etc.).  It won't help with passive cooling yet (we 
> need to sort out the processor device control first), and it may well 
> have problems (there are places where the specification is vague about 
> what should be in the namespace and my ability to test these options is 
> limited).

I tested this a bit and noticed following messages.

unknown: error fetching current temperature

I think that notify handler got wrong parameter, device_t not softc.
Here is the fix for it.

Index: acpi_thermal.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_thermal.c,v
retrieving revision 1.8
diff -u -r1.8 acpi_thermal.c
--- acpi_thermal.c  2001/06/28 06:17:16 1.8
+++ acpi_thermal.c  2001/06/29 17:48:14
@@ -151,7 +151,7 @@
  * Register for any Notify events sent to this zone.
  */
 AcpiInstallNotifyHandler(sc->tz_handle, ACPI_DEVICE_NOTIFY, 
- acpi_tz_notify_handler, dev);
+ acpi_tz_notify_handler, sc);

BTW, how about sysctl interface for ACPI thermal zone?
At least the representative temperature would be useful for users.

Thanks

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP - more ACPI updates, CPU throttling

[Mitsuru IWASAKI]

Hi,

> I've committed another round of ACPI changes to -current.
> 
> The major addition is CPU throttling support.  This is implemented using
> ACPI, not any vendor-specific technology, so it should work on any
> platform that exports the relevant information.  By default, the CPU will
> run at 100% in 'performance' mode and 50% in 'economy' mode, however these
> levels can be adjusted with the following sysctls:

Cool!  I'll check whether the cpu performance actually changes on
AC-line on/off events.
BTW, I've found a couple of typo :) will commit soon.

Thanks

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: [acpi-jp 1221] Re: question about acpi sleep.

[Mitsuru IWASAKI]

Hi,

> >>> IWASAKI-san wrote:
> > I think your NotePC doesn't have _S1_ object in ACPI data block.
> > Plese check `acpidump | grep _S1' to see if _S1_ object is there.
> 
> No, there isn't _S1_ object.

Yup, it has only S0, S3, S4 and S5.  No S1 on your NotePC.

> > Maybe yours has other _Sx_ object (such as _S3_ for Sleep State 3,
> > meaning suspend in APM term).
> > And could you send us acpidump output from PCG-C1VSX/K? 
> 
> I attach those.
> Now acpiconf -s 3 doesn't work well. After resume,
> LCD doesn't recover, but Ctrl-Alt-Delete does shutdown.
> (Doesn't reboot, so I had to press power button after that.)
> I also attach related log.

Thanks.
Hmmm, _WAK method checks OS type (in CKOS method) and skips calling
PHS(0xe1).  I suspect that this is needed to be done after wakeup.
i.e. the OS which have `FreeBSD' as ACPI_OS_NAME might have problems
on your NotePC's ACPI.

Try running `amldb PCG-C1VSXK.dsdt' to see what happen on Windows NT...
# Yes, amldb has string "Microsoft Windows NT" in _OS_ object for this
# purpose :-)

Thanks

P.S.
I've found another problem; RTC interrupts are disabled after wakeup
on some machines.  And statclock() never be called after that.  I hope
I can fix this soon.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

CFR: acpi userland manpages

[Mitsuru IWASAKI]

Hi, I've just imported acpi userland tools and writing manpages for
them with contributers in Japan.
Please review them and send any comments (or diffs) for me
([EMAIL PROTECTED]) in terms of English/roff or whatever.

The draft version of manpages are available at
http://people.FreeBSD.org/~iwasaki/acpi/acpidump.8
http://people.FreeBSD.org/~iwasaki/acpi/amldb.8

and one more manpage is coming soon (acpiconf.8).

Thanks!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ACPI merge finished!

[Mitsuru IWASAKI]

Hi, merging the code from ACPI For FreeBSD project into CURRENT finished!
We would very much appreciate for all people who encouraged and helped
and supported us.

1. Using ACPI
If you have machines with ACPI BIOS, you should be able to power off the
machine by shutdown -p (or acpiconf -s 5), or the power button is pressed
if the machine support it.  This is one of the power management
features covered by ACPI.  The implementaion of PnP configuration,
processor control and thermal management features will come later.
To activate acpi driver, just add
  device acpi
in your kernel configuration file.  Also you maybe interested in
  options ACPI_DEBUG
  options AML_DEBUG
to watch the ACPI events and trace of AML interpreter.

2. Further development
We, ACPI project guys, will stop maintaining own CVS repo. except for
ACPI DSDT (Differentiated System Description Table) data file and ASL
(ACPI Source Language) file collection.  We're going to concentrate our
development on -CURRENT.
Because it is still in experimental phase, more developers are needed.
To avoid making duplicate effort, I'd like to propose that having an
announcement in -current (or -hackers?) ML first then starting your
development.
Watanabe-san and Yokoyama-san are working on GPE (General Purpose
Event) handling, I myself (iwasaki) working on PowerResource
implementaion for now.
# Battery, Thermal management would be good candidates for your first trial.

3. ACPI data file collection
The DSDT/ASL collection is available at
http://www.jp.freebsd.org/cgi/cvsweb/ACPI/util/takawata/acpi/?cvsroot=freebsd-jp
http://www.jp.freebsd.org/cgi/cvsweb/ACPI/util/dfr/acpitest/?cvsroot=freebsd-jp
Note: this URL maybe change in the near future.

If your machine has ACPI BIOS, please send us ({iwasaki|takawata}@FreeBSD.org)
obtained data files as follows;
# acpidump -o foo.dsdt > foo.asl

4. Information about ACPI
http://www.teleport.com/~acpi/
has enough information about ACPI including links.  It seems ACPI 2.0
Specification is now available for download from this site.  I put
diffs between 1.0b and 2.0 index with a little modification for your
convenience at
http://people.freebsd.org/~iwasaki/acpi/spec-index.diff

Have fun!  and Thanks!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI merge finished!

[Mitsuru IWASAKI]

FYI,

> Because it is still in experimental phase, more developers are needed.
> To avoid making duplicate effort, I'd like to propose that having an
> announcement in -current (or -hackers?) ML first then starting your
> development.

I've just add `Who is woking on what' section in ACPI for FreeBSD
Project Web page at
http://www.jp.freebsd.org/acpi/

Thanks!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: xl driver

[Mitsuru IWASAKI]

> > : Sep  3 13:24:26 manatee /kernel: xl0: <3Com 3c900-COMBO Etherlink XL> port 
>0x6c00-0x6c3f irq 11 at device 9.0 on pci0
> > : Sep  3 13:24:26 manatee /kernel: xl1: <3Com 3c900-COMBO Etherlink XL> port 
>0x6c00-0x6c3f irq 11 at device 9.0 on pci2
> > 
> > Looks like your pci bus is getting probed twice!
> 
> This happened to me when I turned on ACPI support - infact it
> thought I had 3 PCI busses when I only had one! I haven't had time
> to look into it yet though.

Hmmm, can I have your full output of dmesg?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

CFR: New pseudo timer device driver for power management events

[Mitsuru IWASAKI]

Hi,

I'm working on ACPI and thinking of sharing the related code with
other power management subsystem (currently apm) rather than having
duplicated code.  Updating timer/clock before and after sleeping, is
my first target.

My idea is that create new pseudo timer device driver for power
management events in i386/isa/pmtimer.c which should be statically
wired and always only one instance, then move
apm_default_{suspend|resume} in i386/apm/apm.c into pmtimer as
device_{suspend|resume} method.

Firstly I thought that this should be moved to i386/isa/clock.c and
define device_{suspend|resume} method of attimer. But I noticed that
it's for PnP and we cannot guarantee that there is always only one
device instance and device_{suspend|resume} is executed once per
event.

I put the code and diffs at
http://people.freebsd.org/~iwasaki/acpi/pmtimer.c
http://people.freebsd.org/~iwasaki/acpi/pmtimer.diff

Please review them, I'll commit this change this weekend.

Thanks!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: AIC-7890 problems with kernel build

[Mitsuru IWASAKI]

Hi,

> And, of course, the kernel config... a fair amount of crap still not trimmed
> out, but the only difference between this config and the one used to build
> the functional kernel is apm commented out and ACPI added, which I've already
> tried reversing without much difference.

All I can say is that acpi is initilized after pcib and its children
are attached so I don't think ACPI code affects PCI stuff...

> # Power management support (see LINT for more options)
> #device   apm
> deviceacpi

Could you disable acpi and try again to make the problem clearer?
Without `device acpi' line in your kernel config file, any ACPI code
isn't compiled in your kernel.

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: AIC-7890 problems with kernel build

[Mitsuru IWASAKI]

> > Could you disable acpi and try again to make the problem clearer?
> > Without `device acpi' line in your kernel config file, any ACPI code
> > isn't compiled in your kernel.
> 
> That was the first thing I tried when mine failed. It didn't make any
> difference - I saw the same failure (the page fault, not the SCB
> errors).

Ah, I haven't read previous mails.  I'm sorry about that.
# Now I can go to my bed :-)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: CFR: acpi userland manpages

[Mitsuru IWASAKI]

> > The draft version of manpages are available at
> > http://people.FreeBSD.org/~iwasaki/acpi/acpidump.8
> > http://people.FreeBSD.org/~iwasaki/acpi/amldb.8
> 
> I've just found the time to give them a quick once over, and I'd have no
> problem with them going in as they are.  There are some grammar changes,
> and possibly terminology changes that might be appropriate, but I haven't
> got the time to enumerate them all at the moment, and I'm sure the wider
> community can make suggestions as time goes on.

Thanks.  I got mails from kind guys including some grammar changes,
but my main NotePC has a problem with keyboard and it's in repairing
(yes, revised version of manpages are in that PC...) :-<

> Sheldon can probably render an opinion on their usage of the macros.

OK, I'm looking forward to see it :-)

Thanks again


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Partial success with current on Laptop.

[Mitsuru IWASAKI]

> >   - apm (suspend/resume not testet)
> 
>   Works for me.
> 
>   My only problem is that Fan is NEVER turned off (it seems that
> idle loop in kernel as become CPU intensive and energy hardware can not
> stop cooling). At this time, this is a minor annoyance.

Do you have acpi enabled in your kernel?  If so, it could be.  Thermal
and processor power management portion of acpi is not implemented yet.
All of the power resource components such as fan are just turned on at
booting for now :-)



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Partial success with current on Laptop.

[Mitsuru IWASAKI]

> > Do you have acpi enabled in your kernel? 
> 
>   no. I have tried ACPI some days ago, but system boot becomes
> incredibly slow (for example, syslogd complained about something like
> 'child process timeout' after enabling ACPI). All system activity such
> as fork and so was affected.

It seems the same with my TOSHIBA POTEGE 3110CT because of lack of
processor power management implementation I think.  My short term
solution is acpiconf -d to make CPU running in normal speed.

> > and processor power management portion of acpi is not implemented yet.
> > All of the power resource components such as fan are just turned on at
> > booting for now :-)
> 
> Other problem with -CURRENT and laptops is that system time is not
> reinitialised after suspend and resume :)

Ah, you probably need to have a `device pmtimer' in your kernel config
and `hint.pmtimer.0.at="isa"' in your devce.hints.  If you don't like
to reinitialize system time (e.g. prefer running ntpdate), you don't
need to have pmtimer.


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

[Mitsuru IWASAKI]

> 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

[Mitsuru IWASAKI]

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

[Mitsuru IWASAKI]

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

[Mitsuru IWASAKI]

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 
+
+#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 
+#include 
+#include 
 #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:  /* SleepOp */

Re: My system hang with ACPI kernel thread

[Mitsuru IWASAKI]

> > > > 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 , 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: ACPI megapatch

[Mitsuru IWASAKI]

Thanks a lot mike, these are mostly acceptable for me.

> Here's the latest ACPI megapatch:
> 
>  - Move all the register I/O into a separate file

Agreed.

>  - Made all the I/O spaces use proper bus resources
>  - Allocate the resources in machine-dependant code

I prefer previous patch because most of the code in i386/acpi_machdep.c
can be shared with IA64 I think.

>  - Map ACPI-used memory in machine-dependant code

Agreed.

>  - Create a machine-dependant "acpiprobe" device which just knows
>how to find and set up ACPI for the machine-independant code

I think only machine-dependant sub-routines should be in acpi_machdep.c,
the rest common code should be moved back to dev/acpi/acpi.c.
The first half of acpiprobe_identify() is trying to find rsdp, so
renaming it to acpi_find_rsdp() (returns struct ACPIrsdp * or NULL),
moving the rest of acpiprobe_identify() to dev/acpi/acpi.c:acpi_identify()
and calling acpi_find_rsdp() from acpi_identify() would be better for me.
acpiprobe_mapmem() seems machine-dependant, so just renaming (acpi_mapmem() ?)
would be enough.
acpiprobe_facp(), I think, is MI, should be moved dev/acpi/acpi.c and
renamed (acpi_find_facp() ?).

In summary, my suggestions are
 - i386/i386/acpi_machdep.c
acpi_find_rsdp() and acpi_mapmem()
 - dev/acpi/acpi.c
acpi_identify() and acpi_find_facp()

>  - Remove all the ACPI #ifdefs from non-ACPI code
>  - Minor style and commenting fixes

Completely agreed.

> Issues outstanding:
> 
>  - Need to remove superfluous headers
>  - Need to decide the correct split between  and 
> in terms of functionality.

I'd like to move and rename them as I said in my previous mail,
 -> 
shared by both kernel and userland programs
 -> 
shared within kernel code (acpi stuff and related drivers)

That's my rough understanding, but I could be wrong :-)

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

Hi,

> > I'd like to move and rename them as I said in my previous mail,
> >  -> 
> > shared by both kernel and userland programs
> >  -> 
> > shared within kernel code (acpi stuff and related drivers)
> 
> IMHO, it's desirable to use the name "acpi.h", because of conflict
> with the file dumped by /usr/sbin/config.
> 
> I love :
>   fooreg.h : device dependent and implementation independent
>  structures, macros, and others.
>   foovar.h : implementation dependent ones.

Thanks Shiozaki-san, I think `reg' is short for registers of the
target chip, correct?  In ACPI's case, PM1 register and some such
and maybe definitions for ACPI tables.
How about kernel/userland shareable stuff like ioctl?  for example,
usb(4) has this kind of definitions in dev/usb/usb.h, not in usbreg.h.
Is this a special case violating the guideline?
I think we can distinguish them like "usb.h" and ,
also we will stop generating acpi.h in kernel build directory.

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

> In summary, my suggestions are
>  - i386/i386/acpi_machdep.c
>   acpi_find_rsdp() and acpi_mapmem()
>  - dev/acpi/acpi.c
>   acpi_identify() and acpi_find_facp()

Here is a patch for your megapatch at
http://people.FreeBSD.org/~iwasaki/acpi/patch-for-megapatch.diff
I'll be happy if you accept and commit this :-)

Thanks!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

> >Here is a patch for your megapatch at
> >http://people.FreeBSD.org/~iwasaki/acpi/patch-for-megapatch.diff
> >I'll be happy if you accept and commit this :-)
> >
> 
> I think it is better bus attachment code is in MD part than in MI part.
> And MD bus attachment code calls MI bus attachment code.
> 
> For example,Current acpi_probe code rename to acpi_probesubr and
>  call it from acpi_probe in acpi_machdep.c . 

Hmm, I think you're talking about BI/BD.  Most of ACPI code must be
shared between IA32/IA64 (even bus interface code). Difference between
them is very limited, we can put them in acpi_machdep.c.  I like this
model.  NetBSD's pci code take this one (dev/pci/pci.c has MI code
like pcimattach(), arch/*/pci/pci_machdep.c have a set of MD
sub-routines for the specific machine architecture such as
pci_conf_read().).  I'm not sure this is correct or not, but it seems
reasonable for me.

> And probe method and identify method should not be confused.
> Memory area check etc can be in MD acpi probe code.

Yes, I think it's in acpi_machdep.c :-)
if not, which one?

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

Hi,

> > I prefer previous patch because most of the code in i386/acpi_machdep.c
> > can be shared with IA64 I think.
> 
> I'm not so sure about that.  I suspect that the IA64 code is going to be
> using the 'generic address' structures and the x-fields in eg. the FACT.
> It won't be using the bios signature search either, or the int15
> interface.  Realistically, the code in acpi_machdep.c is very simple.a
> 
> I also think that if I'm going to continue to use a private identify 
> method to attach ACPI (IMO a good idea) then I want to keep its 
> implementation as separate from the 'generic' ACPI code as possible.  The 
> pmap interface and one checksum routine is all that the current division 
> uses, and that's fairly clean.

OK, understood.  How about having MD sub-routine in the same interface
(say acpi_set_resources() or acpi_create_instance() or whatever) for
i386 and ia64?  Then generic ACPI identify method calls suitable
sub-routine depending on machine architecture.

 - i386/i386/acpi_machdep.c
acpi_set_resources() (ex-acpiprobe_identify())
 - ia64/ia64/acpi_machdep.c
acpi_set_resources()

 - dev/acpi/acpi.c
acpi_identify()
this is quite simple, just do simple error checking and
call acpi_set_resources() then return.

Is this good for you too?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

Hi,

> Ok.  Based on all the suggestions, received today, and some more ideas 
> besides, here's the latest megapatch.
> 
>  - Move all register I/O into a new file
>  - Move event handling into a new file
>  - Move headers to acpivar/acpireg/acpiio
>  - Move find-RSDT and find-ACPI-owened-memory into acpi_machdep
>  - Allocate all resources (except OperationRegions in AML) using
>real resources.  AML fix will now be easy though.
>  - Remove all ACPI #ifdefs
>  - Minor style and commenting fixes
>  - Removed unnecessary #includes
> 
> Please test this; there are lots of opportunities for error in these 
> changes.  In particular, I am afraid that I may have broken I/O from AML 

I did test it, S1, S5 transition, PowerResource On/OFF and GPE handling
by kernel thread, everything seems OK!
I think nobody has objections for your commit.  I also have something to
commit (SleepOp/StallOp, acpi_disable_events()), I'll do it after you.

> bytecode.  Hopefully with this committed I can finally get to work on the 
> thermal management. 8)

Cool.  On some machine, thermal management requires Embedded Controller I/O.
Anybody working on this?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

Hi,

> > Cool.  On some machine, thermal management requires Embedded Controller I/O.
> > Anybody working on this?
> 
> Yeah.  I just discovered that I need this. 
> 
> I haven't look at how operation regions are handled, so I'm not sure how 
> hard it's going to be to implement the hooks necessary for this.

Some VAIOs, ThinkPads require this too, luckily my PORTEGE doesn't. 
I can test the thermal management code earlier :-)

> There is another major problem here too.
> 
> Some complete idiot in the ACPI team decided that the "right" way to 
> implement hysteresis for the temperature settings was to have the system 
> send a Notify(zone, 0x80) to the thermal zone and then have it re-parse 
> it's AML to discover new settings.  This means that you need to keep a 
> pointer to the *original* location of the AML for at least some methods 
> inside a thermal zone, if not the entire zone itself.
> 
> My laptop does this too.  8(

PowerResource code keeps pointers to the PowerResource objects, then
finds a pointer to methods of the object dynamically.  Can we do it in
similar way for thermal management?

> I haven't looked at the ACPICA code yet, but it wouldn't surprise me if 
> all the embedded controller stuff is already supported there.  How bad do 
> you think it's going to be to make it work?  You've already looked at the 
> modifications that the Linux people have made - were they just bug fixes, 
> or are there serious problems with the code?

I didn't read closer, but I couldn't find any embedded controller
stuff in both linux-2.4.0-test8 and acpica-unix-2901 except for
definitions in header files.
Subsystem/Include/acinterp.h:AcpiAmlEmbeddedControllerSpaceHandler in acpica,
drivers/acpi/include/interp.h:acpi_aml_embedded_controller_space_handler in linux.

I guess this function will be implemented in interpreter/amregion.c in future.

Last time I compared only few files and found many differences between
them not only for naming.  I think these two used the same code
originally, but enhanced separately.  Now that it's difficult to
compare them...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

> >>> Cool.  On some machine, thermal management requires Embedded Controller I/O.
> >>> Anybody working on this?
> >> 
> >> Yeah.  I just discovered that I need this. 
> >> 
> >> I haven't look at how operation regions are handled, so I'm not sure how 
> >> hard it's going to be to implement the hooks necessary for this.
> > 
> > Some VAIOs, ThinkPads require this too, luckily my PORTEGE doesn't. 
> > I can test the thermal management code earlier :-)
> 
> Swine. 8)

Yes :-)

> > PowerResource code keeps pointers to the PowerResource objects, then
> > finds a pointer to methods of the object dynamically.  Can we do it in
> > similar way for thermal management?
> 
> Well, yes, but you have to go back and re-parse the actual AML.  I'm not 
> even sure if it's safe to assume that the thermal zone is in the same 
> place in the bytecode (it should be, I guess).

I also think it shoud be...

> I went reading through the ACPICA documentation to work this out.  They 
> acually have a very nice technique where they attach the I/O handlers to 
> a point in the namespace, and then when something attempts I/O, they 
> travel back up the namespace to the root, looking for the first matching 
> I/O handler.
> 
> This means that when your EC driver finds an embedded controller, you 
> just attach your I/O handler to the EC object.  Then anytime someone 
> tries to do I/O to the EC, your handler gets called.

Yes, we can have large benefit by migrating to ACPICA.  I suggest that
we make ACPICA version of AML interpreter run in userland as a
debugger for the first evaluation.  By doing this work we can make
sure it works actually on FreeBSD and estimate the work volume of
kernel porting.  Also we know the amldb is very useful from our
development experience.
Another suggestion is that this migration should be done prudently.
During ACPICA porting, we add ACPICA compatible wrappers to current
aml code (e.g. AcpiWalkNamespace() -> aml_apply_foreach_found_objects())
and modify acpi driver code so that we migrate to ACPICA smoothly.

BTW, last time Watanabe-san tried to write EC stuff, but unfortunately
his laptop was broken *twice* by testing.
Be careful, otherwise your Dell will go to the hospital 8)

> I can write the driver easily enough, but I don't know how I/O is 
> currently handled in the AML interpreter.  The more I look at ACPICA, the 
> more I like the idea of using it, presuming that it actually works...
> 
> > Last time I compared only few files and found many differences between
> > them not only for naming.  I think these two used the same code
> > originally, but enhanced separately.  Now that it's difficult to
> > compare them...
> 
> Hmm.  I guess I should spend some more time looking at this.  I don't 
> mean to devalue all the work that's been put into the current AML code, 
> but ACPICA has already solved a lot of the problems that we haven't even 
> touched yet (Notify, locking, etc...)

OK, before making our decision, I want to make sure something.
 - Licence
   Linux folks apply GPL for it.  Is it possible to apply BSD style
   licence for FreeBSD version of ACPICA?  or should we put it sys/contrib?
 - Support from Intel
   My major concern is this one.  I wonder whether our local changes
   for ACPICA can feed back to original code. If not, maintenance will
   become hard...

Thanks




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

> > Yes, we can have large benefit by migrating to ACPICA.  I suggest that
> > we make ACPICA version of AML interpreter run in userland as a
> > debugger for the first evaluation.  By doing this work we can make
> > sure it works actually on FreeBSD and estimate the work volume of
> > kernel porting.  Also we know the amldb is very useful from our
> > development experience.
> 
> Indeed.  I've just taken the hard path to start with, and got the kernel 
> integration (mostly) resolved.  Fortunately, the ACPICA code includes a 
> complete user-space ACPI interpreter for just this purpose.  I think some 
> of their test code has rotted a bit (eg. their AcpiDump tool), but it 
> shouldn't be too hard to get this going.

I and acpi-jp folks discussed ACPICA migration last night, there is no
objections so far.  Most of them agreed that evaluation must be done
at least.  Some people already started lerning ACPICA with documents and
source code.
Mike, I'm feeling we need to have a migration plan.  Do you have any
plan on this?
# I have to learn first before my participation to the discussion :-)

> > Another suggestion is that this migration should be done prudently.
> > During ACPICA porting, we add ACPICA compatible wrappers to current
> > aml code (e.g. AcpiWalkNamespace() -> aml_apply_foreach_found_objects())
> > and modify acpi driver code so that we migrate to ACPICA smoothly.
> 
> This would be very difficult.

OK, but I'll try, this will be my private project.  I won't complain
anything if most of the code is deleted after migration.  I hope I'll
get some understanding on ACPICA programming.

> > OK, before making our decision, I want to make sure something.
> >  - Licence
> >Linux folks apply GPL for it.  Is it possible to apply BSD style
> >licence for FreeBSD version of ACPICA?  or should we put it sys/contrib?
> 
> The Intel licence on the "generic Unix" version of ACPICA is suitable for 
> direct inclusion in FreeBSD.  I'm not sure that the Intel code shouldn't 
> be in sys/contrib *anyway*.

I see.  I found that we may have additional license terms, but I leave
it to your discretion.

> >  - Support from Intel
> >My major concern is this one.  I wonder whether our local changes
> >for ACPICA can feed back to original code. If not, maintenance will
> >become hard...
> 
> If we do things right, we should have little trouble with this.  We have 
> some pretty good relations with the right parts of Intel, and as long as 
> we keep the code changes clean, they should be happy to accept them.

OK.

> Given how much work the Intel people went through just to get their code 
> into the Linux kernel, I think they will find us *much* more friendly. 8)

# Welcome new committers from Intel :-)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Interesting AML bug... recommended workaround?

[Mitsuru IWASAKI]

> Here's what seems to be an interesting AML or AML parser bug.
> 
>   OperationRegion(PSRG, SystemMemory, 0x0410, 0x1)
>   Field(PSRG, DWordAcc, NoLock, Preserve) {
>   ,   2,
>   PS2E,   1
>   }
> 
> The field is marked for 32-bit access, but the region is only 1 byte 
> wide.  What's the correct thing to do here?  Expand the region to 
> accomodate the field's access requirements?  Constrain the access size of 
> the field to that of the region?

I thought read 32-bit, update target bits, write back whole 32-bit for
updating.  For reading value, read 32-bit and shift & mask bits as well.
I hope I could understand description in Spec 15.2.3.3.1.9; "If desired,
AccessType can be used to force minimum access width."

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

> Actually, I couldn't make CVS do what I wanted, so it's a big tarball 
> with an itty-bitty little patch instead.
> 
> This requires an up-to-date -current kernel (for the pci_cfgreg changes, 
> etc.)
> 
> I haven't done anything special with newbus attachments yet, and the 
> embedded controller stuff is still broken, but this should compile and 
> run.  It needs resource management work (only interrupts are handled 
> correctly) and lots of event handlers and so on, but it should be a good 
> foundation to start with.

Great!  This is really great!!  I didn't think we can have ACPICA
kernel so earlier.

> Comments and suggestions would definitely be appreciated.
> 
>  http://people.freebsd.org/~msmith/acpica-bsd-20001002.tar.gz

OK, I have a patch for AcpiOsSleep and AcpiOsSleepUsec which I was
involed in recently.
For Semaphore, mtx_* (ported from BSD/OS?) is used in your implementation.
I just wonder if NetBSD people will use traditional lock...

--- OsdSchedule.c-  Mon Oct  2 18:20:32 2000
+++ OsdSchedule.c   Mon Oct  2 18:34:24 2000
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * This is a little complicated due to the fact that we need to build and then
@@ -112,11 +113,20 @@
 void
 AcpiOsSleep (UINT32 Seconds, UINT32 Milliseconds)
 {
-tsleep(NULL, 0, "acpislp", (Seconds * hz) + Milliseconds / (1000 * hz));
+inttimo;
+
+timo = (Seconds * hz) + Milliseconds / (1000 * hz);
+if (timo == 0) /* 0 means no timeout... */
+   timo = 1;
+tsleep(NULL, 0, "acpislp", timo);
 }
 
 void
 AcpiOsSleepUsec (UINT32 Microseconds)
 {
-tsleep(NULL, 0, "acpislp", Microseconds / (100 * hz));
+if (Microseconds > 1000) { /* the interpreter will be released */
+   AcpiOsSleep(0, Microseconds / 1000);
+} else {
+   DELAY(Microseconds);
+}
 }


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

> > Great!  This is really great!!  I didn't think we can have ACPICA
> > kernel so earlier.
> 
> Well, let's see if it works right first.  8)  I hear from Intel that they 
> plan to release a new code revision today, so I will be updating when 
> they do.  I also hear that Andrew Grover (the chap at Intel that's been 
> answering my mails) has just joined acpi-jp (G'day!).

Welcome to acpi-jp ML, Andrew and Mike!
I've just tried acpica-bsd-20001003, this is greater than before :-)
It seems GPE events are handled correctly on my PORTEGE.

BTW, System sleep transition and PowerResource manipulation are not
implemented yet where we have done already.
# I'm not sure we did in right way though :-)

How is the status on them?  May I try to implement them porting our old code?

> > OK, I have a patch for AcpiOsSleep and AcpiOsSleepUsec which I was
> > involed in recently.
> 
> Thanks, I've incorporated it.

Ack, thanks.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Recent kernels won't boot

[Mitsuru IWASAKI]

> On Sat, Oct 07, 2000 at 03:30:25PM +0100, Bob Bishop scribbled:
> | Kernels built from recent cvsup (<24 hrs) quit immediately on boot, back to
> | the BIOS, no messages no nothin'.
> 
> Try removing the ACPI options in kernel and apply Mike Smith's latest
> ACPI megapatches.  Please also include info on your hardware/BIOS when
> your system cannot boot like your situation.

I encountered the same problem in opposite condition.
I think ACPI is not related with this problem, it was simply 
kernel size ( >4MB) for me.  I removed some device drivers and options
from my kernel config then the problem was solved.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Recent kernels won't boot

[Mitsuru IWASAKI]

> That was it. Is the 4MB kernel size limit documented anywhere?

I don't know :-)   I luckily noticed this by a lot of trials.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Recent kernels won't boot

[Mitsuru IWASAKI]

> I'm not aware of any 4MB limit on kernel size (and I ought to be if there 
> is one 8).  Can you run the details past me?  (I've regularly booted much 
> larger kernels in the past...)

OK, I built 5 kernels based on the same kerne config file giving some
modifications.  Here is the result.

boot?   kernel size description ( (+)Add  (-)Delete )
---+---+--
OK   4007152(+)device acpica
NG   4182845(+)device acpica (+)options ACPI_DEBUG
OK   4011963(+)device acpica (+)options ACPI_DEBUG (-)USB stuff
OK   3470869GENERIC
OK  1600config -g GENERIC

Mysteriously, kernel.debug (16MB) does boot...
Ah, probably section size limitation?

% size ACPICA/kernel* GENERIC/kernel*
   textdata bss dec hex filename
3176366  370104  172152 3718622  38bdde ACPICA/kernel.big
3058264  346724  165848 3570836  367c94 ACPICA/kernel.normal
3009909  368024  169688 3547621  3621e5 ACPICA/kernel.small
2745241  206872  152184 3104297  2f5e29 GENERIC/kernel
2745241  206872  152184 3104297  2f5e29 GENERIC/kernel.debug

Maybe /boot/ stuff is reltated with this too.
% ls -ltR /boot
total 908
drwxr-xr-x  2 root  wheel3072  10/ 8 15:50 kernel
-r-xr-xr-x  1 root  wheel  159744  10/ 8 15:49 liloboot
-r-xr-xr-x  1 root  wheel  157696  10/ 8 15:49 pxeboot
-r-xr-xr-x  1 root  wheel  157696  10/ 8 15:49 cdboot
drwxr-xr-x  2 root  wheel 512  10/ 8 15:49 defaults
-r-xr-xr-x  1 root  wheel  155648  10/ 8 15:49 loader
-r--r--r--  1 root  wheel7680  10/ 8 15:49 boot2
-r--r--r--  1 root  wheel 512  10/ 8 15:49 boot1
-r--r--r--  1 root  wheel 512  10/ 8 15:49 boot0
-r--r--r--  1 root  wheel 512  10/ 8 15:49 mbr
drwxr-xr-x  2 root  wheel 512  10/ 7 11:29 kernel.old
-rw-r--r--  1 root  wheel7816  10/ 6 02:08 loader.conf
-rw-r--r--  1 root  wheel1440  10/ 4 19:23 device.hints
-r-xr-xr-x  1 root  wheel  155648  10/ 2 16:35 loader.old
-r--r--r--  1 root  wheel7577   9/27 10:57 loader.4th
-r--r--r--  1 root  wheel   35170   9/27 10:57 support.4th
drwxr-xr-x  2 root  wheel 512   9/16 18:33 modules
-rw-r--r--  1 root  wheel  24   8/ 4 23:58 kernel.conf
-r--r--r--  1 root  wheel   12064   4/17 16:33 loader.help
-r--r--r--  1 root  wheel 338   1/31  2000 loader.rc

/boot/kernel:
total 8536
-r-xr-xr-x  1 root  wheel20741  10/ 8 15:50 if_wi.ko
:
-r-xr-xr-x  1 root  wheel15097  10/ 8 15:49 3dfx.ko
-r-xr-xr-x  1 root  wheel  3891459  10/ 8 15:40 kernel

/boot/defaults:
total 8
-r--r--r--  1 root  wheel  7979   9/19 04:38 loader.conf

/boot/kernel.old:
total 3768
-r-xr-xr-x  1 root  wheel  3844898  10/ 7 11:29 kernel

/boot/modules:


Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Recent kernels won't boot

[Mitsuru IWASAKI]

> >> > That was it. Is the 4MB kernel size limit documented anywhere?
> >> 
> >> I don't know :-)   I luckily noticed this by a lot of trials.
> > 
> > I'm not aware of any 4MB limit on kernel size (and I ought to be if there 
> > is one 8).  Can you run the details past me?  (I've regularly booted much 
> > larger kernels in the past...)
> 
> I think the PSE optimization may limit us to a 4mb kernel size?  Perhaps
> options DISABLE_PSE would work around it then?

I tried `options DISABLE_PSE', but no effect...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI and Sony laptop

[Mitsuru IWASAKI]

Hi,

> Also, if I compile device acpica into the kernel, it hangs probing and
> attaching ACPI stuff. In particular, it gets a little further if I put
> an ENXIO at the start of acpi_tz's attach routine, but after doing that
> a couple times in acpi_*_attach() I gave up. I don't see a lot in the
> recent archives of -current, so either everyone but me is running with
> ACPI happily or everyone knows to keep away. I'm not sure which. :-)

I have 3 machines with ACPI BIOS here, I have no serious problems
with ACPICA code luckly (or unfortunately? :-) 
However It seems that there are some bugs in ACPI CA code, acpi-jp
folks and some developers from Intel are discussing this sometimes at
[EMAIL PROTECTED]

The problem you are having is reported by VAIO Z505JX user; some ACPI
methods seems cause infinite loop within the method.
Unfortunately we haven't find the effective solutions for it.  Could
you disable dev/acpica/acpi_*.c lines in sys/conf/files and see which
module cause this hang?

Oh yes, and please dump your Z505JE's DSDT data with `acpidump -o' and
send it for us.  This would be useful for debugging.

> Those paying attention on -hackers know I've offered a prize for a
> jogdial driver. I've gotten some stuff off the web and am hoping to take
> a crack at a spic driver (Sony Programmable I/O Controller), but I think
> I need working ACPI first.

Sounds interesting :-)

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: dev/acpica/acpi.c - minor patch for cleaner poweroff

[Mitsuru IWASAKI]

Hi,

> I think you're the main maintainer of the ACPICA codebase (and yes, I know
> that parts of it is imported from Intel).  Attached is a trivial patch which
> makes for cleaner testing for RB_POWEROFF in acpi_shutdown_final() - I've had
> various kernel/userland routines invoke reboot sequences where the howto had
> more bits set than RB_POWEROFF, e.g. RB_NOSYNC.  With this patch, shutdown -p
> works for me :)

Thanks, this patch looks good.  I'll fix this soon.
I'm sure mike will agree on it :-)

> Thanks for all the work on ACPICA :)
> 
> G'luck,
> Peter
> 
> PS. Please CC: me in replies as I'm not on -current.
> 
> -- 
> If I had finished this sentence,
> 
> Index: acpi.c
> ===
> RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v
> retrieving revision 1.7
> diff -u -r1.7 acpi.c
> --- acpi.c2000/12/12 14:20:27 1.7
> +++ acpi.c2000/12/18 14:55:43
> @@ -657,7 +657,7 @@
>  {
>  ACPI_STATUS  status;
>  
> -if (howto == RB_POWEROFF) {
> +if (howto & RB_POWEROFF) {
>   printf("Power system off using ACPI...\n");
>   if ((status = AcpiSetSystemSleepState(ACPI_STATE_S5)) != AE_OK) {
>   printf("ACPI power-off failed - %s\n", acpi_strerror(status));
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

CFR: Generalized power-management interface

[Mitsuru IWASAKI]

Hi,

I've created new common framework on generalized power-management
interface for userland utilities.

http://people.freebsd.org/~iwasaki/acpi/power-20001229.tar.gz

This provides some PM APIs to APM applications, such as wmapm, so that
these applications can be ported smoothly to use ACPI (power
management portion).  Currently following APIs are implemented;

int  power_get_syspm_info(struct power_syspm_info *);
int  power_get_batt_info(u_int, struct power_batt_info *);
int  power_standby(void);
int  power_suspend(void);
int  power_hibernate(void);

And PM event notification mechanism is suggested to be implemented so far.

Sample application is included in usr.sbin/power/ which is very similar
to apm(8) but supports ACPI as well.

usr.sbin/acpi/acpibatt/ is for displaying acpi_cmbat (ACPI Control
Method Battery), can be used to verify that generalized
power-management interface is working correctly.
Note that many ACPI BIOS give us unknown battery remaining time when
ac-line is plugged in.  MIB 'hw.battery.full_charge_time' can be used to
specify the full charged remaining time of batteries in minutes, like
sysctl -w hw.battery.full_charge_time=60,60
for multiple number of batteries, or
sysctl -w hw.battery.full_charge_time=120
for a battery installed.

To test them, /dev/power is required as a device control file.

% ls -l /dev/power
crw-r--r--  1 root  wheel  210,   0  12/19 04:51 /dev/power

I'll commit them at sometime early in coming century.

Any comments would be appreciated.  Thanks!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Fan speed control sony vaio lx800 slimtop

[Mitsuru IWASAKI]

Hi,

> Now I'd like to figure out how to turn the damn fan up and down.  This
> machine is quiet under windows but sets the fan to high under FreeBSD
> and never turns it down.  The fan has three settings - 0V, 6V and
> 12V.  Under windows it stays between 0 and 6V.

Thermal management implementation is in our queue.  We'll create
policy manager for ACPI subsystems including thermal (Active, Passive
cooling etc.).  Of course any help would be welcome :-)

> I've tried "apm -h 1; apm -e 1;" hoping something would happen
> but it still doesn't slow down the fan.

Currently we don't have any means to control fan device (except for
the machine specific tools).

> If someone can sketch out a road map of what I should do I'll do the
> dirty work.  I don't know about ACPI etc and so would appreciate a
> kick start.  I've picked up the spec but haven't printed it out yet.

You could find `3.10 Thermal Management' for overview and
`12 THERMAL MANAGEMENT' for detail in ACPI 2.0 spec.  Also
`7.1 Declaring a Power Resource Object' and `10.6 Fan Device'
may help you.

[EMAIL PROTECTED] is a mailing list for ACPI development.
# English and Japanese are mixed :-)
If you are interested in it, please send a mail to
[EMAIL PROTECTED] with
subscribe acpi-jp
on body.

Thanks



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pmtimer

[Mitsuru IWASAKI]

Hi,

> I'm not sure what pmtimer is supposed to do. Isn't it supposed to give
> support for the broken statclock on laptops? I saw my friend running 4.1
> with some patches that allowed him to use the statclock (and the rtc
> device showed up in systat -vm 2) On my laptop, pmtimer doesn't appear to
> do anything; and I couldn't find a manpage on it

Please refer to src/UPDATING for -current.
The new pmtimer device is necessary for laptops.  Failure to
include the device will cause suspended laptops losing time
when they resume.

Currently pmtimer won't solve the broken statclock problem...
The timer related code at suspend/resume time have been moved from APM
to pmtimer so that ACPI (includes new power management system) use
pmtimer at sleep/wakeup time as well.

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Fan speed control sony vaio lx800 slimtop

[Mitsuru IWASAKI]

> Note also that Scott Long ([EMAIL PROTECTED]) is also working on this, 
> you will want to check with him to work out where he's up to...

OK, I intended to try acpi_thermal hacking for the next target, now
I can be a tester and feed back something for Scott's hack :-)

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message