커널-W420040330.ZIP

마루 0 3,815 2023.04.03 11:17

This contains fixes since xr_e002/xr_m015/mcp/acp. Important note: If you use

the OS/2 SES facility, you need a new sesdd32.sys dated April 2001 or later

to use this kernel. Also, a matching dump formatter (df_ret.exe), provided

separately, is required, if you want to analyze a dump from this kernel.

Finally, note that os2ldr is only required for the >64mb memory detection

mentioned below.



***New as of 2002/04/16: I'm including an updated os2dump module, because the

   one that comes with mcp2/acp2 can possibly OVERWRITE your partition(s)!

   If you plan to use standalone dump and you have mcp2 or acp2, use this!

   Caveat: This os2dump will *not* work on non-LVMized systems (i.e. Warp 4+

   FP13-16). On the other hand, the bad os2dump wasn't distributed for FP13-16.



New function:

    1) Support for >64m memory using int15 func e820. Note, this support is

       enabled ONLY for Intel Pentium Pro or later, or non-Intel Pentium-class

       machines. This is done in an effort to prevent problems on older PCs.

    2) The presence of \os2\boot\os2norev.$$$ suppresses the display of 

       internal revision during boot.

    3) Adding "EARLYMEMINIT=TRUE" to config.sys will allow device drivers, etc.,

       access to the memory above 16mb early in boot. Previously, this was only

       available after DD and IFS init was completed. This has various

       implications when enabled:

  a) AHA154X.ADD may do bad things to your system. Don't even ask.

  b) There may be some settings of HPFS386 cache that are incompatible.

    4) Trap messages will now give the module name instead of the device name.

       For example, "Exception in module: CLOCK01" instead of "Exception in

       Device Driver: CLOCK$". 

***change from 0220/0223: Traps in 32 bit code now show the modname, too

    5) Systems with a 486SX chip running FP15 will function correctly. Note,

       they will NOT work with ACP or (necessarily) on MCP.

    6) SESDD32 will now work correctly (I hope) for both uni and smp

    7) All process dumps should now be considerably faster. paddr(all) dumps

       should take about 40% less time and others around 80-90% less time.

    8) EXE names will now also be displayed in alt-f2/alt-f3 processing (note

       that CMD file names, e.g. MPTSTART, will NOT be displayed, only cmd.exe)

    9) alt-f4 is like alt-f2 plus it pauses after displaying each names (does

       not pause after BASEDEV= or PSD=) and, by pressing F1, allows you to

       skip loading/running the file displayed.  Alt-f5 is like alt-f4+alt-f1.

    10) The dump formatter (in dfxxx.zip) should be faster and also work on

        dumps >= 2gb, which was not formerly possible.

  04/16/2002:

    11) Added "1" as an OK setting for flags in config.sys. Now, things like

        EARLYMEMINIT=TRUE can also be YES,ON, or 1 (or FALSE,NO,OFF, or 0).

I wish I could make stuff like this NLV-independent but that is 

ABSOLUTELY IMPOSSIBLE without HUGE changes.


 2002/01/02:

    Support for 16bit filesystems with >2gb file support (e.g.the forthcoming

    >2gb dump support ifs)


 9/13/01

    11) If you also install the enclosed clock01.sys to \os2\boot, you can 

        add "CLOCKSCALE=x" to config.sys. The choices for x are 1 (the default,

which is the old behavior), 2, and 4. The number represents a scale 

factor for the frequency of clock ticks. The theory is that CLOCKSCALE=4

will speed up some apps (maybe Netscape and/or Java).


Bug Fixes:

  Fixes from earlier "dated" kernels:

    Fixed a trap 000d in w_OpenCreate (140:4dfd or so in uni/w4 krnls, don't

              have regs for SMP). This was a post mcp/acp regression

    Fixed strange loader i/o problems specific to the 0111 kernel.

    Fixed a bootup sys31xx problem specific to the 0123 kernel.

    Fixed a problem that was (I think) specific to  Janauary uni & W4 kernels


          which resulted in odd ring 3 (maybe ring 0?) traps and hangs

    Fixed some trap and other peculiar problems specific to the 0206 kernel.

          Those were the result of a build problem.

    Fixed some trap and other problems specific to the 0220/0223 kernels

    Fixed a regression from JR15038 that caused a trap in CWBBS.IFS and

    PCSFLR0.IFS (AS/400 shared folders access).

    Fixed a regression in the 0330 kernel that messed up getting procdumps

    Fixed a regression in the 0416 kernel that caused some hangs and also

        affected APM

    Fixed a regression in the 0502 kernel that prevented booting altogether or

            caused other very bad problems.

    Fixed a regression in the 0502/0503 kernels that caused some odd trap d/e's

            in the scheduling code

    Don't use the 0601 kernels.

    Don't use the 0615 kernels, either. There seems to have been some kind of

            build problem, there.

    Removed the int 3's I'd accidentally left in some EA code in 0727 build

    The 0730-0801 kernels all had problems due to various attempts to fix

            PJ28078. Sorry about that!

    10/16: the 1015 os2ldr was broken on some CPUs

    11/29: Trap 000e (DS will be 0) in 11/28 kernels (only)

           Some peculiarities deleting files

    01/18: Some hang/trap problems relating to the 01/17 kernel

    01/25: Fixed regression from DosDelete change where some files weren't

       getting deleted if DELDIR was set.

    02/21: Strange problems on SMP kernel, particularly with HPFS386 (related to

       0201 kernel, only)

    02/22: 2/21 kernel fix for PJ28434 fix was bad. Unknown possible side-

           effects during bootup.

    03/15: Chgfileptr (seek) ops may fail on FAT, particularly on a vdisk

    04/01: df_ret/df_deb trap on some memory analysis operations. note, you can

           use this df_ret.exe (& df_deb.exe) on dumps of kernels back to about

   Sep 2001 or so. Just always use the symbols that match the dump.

    04/16: Added test fix for trap 000e in _ldrSegFixAddIterRec

           - *May* have fixed some strange program load behavior with the

     implementation of the latest JR15038 fix.


  Fixes to problems that exist in released code:

    JR15494: Delayed response of Ctrl-C or Ctrl-S (pause) in os/2 windows

    JR15405: (probably) DosQueryAsyncTimer fails on timecritical thread after

         mscount rolls over after 49.7 days of uptime

    JR15030: TRAPDUMP QUERY doesn't show PD (needs a new trapdump.exe, too)

    JR13335: Some VDMs won't run, complaining of too-long command lines

    JR15194: XCOPY fails with SYS1186 or SYS1192 on (at least) MO drives 

    JR15038: Trap 8 in h_DeviceHelpDM running an app from a tcpbeui drive

    JR15229: Files left open after ERROR_TOO_MANY_OPEN_FILES returned to app

    PJ27700: SMP systems may get a trap 000e in _tkStopScan, particularly 

             during a procdump operation.

    PJ27676: Causes hangs on some systems running UNI or W4 kernels

    PJ27554: Hang or (on allstrict) trap 3 on SMP (only) during beeps

    PJ27678: SMP kernels could not be RIPL-booted. As part of this, there is

     a new config.sys parameter I13PAGES= available. Adding I13PAGES=1

     to config.sys (note, no SET) reduces the memory usage of the mini

     VDM processes used by ibm1s506.add and the GRADD drivers. This

     becomes important in RIPL-boot situations. It may be helpful for

     UNI RIPL boot, as well.

    PJ27677: SMP systems hang with multiple threads of same process

     entering a critical section (affects ADSM client)

    PJ27757: Trap 000e running Theseus/4 (note, theseus4.exe may still end up

             with a sys3175, but at least the system doesn't crash).

    PJ27736: Trap in _PLD_WriteReturnCode

    PJ27777: Set BEGINLIBPATH= (in config.sys ONLY) may be ignored. Also, 

             it would lead to a bogus copy of BEGINLIBPATH= in the environment.

    ;PJ27821: Trap 000e in SchedNextRet2 on some APM-enabled machines

    ;         *removed as of 0508 -- original fix caused regressions. new fix

    ;         on hold, for now

    PJ27906: Trap 000e in pvwRegKrnlInstance running SPM/2 (may also cause

             unknown odd behavior in other performance monitors).

    PJ27919: Complete system hang running some apps (same as JR12136)

    PJ27544: Panic in SwitchNPX

    PJ27972: trap 000e in _SecExecPost (the actual fix is in ses0604 or later)

    PJ27952: DosFindFirst returns incorrect returncode for various bufsizes

             when querying extended attributes

    PJ28005: ProcDump command returns error code 6 (and the procdump is invalid)

    PJ28013: read of >2k from named pipe on a timecritical thread can cause

         loss of pipe data or session hang

    PJ28027: trap in KMQueryClientRegister reallocating a trace buffer

    PJ28068: trap 000e in clock$ where sslim is ffffffff (during JFS activity)

    PJ28076: "trapdump [PD|NOPD]" disables the procdump.exe command. Also, it

         causes a trap 000e if you initiate a dump with ctrl-alt-f10-f10

     (or numlock-numlock).

    PJ28077: Some VPM apps will refuse to initialize

    PJ28078: Various traps with floppy disk hard errors when UDF is loaded

    JR13789: DRIVES does not reflect change in directory entries

    PJ28102: Performance tracing slow on Pentium 4 CPUs (this is the only 

             APAR listed here fixed in os2ldr)

  10/16:

    PJ28199  SES QUERYFILEINFO buffer pointer always -1

    PJ28207  SES callgate hooks don't work

  10/26

    PJ28215  Added HMA flag to DevHelp_GlobalToProcess. The new flag 20h (in

             EAX for the call to the DevHelp) allows a device driver to map

     global memory to a process' high private arena.

    PJ264136 Trap 000e in the kernel when theseus gets system working set. Also

             fixed a theseus problem on systems with HPFS386.

  11/28 (MCP2/ACP2 kernel plus the following)

    IC32279  Trap 000e in TKDeclareInversion after killing a process while it's

             doing DosDelete processing.

  01/17 (happy new year) revision 14.086c

    PJ28355  SYS3175 (or other problems?) when booting a Pentium 4 machine when

             initializing testcfg.sys or apm.sys


    **Note: For those of you with ACP1 or earlier, the os2ldr contained here is

            also mandatory to fix the P4 problem.


  01/18 revision 14.086d

    PJ28362  traps in os2krnl running theseus/4

  01/25 revision 14.086e

    PJ28379  disallow alt-f4 and alt-f5 in the presence of altf1sec.cmd

  02/01 revision 14.086g

    PJ28392  trap in f_w16_DoPageIO ***** see 03/06 *******

  02/21 revision 14.088a

    PJ28434  swapper.dat can be trashed from a VDM session

    JR15405: Second attempt to fix this

  02/26  revision 14.088c

    PJ28450  fix random problems on SMP Pentium PRO machines that started as

             of 2001/08/21

    PJ28355 part 2 -- some P4 machines STILL had boot problems

  0306   revision 14.088d

    PJ28392   Again! Somehow, this fixed got dropped from 0226

  0311   revision 14.088e

    PJ28468   Undelete not working since CP2

  0315   revision 14.088f

    PJ28472   Trap 000e in THEArena_Get running theseus/4 (may also be in 0311)

  0401   revision 14.088g

    JR15405 part 2: more likely fix for 49.7 day hang (still in test)

    JR15038 part 2: more trap 8s running an app from a tcpbeui drive

  0408   revision 14.088h

    JR15038 part 3: more trap 8s running an app from a tcpbeui drive

  0416   revision 14.089b

    PJ28541 sys0008 trying to start up lots of huge DLLs

    JR15038 new version: rather than slowing executable loads for everyone, I've

            gone back to using the faster stack-based buffer allocations most

    of the time. If you have loaded an ISS (security) or if you

    explicitly add "LDRSTACKOPT=TRUE" (No "SET ,,," please) to

    config.sys, we will try to minimize ring 0 stack usage by

    allocating buffers off the heap.  This is slower, but prevents

    ring 0 trap 0008s in some cases. If you use TCPBEUI, particularly

    with the IBMTRP driver, you should probably add this parameter

    to config.sys.

  0426   revision 14.089c

    Note: JR15038  from 0416 temporarily removed, as I think it was causing

          unstable behavior (including trap 000E and trap 0008). I left the

  LDRSTACKOPT option in, but for now it does nothing.

    PJ28547 trap 000e in _ldrSegFixAddIterRec running Oracle 6 and other apps

    PJ28566 trap 000e at _PLD_WriteReturnCode + 169 or so during procdump.

    PJ28567 trap 0003 in _PLDClose during procdump.

  20020515   revision 14.089d  (note the new naming convention)

    PJ28600 non-zero return from SecOpenPost ISS callout after file create

        operation leaves zero length files around

    PJ28602 internal thread names wrong in df and debug krnl on 1 cpu SMP

    PJ28603 module name missing or incorrect in r0 trap screen

  20020516   revision 14.089e

  A build problem caused the 20020515 PJ28600 fix to cause a trap. You

will only see this if you have a security device driver installed.

  20020802   revision 14.091a

  - not clear whether PJ28392 was included in recent kernels before this

- IRQ sharing problem in os2ldr caused hang on reboot for some USB

  controllers sharing IRQs

- Yet another attempt (the last, we hope) to fix the 49.7 day hang

  20020822   revision 14.091b

  - backed out the os2ldr junk from 20020802

JR15405 (final) the 49.7 day change might not have been in 20020802.

  20021010   revision 14.091c

        - put back in the IRQ fix in os2ldr. seems to be ok

- took clock01 out of the package.

  20021028   revision 14.093a

  PJ28871 trap with TRACEBUF= .../D=ALL in config.sys

- fix an obscure trap in KernelFaultEntry on debug kernel only

- fix a trap if Kern32ReadFileAt called and an ISS is installed

  20021205 14.093c

- fix a trap if Kern32ReadFileAt called and an ISS is installed

  (the fix was not correct in 1028)

- trap in w_dup trying to do DosDupHandle to target handle outside range

  of current max file handle number

PJ28941 trap 000e routine VMAliasToAlias doing procdumps on some systems

  20031226 14.093d

  - back out all experimental stuff including the w_dup trap and trap 8

  test fixes

  20030213 14.093e

- close some files that had been left over by some inconsiderate DD

  init code. the extra handles choked some apps, like MS C6

- Prevent trap under some condtion I don't understand while using a

  debugger (like codeview or ipmd or whatever) in DbgSeverConnection

JR17862 fix a problem with a thread hanging (but not the whole system) 

  after the 49.7 day rollover doing a DosSleep (*Not* fixed in 1226)

          Also, DosRequestMutexSem with 0 < timeout < ffffffff may hang if the

  thread wakes up after rollover and still doesn't own the sem.

PJ29032  trap in thesmte_get or themte_get running theseus4 or using

         theseus4 APIs

  20030303 14.093f

       - backed out the file closing change in 0213, as it seems to be causing

         problems on some systems. the underlying problem will be investigated

later in individual drivers.

       - change to fix from JR17862 in 0213 kernel due to possible regression

         that would result in a semaphore not timing out properly

       PJ29066 possible fix for a rare trap in _qsSem running pstat

       JR17842 various dump formatter rc:5 problems (fixed in df_ret/df_deb)

  20030306 14.093g

       - w_dup fix back in

       - another shot at fixing the trap 8 problems while running an ISS or

      using tcpbeui. If you're using tcpbeui (*especially *under SMP), you

      should not use this. If you're using an ISS, we ignore this. For others,

      you may get some speed improvement in loading apps by adding

      LDRSTACKOPT=FALSE to config.sys (the default being true).

  20030415 14.093h

       - LDRSTACKOPT back out. It caused too much confusion and I'm not 100%

         sure about its stability. Sigh.

       - Some enhancements to the ".pb" command in the dump formatter

  20030501 14.093i

       - I kept forgetting to take out the code that closes file handles > 2

         before starting PROTSHELL. The good news is that doing the close

reduces the number of leaked file handles by a few in some systems.

The bad news is that it also makes PMDD$ trap on boot on other

systems. So, if that happened to you with 14.093h, get this kernel.

As of now, add CLOSEFILES=TRUE if, like me, you need the changed

behavior (in my case, Microsoft C 6 kept aborting).

       PJ29180  Trap 000E while taking a process dump

  20030620 14.093i1

  - don't use this one. I put it out by accident due to packaging bug.

  20030621 14.094

  - nothing new, but this is the first "official" (i.e. one where we'll

  actually have full source code control) in a while. It leaves out

  the CLOSEFILES keyword, though.

  20030822 14,096

  PJ29349  Trap in ThePD_Get (another theseus/4 trap)

PJ28318  problems accessing non-US filenames (regression due to PJ29234)

         (related fix to cmd.exe to back out bogus changes will be 

  available in next fixpack)

  20031031  14.096b

- CLOSEFILES= back in

- fix 2 traps in w_DupHandle

   Seems to affect Netfinity remote access.

PJ29849  trap 000c in w_NewSize during procdump processing

  20031103  14.096c

        - incorrect parameters being reported in some devhelp system traces

  20031110  14.096c

        - 1103 system trace fix not built into some kernels

- fix named pipe regression in 1031 and 1103 kernels

- os2ldr is now the version that "works" with shared interrupts. 

  HOWEVER, if your system has shared interrupts that didn't used to

  get noticed, then you may suddenly get much slower. This happens on

  my personal Intellistation which shares an IRQ for the USB and audio.

  20031113  14.096e

- trace fix didn't get into previous w4 and uni kernels

- EXPERIMENTAL: Removed a bunch of redundant locking and unlocking of

  some pages in filesystem code that's already pinned, anyway. This

  ought to speed up a number of filesys-related APIs. Also, re-enabled

  the un-pinning of numerous pages of memory from init code. This

  memory is now available for other uses, which should reduce paging on

  many systems. This had been turned off since WSeB!

PJ29472: process hangs (and other things?) if named pipe handle is

   closed while another thread is blocked in DosConnectNmPipe.

  20031117  14.097b  (post xr_c004)

  - Some of the pages in the 20031113 package may possibly need to stay

  resident to avoid any danger of a trap 000e if they're needed during

  page fault processing or interrupt time. So, this time, I left those

  pages resident,too.


  20040116 14.097d

  - the code lock stuff seems to be working well, so it's no longer 

   "experimental."

- possible DosConnectNmPipe regression test fix

- Support for loading pure 32 bit code and data objects in DLLs above

  the 512mb line. More details on that to come separately.

  20040119 14.097d  (still)  *DON'T USE THIS OS2LDR*

  No kernel changes from 0116, but OS2LDR changes:

  - the interrupt sharing fix had, at some point, got taken back out.

  users with seeming IRQ issues should try this

- possible problem booting up P4 Xeon 4 gHz (hang at boot blob)

  20040123 14.097e

  - fix bad cFH count in DosQuerySysState/QProcStatus with level=0

- attempt to fix intermittent trap 000e resulting from highmem loadin

  in 116 kernel

    - bad fix for boot blob hang in 20040119 caused "unable to operate

  hard disk" failures with os2ldr from 20040119 packages

  20040126 14.097f

  - fix bad file handle array in DosQuerySysState/QProcStatus with level=0

  - more changes related to boot hangs and other weirdness from 1/23

  20040126 14.097g

  - more on file handle array in DosQuerySysState/QProcStatus with level=0

  - another attempt to update os2ldr to work with everything from 486SX to P4 Xeon >3gHz....

PJ29595: trap 000e at SftFileSize + 66 or so

  20040206 14.097h

  PJ29602 trap 000d at h_DOS_ChDir + 28 or so after media change

- backed out bogus os2ldr changes (again)

  20040323 14.098a

  PJ29697 add debug support for disappearing browser windows

- fix DevIOCtl passthru support

- fixed the "k" command in the dump formatter (at least it's better)

  20040330 14.098b

  PJ29712 (os2ldr) final fix for boot blob hang on fast (around 3+ gHz) CPUs

- backed out some kernel stuff that accidentally got built


Following are rough instructions for applying the os2krnl fix:

In the directory from which you boot (C:\ or d:\ or whatever), type these

commands. Note that os2krnl should have come with this file.


Also, there are some REXX scripts written by third parties that might make

installation/archiving of your kernels easier. Go to http://hobbes.nmsu.edu

and search for "moritz", for example. This is unsupported by IBM!


1. attrib -r -s -h os2krnl

2. attrib -r -s -h os2ldr

3. copy os2krnl os2krnl.sav

4. copy os2ldr os2ldr.sav

5. copy \os2\system\trace\*.tdf  \save       (or wherever)

5. unzip -o xxx.zip

If you want, you can turn the os2krnl and os2ldr attributes back on, but

it's not necessary to do so.


Trace files (*.tdf)  have been included.


An os2krnl.sym file has been provided with this fix. Just save it somewhere

(root directory or anywhere). It is only needed in case OS/2 

service requests a standalone dump of your system in the future.


Comments

Category
State
  • 현재 접속자 249 명
  • 오늘 방문자 680 명
  • 어제 방문자 1,567 명
  • 최대 방문자 11,402 명
  • 전체 방문자 2,449,061 명
  • 전체 게시물 3,053 개
  • 전체 댓글수 4,592 개
  • 전체 회원수 104 명

- 쇼핑몰 : Softbox
- 예전 문서 / Old docs
- FTP Server: http://ftp.hanmesoft.com
Facebook Twitter GooglePlus KakaoStory NaverBand