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
***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.
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.
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.
Support for 16bit filesystems with >2gb file support (e.g.the forthcoming
>2gb dump support ifs)
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).
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
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
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)
PJ28199 SES QUERYFILEINFO buffer pointer always -1
PJ28207 SES callgate hooks don't work
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
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
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
- 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
- back out all experimental stuff including the w_dup trap and trap 8
- 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
- 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)
- 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).
- 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
- 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
- don't use this one. I put it out by accident due to packaging bug.
- 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.
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)
- CLOSEFILES= back in
- fix 2 traps in w_DupHandle
Seems to affect Netfinity remote access.
PJ29849 trap 000c in w_NewSize during procdump processing
- incorrect parameters being reported in some devhelp system traces
- 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.
- 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
- the code lock stuff seems to be working well, so it's no longer
- 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)
- 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
- fix bad file handle array in DosQuerySysState/QProcStatus with level=0
- more changes related to boot hangs and other weirdness from 1/23
- 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
PJ29602 trap 000d at h_DOS_ChDir + 28 or so after media change
- backed out bogus os2ldr changes (again)
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)
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.