From owner-freebsd-mobile  Sun Jun  2 03:42:26 1996
Return-Path: owner-mobile
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id DAA13931
          for mobile-outgoing; Sun, 2 Jun 1996 03:42:26 -0700 (PDT)
Received: from frig.mt.cs.keio.ac.jp (frig.mt.cs.keio.ac.jp [131.113.32.7])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA13903;
          Sun, 2 Jun 1996 03:42:03 -0700 (PDT)
Received: (from hosokawa@localhost) by frig.mt.cs.keio.ac.jp (8.6.12+2.4W/3.4Wbeta3) id TAA03106; Sun, 2 Jun 1996 19:41:23 +0900
Date: Sun, 2 Jun 1996 19:41:23 +0900
Message-Id: <199606021041.TAA03106@frig.mt.cs.keio.ac.jp>
To: msmith@atrad.adelaide.edu.au
Cc: hardware@FreeBSD.org, mobile@FreeBSD.org, hosokawa@mt.cs.keio.ac.jp
Subject: Re: Laptop hardware FOUND
In-Reply-To: Your message of Sun, 2 Jun 1996 19:40:50 +0930 (CST).
	<199606021010.TAA27202@genesis.atrad.adelaide.edu.au>
From: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi)
X-Mailer: mnews [version 1.18PL3] 1994-08/01(Mon)
Sender: owner-mobile@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

>> Ok.  Please patch your apm.c sources so that the APM_DSVALUE_BUG
>> code uses apm_bios_work not apm_bioswork, and and M_DEVBUF not M_DEVBUG,
>> as otherwise it won't compile 8)

This typo has been fixed by our latest pccard package :-).

>> With APM_DEBUG, FORCE_APM10, APM_DSVALUE_BUG and APM_BROKEN_STATCLOCK,
>> now reads 'Data 0xf084d000'.  'apm' still causes a trap 12 at
>> 0x48:c43e with fva 0xfd45.
>> 
>> Next? 8)

I have no idea :-).

Trap 12 of 386 architecture is "stack fault".  This probably means
that intersegment call/return to APM BIOS or internal procedure of APM
BIOS causes stack overflow or underflow.

But I think that intersegment call/return (yes, I wrote it) is not
guilty because this is machine-independent operation, and the trap
happens at 0x48:c43e.

0x48 means that segment index is 0x9 and priv. level is zero.
Hmm... Index 0x9????  Index 0x9 is 16bit APM API segment. 32bit API
segment is 0x8.  Why?

Target of the APM driver is set at apm_addr in apm.c.  I believe that
apm_addr is set to 0x40:(sc->cs_entry) at apmattach(), but the trap
happens at 0x48:xxxx???

        apm_addr.segment = GSEL(GAPMCODE32_SEL, SEL_KPL);
        apm_addr.offset  = sc->cs_entry;


GAPMCODE32_SEL is 8 and SEL_KPL is 0, and GSEL is 

#define GSEL(s,r)       (((s)<<3) | r)                  /* a global selector */

(in machine/segments.h) so, GSEL(GAPMCODE32_SEL, SEL_KPL) should be
0x40....

I'm confused now.... (but it should not be the problem because probe
message says that the 16bit API address is same as the 32bit API
address.  In such case, APM is written in machine opecodes that do not
changes their behavior whether CPU is in 32bit mode or 16bit mode.)

--
	HOSOKAWA, Tatsumi              E-mail: hosokawa@mt.cs.keio.ac.jp
	  WWW homepage: http://www.mt.cs.keio.ac.jp/person/hosokawa.html
	Department of Computer Science, Keio University, Yokohama, Japan