Discussion:
Using JFS on a removable media leads to trap
(too old to reply)
Lars Erdmann
2008-01-01 19:51:36 UTC
Permalink
Hallo,

using eCS 1.2 R, all latest fixes, XRGC005 (Fixpak 5), kernel 14.104a_W4
and, in particular JFS update 14.105:

Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature: @#IBM:14.105#@ IBM OS2 JFS retail bld
Vendor: IBM
Revision: 14.105
File Version: 14.105
Description: IBM OS2 JFS retail bld


I tried to format a Zip 100 medium with JFS. On the medium, I created a
LVM volume, then I formatted to JFS. The format went through almost all
the way but when it came to the very end where the BPB is written (I
suppose), JFS trapped with this error:


OS/2-Kernel-Überarbeitung 14.104a_W4
Exception in module: JFS
TRAP 000e ERRCD=0000 ERACC=**** ERLIM=********
EAX=00000000 EBX=00000200 ECX=fd837a90 EDX=00000000
ESI=f9ca5bbd EDI=26cb0108 EBP=f9908c18 FLG=00212246
CS:EIP=2a68:f8b7b176 CSACC=d09b CSLIM=ffffffff
SS:ESP=1550:f9908bf0 SSACC=c093 SSLIM=ffffffff
DS=0160 DSACC=c093 DSLIM=ffffffff CR0=8001001b
ES=0160 ESACC=c093 ESLIM=ffffffff CR2=00000008
FS=03c0 FSACC=0093 FSLIM=00000023
GS=0000 GSACC=**** GSLIM=********


The same trap occurs when I leave the "screwed up" medium inserted on
OS/2 boot, obviously when the JFS filesystem tries to read the BPB
information.

Is this a known problem ? Is there any way to circumvent the trap ? I
have a complete system dump available but it is 2 GB ...
Or, can anyone help me with examining the system dump ? I have the
debugging handbooks available but I don't know how to start ...

Lars
t***@antispam.ham
2008-01-02 02:01:52 UTC
Permalink
I formatted a 320 GB USB drive using JFS. Working fine.
Lars Erdmann
2008-01-02 10:25:45 UTC
Permalink
Hi,

I am not using USB, it's a parallel port attached Zip 100 Iomega drive which
is handled by PPAOS2.ADD and not the USB driver stack. But that gives an
indication that perhaps it's a problem with PPAOS2.ADD and not with
OS2LVM.DMD / OS2DASD.DMD.

Lars
Post by t***@antispam.ham
I formatted a 320 GB USB drive using JFS. Working fine.
Steven Levine
2008-01-02 04:56:19 UTC
Permalink
In <477a99cd$0$16572$***@newsspool1.arcor-online.net>, on 01/01/2008
at 08:51 PM, Lars Erdmann <***@arcor.de> said:

Hi,
Post by Lars Erdmann
I tried to format a Zip 100 medium with JFS. On the medium, I created a
LVM volume, then I formatted to JFS. The format went through almost all
the way but when it came to the very end where the BPB is written (I
Is the Zip drive normally handled as a large floppy or is it partitioned?

Which driver is providing access to the drive?

Lot's of folks are just JFS formatted removables, but these are typically
USB attached, so it's usbmsd that providing the low level access to the
drive.
Post by Lars Erdmann
OS/2-Kernel-Überarbeitung 14.104a_W4
Exception in module: JFS
TRAP 000e ERRCD=0000 ERACC=**** ERLIM=********
EAX=00000000 EBX=00000200 ECX=fd837a90 EDX=00000000
ESI=f9ca5bbd EDI=26cb0108 EBP=f9908c18 FLG=00212246
CS:EIP=2a68:f8b7b176 CSACC=d09b CSLIM=ffffffff
SS:ESP=1550:f9908bf0 SSACC=c093 SSLIM=ffffffff
DS=0160 DSACC=c093 DSLIM=ffffffff CR0=8001001b
ES=0160 ESACC=c093 ESLIM=ffffffff CR2=00000008
FS=03c0 FSACC=0093 FSLIM=00000023
GS=0000 GSACC=**** GSLIM=********
What you might try is

ln 2a68:f8b7b176
u 2a68:f8b7b176-20 l25t

and Analyze-Thread->Ring0 Stack Trace

These might give you some idea what the code was doing. The Trap E says
the driver is probably trying to access uncommitted memory. It's hard to
say why with just a popuplog.

If you have the bootable JFS components installed, you might try creating
a compatibility volume and formatting this JFS.

Steven
--
--------------------------------------------------------------------------------------------
Steven Levine <***@earthlink.bogus.net> MR2/ICE 3.00 beta 10pre #10183
eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------
Lars Erdmann
2008-01-02 10:23:48 UTC
Permalink
Hallo,


"Steven Levine" <***@earthlink.bogus.net> schrieb im Newsbeitrag news:477b1bd3$2$fgrir53$***@news.west.earthlink.net...
In <477a99cd$0$16572$***@newsspool1.arcor-online.net>, on 01/01/2008
at 08:51 PM, Lars Erdmann <***@arcor.de> said:

Hi,
Post by Lars Erdmann
I tried to format a Zip 100 medium with JFS. On the medium, I created a
LVM volume, then I formatted to JFS. The format went through almost all
the way but when it came to the very end where the BPB is written (I
Is the Zip drive normally handled as a large floppy or is it partitioned?

Well, I used LVM to create a LVM volume as otherwise it was not possible at
all to create a partition that could be formatted to JFS. How do I prepare a
media as a large floppy ? Will I then be able to format it with JFS ?



Which driver is providing access to the drive?

It is PPAOS2.ADD as I am using that stone old parallel port attached ZIP 100
drive.


Lot's of folks are just JFS formatted removables, but these are typically
USB attached, so it's usbmsd that providing the low level access to the
drive.

In that case, it's not, see above.
Post by Lars Erdmann
OS/2-Kernel-Überarbeitung 14.104a_W4
Exception in module: JFS
TRAP 000e ERRCD=0000 ERACC=**** ERLIM=********
EAX=00000000 EBX=00000200 ECX=fd837a90 EDX=00000000
ESI=f9ca5bbd EDI=26cb0108 EBP=f9908c18 FLG=00212246
CS:EIP=2a68:f8b7b176 CSACC=d09b CSLIM=ffffffff
SS:ESP=1550:f9908bf0 SSACC=c093 SSLIM=ffffffff
DS=0160 DSACC=c093 DSLIM=ffffffff CR0=8001001b
ES=0160 ESACC=c093 ESLIM=ffffffff CR2=00000008
FS=03c0 FSACC=0093 FSLIM=00000023
GS=0000 GSACC=**** GSLIM=********
What you might try is

ln 2a68:f8b7b176
u 2a68:f8b7b176-20 l25t

and Analyze-Thread->Ring0 Stack Trace

These might give you some idea what the code was doing. The Trap E says
the driver is probably trying to access uncommitted memory. It's hard to
say why with just a popuplog.

As I said I have a complete system dump (2 GB in size). First I will look at
your suggestion. Then, if you want more info, can you tell me how to give it
? I have your trapdumpscreen.cmd file, would that provide more info ?




If you have the bootable JFS components installed, you might try creating
a compatibility volume and formatting this JFS.

I did, see above. I don't have bootable JFS installed. Where do I get it ? I
read that I have to use it instead of the standard JFS. How do I do that ?
eCSMT does not offer me a download for bootable JFS.



Thanks,
Lars
Steven Levine
2008-01-02 17:57:52 UTC
Permalink
In <477b6634$0$16577$***@newsspool1.arcor-online.net>, on 01/02/2008
at 11:23 AM, "Lars Erdmann" <***@arcor.de> said:

Hi,
Post by Lars Erdmann
It is PPAOS2.ADD as I am using that stone old parallel port attached ZIP
100 drive.
Without additonal evidence, I would suspect this driver did something
wrong. That said, until we see a disassembly of the code in the vicinity
of the trap, this is just a guess. I am assuming you are using JFS on
other volumes without any issues.
Post by Lars Erdmann
As I said I have a complete system dump (2 GB in size). First I will look
at your suggestion. Then, if you want more info, can you tell me how to
give it ? I have your trapdumpscreen.cmd file, would that provide more
info ?
It might, but not all that much more. DumpTrapScreen.cmd is for folks
that for one reason or another are unwilling to install a trap dump
partition, but happen to have a diskette drive installed. The system dump
file contains orders of magnitude of more useful information. :-)
Post by Lars Erdmann
I did, see above. I don't have bootable JFS installed. Where do I get it
?
It's standard with eCS2.0. If you have an eCS Support Subscription, you
have access to the 2.0 betas and as with most eCS/OS2 components you can
mix and match in most cases.
Post by Lars Erdmann
I read that I have to use it instead of the standard JFS.
Well, it is an upgrade to the IBM supplied JFS.
Post by Lars Erdmann
How do I do that ?
The core of bootable JFS is a replacement UJFS.DLL. This implements
support for formatting the JFS volume and installing the appropriate
bootloader and OS2BOOT.

Steven
--
--------------------------------------------------------------------------------------------
Steven Levine <***@earthlink.bogus.net> MR2/ICE 3.00 beta 10pre #10183
eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------
Lars Erdmann
2008-01-07 20:58:49 UTC
Permalink
Hallo,

I queried the system dump:
1.) dg 2a68 -> 2a68 Code
Bas=00000000 Lim=ffffffff DPL=0 P RE A G4k C32 UV (flat code
segment, offset is therefore linear address)

2.) lg jfs (I have jfs.sym loaded) -> Map Addr Map Name
%f8b78000 CODE32
0a78:00000000 _TEXT
%fa7b8000 CONST32_RO
0a88:00000000 DATA16
%fa7b6000 unictab
0a98:00000000 DGROUP
therefore the trap occurs in jfs.ifs, segment CODE32 (the flat code segment)

3.) ln 2a68:f8b7b176 (or ln %f8b7b176) -> %f8b7afe3 JFS
FS32_MOUNT + 193 (the error occurs in the MOUNT file system routine or
somewhere off of the MOUNT routine)

4.) u %f8b7b176-20 l30t:

%f8b7b156 18457b sbb byte ptr [ebp+7b],al
%f8b7b159 fa cli
%f8b7b15a 89591c mov dword ptr [ecx+1c],ebx
%f8b7b15d 8b5df4 mov ebx,dword ptr [ebp-0c]
%f8b7b160 0fb75b0b movzx ebx,word ptr [ebx+0b]
%f8b7b164 895910 mov dword ptr [ecx+10],ebx
%f8b7b167 8b401e mov eax,dword ptr [eax+1e] <---
16:16 pointer in eax
%f8b7b16a 85c0 test eax,eax
%f8b7b16c 7405 jz %f8b7b173
%f8b7b16e e8c1dbffff call %f8b78d34
<--- call to _DosSelToFlat
%f8b7b173 8945f0 mov dword ptr [ebp-10],eax <---
linear address in eax and saved on stack
%f8b7b176 8b5808 mov ebx,dword ptr [eax+08] <---
error occurs here
%f8b7b179 895920 mov dword ptr [ecx+20],ebx
%f8b7b17c 8bd8 mov ebx,eax
%f8b7b17e f6430480 test byte ptr [ebx+04],80
%f8b7b182 740c jz %f8b7b190
%f8b7b184 8b5b1c mov ebx,dword ptr [ebx+1c]
%f8b7b187 895924 mov dword ptr [ecx+24],ebx
%f8b7b18a eb0d jmp %f8b7b199
%f8b7b18c 8bc0 mov eax,eax
%f8b7b18e 8bc0 mov eax,eax
%f8b7b190 8bc1 mov eax,ecx
%f8b7b192 c7402400000000 mov dword ptr [eax+24],00000000
%f8b7b199 8b0d104d7bfa mov ecx,dword ptr [fa7b4d10]
%f8b7b19f 51 push ecx
%f8b7b1a0 8b5dfc mov ebx,dword ptr [ebp-04]
%f8b7b1a3 53 push ebx
%f8b7b1a4 e89b4d0000 call %f8b7ff44
%f8b7b1a9 8945f8 mov dword ptr [ebp-08],eax
%f8b7b1ac 85c0 test eax,eax

5.) ln %f8b78d34 -> %f8b78d34 JFS _DosSelToFlat


Therefore, JFS's DosSelToFlat is not able to return a valid linear
address from the selector:offset passed to it via eax. As can be seen
from the code, not even the 16:16 input address to _DosSelToFlat is
properly checked, if it is NULL:NULL, just the call to _DosSelToFlat is
skipped and nothing else. In any case, a NULL linear address is returned
(or the 16:16 address is NULL:NULL already) which JFS does not check on
access.


If I only had access to the JFS code ....
By the way: does anyone know if the JFS code comes close to the OPENJFS
code (from netlabs.org) ?


Lars
Post by Steven Levine
Hi,
Post by Lars Erdmann
I tried to format a Zip 100 medium with JFS. On the medium, I created a
LVM volume, then I formatted to JFS. The format went through almost all
the way but when it came to the very end where the BPB is written (I
Is the Zip drive normally handled as a large floppy or is it partitioned?
Which driver is providing access to the drive?
Lot's of folks are just JFS formatted removables, but these are typically
USB attached, so it's usbmsd that providing the low level access to the
drive.
Post by Lars Erdmann
OS/2-Kernel-Überarbeitung 14.104a_W4
Exception in module: JFS
TRAP 000e ERRCD=0000 ERACC=**** ERLIM=********
EAX=00000000 EBX=00000200 ECX=fd837a90 EDX=00000000
ESI=f9ca5bbd EDI=26cb0108 EBP=f9908c18 FLG=00212246
CS:EIP=2a68:f8b7b176 CSACC=d09b CSLIM=ffffffff
SS:ESP=1550:f9908bf0 SSACC=c093 SSLIM=ffffffff
DS=0160 DSACC=c093 DSLIM=ffffffff CR0=8001001b
ES=0160 ESACC=c093 ESLIM=ffffffff CR2=00000008
FS=03c0 FSACC=0093 FSLIM=00000023
GS=0000 GSACC=**** GSLIM=********
What you might try is
ln 2a68:f8b7b176
u 2a68:f8b7b176-20 l25t
and Analyze-Thread->Ring0 Stack Trace
These might give you some idea what the code was doing. The Trap E says
the driver is probably trying to access uncommitted memory. It's hard to
say why with just a popuplog.
If you have the bootable JFS components installed, you might try creating
a compatibility volume and formatting this JFS.
Steven
Lars Erdmann
2008-01-08 02:03:38 UTC
Permalink
Hi,

I had a look at the OPENJFS source in the hope that I would be able to
deduce from the code and understand the error and yes, I do !

The following code fragment (in FS32_MOUNT), taken from OPENJFS fails:

/* get the address of the strategy routine for
* this device and save it in the vfs.
*/
capsp = pvpfsi->vpi_pDCS; <-- capsp is assigned NULL
pointer, also thunk from 16:16 to 0:32 (_DosSelToFlat) as pDCS is 16:16
whereas capsp is 0:32
vfsp->vfs_strat2p = *(void * _Seg16 *)&capsp->Strategy2;


Since no check is done on capsp, trying to query the Strategy2 pointer
consequently fails.

The culprit is that the pDCS pointer is not correctly passed to the
filesystem (my impression is, the first call to the mount routine is
executed before the pDCS pointer is queried from OS2DASD/OS2LVM
combination and correctly set in pvpfsi).
I had this very same error when I worked on the FAT32 filesystem but at
that time, I only had Warp4 and I used the DANIDASD.DMD (in order to be
able to access FAT32 partitions) that is derived from the old 16-bit
OS2DASD.DMD.
But that error seems to be also existent with the new 32-bit
OS2DASD.DMD/OS2LVM.DMD and it seems to only occur for removable media (I
had also tested the FAT32 filesystem with my parallel port Iomega Zip
100 drive just as I tried with JFS now).

For the FAT32 driver, I built this really dirty quick hack into the
filesystem that, in case of pDCS = NULL, queries pDCS directly from
OS2DASD.DMD through the device driver chain:

216 pDevCaps = pvpfsi->vpi_pDCS;
217 pVolChars = pvpfsi->vpi_pVCS;
218
219 if (!pDevCaps)
220 {
221 Message("Strategy2 not found, searching Device Driver
chain !");
222 pDevCaps = ReturnDriverCaps(pvpfsi->vpi_unit);
223 }
225 if (pDevCaps)
226 {
....
249 }
...

409 P_DriverCaps ReturnDriverCaps(UCHAR ucUnit)
410 {
411 RP_GETDRIVERCAPS rp={0};
412 PRP_GETDRIVERCAPS pRH = &rp;
413 PFN pStrat = NULL;
414 SEL dsSel = 0;
415 SEL SAS_selector;
416 struct SAS far *pSas;
417 struct SAS_dd_section far *pDDSection;
418 struct SysDev far *pDD;
419
420 SAS_selector = SaSSel();
421 pSas = (struct SAS far *)MAKEP(SAS_selector,0);
422 pDDSection = (struct SAS_dd_section far
*)MAKEP(SAS_selector,pSas->SAS_dd_data);
423 pDD = (struct SysDev far
*)MAKEP(SAS_selector,pDDSection->SAS_dd_bimodal_chain);
424
425 while (pDD && (pDD != (struct SysDev far *)-1))
426 {
427 if (
428 (memicmp(&pDD->SDevName[1],"Disk DD",7) == 0) &&
// found OS2DASD.DMD
429 (pDD->SDevAtt == (DEV_NON_IBM | DEVLEV_1 | DEV_30))
// found OS2DASD.DMD
430 )
431 {
432 pStrat = (PFN)MAKEP(pDD->SDevProtCS,pDD->SDevStrat);
433 dsSel = pDD->SDevProtDS;
434
435 if (pStrat)
436 {
437
438 pRH->rph.Len = sizeof(rp);
439 pRH->rph.Unit = ucUnit;
440 pRH->rph.Cmd = CMDGetDevSupport;
441
442 _asm {
443 push ds
444 push es
445 push bx
446 mov ax,dsSel
447 mov ds,ax
448 mov es,word ptr pRH+2
449 mov bx,word ptr pRH
450 call dword ptr pStrat
451 pop bx
452 pop es
453 pop ds
454 }
455 return pRH->pDCS;
456 }
457
458 break;
459 }
460 pDD = (struct SysDev far *)pDD->SDevNext;
461 }
462 return NULL;
463 }


1 .MODEL LARGE,C
2 .386p
3
4 PUBLIC SaSSel
5 EXTRN PASCAL SAS_SEL:ABS
6 EXTRN C Device_Help:DWORD
7
11 .CODE
12 SaSSel PROC
13 mov ax,SAS_SEL
14 ret
15 SaSSel ENDP
16
17 END



I fear, it's a systematic problem in the kernel or with OS2DASD/OS2LVM ...


Lars
Post by Lars Erdmann
Hallo,
1.) dg 2a68 -> 2a68 Code
Bas=00000000 Lim=ffffffff DPL=0 P RE A G4k C32 UV (flat code
segment, offset is therefore linear address)
2.) lg jfs (I have jfs.sym loaded) -> Map Addr Map Name
%f8b78000 CODE32
0a78:00000000 _TEXT
%fa7b8000 CONST32_RO
0a88:00000000 DATA16
%fa7b6000 unictab
0a98:00000000 DGROUP
therefore the trap occurs in jfs.ifs, segment CODE32 (the flat code segment)
3.) ln 2a68:f8b7b176 (or ln %f8b7b176) -> %f8b7afe3 JFS
FS32_MOUNT + 193 (the error occurs in the MOUNT file system routine or
somewhere off of the MOUNT routine)
%f8b7b156 18457b sbb byte ptr [ebp+7b],al
%f8b7b159 fa cli
%f8b7b15a 89591c mov dword ptr [ecx+1c],ebx
%f8b7b15d 8b5df4 mov ebx,dword ptr [ebp-0c]
%f8b7b160 0fb75b0b movzx ebx,word ptr [ebx+0b]
%f8b7b164 895910 mov dword ptr [ecx+10],ebx
%f8b7b167 8b401e mov eax,dword ptr [eax+1e] <---
16:16 pointer in eax
%f8b7b16a 85c0 test eax,eax
%f8b7b16c 7405 jz %f8b7b173
%f8b7b16e e8c1dbffff call %f8b78d34 <--- call to
_DosSelToFlat
%f8b7b173 8945f0 mov dword ptr [ebp-10],eax <---
linear address in eax and saved on stack
%f8b7b176 8b5808 mov ebx,dword ptr [eax+08] <---
error occurs here
%f8b7b179 895920 mov dword ptr [ecx+20],ebx
%f8b7b17c 8bd8 mov ebx,eax
%f8b7b17e f6430480 test byte ptr [ebx+04],80
%f8b7b182 740c jz %f8b7b190
%f8b7b184 8b5b1c mov ebx,dword ptr [ebx+1c]
%f8b7b187 895924 mov dword ptr [ecx+24],ebx
%f8b7b18a eb0d jmp %f8b7b199
%f8b7b18c 8bc0 mov eax,eax
%f8b7b18e 8bc0 mov eax,eax
%f8b7b190 8bc1 mov eax,ecx
%f8b7b192 c7402400000000 mov dword ptr [eax+24],00000000
%f8b7b199 8b0d104d7bfa mov ecx,dword ptr [fa7b4d10]
%f8b7b19f 51 push ecx
%f8b7b1a0 8b5dfc mov ebx,dword ptr [ebp-04]
%f8b7b1a3 53 push ebx
%f8b7b1a4 e89b4d0000 call %f8b7ff44
%f8b7b1a9 8945f8 mov dword ptr [ebp-08],eax
%f8b7b1ac 85c0 test eax,eax
5.) ln %f8b78d34 -> %f8b78d34 JFS _DosSelToFlat
Therefore, JFS's DosSelToFlat is not able to return a valid linear
address from the selector:offset passed to it via eax. As can be seen
from the code, not even the 16:16 input address to _DosSelToFlat is
properly checked, if it is NULL:NULL, just the call to _DosSelToFlat is
skipped and nothing else. In any case, a NULL linear address is returned
(or the 16:16 address is NULL:NULL already) which JFS does not check on
access.
Steven Levine
2008-01-08 07:18:53 UTC
Permalink
In <4782d9fd$0$25376$***@newsspool4.arcor-online.net>, on 01/08/2008
at 03:03 AM, Lars Erdmann <***@arcor.de> said:

Hi,
Post by Lars Erdmann
I had a look at the OPENJFS source in the hope that I would be able to
deduce from the code and understand the error and yes, I do !
Good. I see you found the sources.
Post by Lars Erdmann
But that error seems to be also existent with the new 32-bit
OS2DASD.DMD/OS2LVM.DMD and it seems to only occur for removable media (I
had also tested the FAT32 filesystem with my parallel port Iomega Zip
100 drive just as I tried with JFS now).
This could even be some sort of timing issue.
Post by Lars Erdmann
For the FAT32 driver, I built this really dirty quick hack into the
filesystem that, in case of pDCS = NULL, queries pDCS directly from
It seems sufficiently robust to me. It's a shame I did not know about
this sooner. I don't use the FAT32 driver or I probably would have.
There was a time in the not so distant past that we might have been able
to open an APAR against this.
Post by Lars Erdmann
I fear, it's a systematic problem in the kernel or with OS2DASD/OS2LVM ...
It's probably something that's just going to need workarounds until these
drivers are reimplemented.

Would you open a support ticket for this a www.ecomstation.com and let me
know the ticket number? I can't make any promises, but I'll do what I can
to get your fix implemented in jfs.ifs.

Regards,

Steven
--
--------------------------------------------------------------------------------------------
Steven Levine <***@earthlink.bogus.net> MR2/ICE 3.00 beta 10pre #10183
eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------
Lars Erdmann
2008-01-12 11:59:32 UTC
Permalink
Hi,

the trap cause is clear and I know where it comes from. However, I
investigated further. Recently, I formatted an USB stick with JFS and
there was NO trap right after the format and I could use it without
problems. However, USB mass storage devices are handled by USBMSD.ADD
and not by PPAOS2.ADD (as for the parallel port Zip 100 drive).
So my conclusion is that for some reason, OS2DASD.DMD does not properly
return the "Device Capabilities pointer" (pDCS) that, amongst others,
contains its own strategy 2/strategy 3 entry point for all volumes that
are handled by PPAOS2.ADD.
I don't understand why, as strategy2/strategy3 entry point is an entry
point into OS2DASD.DMD and NOT into the underlying ADDs/FLTs so why
would OS2DASD.DMD fail to correctly return pDCS while it happily accepts
I/O requests on its strategy2/strategy3 entry point and correctly routes
these to PPAOS2.ADD ?
I also see a few minor problems with my "quick hack" as it assumes that
each volume is managed by OS2DASD.DMD:

1.) It will fail if the volume is managed not by OS2DASD.DMD but instead
by an old fashioned block device driver (installable .SYS driver) as
these drivers export their own strategy2 entry points and basically
completely bypass OS2DASD.DMD. Examples are vfdisk.sys (well it's a
virtual floppy device driver so you cannot format it to FAT32 or JFS
anyway) and vdisk.sys (the RAM disk device driver that comes with OS/2).

2.) Sometimes (is that rare of frequent ?) a volume is managed by
OS2SCSI.DMD instead of or in addition to OS2DASD.DMD. Note that SCSI
drives are NOT normally handled by OS2SCSI.DMD but by OS2DASD.DMD.
OS2SCSI.DMD just provides some quirky SCSI direct interface, as far as I
understand it. Maybe it's not even for storage media but something else
(read and write to a SCSI scanner as a file ?)

Do you think that my quick hack is better or is it better to return from
FS_MOUNT with an error if the pDCS cannot be obtained ? Obviously the
latter means that you cannot use that volume with that filesystem but at
least the FSD does not trap any more.
There is yet another alternative: do not try query pDCS from FS_MOUNT.
Instead, query it when you need it :you can always get to volume
information via the volume handle (hVPB) and the FSH_GETVOLPARM helper.
I haven't tried out if that circumvents the unavailability of pDCS, though.

Let me know your opinion. Thanks,

Lars
Post by Steven Levine
Hi,
Post by Lars Erdmann
I had a look at the OPENJFS source in the hope that I would be able to
deduce from the code and understand the error and yes, I do !
Good. I see you found the sources.
Post by Lars Erdmann
But that error seems to be also existent with the new 32-bit
OS2DASD.DMD/OS2LVM.DMD and it seems to only occur for removable media (I
had also tested the FAT32 filesystem with my parallel port Iomega Zip
100 drive just as I tried with JFS now).
This could even be some sort of timing issue.
Post by Lars Erdmann
For the FAT32 driver, I built this really dirty quick hack into the
filesystem that, in case of pDCS = NULL, queries pDCS directly from
It seems sufficiently robust to me. It's a shame I did not know about
this sooner. I don't use the FAT32 driver or I probably would have.
There was a time in the not so distant past that we might have been able
to open an APAR against this.
Post by Lars Erdmann
I fear, it's a systematic problem in the kernel or with OS2DASD/OS2LVM ...
It's probably something that's jus t going to need workarounds until these
drivers are reimplemented.
Would you open a support ticket for this a www.ecomstation.com and let me
know the ticket number? I can't make any promises, but I'll do what I can
to get your fix implemented in jfs.ifs.
Regards,
Steven
Lars Erdmann
2008-01-22 21:26:58 UTC
Permalink
Hi Steven,

I have submitted a bug report in bug tracker as well as in the ticket
system.
The bug report number in bug tracker is:

0001893


Lars
Post by Steven Levine
Post by Lars Erdmann
For the FAT32 driver, I built this really dirty quick hack into the
filesystem that, in case of pDCS = NULL, queries pDCS directly from
It seems sufficiently robust to me. It's a shame I did not know about
this sooner. I don't use the FAT32 driver or I probably would have.
There was a time in the not so distant past that we might have been able
to open an APAR against this.
Post by Lars Erdmann
I fear, it's a systematic problem in the kernel or with OS2DASD/OS2LVM ...
It's probably something that's just going to need workarounds until these
drivers are reimplemented.
Would you open a support ticket for this a www.ecomstation.com and let me
know the ticket number? I can't make any promises, but I'll do what I can
to get your fix implemented in jfs.ifs.
Regards,
Steven
scott g
2008-01-02 16:19:38 UTC
Permalink
well the trap screen suggests that JFS tried to allocate some memory from
somewhere, got an out of memory condition, and tried to use the (invalid)
pointer, anyway. My suggestion is to just not use JFS for this drive. Although
some people are certainly making it work, JFS on OS/2 was never meant to be used
on removable drives. Also, I have a vague recollection about PPAOS2 doing bad
things (a-la the aha1542 driver). So, if you feel you must you JFS on your zip
cartridges, get a different drive. Hell, I have an old SCSI Zip drive I'll sell
you cheap <g>.

-Scott
scott g
2008-01-02 16:22:38 UTC
Permalink
well, thinking more, probably not "out of memory" so much as "I can't give the
pointer you want" and then the caller didn't check for a null pointer.
Loading...