From:	Harold Roman 978-461-0402 Ext 223 <harold AT giganet DOT com>
Newsgroups:	comp.os.msdos.djgpp
Subject:	CWSDPMI Physical Memory Addresses
Date:	Mon, 26 Oct 1998 17:53:11 -0500
Organization:	GigaNet Inc.
Lines:	52
Message-ID:	<3634FD57.7034AA15@giganet.com>
NNTP-Posting-Host:	207.60.106.223
Mime-Version:	1.0
X-Mailer:	Mozilla 4.04 [en] (X11; U; HP-UX B.10.20 9000/780)
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

I am writing a progam that interacts with a card that does DMA and is
memory mapped. I need to get physical addresses for my data buffers.
I looked through the archives and found a "back door" described by
Charles Sandman (posted 9/22/96). This technique uses the "sgdt"
instruction to find the global descriptor table and the "str"
instruction to find the current task structure. This allows the CR3
value to be read. From there it is a short hop, skip and jump through
the Page Directory and Page Table to translate a virtual to a physical
address.

This worked fine on one machine, but when I ran the same program on
another machine it failed badly. It seems that the gdt is full of
0xffffffff.

I've verified that I'm running the same CWSDPMI on both machines. I've
used __dpmi_get_version() and looked at _go32_info_block and I can't
find anything wrong.


On the good machine I see:

sgdt returns  00 01 9c 20 00 87  (base: 00019c20  limit: 0087)
memory looks like:
00019c20:  00 00 00 00 00 00 00 00
00019c28:  00 00 92 01 9c 20 00 87
00019c30:  00 00 92 01 90 20 07 ff
00019c38:  00 00 9b 01 42 20 ff ff
...


On the failing machine I see:

sgdt returns 00 0d e3 8a 00 87 (base: 000de38a  limit: 0087)
memory looks like:
000de38a: ff ff ff ff ff ff ff ff
000de392: ff ff ff ff ff ff ff ff
000de39a: ff ff ff ff ff ff ff ff
000de3a2: ff ff ff ff ff ff ff ff
...


The limit of the gdt is the same in both cases, but it's base is quite
different, and the allignment looks bad in the second case, hmmm....

The problem is not complicated, sgdt is returning a pointer to something
that just can't possibly be the gdt, and I can't figure out what's
wrong. Is sgdt failing? Is CWSDPMI runing a different memory mode? Any
thoughts or clues would be greatly appreciated.

- Raw text -