|Michael Smith||Jun 1, 1996 10:38 pm|
|HOSOKAWA Tatsumi||Jun 2, 1996 12:47 am|
|Michael Smith||Jun 2, 1996 1:11 am|
|HOSOKAWA Tatsumi||Jun 2, 1996 2:09 am|
|Michael Smith||Jun 2, 1996 2:17 am|
|Michael Smith||Jun 2, 1996 3:10 am|
|HOSOKAWA Tatsumi||Jun 2, 1996 3:41 am|
|Nate Williams||Jun 3, 1996 7:42 am|
|Michael Smith||Jun 3, 1996 7:21 pm|
|Nate Williams||Jun 3, 1996 9:00 pm|
|Michael Smith||Jun 3, 1996 10:16 pm|
|Nate Williams||Jun 4, 1996 8:08 am|
|Nate Williams||Jun 4, 1996 8:23 am|
|Michael Smith||Jun 4, 1996 8:38 am|
|Nate Williams||Jun 4, 1996 8:54 am|
|Michael Smith||Jun 4, 1996 9:02 am|
|Subject:||Re: Laptop hardware FOUND|
|From:||HOSOKAWA Tatsumi (hoso...@mt.cs.keio.ac.jp)|
|Date:||Jun 2, 1996 3:41:03 am|
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.
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.)