home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 8 Other / 08-Other.zip / mdosbug4.zip / MDOSBUG.TXT < prev    next >
Text File  |  1997-04-11  |  9KB  |  253 lines
  1. MDOS 100% BUG PROBLEM DESCRIPTION        Rev. 2.0 / March 9th, 1997
  2.  
  3. CONTACT PERSON:
  4.  
  5.     Tobias Ernst             e-mail:  tobi@bland.fido.de
  6.     Werderstr. 70            fidonet: 2:2476/418
  7.     D-76137 Karlsruhe        os2net:  81:449/7835
  8.     Germany                  phone:   +49 721 9374497
  9.  
  10.  
  11. CONTENTS OF THIS DOCUMENT
  12.  
  13.     This document contains
  14.  
  15.     - A typical phenomenological problem description
  16.     - A technical problem description
  17.     - A kernel patch to solve the problem (!)
  18.     - Annotations
  19.  
  20.  
  21. ONE-LINE DESCRIPTION OF THE PROBLEM:
  22.  
  23.     APAR JR-10024:
  24.  
  25.     MDOS APPS CAUSE 100% LOAD DUE TO BROKEN TIME SLICE API IN WARP4
  26.  
  27.  
  28. A TYPICAL PHENOMENOLOGICAL PROBLEM DESCRIPTION
  29.  
  30.     A lot of different DOS software, esp.  DOS DFUE software, which
  31.     ran smoothly under Warp  3,  causes  100% system workload since
  32.     upgrade from Warp 3 to Warp 4.  Most of these programs claim to
  33.     be OS/2 aware, i.E.  to  release  time  slices  to  OS/2.   The
  34.     difference  between Warp 3 and Warp 4 can be visualized using a
  35.     system process monitor.  It reveals the following:
  36.  
  37.                        WARP 3->              WARP 4->
  38.                        Priority  State       Priority  State
  39.     Program active     0x0201    Ready       0x0201    Ready
  40.     Program idle       0x0200    Blocked     0x0200    Ready
  41.  
  42.     Warp 4 simply "forgets" to block the program when it  is  idle.
  43.     The   following  diagraph  shows  an  interesting  effect  that
  44.     illustrates that  there  must  be  a  serious  bug  in the time
  45.     slicing API.  It was taken with the DOS fidonet mailer software
  46.     "McMail", a typical OS/2-aware DOS program:
  47.  
  48.                                      Resulting system load
  49.                                      maesured using PULSE.EXE
  50.  
  51.     Program is told to ..            Warp 3            Warp 4
  52.  
  53.        Release OS/2 time slices      3%                100%
  54.        Not release any time slices   50%               50%
  55.  
  56.     Actually, giving  a  time  slice  back  to  OS/2  V4  makes the
  57.     situation WORSE than not giving a time slice at all!
  58.  
  59.     There seem to be further  problems  with the DOS emulation idle
  60.     time detection.  For example, on  my  system  the  TSR  program
  61.     DOSKEY, which is included in OS/2 MDOS, causes 100% system load
  62.     *SOMETIMES*.  This is not reproducable  at  will,  but  happens
  63.     casually and is very worrying.
  64.  
  65.  
  66. A TECHNICAL PROBLEM DESCRIPTION
  67.  
  68.     There are four methods of releasing time slices under OS/2:
  69.  
  70.        Method                Works with Warp 3    Works with Warp 4
  71.  
  72.     a) "Generic DOS pause"   yes                  yes (?)
  73.        INT 28h
  74.     b) "DPMI time slice"     yes                  no
  75.        MOV AX,1680H
  76.        INT 2FH
  77.     c) "BIOS delay"          yes                  yes
  78.        CX:DX=my_secs
  79.        MOV AH,86H
  80.        INT 15h
  81.     d) "CPU halt"
  82.        DX:AX=msecs           yes                  no
  83.        STI
  84.        HLT
  85.        DB 035h, 0CAh
  86.  
  87.     From  these  four  methods,  number  b)  and  d)  are  the most
  88.     frequently used methods, so  that  about  80% of all OS/2-aware
  89.     DOS-software is nearly inoperable under Warp 4.
  90.  
  91.     We have done some debugging of the OS/2 Warp 4 kernel and  have
  92.     found the reason why INT 2F does not work any more:
  93.  
  94.     OS/2 Versions prior to OS/2 Warp  4  were  handling  INT  2F  /
  95.     AX=1680h via the 16 bit doskrnl.  The 16 bit doskrnl contains a
  96.     routine to trap the INT 2F / AX=1680h and release the DOS tasks
  97.     processor  time  slice.   In  Warp  4, the 16 bit doskrnl still
  98.     conatins this code and it is still  operable - but the INT 2F /
  99.     AX=1680h never reaches the doskrnl at all.
  100.  
  101.     In Warp 4, INT 2F /  AX=1680h  is trapped by the MVDM before it
  102.     ever reaches doskrnl, and MVDM seams to be inable to handle  it
  103.     correctly.   Now  there  are  two  possible  solutions  to  the
  104.     problem,  namedly  either make MVDM process the time slice call
  105.     correctly - or disable MVDM  from  handling the time slice call
  106.     at all, so that it can reach the routines in doskrnl which  are
  107.     still operable.
  108.  
  109.     As a first workaround, we have chosen the latter method:
  110.  
  111.  
  112. A KERNEL PATCH TO SOLVE (WORKROUND)THE PROBLEM
  113.  
  114.     The following kernel patch  is  valid  for OS/2 Warp XR4000 and
  115.     XRG4000 service levels. We have not  debugged  the  Fixpack  #1
  116.     kernel yet, so I cannot estimate if it is valid for this kernel
  117.     as  well  (I only know that the Fixpack #1 kernel has still the
  118.     problem ...).
  119.  
  120.     Service  level  XR4000 or XRG4000, File OS2KRNL (located in the
  121.     root dir of the installation  drive):  For Revision 9.023 (Warp
  122.     4 w/o fixes) at offset 67C2Eh for Revision  9.025  (Warp  4  w/
  123.     fixpack #1) at offset 67D73, change the following six bytes:
  124.  
  125.        66 25 80 00 74 45   (old)
  126.  
  127.     as follows:
  128.  
  129.        66 3D 80 00 7E 45   (new)
  130.  
  131.     This  will  stop MVDM from processing INT 2F/AX=1680 and voila,
  132.     time slices  work  again.   -  What  this  patch  does  is also
  133.     illustrated by the following disassembly of the OS2KNRL:
  134.  
  135.     F8C6B4      push    ebp
  136.     F8C6B5      mov     ebp, esp
  137.     F8C6B7      push    ebx
  138.     F8C6B8      push    esi
  139.     F8C6B9      mov     ebx, [ebp+8]
  140.     F8C6BC      cmp     byte ptr [ebx+1Dh], 16h
  141.     F8C6C0      jnz     loc_FFF8C6EA
  142.     F8C6C2      movzx   esi, byte ptr [ebx+1Ch]
  143.     F8C6C6      mov     eax, esi
  144.     F8C6C8      mov     ecx, eax
  145.     F8C6CA      and     ax, 80h
  146.     -->CHANGED: cmp     ax, 80h
  147.  
  148.     F8C6CE      jz      loc_FFF8C715
  149.     -->CHANGED: jle     loc_FFF8C715
  150.  
  151.     F8C6D0      cmp     ecx, 8Ah ;
  152.     F8C6D6      ja      loc_FFF8C715
  153.     F8C6D8      and     ecx, 0FFFFFF7Fh
  154.     F8C6DE      mov     esi, ecx
  155.     F8C6E0      push    ebx
  156.     F8C6E1      call    dword_FFF14C50[ecx*4]
  157.     F8C6E8      jmp short loc_FFF8C717
  158.     F8C6EA
  159.     F8C6EA
  160.     F8C6EA loc_FFF8C6EA:
  161.     F8C6EA      cmp     word ptr [ebx+1Ch], 4010h
  162.     F8C6F0      jnz     loc_FFF8C705
  163.     F8C6F2      mov     word ptr [ebx+1Ch], 0
  164.     F8C6F8      mov     word ptr [ebx+10h], 1428h
  165.     F8C6FE      mov     eax, 1
  166.     F8C703      jmp short loc_FFF8C717
  167.     F8C705
  168.     F8C705 loc_FFF8C705:
  169.     F8C705      cmp     word ptr [ebx+1Ch], 4011h
  170.     F8C70B      jnz     loc_FFF8C715
  171.     F8C70D      push    ebx
  172.     F8C70E      call    loc_FFF94691
  173.     F8C713      jmp short loc_FFF8C717
  174.     F8C715
  175.     F8C715 loc_FFF8C715:
  176.     F8C715      sub     eax, eax
  177.     F8C717
  178.     F8C717 loc_FFF8C717:
  179.     F8C717      pop     esi
  180.     F8C718      pop     ebx
  181.     F8C719      leave
  182.     F8C71A      retn    4
  183.  
  184.  
  185. HOW TO REPRODUCE THE PROBLEM
  186.  
  187.     The  problem  can  be  and  has been reproduced on all existing
  188.     versions of Warp 4  (Beta,  Gamma,  German  GA, US American GA)
  189.     virtually  independent   of   installed   hard-   or   software
  190.     components.    Using  the  following  method,  I  was  able  to
  191.     reproduce it on *any*  OS/2  Warp  4  system I have worked with
  192.     since.
  193.  
  194.     Enter the following lines on  the  MDOS  prompt and do not omit
  195.     the empty lines:
  196.  
  197.     ==begin==
  198.     debug
  199.     a100
  200.     mov ax,1680
  201.     int 2f
  202.     jmp 100
  203.  
  204.     rcx
  205.     7
  206.     nloop.com
  207.     w
  208.     q
  209.     ==end==
  210.  
  211.     This  creates  a little program LOOP.COM.  This program is just
  212.     an endless loop  which  does  nothing  more than to continuosly
  213.     release all of its processor time back to OS/2 via the  INT  2F
  214.     call.   Consequently, this program should not cause any visible
  215.     system  load.
  216.  
  217.     Start PULSE.EXE.   Then  run  LOOP.COM  in  a  windowed or full
  218.     screen DOS session with standard settings (IDLE_SENSITIVITY=70,
  219.     IDLE_SECONDS=0)  and  watch  the  Pulse.   You  will  see  that
  220.     LOOP.COM does not produce any system load under Warp  3,  while
  221.     it  produces,  depending  on  the  system, between 40% and 100%
  222.     under Warp  4.   (Note  that  you  will  not  see anything when
  223.     running the program except for the pulse change.  You  have  to
  224.     terminate it by closing the DOS window).
  225.  
  226.  
  227. ANNOTATIONS
  228.  
  229.     Note:   It  is  evident that, while LOOP.COM drives system load
  230.     display to  100%,  you  will  not  perceive  relevant impact on
  231.     overall system performance.  LOOP.COM is just  a  DEMO  program
  232.     for the problem which does nothing more than producing the bug.
  233.     But imagine a full-grown program with a main loop like that:
  234.  
  235.     - Poll I/O-Port
  236.     - Poll Keyboard
  237.     - Check Harddisk for file semaphores
  238.     - If OS/2 then  give up timeslice
  239.               else  do nothing for 1/10 sec
  240.     - Redo from start
  241.  
  242.     With the Warp 4 problem, this program will poll the hardware 10
  243.     times  as often as with Warp 3.  This causes highly perceptible
  244.     effects on overall system load.
  245.  
  246.     Note 2:  Of course you can pull "LOOP"'s system load down using
  247.     very low values  of  IDLE_SENSITIVITY.   But  you can't do this
  248.     with a full grown BBS software.  Meaning, of  course  you  can,
  249.     but  then  the  BBS  will  not  respond  to user input within a
  250.     reasonable time any more.
  251.  
  252. [EOF]
  253.