.fo off
This is file: 09_95QA.TXT

This file contains questions asked of the Driver Development Support Center
(DDSC) and the answers given to that particular question.  Entries are
appended to the top, so the most recent entry is available first.

Each entry starts with a header line that has a KEY WORD (or words) included
to allow the reader to "search" on KEY WORDS of particular interest.  Each KEY
WORD starts with the exclamation point character (!).  This allows for search
arguments that will limit matches to the header lines.

The following KEY WORDS are supported in this file.

KEYWORD                      DEVICES/TYPES OF QUESTIONS
===========   ==========================================================
!BASE         Loader, Memory Management, Strategy/Architecture
!I/O          Serial/Parallel, Pointing Device, Trackball, Keyboard, Pen
!MULTIMEDIA   Motion, Sound
!NETWORK      LAN,
!OTHER        PCMCIA, APM, Miscellaneous
!PRINT        Printer, Scanner
!STORAGE      DASD, SCSI, Tape, CD-ROM, ASPI, IFS
!VIDEO        VGA, SVGA, XGA, 8514, Display
**********    Entry separator (10 *'s)
==============================================================================
!DISPLAY________________________________**********
September 1, 1995
QUESTION: (Ref: IB7)
We have a combination SVGA display and image capture board.  The design is to
use the SAME memory for both the SVGA display and the image
captured/overlayed.  This is a problem as far as I can see.

The APIs assume that a KeyColor is used to determine where to overlay the
video into the output stream.  The FlashPoint has a seperate memory block
which is a bit field as to whether to use the overlay live/capture or the SVGA
image.


1) Integral would like the VSD written entirely at ring 3 and is willing to
forgo the streaming protocol.  Are there any obvious pitfalls that I should be
concerned about in this sort of methodoligy?  At some point I suspect that I
will want to perform streaming, but not for this bid.

Potential problem 1) Generally slow behavior.

(Based upon my Targa+ driver, it LOOKS like there should be no problems, but
there will not be a file handle for the MMOS/2 subsystem directly.  It will
have one indirectly from thier support DLL.)


2) When is the key color written?
Solution 2) Monitor the whole display for the key color to use and when
            found, set the bit image.  This would be very slow and ugly.
            Additionaly, I would have to monitor the PM message queue to
            determine whether the window has been covered.

3) Is there some mechanism (like in Windows) the a callback can be setup to be
invoked whenever the video painting region changes so that I could change the
board's bit map?

4) Can I suppress the painting of the video keyer color?


I can use the destination rectangle to determine where to punch my hole in the
screen.  I think if I try this and the window is partly covered, I will have a
video mess.  Integral is willing to allow a messy display (covering windows
get trashed) if it will work most of the time.

As stated, the board does NOT use color keying AT ALL to determine where to
capture/display.



ANSWER:
Currently, the MMPM/2 Architecture/Code does not support video overlay via
shared frame buffer.  The GOOD NEWS is we are working on it and it doesn't
appear to be a big change.  The changes will involve the MCD passing the list
of visible rectange for the window to the VSD as a part of the
VSD_SETVIDEORECT command.  The MCD already uses the Visible Rectangles for
software video monitor so to pass them to the VSD should be fairly simple.
Some Shared frame buffer devices may also require us to allocate offscreen
VRAM from the display driver through the ENDIVE interface.

In answer to you specific questions:
1) Writing Driver entirely at Ring 3. This shouldn't be a problem other than
the ones you noted.  Currently the MCD expect any card that can monitor can
also record but this is also being fixed as we speak.

2) When is Key Color written.  Currently the Key Color is only painted when
the window is uncovered or resized, As a part of the shared frame buffer
updates to our MCD we expect that we will not paint the the monitor window for
cards that are using clipping rectangles instead of Key Color.  So with the
new updates the when the window is covered or uncovered the MCD will skip the
window paint and call the VSD with the new list of Visible Rectangles.  3)
Call back function for window visible regions.  Yes OS/2 has such a function.
The MCD is using the callback today and now will report it to the VSD.  4) Can
key color painting be suppressed.  Not at the present time, but we are fixing
this as noted above.  Currently it looks like we will be defining a new card
type that act like overlay (inlay) except the key color is not painted and the
VSD_SETVIDEORECT call from the MCD to the VSD will have a Visible Rectangle
list appended to it.




!DISPLAY________________________________**********
September 1, 1995
QUESTION: (Ref: IC7)
We encounter a problem when we switch sessions between PM and a FS WINOS2
session.

Windows 3.1 in any resolution x 64k or 16m colors.  The screen shows the
following message:

        The system detected an internal processing error at location
        #0170:fff8905a -- 000f:0004e05a
        line 650, in file 7026 @(#) vdmpage.c 6.9 92/06/03
        VDHReallocPages:Invalid Parameter

What do we need to concern ourselves with when we develop 64K & 16M colors
driver?


How can we fix this problem?



ANSWER:
There are multiple design issues to co-ordinate switching between PM and Full
screen Windows 3.1.  display driver.  Refer to Chapter-8 "Seamless Windows
Support" in "Display Device Driver Reference".

The off-screen video memory is typically employed to permit access to this
resource for both the PM and seamless windows drivers.  Alternatively dynamic
allocation or total dedication of the memory to one driver is used.  At a
minimum, both the PM and seamless windows driver character caches are
maintained in off-screen video memory for the sake of performance.  For 64k X
16M colors drivers the memory requirement would be more.  VWIN, the special
virtual device driver shares all windows and PM desktop windowing state
information.  As per your provided information the VDM tries to reallocate or
resize memory object via VDHReallocPages Virtual DevHelp call and fails to
succeed.  This might be due to the number of pages of memory could both be
expanded or shrinked.

You could also look into the optional disk - MS Windows V3.1 DDK modified
code which contains sources for WIN-OS/2 Mouse, WIN-OS/2 Serial and
WIN-OS/2 Seamless VGA.

You can use the OS/2 Debug Kernel, which should be at the same level as the
retail version. The debug terminal is hooked-up to the machine under test
through the serial port. Just make sure that the symbol filename is the
same as the driver itself with extension .SYM.




!PRINT__________________________________**********
September 1, 1995
QUESTION: (Ref: IF9)
I want to develop a new 32-bit printer driver that works with both OS/2 2.11
and Warp.  Which sample code do I start with- Minidriver 1, Minidriver 2, or
the OMNI code?  I noticed that the OMNI code is not on the latest DDK.  Where
can I get it (if that is the correct code to start with)?


ANSWER:
There are no plans for the OMNI code to be included in the DDK.  MiniDriver 1
Code is available in DevCon DDK 2. It is a good starting point for a 32 bit
printer driver which works both in OS/2 2.11 & Warp.  The MiniDriver 2 Code
would work only in Warp(GRE Version 220).

Also, download MINIDRV1.TXT from the MAIN file area.




!OTHER__________________________________**********
September 1, 1995
QUESTION: (Ref: IG2)
We need to provide presence-check functionality in order to be considered for
future bundling.  We have the TESTCFG directory from vers.  2, vol.  7 of the
DDK, but testcfg.c only detects EISA, ISA and MicroChannel buses.  Do you have
a version of testcfg.c that will allow us to read pci configuration space?

ANSWER:
There is no special version of testcfg.c, but OEMHLP.ZIP from the DUDE BBS has
this information.  There is information in this file on how to access the PCI
configuration space.




!STORAGE________________________________**********
September 5, 1995
QUESTION:  (Ref: IA6)
I have discovered why I am unable to see my transient piece of code from
DEBUGO when the filter is doing its INIT processing.  It appears that OS/2
rewrites the master boot record and eliminates mine.  Will my filter be able
to block the rewrite?  Or will the rewrite not occur if the master boot record
appears to be what OS/2 is expecting?

ANSWER:
A filter can block the write from OS/2 FDISK.




!BASE___________________________________**********
September 5, 1995
QUESTION:  (Ref: ID5)
We have written a device driver to facilitate communications via an OS/2 Warp
box and other CPU's over a common VME bus via shared memory.  The "shared"
memory is addressed out of the way of normal address ranges.  For example:

                VME_PHYS_A16WS  90000000
                VME_PHYS_A24WS  A0000000
                VME_PHYS_A32WS  B0000000

We have been able map this memory with the device helper function
DevHelp_VMAlloc() but have run into the following difficulty.  All linear
address handles allocated appear to be forced to a 4k or page boundary.  For
example, if we allocate linear address handles for the physical memory
addresses 0xb8000, 0xb8001, 0xb8fff, the linear addresses returned actually
points to 0xb8000.  However, if we allocate a linear address handle for
physical address 0xb9000, the handle will actually point to 0xb9000.

I am passing the following value in the flags parameter to VMAlloc():

                0x0410 or 0000001000010000b
                                            ^
                              ; VMDHA_PHYS - If bit 4 (000010000B) is set,
                              ;    then a linear address mapping will be
                              ;    obtained for the physical address
                              ;    passed in the PhysAddr pointer.

I am unsure of the meaning of bit 10, since the PDDREF.INF file that I have
does not mention it; We appear to need it to obtain linear address handles to
"shared" memory.  I'm curious what this bit is?  Is there an updated
reference?  The reference file that I have is:  10-11-94 10:21a 1002531 0
PDDREF.INF.


ANSWER:
The linear address returned by the VMAlloc call will be page aligned.  Bit 10
is not documented in the PDD Ref.  An updated PDD Reference, dated 04-14-95,
is available in DevCon DDK Ver. 2.0.




!OTHER__________________________________**********
September 5, 1995
QUESTION:  (Ref: IE7)
I am writing a program that has to redirect the data stream from the parallel
port to my device (really to the network).  I found that the character monitor
provides this possibility.  But there is no info (samples, description) about
DosMon commands, because those commands are unchanged since OS/2 1.3.  All
books and docs we have refer to OS/2 1.3 books that we don't have.  I didn't
find any description of the character monitor commands in IBM C Set++
references.  There is also no information in the Tool Kit.  Only the DDK
provides some info, but this is not enough for the application layer.  My work-
ing environments are:  OS/2 V2.1/3.0, IBMC Set++, DDK, Tool Kit 2.1.

I have found the DosMon prototypes in the header files and found out that the
monitor functions are placed in the MONCALLS.DLL.  I have tried to load this
dll (successfully), get proc.  addresses (successfully), call it (fail).  I
didn't find any library that provides the monitor commands definition and can
be linked with my program.

Q1.  What do I have to do in order to use the character monitors under OS/2
v2.1 and  higher?

A1.  Refer to the "Physical Device Driver Reference" Chapter on "Character
Device Monitor", for details regarding device monitors.

================================================================
Q2.  Can anybody provide pointers to the samples and documentation?

A2.  There is a sample monitor available in the disk included in the book
"Writing OS/2 2.1 Device Drivers in C, 2nd Edition", by Steven J. Mastrianni

================================================================
Q3.   Can I use IBM C++ (it is 32bit; is the library 32bit as well)?

A3.  Yes, the above said sample uses IBM CSet++.

================================================================
Q4.   What are the libraries that have to be involved in the link process?
(I have tried DISCALLS, OS2286, OS2386 but to no avail).

A4.   The Dos16Monxxx calls are available in os2286.lib and os2386.lib.  The
sample monitor uses icc compiler and it needs os2386.lib and dde4mbs.lib.




!STORAGE________________________________**********
September 5, 1995
QUESTION:  (Ref: I87)
We are developing some security software for OS/2 that requires the use of
filters.  We have taken the LOCKDRV filter from the DDK and used it as a base
for our testing and discovery process.  We developed it to display the packets
received via the COM port used by the debug version of the kernel.  I have
taken the basic loop that looks at all ADDs and UNITs on the system.  As we
gain more understanding of the basic 16-bit BASEDEV land, we will need
access to someone who can answer some questions.

Q1.  I know we need to understand the relationship between the various UNITs
and the INT 13h physical drive number.  This information is needed during the
INIT processing of the filter so the DMD is not present.

A1.  .ADD drivers should be loaded in the same order as adapter ROMs are
scanned.  The load order of ADD drivers is controlled by the ordering of their
BASEDEV statements in CONFIG.SYS.

In general the IDE ADD driver (IBM1S506) is loaded first and then OEM SCSI.ADD
drivers followed by (IBMINT13.I13) for SCSI adapters when no ADD support is
available.

You can determine the UNITs supported by .ADD drivers by obtaining the Device-
Table of each ADD driver registered and scanning the table for UnitType=0
(Magnetic) and !(UnitFlags & UF_REMOVABLE).

See src\dev\dasd\os2dasd\dminit.c(Build_UnitCBs)

===================================================================
Q2.  We also need to know if the broadcast that tells the ADDs that OS/2 is
going to switch from using INT 13h to using the OS/2 protected mode filesystem,
will be sent to our filter.

A2.  All ADD drivers which register via DevHelp_RegisterDeviceClass will re-
ceive the IOCC_CONFIGURATION/IOCM_COMPLETE_INIT IORB.

If you register it is recommended that you provide a DeviceTable when requested
(IOCC_CONFIGURATION/IOCM_GET_DEVICETABLE).  You should fill-in the DEVICETABLE
structure indicating that you support 0 adapters.

===================================================================
Q3.  We may need to do some processing at that time.  At that point in time can
the base memory arena be modified so that memory being used by our loader be
returned to OS/2?

A3.  We do not recommend that you resize the default data segment after INIT-
time.

Instead you can dynamically allocate memory via DevHelp_AllocPhys and map it
using DevHelp_PhysToGDTSelector or DevHelp_PhysToVirt. The choice depends on
the required lifetime of the mapping. To release the memory and GDT selector
use DevHelp_FreeGDTSelector and DevHelp_FreePhys.  Mappings obtained via
DevHelp_PhysToVirt are released automatically.

Instead you can dynamically allocate memory via DevHelp_AllocPhys and map it
using DevHelp_PhysToGDTSelector or DevHelp_PhysToVirt. The choice depends on
the required lifetime of the mapping. To release the memory and GDT selector
use DevHelp_FreeGDTSelector and DevHelp_FreePhys.  Mappings obtained via
DevHelp_PhysToVirt are released automatically.

===================================================================
Q4.  Does your previous response mean that the .ADD drivers will ALWAYS be in
the correct order?  I must be able to map UNITs to physical INT 13h drive
numbers with no possibility of an error.

A4.  No.

===================================================================
Q5.  Our loader is present before even the master boot record code is executed
and we have reserved memory at the top of the conventional memory arena by
reducing the amount reported via INT 12h.  In your previous response, you
stated that "We do not recommend that you resize the default data segment after
INIT-time."  My question is, whose INIT-time, OS2LDR, OS2KER, BASEDEVs?

A5.  The INIT time of the device driver.

===================================================================
Q6.  Does the missing memory block have any impact upon the primary OS/2 memory
block as it does in the Windows VM?  Certain structures and other data items
must be loaded in the lower 640k and reducing that 640k to a lower amount
produces reduced capabilities that we do not want to incur in OS/2.  Any reason
why we should be concerned about OS/2's memory?

A6.  As long as you don't take up too much memory (don't know the exact amount,
but I'd start getting worried after removing about 32kb to 64Kb) you should be
OK.  This should only affect a) the ability of the system to boot (but not per-
formance) and b) the amount of memory available to a VDM.  Windows is DOS based
(uses Real Mode), and thus requires the use of memory below 640Kb.  OS/2 only
uses real mode during boot, then it runs in protected mode and can access all
memory equally.

===================================================================
Q7.  Per your previous response, "In general the IDE ADD driver (IBM1S506) is
loaded first and then OEM SCSI.ADD drivers followed by (IBMINT13.I13) for SCSI
adapters when no ADD support is available."

Here you mention the possibility that INT 13h will still be used to access
some physical drives.  We need to know how to determine this.  What does the
.ADD structures we can see in a filter look like for these drives?  This is
another reason why we will need to be able to map INT 13h drive numbers to
UNITs.

A7.  A suggestion is to search down the device driver tree, after all BASEDEVs
are loaded, looking for block device drivers (excluding floppy drivers).  In the
header of each block device driver, is a field indicating the number of units
attached to the driver.  Through simple arithmetic, you should be able to de-
termine if the IBMINT13 device driver has any devices attached to it and which
drive letter the attached devices are assigned to. Here is the arithmetic:

    'B' + (Number of devices attached to other .ADDs) + (unit number of INT13
    device)

===================================================================
Q8.  Is the source to IBMINT13.I13 available?

A8.  No.




!OTHER__________________________________**********
September 5, 1995
QUESTION: (Ref: IE8)
Could you please help me with the following problem:
I am currently writing a VDD for Network application.  This VDD (one of its
function) should provide the DOS/WIN application with memory buffer.  This
buffer I have allocated with the VDHAllocMem function, but this function
returns FLAT pointer.  I have been tring alot of macroc to conver this pointer
to the pointer applicable for the DOS/WIN appl.  I see that this is not the
pointer that I got from VdhAllocmem.  Could you plese provide me a siquence of
the stepd to pass the FLAT pointer to the DOSD/WIN appl (allocated with
VDHAllocMem) and then to restore its value to free it.

ANSWER:
1. For conversion of Linear Address to Sel:Offset you could invoke the
DosSelToFlat or DosFlatToSel macros (available in DDK).

2. Pointers in a VDM:  DOS applications running in a VDM utilize real mode
addressing.  A 20-bit real mode address in the segment:offset form can refer
to a physical address within the VDM's one megabyte address space.  If the VDM
makes an IOCTL call to your device driver with pointers in the private data
and/or parameter buffers, the driver must take an extra step to ensure the
pointers are converted correctly.  The driver checks the TypeProcess variable
in the local info.  seg structure to determine if the application is a VDM
application.

If it is a DOS application, the driver allocates a GDT selector and converts
the segment:offset address to a VDM-relative physical address by shifting the
segment left 4 bits and adding in the offset.  This is the same way the
physical address is calculated in real mode for a real-mode application.  The
driver then calls LinToGDTSelctor with the 20-bit physical address of the VDM
application's buffer and/or parameter address.  This call maps the 20-bit
physical address to the caller's address using a GDT selector which can be
accessed at kernel or interrupt time.  The selector should be released by a
call to FreeGDTSelector when the driver is finished with it.  It is important
to note that normally, LinToGDTSelector requires a 32-bit linear address and
not a 20-bit physical address.

3. You could also use VDHMapPages Virtual DevHelp call to map the linear
address region in the V86 address space.

Refer "Virtual Device Driver Reference", Chapter 6 "C Language Virtual DevHlp
Services", Section on "VDHMapPages".




!OTHER__________________________________**********
September 6, 1995
QUESTION:  (Ref: ID7)
We are currently in hardware/software integration.  The hardware generates an
interrupt when it has data available for the driver.  When this happens, we
experience an intermittent error that crashes the operating system.  The error
is not 100% repeatable and also varies in repeatability on different computer
platforms.  We are trying to determine whether the problem is being caused by
the hardware or is due to a software collision.

As a debugging aid, I am writing to the serial port from the driver and am
displaying the output on a data analyzer.  The very first thing that the
interrupt handler does is write to the serial port, but that information is
never seen when the crash occurs, indicating that the crash happens after the
interrupt but before the interrupt handler does any processing.

When the OS crashes, the following information is displayed:
----------------------------------------------------------------------------
TRAP 000e  ERRCD=0000  ERACC=****  ERLIM=********
EAX=fff00000  EBX=fff20008  ECX=8001001B   EDX=abdc0000
CS:EIP=2a78:000001bc  CSACC=009b  CSLIM=000002b2
SS:ESP=00e8:000007a2  SSACC=0093  SSLIM=000007ff
DS=2a68  DSACC=0093  DSLIM=00001600  CR0=8001001b
ES=0158  ESACC=c093  ESLIM=ffffffff  CR2=fc8491bc
FS=0000  FSACC=****  FSLIM=********
GS=0000  GSACC=****  GSLIM=********

The system detected an internal processing error at
location ##0160:fff5c364 - 000d:a364.
60000, 9048

05860480
Internal revision 8.209, 94/11/09
----------------------------------------------------------------------------

I am hoping that you can help me to interpret this information in order to get
a better idea of where and why the OS is crashing.  My questions are:

Q1.  What does a trap 000e indicate?

A1.  Trap 000e is a Page Fault.  This fault occurs while translating a linear
address to a physical address when the page table or the page containing the
operand is not present in physical memory.

=====================================================================
Q2.  How can I decode the crash address to determine what the OS was doing
when the crash occurred?

A2.  The contents of CS:EIP registers points to the instrucion to be executed
after the instruction which generated the trap.  The contents of CR2 register
is the 32-bit linear address which generated the trap.

=====================================================================
Q3.  Is there anything else that can be determined from the register dump that
would help me to determine the cause of the problem?

A3.  See above answer (A2).

=====================================================================
Q4.  If the hardware is determined to be functioning properly, do you have any
other suggestions for isolating this bug?

A4.  Since you are trasferring the data in the interrupt handler, you need to
lock the memory.  Make sure your data buffer is locked.

Do you have any buffer which spans 2 non-contiguous (physically) pages?

You could debug your driver using the Kernel Debugger.  That helps you in your
driver development.  Install the "Debug Kernel" in one of the machines which
gets the trap.  Hook it up to a debug terminal.  Make sure you have the symbol
file (.SYM) of the user device driver as well as the system device drivers (this
helps in debugging).  From the debug terminal, invoke "vsf *" and then give "G"
(for GO).  The instruction (and the module) which is causing the trap will be
listed when you get a trap.  This helps in pinpointing the problem.

=====================================================================
Q5.  In a previous inquiry, I asked for help in interpreting the OS/2 register
dump displayed when the operating system crashes.  In your reply you stated
that:

"The contents of CS:EIP registers point to the instruction to be executed
after the instruction which generated the trap.  The contents of CR2 register
is the 32-bit linear address which generated the trap."

Without using the debugger, is there a way to determine which module these
instructions/addresses belong to?

A5.  If your code is generating the trap, then you could determine the module
by using the value in the EIP register and the generated .MAP file.  If the
trap is generated in some system services (.DLL) then you cannot identify
the module using the register values and you need to use the kernel debugger.
You could try the "ln" & "k" commands from the kernel debugger.  This would
list the near symbols around the point the exception occurred.  This could
give you a rough estimate of the module you are in.  You could also use the
"mamc <linear address> command to let you know the module which contains the
linear address.

=====================================================================
Q6.  Also, you suggested that I load the debug kernel and use it to determine
the module in which the crash occurs.  I have loaded and used the debug kernel
supplied with the DDK on a previous occasion, but we were then running OS/2
2.1.  We are now running WARP 3.0 on some machines and WARP Connect on others.
To debug the crash problem I will need the debug kernel for WARP Connect and
possibly also for WARP 3.0.  How can I (quickly) get access to the debug kernels
for both of these versions of OS/2?

A6.  The DevCon Vol 7 contains the kernel debugger for warp internel revision
up to 8.200.  For Warp Connect, the debug kernel is on the Warp Connect CD.
All the CDs include the corresponding debug kernel.





!MULTIMEDIA_____________________________**********
September 6, 1995
QUESTION:  (Ref:  IE1)
*)PROBLEM EFFECT:
=================
When I playback an audio stream, if the application often calls SpiGetTime, the
returned value is occasionally 3 times too large.

*) EXAMPLE :
============
If the application calls SpiGetTime every 1/5 second , SpiGetTime reports a
spurious value (3X greater than it should be) at least once in 12 minutes of
playback.

*)PROBLEM EXPLANATION:
======================
Hardware interrupts from the cards occurs 10 times per second.  Then an
interrupt occurs, if there is an empty buffer, the PDD (audio physical device
driver) calls the audio stream handler using SHD_REPORT_INT (SHD_WRITE_COM-
PLETE).  And it puts the current StreamTime in milli-seconds in "ulStreamTime"
field of "struct SHD_REPORTINT_PARM".  Then, the audio stream handler multi-
plies this value by 3, to have the current stream time in MMTIME unit, and
could give it back to the application.

5 times per second, the application calls the audio stream handler, using
SpiGetTime().  Then, the audio stream handler calls the driver using
DDCMDStatus() to get the current stream time (in milli-seconds).  And, it
multiplies the returned value by 3 to get it in MMTIME unit.  (MMTIME =
1/3000 second).

The bug occurs if, AT ALMOST THE SAME TIME (less than 2 milli-second):

1) the PDD sends streamtime to the stream handler using SHD_REPORTINT.

2) the stream handler get streamtime from the PDD using DDCMDStatus()
In that case, I am sure the PDD give 2 good values (almost the same) to the
stream handler.  But the stream handler gives back to the application a
spurious value.

I wonder if that case confuses the stream handler.  And it seems that the
stream handler, instead of multiplying each returned value by 3, multiplies
only one twice (multiplies it by 9).  So, the value is 3 X greater than it
should be.

This problem is very important, I'd like to know what can be done to solve
this problem.



ANSWER:
1. A defect (defect# 16915) has been opened for this problem.  Once this fix
is made public, you can use the fixed DLL.




!BASE___________________________________**********
September 6, 1995
QUESTION:  (Ref:  IF8)
I need a CPU load measuring mechanism other than an idle-priority spin loop,
since it interferes with other performance monitors, and defeats notebook
power-save features.

I've been told on several occasions that there are operating system services
for this type of monitoring, but a close examination of the DDK shows only one
possible candidate, the DosProfile/Perfview API support mentioned in BSEDOS.H
and PVWSPORT.H, but not further documented.  I also see VDH and DevHelp
versions of the DosRegisterPerfCtrs API.  Are these APIs useful for CPU
performance monitoring and other profiling duties?  If so, where can I obtain
the documentation?  Are there other, undocumented APIs available that you
could release information on?



ANSWER:
SPM/2 2.0 provides documentation for this API, plus it provides the APIs
necessary to retrieve this information and analyze it.  SPM/2 2.0 gets this
information through APIs in OS/2 that are available in the OEMI document
only.

These are documented in the "User Metrics: Overview" section under "Ring 0
applications" in the SPM documentation.  You can also look at the file
SPMUH.INC that is installed in the \API subdirectory off of the main SPM
subdirectory if you install with the /API option.

SPM/2 2.0 allows you to register and update performance hooks.  You can
then collect them with SPM/2 and generate reports.  You can use this for
debugging, where you code the hooks during your development and remove
them before shipping.  For example, you could use this as a profiling tool
to count the number of times a procedure gets executed, or the amount of
time spent in a procedure.  You could also define a set of hooks that would
be useful to your customer, for example hooks to measure response time.
You could then ship these hooks in your code and tell your customers that
your product is enabled with SPM performance hooks.

** SPM/2 is the IBM System Performance Monitor/2.




!STORAGE________________________________**********
September 7, 1995
QUESTION: (Ref: IE4)
I am trying to develop a device driver to support a unique sort of CDROM drive.
It's a 3-CD changer.  We need to watch disk requests and sense when a drive
change command should be issued.  Then we gotta issue it!

I was on one of the IBM WWW pages and found a document referring to "PJ16058",
called NON-ATAPI compliant fixes.

ANSWER:
You will have to write an OS/2 Filter driver .The filter would need to:

1.)  Provide a private IOCtl interface to an application that would allow the
user to select the appropriate CD-Drawer(in case you have more than 1
Changer).

2.)  Simulate a media change indication back to the CD-ROM manager when the
user changes the CD selected so that new CDROM directories are read.

3.)  Provide IORB routing based on the user selected CD-Drawer.

This would involve directing the IORB to the ADD/ADDUnitHandle corresponding
to the Target/Lun for the selected CDROM Drawer.

The filter implemented should be useable across all OS/2 SCSI ADD drivers and
should be compatible with the existing OS2CDROM manager.

APAR PJ16058 Abstract - IDE Mitsumi 3X/4X  and IDE Sony need workarounds
                                  Because of Hardware inconsitencies,software fixes
                                  had to be provided in the ATAPI code.These fixes
                                  are available in Warp Full Pack.




!OTHER__________________________________**********
September 8, 1995
QUESTION: (Ref: IG8)
I am having a sporadic problem with a device driver I have written for a
specialized hardware device.  It seems that there is something in the driver
that does not get cleaned up properly after an application which has been
using the driver has terminated.

One of the ways I have detected this is, after the application has closed, to
go into the OS/2 command line window and attempt to rename the application
source file using the rename command.  I occassionally get the following error
message:

SYS0032:  The process cannot access the file because it is being used by
another process.

I would have thought that this could be the result of, saying Locking a
segment and failing to unlock it, or blocking a process thread and failing to
unblock it.  I looked for things like that in my device driver.  I found one
place where it could possibly happen and corrected that, but the problem
persists.

I have also made sure that the application, upon termination, closes all open
devices and that my device driver de-installs the Timer Interrupt handler as
the last device is being closed.  (This is the recommended approach for MCA
type buses in Mastrianni's "Writing OS/2 Device Drivers in C" book).

What else could this error mean?

It is important to note that the application is probably not the problem.  I
have a another hardware device, made by a different manufacturer that does the
same job as the device I am writing the driver for.  It has its own device
driver for OS/2.  When I run the application using the other device and
driver, this problem does not appear.

ANSWER:
On receiving Close Request packet, the following points must be taken care of:

1) If any interrupt level was registered, it must be released.

2) If any requests are pending in the queue, RPDONE must be issued to these
requests.

3) The device driver must ensure that the Pid of closing application is the
same as the Pid of the program that opened the device.  If the Pid is valid,
the driver must decrement Open counter and return DONE status to the kernel.

4) Any memory previously allocated must be freed.

If the application has created additional handles to a file with DosDupHandle
it must issue DosClose for the duplicate handles.

Refer chapter on " A simple OS/2 Device Driver", section "Device Driver
Operation" in "Writing OS/2 2.1 Device Drivers in C" by Steve.J.Mastrianni.
Also refer to the "Sample OS/2 Serial Device Driver" listing in Appendix C of
the same book.




!OTHER__________________________________**********
September 11, 1995
QUESTION: (Ref: IF6)
I'm in the process of developing a PDD and believe I need to use PhysToGDTSel
to modify the access rights of a GDT selector I created at init time with
AllocateGDTSelector.  However, I do not understand the return code for the
PhysToGDT function.  What does 0 if pages locked, return selector with
modified RPL mean.  It appears that thus far all my calls to this function
have returned 0 in AX.  I'm also unclear whether, if another selector is
returned, why another call to the same function on the original selector would
wipe out the results of the first call.

In addition, is it safe for me to directly modify a GDT entry? If not, what
is the reasoning behind this?



ANSWER:
1) If the pages are locked and PhysToGDTSel is successful, the returned
selector has the modified RPL bits as requested in the Access parameter of
PhysToGDTSel call.

2) PhysToGDTSel returns AX = 0 if successful with modified selector in SI.
The Modified Selector is available in SI and not in the AX Register.The
documentation error has been reported and will be fixed in the next Release
(Defect # 121562)

3) Once a PhysToGDTSel is issued for a particular selector, the addressability
using that selector is valid till you make another PhysToGDTSel,
PhysToGDTSelector, LinToGDTSel or PageListToGDTSel with the same selector as
one of the parameters.

4) It is not recommended to modify GDT entry directly since memory management
is a Kernel perogative.




!PRINT__________________________________**********
September 11, 1995
QUESTION: (Ref: II8)
I'm seeking for enlightment about OS/2 native Printer Drivers.

o What IBM tools I need exactly to create a OS/2 printer driver
o Where to start
o Can I write the driver without _any_ makefile and assembly fuzz in the
VisualAge environment? Just "Create new project", "DLL" or whatever, and
start coding?
o How to install an OS/2 driver.
o Any kind of help or suggestion welcomed

ANSWER:
You will need to obtain the DDK v2 which has printer sample code and the
device driver reference manuals.  The DDK contains the information needed
regarding the tools needed and printer device driver architecture.  You can
contact the ordering center at 1800-633-8266.




!VIDEO__________________________________**********
September 13, 1995
QUESTION: (Ref: II0)
Our PM driver locates the memory-mapped registers of the Spitfire video chip
by calling through the OEMHELP PCI interface, and then maps the physical
address we receive to linear by calling through the usual PMDD.SYS IOCtl.

For most PCI motherboards this code works fine for us, but the particular
motherboard noted above causes us a serious problem.  OEMHELP tells us that
our MMIO registers are located at 0xffbeff00--i.e.  very high in memory.  (We
have confirmed that this is the same location returned by Int 0x1a under real
DOS.)  Yet after we have mapped this location to a linear pointer through
PMDD.SYS, we find there's nothing there:  Our whole memory space appears as
0xFF FF FF FF, and these values cannot be changed when we attempt to write
into what should be writable offsets within our graphics engine.

Q:  Does OS/2, or PMDD.SYS, impose some sort of upper limit on physical
addresses that can be mapped to linear by our driver?  If not, what else could
be preventing us from acessing our chip's registers in this case?

ANSWER:
The flat pointer obtained from PMDD can be used in the MoveCursor32 only in
Ring 2.

Refer to "Obtaining Pointers to Video Memory" in Section "S3 Driver" under
"Overview" in Chapter "S3 Display Driver" of "Display Device Driver
Reference".

The AllocGlobalVRAM function supported by the PMDD needs a flag.  If the first
bit is 0, the pointer obtained will be accessible only in Ring 0.

Refer to "Set up and Sharing of a pointer to video RAM" in Section "Seamless
Design Issues" Chapter on "Seamless Windows Support" in "Display Device Driver
Reference".

What is the physical address and the linear address on the working
motherboards?

What is the corresponding linear address for the given physical address?

If the linear address falls above 512MB, the ring 3 application cannot access
that memory since it is reserved by the OS/2 system.




!STORAGE________________________________**********
September 14, 1995
QUESTION:  (Ref:  I09)
Our device driver is a filter driver for IBM1S506.ADD which provides services
to control an ATAPI tape drive.  Our driver was originally based off of the
IBMIDECD.FLT source code, but has changed quite a bit.  The trouble we are
experiencing is that we cannot reliably suspend/resume with IBM1S506.ADD when
an ATAPI CD-ROM is used with IBMIDECD.FLT.  The sequence of events are as
follows :

  1) Our driver (BTSEIDE.FLT) receives an IORB to do some tape I/O,
     and issues a suspend IORB (IOCC_DEVICE_CONTROL / IOCM_SUSPEND).
  2) When this suspend IORB is completed, BTSEIDE begins processing
     the I/O request.
  3) While BTSEIDE is processing the I/O request, an IORB is issued to
     the IBMIDECD filter by another application (WPS, word processor, etc).
  4) IBMIDECD issues a suspend IORB to IBM1S506.ADD.
  5) IBM1S506 processes the suspend IORB even though it has already been
     suspended.

The results after this seem to be somewhat unpredictable.  Since IBM1S506 now
calls the interrupt handler for IBMIDECD, our processing stops.

The only solution I have thought of is to prevent IBM1S506.ADD from completing
a suspend IORB while it is suspended.  This wouldn't require changes to
IBMIDECD.FLT as near as I can tell.

On a side note, IBMIDECD.FLT seems to allocate all ATAPI devices it finds,
including the ATAPI tape unit.  Shouldn't it just allocate CD-ROM devices?  I
believe this is because in the function ClaimUnit() in ATAPINIT.C, 0 is
returned if the unit is not a CD-ROM.  I patched this to return -1 if the unit
is anything but a CD-ROM and this seems to have taken care of this problem.



ANSWER:
This problem has been determined to be an OS/2 defect.  APAR PJ19658 has
been created to address this problem.  At this time, the APAR is still open
which means that a fix is not yet available.   Please periodically contact the
OS/2 Supportline, at 1-800-992-4777, for a status of the fix for this problem.




!BASE___________________________________**********
September 14, 1995
QUESTION:  (Ref:  I24)
The 32-bit Calling Sequence for DosDevIOCtl is:
-----------------------------------------------
rc = DosDevIOCtl ( DevHandle, Category, Function, ParmList, ParmLengthMax,
                   ParmLengthInOut, DataArea, DataLengthMax, DataLengthInOut)

HFILE   DevHandle;
ULONG   Category;
ULONG   Function;
PVOID   ParmList;
ULONG   ParmLengthMax;
PULONG  ParmLengthInOut;
PVOID   DataArea;
ULONG   DataLengthMax;
PULONG  DataLengthInOut;

The Request Block Format for 16-bit and 32-bit DosDevIoctl is:
--------------------------------------------------------------
Request Header               13 BYTES
Function Category            BYTE
Function Code                BYTE
Parameter Buffer Address     DWORD
Data Buffer Address          DWORD
System File Number           WORD
Parameter Buffer Length      WORD
Data Buffer Length           WORD


The IOCTL request block format does not indicate a way to get to the pointers
DataLengthInOut and ParmLengthInOut passed by the application.  I would like
to use these pointers to return data sizes to the application.  I could embed
the size information into the ParmList and DataArea buffers, but it would be
cleaner and more convenient to use DataLengthInOut and ParmLengthInOut.  Is
there a way for my physical device driver to access these pointers?


ANSWER:
The packet for a generic IOCTL call does not contain ParmLengthInOut and
DataLengthInOut parameters.   Therefore they cannot be modified by the
device driver.  Secondly, these parameters get changed to DataLengthMAX
and ParmLengthMAX by the kernel prior to entering the device driver's
strategy routine.  DataLengthMAX and ParmLengthMAX should NOT, under any
circumstance, be modified by the device driver.  This could lead the device
driver or the application to reference a piece of memory outside of the
established boundaries and cause a SYS3175 or even a hard trap.

In any case, the documentation is lacking and I have requested a documentation
change.




!MULTIMEDIA_____________________________**********
September 15, 1995
QUESTION:  (Ref: IE9)
Q1.  I am currently evaluating the possibility of porting a software MPEG
driver that we have written for MS Windows.  I read the the documentation and
the sample codes that are available on DevCon#7 and the DDK but I still have
some questions.  First, what do I need to implement?

A1.  You will need to implement and MPEG Software CODEC to replace the MPEG
H/W Codec.

- The CODEC is passed MPEG Video packets from the MPEG file.

- The CODEC decompresses the Video (in the H/W CODEC case calls
  the VSD/PDD to decompress the video)
  The Displays the Decompressed IMAGE thru a call to DIVE (or
  in the H/W Codec case the Hardware gets the image on the screen.

- When the CODEC is installed it can request various method
  of audio and video sync to be preformed. The H/W CODEC
  request that No SYNC be preformed and lets the PDD (H/W)
  preform the sync via the Audio time that is being reported
  by the audio DD which come back thru the CODEC.

=======================================================================
Q2.  Will the source code for MPEG IOProc be available in the future?

A2.  Yes, we will have a single stream MPEG I/O proc that passes a raw MPEG
file to the CODEC.  This should be available in the next DDK (current version
is DevCon DDK 2.0).

We have two types of MPEG I/O procs:

Split Stream, that shipped in WARP
----------------------------------
The Split Stream I/O proc Splits the Audio and Video apart.  It sends the
Audio packets thru the system to the Audio VSD/PDD.  It sends the Video
packets thru the system to the MPEG Video CODEC which then forwards it to
the Video VSD/PDD.  The PDDs then write the Audio and Video data into there
separate chips to be decoded.  Typical chips that use this method are:

           Video = C-Cube CL450, IBM's MPEG-2 chip
           Audio = Analog Devices' AD105 or TI's AV110, IBM's M-Wave

Single Stream, this should be in the next DDK
---------------------------------------------
Reads in the entire MPEG file and sends it to the MPEG Video CODEC which
the H/W CODEC forwards to the Video VSD/PDD which writes the data into
hardware that know how to decode a raw MPEG file (both audio and Video).
The Video VSD writes the data into the MPEG Video/Audio chip.  Typical
chips that use this method are:

           Video/Audio = Zoran's ZR36100

=======================================================================
Q3.  How is audio being handled?  I am not too familiar with MPEG but I
was told that our software MPEG decoder decodes the video and audio
portions simultaneously.  Looking at the real magic PDD and its associated
MPEG, it seems that either only video is handled by the decoder (at least
that is what the documentation claims).  Some comment about the feasibility
of a CODEC or IOProc that handles both video and audio will be appreciated.

A3.  See answer number 2 above.  Also, without an Audio device, the system
thinks that we have no control over audio (Volume, Bass, ....).  In the
case of the single stream H/W decompressing, we have to write a dummy audio
VSD that passes Volume, Bass ... controls messages to the Video VSD and on
then on to the Video/Audio PDD.

In your case, I would recommend the Split Stream model.  The Audio side also
has the concept of CODECs where you could plug in your audio decompressor and
then send the decompress MPEG audio data (now in PCM/Wave format) to a wave
audio device.  If the system has an audio device that know how to decompress
MPEG Audio, your Audio codec could be skipped and let the H/W decompress the
audio.


!OTHER__________________________________**********
September 25, 1995
QUESTION: (Ref: IL8)
I recently talked with someone who was creating a device driver, as an
.EXE file. It was a Class driver, which as far as I know is usually a .DMD
file.

What are the benefits of .EXE vs.  .DMD?

ANSWER:
There are no advantages using .EXE in comparison to using .DMD.  In OS/2 the
Class Drivers have now been standardised to use the DMD Extension.



!OTHER__________________________________**********
September 25, 1995
QUESTION: (Ref: IF6)
I'm in the process of developing a PDD and believe I need to use PhysToGDTSel
to modify the access rights of a GDT selector I created at init time with
AllocateGDTSelector.  However, I do not understand the return code for the
PhysToGDT function.  What does 0 if pages locked, return selector with
modified RPL mean.  It appears that thus far all my calls to this function
have returned 0 in AX.  I'm also unclear whether, if another selector is
returned, why another call to the same function on the original selector would
wipe out the results of the first call.

In addition, is it safe for me to directly modify a GDT entry? If not, what
is the reasoning behind this?


ANSWER:
1) If the pages are locked and PhysToGDTSel is successful, the returned
selector has the modified RPL bits as requested in the Access parameter of
PhysToGDTSel call.

2) PhysToGDTSel returns AX = 0 if successful with modified selector in SI.
The Modified Selector is available in SI and not in the AX Register.The
documentation error has been reported and will be fixed in the next release.


3) Once a PhysToGDTSel is issued for a particular selector, the addressability
using that selector is valid till you make another PhysToGDTSel,
PhysToGDTSelector, LinToGDTSel or PageListToGDTSel with the same selector as
one of the parameters.

4) It is not recommended to modify GDT entry directly since memory management
is a Kernel perrogative




!PRINT__________________________________**********
September 25, 1995
QUESTION: (Ref: IH0)
I would like to write an application which installs a new queue driver in a
specific printer object.  Which API(s) should I use to install a queue driver
in a printer object?  Do I also have to change the entries in the system.ini
file (or am I allowed to change any entry in the system.ini)?


ANSWER:
To install the new queue driver you can do one of the following:

1) Go to the print object's "Queue options" settings page, bring context menu
up on "PMPRINT" icon, and select "Install" option to install a new queue
driver.

2) Copy the new queue driver(called NEWQDRV in this example) to the boot
driver(C:  in this example) as C:\OS2\DLL\NEWQDRV.QPR, then write the
following INI file entry to avoid having to manually install a queue driver
using the print object:

PrfWriteProfileString( HINI_SYSTEMPROFILE, "PM_SPOOLER_QP",
                      "NEWQDRV", "C:\OS2\DLL\NEWQDRV.QPR;;" );

Now that the queue driver is installed, to set a print queue
("MyQueue" in this example), issue the following API:
SplSetQueue( NULL,  // computer name, null = local
                      "MyQueue",    // queue name
                       3,  // level
                       "NEWQDRV",
                       // buffer containing new value
                       strlen("NEWQDRV")+1, // size of string in buffer
                       PRQ_PROCESSOR_PARMNUM // only change queue driver );

3. You could also refer to chapter on "Queue Driver" in Presentation Driver
Reference and source code in the directory \ddkx86\src\pmprint in DevCon DDK
2.0 CD.




!OTHER__________________________________**********
September 25, 1995
QUESTION: (Ref: IH9)
PROBLEM: Machine lockups using OEMHLP$ to query the PCI BIOS using OS/2 2.11
with CSD level XR_A094.


Questions:
(souce code removed by DDSC Team)
1) My routine works as planned.  All information is recieved and correct.
However, calls to the IOCtl currently locks the system (mouse, keyboard,
everything - requires hardware reset) on about 1 out of 20 calls?

   Solutions tried:

     a) The data structures have been double and triple checked for accuracy.
     b) The code has been re-written to use unique structures for each call,
        that is, no unions.


Next, the problem I am seeing does not occur on WARP.  OEMHLP$ generates a
TRAP under the kernel debugger.  (The problem is interesting because the
OEMHLP$ calls yields the proper information, but locks (generates the TRAP)
about 1 in 20 calls.


Trap generated on 16th execution of above program
Last print to screen:    "Begin 2"

Trap 12 (0CH) - Stack Segment Overrun or Not Present 0000 - In Debugger
eax=47500060 ebx=00000088 ecx=00004750 edx=000010e8 esi=7bd20000 edi=000089a0
eip=00007eba esp=000003c4 ep=000203c4 iopl=2 rf -- -- nv up di pl zr na pe nc
cs=0120 ss=04a0 ds=0128 es=0017 fs=0108 gs=0000 cr2=00053ffe cf3=001b8000
0120:00007eba c9             leave


Trap generated on 12th execution of above program
Last print to screen:    "Begin 3"

Trap 14 (0EH) - Page Fault 0000, Not Present, Read Access, Super
eax=04005d30 ebx=7bc55c50 ecx=0000000b edx=01290ad5 esi=7bd20168 edi=0000003c
eip=fff5b330 esp=00000330 ebp=000203c4 iopl=2 rf -- -- nv up di pl zr na pe nc
cs=0170 ss=04a0 ds=0168 es=0168 fs=0000 gs=0000  cr2=0ff3c3e2  cr3=001b8000
0170:fff5b330 ff1485224ff2ff call    dword ptr [eax*4+fff2ff22]
                                                       ds:0ff3c3e2=invalid

Note:  These traps do not occur under WARP v3.0, however, we will need support
under OS/2 v2.11.


ANSWER:
This problem has been fixed for OS/2 2.11 by upgrading to the latest CSD for
OS/2 2.11.  (as of 9/25/95, the latest CSD is XR_A101).



!OTHER__________________________________**********
September 25, 1995
QUESTION: (Ref: IJ1)
The hardware for the high speed communications port supports only 8 data bytes
per packet.  I need to send 64 packets at a time to a device on the line
without prohibiting other device on the line from maintaining their own
communications or starving other processes of CCPU time.  To do this I need to
allow 4 milliseconds between each packet.  What I did in an attempt to acheive
this level of throughput was 1) put the thread into TIME_CRITICAL priority,
and 1) to transmit two packets and do a block on the device driver so that
other processes would get CPU, and release the block when I got the interrupt
saying that the transmit was done.  I thought this would give up a minimum of
8 milliseconds to other processes, but it didn't I'm getting almost exactly 1
packet every millisecond.

Any suggestions on how to acheive this would be greatly appreciated.

I'm thinking maybe I should do a yield after every 8 or 16 packets to achieve
the desired throughput.


ANSWER:
In order to achieve the 4 ms delay between each ( 8 data bytes ) packet during
transmissions, suggest you follow your existing design implementation with a
slight modification as follows :-

1. Put the thread into TIME_CRITICAL priority.

2. In your driver strategy code initiate transmission of packet and block
(using ProcBlock Devhlp).

3. Once you get an interrupt saying transmission is complete do ProcRun in
your ISR and wake up the blocked thread in the strategy transmit routine.

4. The thread which is woken up after ProcBlock could generate a 3ms delay by
issuing a ProcBlock call with a 3ms timeout option to generate the required
inter packet delay before returning from the driver strategy transmit routine.

If the above does not help could you provide us more info on the following

  - details of IPC between driver and your communication adapter.

  - The mechanism of data xmit & receive between the driver
    and the communication adapter (is it via Dual Ported Ram, Shared Memory
    interrupts or DMA)



!VIDEO__________________________________**********
September 21, 1995
QUESTION: (Ref: IL9)
Currently, we are modifying the sample driver code supplied in the Developer
connection DDK version 2, under the PMVIDEO\S3TIGER directory.  We followed
the strategies described in the documentation for modifying S3 driver and
could compile a DDL.

We have a few questions related to installation and configuration of the
display driver.

(a) Can we copy our driver file (FIS.DLL) to the currently installed display
driver on the target machine and test it using Kernel Debugger.

(b) When we tried this, we found that the OS is not loading the display driver
and fails to boot.  What are the changes required in the driver and in the
environment to build and test a driver named FIS.DLL using the sample code
S3TIGER.

(c) Is it necessary to touch any other DLL or data file to test FIS.DLL as
mentioned above?  as mentioned above?

ANSWER:
1) You can copy your driver file on the target machine.  For debugging
information refer to "Debugging Tips" in Section "Strategies for Adapting the
driver to other chip sets" under "Overview" in Chapter "S3 Display Driver" in
"Display Device Driver Reference" in DevCon DDK 2.0.

2) After display driver related files are copied, the CONFIG.SYS and OS2.INI
files must be updated to complete installation.  Refer to "Updating system
Configuration files" in Section "Overview" Chapter on "Installing and
configuring display device drivers".

3) You need to update CONFIG.SYS & OS2.INI.




!STORAGE________________________________**********
September 25, 1995
QUESTION: (Ref: IK7)
Is it possible to use the warp v3 single processor copy of os2dasd.dmd on smp
machine runing os2.

ANSWER:
The SMP version of OS2DASD is at the same level as OS/2 2.11,which is
different from the Warp level code.  The OS/2 2.11 level code should be
available in DDK v1.2.
