Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Dariusz Piatkowski

Pages: [1] 2 3 ... 71
The system detected an internal processing error at
location ##0168:a41c - 0010:a41c.
60004, 6009
128606c3 - 00/00 00:00:00.00
Internal revision 14.104b_SMP
The system is stopped.  Record all of the above information and
contact your service representative.

That 14.104b_SMP is a very old kernel, in fact the quasi-official latest IBM build was 106. AOS has gone to never kernels since, and that might help.

Applications / Re: LIBC panic errors anyone?
« on: January 12, 2022, 04:06:21 am »
NSPR4 and NSS are usually a matched pair. At that to build standalone NSS, you use the NSPR4 build system.

Oh Dave, I found that out pretty quickly...literally a HARD lock.

Yup, back to the previous versions of NSPR and NSS, and unfortunately had a single crash that implies it's back to LIB's corner.

Man, what a shame though...looked like the updated AOO addressed a few issues too.

Applications / Re: LIBC panic errors anyone?
« on: January 12, 2022, 03:16:40 am »
Dave, everyone...

For Firefox, you might want to try downgrading NSS and NSPR4. Could probably put the DLLs in Firefox's program directory too, untested.

Yup, that's the current "last straw" I'm on LOL.

I did downgrade to LIBICU libicu-65.1-2.oc00.pentium4 first, tried that, but crashes continued, at which point in time I re-installed the 68 release and moved the NSS stuff back to the previous level (3.23).

Since I'm doing all this anyways I thought I'd leave NSPR at 4.23 (per previous upgrade from 4.12) just to see if that is a contributing to the end results I'm seeing in any way.

More to follow as time progresses...thanks for the feedback everyone!

Applications / Re: LIBC panic errors anyone?
« on: January 11, 2022, 09:29:41 pm »
Well you guys...I really honestly wanted this to work...but man, a trap every 3 hrs. is just a little too much for me! (FF is what I'm talking about here)

So I'm trying different things now, I downgraded to LIBICU libicu-65.1-2.oc00.pentium4, which now of course kills the new AOO 4.1.11.

The work around for that is to run the 68 version of LIBICU for AOO (so separate set of DLLs) which I think spells trouble!

Does anyone know of a good AOO work-around for the latest LIBICU challenges?

Applications / Re: LIBC panic errors anyone?
« on: January 10, 2022, 04:40:55 pm »

...Don't shoot the messenger. It looks like there is an actual improvement in libc to properly report if you call "free" on the very same pointer more than once (which is forbidden)...

Thanks for that input...I started to review each trap report closer to see what might be the root cause. I have consistently seen what appear to be memory calls.

The good news is that CRON/2, which is the one most often showing these, had been released with source. That means I can attempt to debug (and probably learn a pile more while doing so).

Thank you, insight greatly appreciated!

Storage / Re: JFS - Trap 0003 - anyone?
« on: January 09, 2022, 05:03:27 pm »

The problem is that you are using the latest kernel on Warp v4.52. IBM has only licensed it for ArcaOS so Arca Noae isn't going to support it, at that they basically can't support it.

That I understand, however my less-than-conducive experience stems from working through some issues I had BEFORE the latest kernel was even being talked about and subsequently released...bottom line: DA's take on my multiple reported issues simply was "unless you're running one of our approved combinations I can't help you"...soo...I gave up!

Besides, you know this very well, take a look at the latest USB driver test request on our Testers List, see that glaring:

As always, please review and follow the Arca Noae Test Team Policy which is available here:

...which I have no access to, so maybe you can tell me what's on there?

Meanwhile I'm guessing that there are way many more hardware combinations out there that the USB driver test effort would benefit from, folks who are NOT currently running AOS, and yet we leave that opportunity completely un-tapped.

Anyways, politics, whatever...following my multiple attempts at providing testing/debugging value I gave up and decided to focus exclusively on stuff that somewhat still remains non-AOS core, such as the Samba clients, general apps (Lucide, etc.).

Applications / Re: SeaMonkey downloads and Unix permissions
« on: January 09, 2022, 02:53:01 am »
You know...there is one more thing I came across while looking into the LIBC errors I am starting to regularly see now.

Here is what I found at the LIBCx Github (

EXPERIMENTAL. Automatic setting of the Unix user ID at process startup to an ID of a user specified with the LOGNAME or USER environment variable if a match in the passwd database is found for it. This has a numbef of side effects, e.g. all files and directories created by kLIBC functions will have an UID and GID of the specified user rathar than root. Also Unix programs will see the correct user via getuid() and other APIs which in particular will make some tools (e.g. yum) complain about the lack of root priveleges. For this reason this functionality is disabled by default and can be enabled by setting LIBCX_SETUID=1 in the environment.

Worth a try? You could try enabling this just for the Seamonkey session itself, so you'd need to start from a CMD and have the environment variables set there before you load Seamonkey.

Applications / LIBC panic errors anyone?
« on: January 09, 2022, 02:18:56 am »
I am running the following LIBC RPM packages:

1) libc.pentium4                            1:0.1.9-1.oc00
2) libc-devel.pentium4                      1:0.1.9-1.oc00
3) libcurl.pentium4                         7.75.0-2.oc00
4) libcx.pentium4                           0.7.2-1.oc00
5) libcx-devel.pentium4                     0.7.2-1.oc00

...and at some point in time (along the upgrade path) I started to notice the following "LIBC PANIC" errors in my trp directory:

LIBC PANIC!! _um_free_maybe_lock: Tried to free block twice - block=37013a00 lo
Call Stack
   EBP     Address    Module     Obj:Offset    Nearest Public Symbol
 --------  ---------  --------  -------------  -----------------------
 Trap  ->  1FE4B89E   LIBCN0    0001:000FB89E
 0013EAF8  1FE4C0A8   LIBCN0    0001:000FC0A8
 0013EB18  1FDE4B69   LIBCN0    0001:00094B69
 0013EB68  1FDC4D69   LIBCN0    0001:00074D69
 0013EB88  7B395268   XUL       0001:03565268  between js::gc::Arena::finalize + 228 and js::gc::ArenaLists::backgroundFinalize - 3678  (both in Unified_cpp_js_src23.cpp)
 34734D20  344B0538   *Unknown*
 Lost Stack chain - new EBP below previous

This one was actually generated by FF following my upgrade to the latest NSPR and NSS runtimes.

However, I've seen this error repeatedly with other applications, such as:

LIBC PANIC!! _um_free_maybe_lock: Tried to free block twice - block=20030035 lo
 Call Stack
   EBP     Address    Module     Obj:Offset    Nearest Public Symbol
 --------  ---------  --------  -------------  -----------------------
 Trap  ->  1FE4B89E   LIBCN0    0001:000FB89E
 0012FF14  1FE4C0A8   LIBCN0    0001:000FC0A8
 0012FF34  1FDE4B69   LIBCN0    0001:00094B69
 0012FF84  1FDC4D69   LIBCN0    0001:00074D69
 0012FFA4  000100E0   CRON2     0001:000000E0
 0012FFC4  00014238   CRON2     0001:00004238
 0012FFF4  1FFECE38   DOSCALL1  0004:0000CE38  DOS32R3EXITADDR

...or PMMail and AOO.

So I'm curious if anyone is seeing this too?

I can't quite peg this to a particular release, but it would have happened within the last couple of drops I think?

Storage / Re: JFS - Trap 0003 - anyone?
« on: January 09, 2022, 02:09:38 am »
Hi Roderick,

Is this under ArcaOS ? I ask this as I am not familiar with older OS/2 versions. But if you are running ArcaOS are you also dealing the latest ACPI, JFS and OS2KRNL from Arca Noae ?

No, this is not AOS. Warp 4.52 actually, SMP of course using the AN drivers, that includes the latest kernel and JFS.

I rarely (if ever anymore) put anything in as a ticket with AN because their official policy is to support only the AOS environment. It may have been somewhat different when the 'OS/2 Drivers' subscription was initially available (not sure if it is anylong actually or not).

Applications / Re: SeaMonkey downloads and Unix permissions
« on: January 08, 2022, 07:07:54 pm »
I see Dariusz has posted an idea too, no idea if a good idea :) this is why I have stuck with OS/2 over so many years (well, one of the reasons anyways), you always get the "opportunity" to find another way...

So here is what I did:

1) OS/2 file
Code: [Select]
-rw------- 1 root root     25602 Dec  6  2017 brp5470enc.ppd

2) NAS box file after being copied
Code: [Select]
[V:\public\raw\software]ls -ltr
-rw-rw-rw- 1 root root    25602 Dec  6  2017  brp5470enc.ppd

So at least here, given the Samba connection ID (root/admin) and therefore the Samba server permissions, the TARGET fs file inherits the ID's permissions.

Storage / Re: JFS - Trap 0003 - anyone?
« on: January 08, 2022, 06:40:24 pm »
OK, thanks for the feedback you guys.

I'll hold off on getting that ticket logged. Instead, I changed my JFS cache settings to those that have proved to provide me the best performance and am currently running with these.

I suspect that the issue I had ran into was probably not caused by the BUFFER settings, however not having a spare setup to replicate this on I'm just going to try to "stay away" from the combo (settings and actions) that caused me that TRAP.

Applications / Re: SeaMonkey downloads and Unix permissions
« on: January 08, 2022, 06:37:43 pm »
I'm curious if this would work as a work-around?

If your SAMBA server (and therefore the Samba server account) that you are connecting to has your ID belonging to the admin/root group, would copying the files from OS/2 allow you to create the TARGET file with the Samba ID matching permissions?

In other words: make sure the Samba connection ID you are using has the best-fitting persmissions so that when you create that file on the Samba server the file inherits your Server ID permissions, as opposed to the original permissions the file was created with on our OS/2 platform.

Makes sense I hope?

I haven't tried this, but from the very start of getting my NAS box connection up and running I was always using my 'admin' ID to connect with, and on the NAS box itself I have my personal ID set as part of the 'Admin' group.

Applications / Apache OpenOffice - OOWpsWizard anyone?
« on: January 08, 2022, 03:09:49 am »
Alright, so way back when (circa OO3.2) there was a handy little WPS class utility (OOWPSWizard) that defined multiple WPS classes that directly mapped to various AOO program objects.

I have had this installed for a long time now...but having just upgraded from AOO 4.1.7 to 4.1.11 I am trying to clean the place up a tad, you know?

So this begs the question: is anyone still using this OOWPSWizard thing?

I can't quite for the life of me remember what use I got out of it back then...clearly I thought there was value in having it installed though..LOL, so maybe the old memory is getting a little shaky???

Come to think of it, the benefit I think we got back then was to map all the AOO program objects to a particular WPS class, which then allowed one to manage those classes and assign WPS associations accordingly.

....yeah, it's been a while, and I really would rather keep the AOO install clean to avoid any problems in the future...which makes me think I should un-install OOWPSWizard...


Storage / JFS - Trap 0003 - anyone?
« on: January 06, 2022, 02:51:27 pm »

I figured I would inquire here first before logging a ticket for the AN folks on this JFS issue.

So the other day I had a weird situation: my nightly RSYNC job LOG needed to be "rotated" having grown to some 32M in size over the past couple of years. I decided to manually split it up into calendar year LOGs. I most likely had the file open in my editor while at the same time attempted to execute a CLI copy of that big file.


JFS died with TRAP 0003...meltdown!

Following a power re-boot JFS did a check disk and uber quickly flashed some messages up on the screen about lost directories. The chkdsk forced an automated re-boot and a 2nd chkdsk run. At the end of what felt like the longest 5 mins ever I got back to my MAINT partition to discover that my 'lost+found' directory now had some 17k files. Clearly chkdsk found some directory problems and moved a boat-load of files into the 'lost+found' directory. Yikes!

Anywyas, I was aware that this is probably the worst JFS situation when directories are mangled. Now luckily for me I had a nightly backup (RSYNC...LOL), so I was able to recover just fine. The mangled directories turned out to be my Firefox and Thunderbird cache, thus the massive listing of files.

Now that I'm up and running again and spending a little time researching this I discovered the following description of a TRAP 0003:

TRAP 0003 - BREAKPOINT. This is a special instruction (INT 3) used in "debugging" software, which was left in the code either accidentally or by design. Contact software support.

Further on, the following is also available:

[G:\]help 1933

SYS1933: A program caused a breakpoint error.  The program was ended.


EXPLANATION: A program started an INT 3 instruction when it was not
being run by a debugger.

ACTION: Correct the program and retry the command.

I found this extremely interesting given that in this latest version of JFS AN announced a successful quashing of a JFS bug when operations on a file LARGER than the JFS CACHE would potentially trap.

In my case I am running a large 1G cache, so I do not think this to be the issue...however as I experiment with various MIN and MAX buffer settings I may have potentially ran into a problem there. Hard to tell and NO I have not tried to replicate this issue!!! ha....

Take a look at the attached TRAP screen...what do you guys make of it?


Multimedia / Re: Audio-Data/CD-Creator - problems scanning the bus
« on: December 29, 2021, 05:24:44 am »
Sorry Dave, I probably didn't explain this fully and/or in the best possible way.

The issue I'm running into occurs only when I select the 'Scan' button from within the 'CD-Creator Settings' object's pages, otherwise from CLI the actual execution is fine, I get my correct device ID back. is what I did find out, I have the following statements in CONFIG.SYS:

REM [ Default shell values ]
SET SHELL=G:/usr/bin/sh.exe
rem SET EMXSHELL=G:/usr/bin/sh.exe
SET CONFIG_SHELL=G:/usr/bin/sh.exe
SET MAKESHELL=G:/usr/bin/sh.exe
SET EXECSHELL=G:/usr/bin/sh.exe

The BOLDED one was the problem-child...I am guessing I most likely set this up, don't remember why, but I do find a specific reference to it in the EMX INF files. For some reason I had set it to sh.exe as opposed to cmd.exe and well, that caused the 'Audio-Data/CD-Creator' class to fail the scan.

Either way, I have it REM'ed out now, noted why, if I fiind that it causes a problem elsewhere I'll need to revisit at that time.

Pages: [1] 2 3 ... 71