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

I've had a pesky problem on my OS/2 box for a while now, that being on Samba connections Lucide takes far too long to open a PDF that's sitting out there on my NAS box. This is not just a Lucide issue, GSView as well as QPDFView show the same behaviour.

We are talking here PDF files that are about 70-150k in size that take 5-10 secs to open up.

To be clear, I am using NetDrive Samba plugin to make this work, and that could certainly be adding, I just can't tell.

What I can see is that as I open a PDF file my TCP/IP monitor shows multiple traffic spikes, they continue (back and forth) until the file is opened up. Now nearly each one of these are spikes are actually larger than the actual PDF file itself, so that's literally flooring me as I can't for the life of me understand what is causing the traffic to happen. how can I troubleshoot this in order to figure out what all that "overhead" is that appears to be moving back and forth?

I've got Wireshark installed, so I could capture the packets as the transactions start...but is there something a little more human-digestable? I'm thinking Samba logging perhaps?


Utilities / Re: MeShell commandline frontend timetable
« on: January 24, 2022, 10:31:15 pm »
Hi Martin,

I paused following this thread for a couple of month. What is Xit?

Xit is a VERY old utility that basically enhances the WPS and beyond it, such as CLI, etc. I have had it installed on my machine for many years now, but occasionally it'll run into a problem with some apps. It does have the option to be disabled for such apps, which is what I had to do with your MeShell utility.

Does anyone has found bugs?

Three things:

1) Bug maybe not, but I find that programs initiated from within MeShell once closed cause the background VIO window ("top (VIO 1)") to be placed into now they become visible, which is not what I think should happen. I would prefer that this window remains in the background and continues to server it's purpose.

2) When a new window is created by MeShell, that window becomes "glued" to the location of MeShell. This means that I cannot move the MeShell and the started VIO session independently of each other, or to clarify: I can only move the CHILD window, but I cannot move the PARENT window because as soon as I try that they always follow each other. This may be fine on a single screen, but on my dual monitor display as soon as I scroll off the screen (with my mouse) the CHILD window stops moving while the PARENT MeShell window continues to go off-screen, this messes up the arrangement between the two and creates some funny (completely off-set, overlapped, or disjointed) windows.

3) Attempts to pipe output to something like "less" simply do not work. The whole output scrolls, and yes, I can then afterwards go back up the page, but sometimes that's not the point, instead I'd like to stop at exactly a pagefull, review that info before I proceed further.

Thanks again!

Networking / Re: Samba Shares - default CAPS in filenames?
« on: January 24, 2022, 02:33:00 am »

So now that I'm aware of this symptom, and can readily replicate it, I spent a little more time learning about the Samba aspects.

As best as I can tell the pertaining section of the smb.conf file is:

Code: [Select]
case sensitive  = auto
default case    = lower
preserve case   = yes
short preserve case = yes

I specifically have these under the [global] group, which means that the same settings apply to all the shares.

I have been able to determine that my Win 7/10 shares behave as expected: the case is preserved when a NEW file is created. It is only my NAS box that does not.

However, further on I discovered that in a CLI window the actual file object does in fact have the correct lower/upper-case, only the WPS folder listing shows the filename in ALL CAPS.

Further still...once a re-boot happens the WPS itself switches to show the correct mix of upper/lower-case, which is a perfect sync with what I see in the CLI itself. I'm running XWP here (1.0.14 - Oct_2021), not sure if that is causing this behaviour, however it is VERY weird that after a re-boot what XWP shows is correct.

Re: smb.conf settings, to rule out any of the above combinations as causing this behaviour I tried multiple combinations, including completely commenting these out. Turns out this had no impact.

What is interesting is that my Win 7/10 shares are flagged as supporting EAs, while the NAS box does NOT, so maybe that has some bearing on the outcome as well?

Networking / Samba Shares - default CAPS in filenames?
« on: January 22, 2022, 05:35:38 pm »
Hi Everyone,

I've noticed this the other week: it would appear that ALL newly created documents which I am saving on my NAS (therefore using Samba client connection) are using UPPERCASE letters, this is despite the fact that within the application itself I am actualy saving with lowercase, and/or combination of the two.

Has anyone else noticed this?

I recall having a sporadic occurence of this before, but I just attributed that to "human mistake" as I rarely create a lot of NEW documents on my NAS. But recently I have been doing a bit of a re-org and moving some of my OS/2 application specific things to formats that non-OS/2 apps can read and that is how I discovered this issue.

The NAS confirmation has not changes at all and so far I haven't spent much time researching the Samba config side of it, that'll be my next step though. In the meantime I was curious if anyone else has been encountering this behaviour?


Networking / Re: Squid Cache
« on: January 22, 2022, 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).

Pages: [1] 2 3 ... 72