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 ... 72
Networking / Re: Squid Cache
« on: Today at 05:20:53 am »
Guys...I'm curious: what's the purspose of setting up Squid on a client machine?

If I understood it's intended purpose correctly, it's meant to be a caching proxy primarily for server environments where the clients which are connecting to the server may fetch the very same data, and when that's coming from the caching proxy instead, it makes the response that much quicker, thus providing scalability, etc.

So when deployed on a client I'm thinking there is a very limitted benefit, no?

I haven't tried it, so no actual metrics to toss into the YEY or NAY side.


Applications / Re: LIBC panic errors anyone?
« on: January 17, 2022, 03:40:18 pm »
Quick update on what I found to be the best combo to assure FF stability:

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

5) nspr.pentium4                           4.12.0-4.oc00
6) nss                                           3.23.0-4.oc00
7) nss-util                                     3.23.0-4.oc00
8) nss-softokn                               3.23.0-4.oc00
9) nss-softokn-feebl                       3.23.0-4.oc00

This gets me back to rock-solid config for running FF, which means an occasional crash (rare) but a normal application re-start being required once FF gets over 1G of memory use.

The caveat here is that I went back to AOO 4.1.7 due to the libicu 68 and 65 issues as they apparently kept on impacting my stable FF setup (so the combo of NSPR and NSS packaged).

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...


Pages: [1] 2 3 ... 72