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 ... 87 88 [89] 90 91 ... 94
1321
Ivan,

Hi Dariusz,

Experience with monitor power supplies says that you not only replace the obvious dead capacitors but also any other electrolytic ones as well.  It might also be a good idea to have a good look at any on the panel driver board and replace any that have the slightest bulge at the top.

Excellent point sir...I did actually closely eye-ball all the capacitors on the power board...luckily only these 2 appeared damaged. There was at least 1 other 1000 uF/35V piece that actually looked "brand-new" (visually that is...LOL). I also pulled the logic board to take a peek at it...this is mostly IC though and contained none of the aluminum case capacitors.

1322
Programming / Re: New OS/4 kernel :: SVN4502
« on: January 02, 2016, 03:14:00 pm »
1) booting with OS4krnl produces a hard trap right after PMSHELL (I can not tell at all what is going on, so this looks like a candidate for a COM port debug, I need to get this organized though)

Similar stuff sometimes happens on  my computer as well. In the comport log it looks like this:

Code: [Select]
DelayHardError SYS3171: 4 string(s):
 Pid 0020  Tid 0001  Slot 0045  HobMte 053A
 C:\OS2\PMSHELL.EXE
c0000005
1f93b94a
P1=00000002  P2=0003ff14  P3=XXXXXXXX  P4=XXXXXXXX 
EAX=00000000  EBX=1f93b93c  ECX=00040028  EDX=0004f564
ESI=00000000  EDI=0004f3f4 
DS=0053  DSACC=d0f3  DSLIM=ffffffff 
ES=0053  ESACC=d0f3  ESLIM=ffffffff 
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:1f93b94a  CSACC=d0df  CSLIM=ffffffff
SS:ESP=0053:0003ff18  SSACC=d0f3  SSLIM=ffffffff
EBP=00040054  FLG=00010206

PMWP.DLL 0001:0000b94a
This happens once every 100 boots approx. I don't know the reason and it happens much later after the init of the kernel has finished.

It's possible that it's some old bug that has no relation to OS/4. I remember on the original kernel there sometimes happened situations when there appeared PMshell background and nothing more. Somebody offered a solution with organizing a kind of delay  before PMshell start, but I cannot find that post.

What you describe is precisely what I see with my standard 3.22.08 setup upon nearly every re-boot. Meaning, the PMSHELL window displays (the blue background) and halts...CTL-ALT-DEL still reboots the PC though. I find that if I hit the CTL-ESC key combination repeatedly as the PMSHELL window is coming up I can sucessfully boot though. This procedure works pretty well when I run my 6-core CPU in 5-core mode, as soon as I enable all the cores the PMSHELL nearly always hangs regardless of what I do during bootup. So this certainly appers to be some type of timing issue...

...Yes, ACPI.PSD has to be patched and used with /ST=0. Indeed,  the patch does very simple thing:
in ACPI.PSD there is something like this:
Code: [Select]
if (ST==0)
{
    ST=4096
}

patch makes this code out of it:
Code: [Select]
if (ST==0)
{
    ST=0
}

thus, if one asks for ST=0 he does get ST=0. I would like to stress that this patch does not "spoil"  ACPI.PSD and it still can be used with original kernel.

ACPI4.BPD - it is an optional acpi driver. It is not obligatory for booting the system.

It is true that there are patches only for 3.22.06 and 3.22.03, that's because nobody had asked for something else. If you insist,  patch for 08 will also be produced. At the same time you may try OS/4 with 06 (ACPI.PSD only  the rest may remain 08)

Well, I will try 3.22.06, but if at all possible (not sure how much work this is) I'd prefer to run the matching 3.22.08 instead.

I will a couple more combinations here, like RETAIL vs DEBUG kernels and /APIC vs none for OS4APIC.PSD driver.

waiting for result  (better with comport log ;) )

...nah, no go here...all other combinations produced the same result...a hang at PMSHELL, so I will focus on teh comport log and will attempt to re-test with the patched 3.22.06 first.

Co-incidentally, what is the reason for the different version of DOSCALL1.DLL? I repeated all my tests with both versions (14.106 SMP and the one included in the 4502 drop) but the results were the same.

Thanks for the quick response!!!

1323
Programming / Re: New OS/4 kernel :: SVN4502
« on: January 02, 2016, 02:04:02 am »
OS/4 kernel svn4502 is released. The changes have occurred mostly in clock$.
If HPET is available in the computer, clock$ will use it for providing DosTmrQueryTime/Freq with 64bit time stamp.

Re-tried this latest release...I am currently successfully running SMP in 5-core mode with ACPI 3.22.08, so that is my starting point.

Here are some brief results:

1) booting with OS4krnl produces a hard trap right after PMSHELL (I can not tell at all what is going on, so this looks like a candidate for a COM port debug, I need to get this organized though)

2) booting with OS4krnl but ACPI.PSD produces a trap with a complaint regarding missing ACPI4.BPD file...did some researching here but best I could do was to find an earlier forum post (http://www.os2world.com/forum/index.php?topic=785.0) and having re-read the on-line docs multiple times I still can not tell whether I should be attempting to patch the ACPI.PSD driver with the patch files supplied at the OS4 site (I am guessing the answer is a NO because those patches are meant for 3.22.06 release whereas I'm running 3.22.08 here)

I will a couple more combinations here, like RETAIL vs DEBUG kernels and /APIC vs none for OS4APIC.PSD driver.

1324
Well you guys...some good news...I took apart my dead 245T panel, as it turns out the power board shows 2 capacitors looking pretty dead...as in you know, all buldging and the icing on the cake is the leak of the internal chemicals right through the top of the capacitor, this shows there is a crack in the aluminum casing, etc, etc...so I'm thinking I will replace the two 1000 uF 35V capacitors first, will give it another try...now good lucking finding capacitors locally...yikes!

Now, here is an OS/2 thought: there was an announcement out a few weeks back about ArcaNoae picking up and re-starting the development of the SNAP drivers. With my previous EDID decoding experience and somewhat of a decent of an understanding of the monitor EDID structures I wouldn't mind getting involved in that aspect of the SNAP drivers development. So in other words, while the core of the heavy lifting is in the core drivers development (I think) it certainly would be a blessing to smarten up the anciliary logic so that modern monitor INF files are recognized, or the EDID information handling is more robust.

Therefore the question I have is: who is the person to contact regarding this?

1325
Hi Andi,

Quote
but that is still driven by the EDID monitor information being correctly recognized by the driver and thus telling it what the screen capability it.
TTBOMK you can bypass all this DDC stuff in SNAP when choosing 'Unknown monitor'...

Interesting..tell me more about this option because as best as I can remember I was never actually able to make this work, and we're talking here about shutting off the GAOPTION DDC mode, etc, etc. In other words, to make my 245T 1920x1200 capability known to the SNAP driver I had to literally re-program the monitor EDID...a bit of a crazy effort when you manually assemble the EDID record based on VESA standards, etc, etc...did it once, I would prefer not to have to do that again....and I say "again" because I have 3 other 245Ts currently at home, 2 linked on my professional/work PC and the 3rd one on kids's PC.

I had actually pulled the kids' 245T and plugged it in, but the SNAP driver would NOT recognize the monitor successfully (using the "Detect Monitor" option failed, importing the Windows INF file failed as well, although I suspect that is b/c SNAP only supports Win95 versions of monitor INF files). When I querried up the DDC/EDID info the SNAP utility came back with "...invalid EDID record..." error message, which I believe is very similar to what I had experienced way back when with my original 245T display that just died.

So...long story short...LOL...if there is a way to force the SNAP driver to 1920x1200 resolution regardless of what capability the monitor reports or SNAP driver is able to establish I'd love to give this a shot.

Thanks again!

1326
Hi Everyone,

Well, my trusty Samsung 245T 24" monitor (1920x1200) finally gave up the ghost...literally nothing happens upon power-up, not even the "blue glow" of ON/OFF button. Per the Service Manual I have that implies either an internally blown fuse or as per the suggestions provided by previous post responses (I had an issue with my LCD coming out of DPMS save, screen was showing flickering for a few minutes each time) it may have been showing some issues with capacitors.

Anyways...as much as I'd love to keep it, the US and Canadian locations are having some pretty crazy Holiday sales still and I might as well take advantage of it.

So...I understand that with SNAP drivers I can define various resolution modes, but that is still driven by the EDID monitor information being correctly recognized by the driver and thus telling it what the screen capability it. Assuming that all that works correctly, what is the highest screen resolution you have been able to use?

My video card is an old ATI X850 XT PE, info as reported by SNAP drivers is:
=== START ===
Graphics device configuration:
  Manufacturer......... ATI
  Chipset.............. Radeon X850 Series
  Bus Type............. PCI Express
  Memory............... 262144 KB
  DAC.................. ATI Internal 24 bit DAC
  Clock................ ATI Internal Clock
  Memory Clock......... 400 MHz
  Default Memory Clock. 400 MHz
  Maximum Memory Clock. 400 MHz
  Driver Revision...... 3.2, Build 29
  Driver Build......... Sep 25 2006
  Certified Version.... 1.60
  Certified Date....... Sep 25 2006
=== END ===

As best as I can tell the single-link DVI connector can display a maximum resolution of 1920×1200, while the dual-link’s maximum for that same screen is 2560×1600.

My ATI X850 User Guide indicates I have a DVI-I connector, which means I'm maxed out at 1920x1200...so I'm curious if anyone else has done better with different hardware?

1327
Applications / Re: AVxCAT 1.4 alpha
« on: December 30, 2015, 04:31:27 pm »
Hi Remy,

Wow...great news...thank you so much for continuing the work on this.

I was never able to overcome the "system freeze" with the latest previous version so I'm happy to give this a try.

-Dariusz

1328
Hardware / Anyone successfully using Brother HL-5470dw?
« on: December 04, 2015, 05:17:04 am »
I've got my good 'ol trusty Brother HL-1650 (with NIC card, so really the same config as HL-1670) Postscript printer here, working very well with my OS/2 setup. Both the standard IBM as well as Alex's PSPRINT drivers support all the feature. However...the printer is aged and while I love it, the reality is that it's starting to show it's age.

With some of the sales around these past couple of weeks I spied the HL-5470dw unit...as the Brother (http://www.brother-usa.com/Printer/ModelDetail/1/HL5470DW/Overview) product page shows this is basically a modern day (updated) version of the HL-1670...still a Postscript printer, duplexed, fast not to mention it support Wi-Fi and the various types of Cloud/Google/Air printing (great for kids to run stuff off of their tablets).

So here is the big question: has anyone tried this unit in OS/2?

1329
Hardware / Re: How to turn OFF monitor DPMS ???
« on: September 13, 2015, 06:55:55 pm »
Hi Ivan,

So I was correct at the beginning  ;)

Indeed  sir  ;D ...the problem was in figuring out this was not an EXE that was started up, rather it was a module install into the WPS.

The fact that when it starts up again you get the blinking does point to a capacitor problem.  If you want to do it yourself PM me and I will e-mail you the service manual - we have repaired a few of these in the past although we get our capacitors from RS.

I will take you up on that offer...if I had any local electronics supply stores I would gladly take the capacitors out and just go shopping for the matching replacements, not sure if RS (I assume RadioShack will carry this, their stuff is bare-bones around here really)...but I suppose this will actually translate to some on-line shopping...

1330
Hardware / Re: How to turn OFF monitor DPMS ???
« on: September 13, 2015, 04:57:44 pm »
FOUND IT!!!

OK, at a loss of where to go next I figured I'd do a brute force search through the registry...so off I went looking for DPMS in hopes that if I am in fact running something else or have done an install of a module to handle this, the developer may have used the "dpms" term....and indeed....I hit the proverbial GOLD VEIN here...

So...I have an app called "Doodle's Screen Saver v1.8" installed (http://dssaver.netlabs.org), this shows up as SSaver entry. Indeed, this executes a DPMS sleep command and of all places you can find it in the Desktop=>Properties=>ScreenSaver tab as it replaces the standard "Lockup" functionality.

For now, I have turned off DPMS, waiting to see the results...and looking at Paul's capacitor fix suggestion in the meantime.

Thanks again everyone...I will update the post once I confirm this was in fact the setting.

1331
Hardware / Re: How to turn OFF monitor DPMS ???
« on: September 13, 2015, 03:26:00 pm »
Thanks for all the responses.

Yeah, I used to use BlankIt a while back...but no longer do as something else replaced it...LOL...meaning I probably got the DPMS function working somehow...LOL...

The 2nd page of Screen properties has DPMS disabled. I actualy did a command line check against the SNAP logs in case the 2nd display head settings was somehow messing around with this. I do not actualy have a 2nd LCD attached at the moment, but tried it a while back and since my video card supports it SNAP always reports back on the 2 heads anyways.

Here is what I find in the log:

=== START ===

Global options for all devices:
  Force VBE Fallback ...... Off
  Force VGA Fallback ...... Off
  Allow non-certified ..... On
  Disable write combining . Off
  Use BIOS for LCD panel... Auto
  Shared AGP memory size... 4096 KB
  Use system memory driver. Off
  Disable DDC detection.... Off
  Virtual Display.......... Off
....
Graphics device configuration:
  Manufacturer......... ATI
  Chipset.............. Radeon X850 Series
  Bus Type............. PCI Express
  Memory............... 262144 KB
  DAC.................. ATI Internal 24 bit DAC
  Clock................ ATI Internal Clock
  Memory Clock......... 400 MHz
  Default Memory Clock. 400 MHz
  Maximum Memory Clock. 400 MHz
  Driver Revision...... 3.2, Build 29
  Driver Build......... Sep 25 2006
  Certified Version.... 1.60
  Certified Date....... Sep 25 2006

Graphics device options:
  Invert .................. Off
  Rotation ................ Off
  Flipped ................. Off
  Prefer 16 bit per pixel.. On
  Prefer 32 bit per pixel.. On
  PCI bus mastering........ On
  Hardware acceleration.... Full
...
Configuration for head 0:

Monitor configuration:
  Manufacturer... Samsung
  Model.......... SyncMaster
  Max Resolution. 1920x1440
  Max HScan...... 81 KHz
  Max VScan...... 75 Hz
  Features....... Wide

LCD panel detected:
  Width:  1920
  Height: 1200
...
Configuration for head 1:

Monitor configuration:
  Manufacturer... Samsung
  Model.......... SyncMaster
  Max Resolution. 1920x1440
  Max HScan...... 81 KHz
  Max VScan...... 75 Hz
  Features....... Wide

=== END ===

Previously the "configuration for head x:" would actually show DPMS as well.

You know, at some point in time I could have sworn that XWorkplace somehow introduced a "screen saver" option somewhere...for some reason I keep on thinking there even was an option to control when the sleep would start up, so along the lines of what Win platform does...man, maybe I'm just confusing stuff...LOL...

BIOS...well, I looked through all the options...ACPI is the only active option I have...if I disable that then there is no boot, which makes sense.

Paul,
Thanks...I'm going to research the capacitor replacement further...it might be the only option...although just yesterday I stopped at the local BestBuy (electronics chain) and found a Samsung 4K LCD on sale, as in down to $425 from $595...resolution of 3840 x 2160, can you imagine that baby??? LOL It actually reminded me of an old 1920x1200 x4 (4 panel) configurations one could find back in the early days of "big" LCD panels.

1332
Hardware / How to turn OFF monitor DPMS ???
« on: September 12, 2015, 11:59:47 pm »
Samsung 245T LCD panel here..ATI X850 XTPE card, SNAP Build 505.

My monitor has been acting up lately coming out of sleep mode...basicaly the screen flashes rapidly several times, sort of a very quick ON/OFF type of a thing...monitor is somewhat old, so I'm thinking probably getting to it's EOL. Still...having said that, it works great once powered up...so I though I'd just bite the bullet and shut OFF the DPMS function so that it does not go into sleep mode.

And here lies the problem...DPMS is shut OFF in the Screen object...SNAP LOG confirms DPSM is OFF, yet the monitor keeps on going into sleep mode. I even remmed out the APM.ADD driver, but that did not help.

Unfortunatley I do not have a way to disable DPMS on the LCD itself, nor could I find this in the service menu either...so I have to find a way from within the OS/2 box.

For the life of me, and maybe I just forgot how to do this, I can not figure out how to shut this off on my W4.52 CP2 machine. So what am I missing here?

Thanks!

1333
Article Discussions / Re: Choice of update channel for eCS / OS2
« on: August 02, 2015, 03:33:04 pm »
Sorry, I'm tired of this meaningless debate.

You are right...this debate is meaningless, too bad, because all along I thought the subject of this thread was : "Choice of update channel for eCS / OS2", yet there you were once again preverbially stuck on RPM/YUM, while I tried to illustrate with numerous examples while RPM/YUM as an update channel may not be the best approach for everyone.

I'm not going to argue with every single statement (you've just gone crazy at some places), which you really wrote a lot (honestly I even didn't read your post thoroughly).

Sometimes it does take a little elbow grease to get to the bottom of a root cause and that statement above is sufficient for me to understand while you clearly miss the big picture.

I'm out of discussing RPM/YUM as an udpate channel with you, it is pointless, you are certainly right on that.


1334
Article Discussions / Re: Choice of update channel for eCS / OS2
« on: August 02, 2015, 05:29:40 am »
Dariusz, I have failed to grasp the central point of your post, but here follows some of the misconceptions in it.

...OK, here it is: given the age of OS/2 and for how long there has NOT been a real enterprise type update system available (think Fixpaks, etc) there are far too many combinations of working systems, or perhaps 99.9% working systems to expect that a single RPM/YUM based deployment methodolgy is going to work. Since I readily acknowledge and accept the small OS/2 development team limitations I am perfect happy and willing to unpack the recommended RPM archives since I am currently in the non-RPM/YUM camp...and you would do us all a favour by NOT pretending like RPM/YUM is the only NORMAL/ACCEPTABLE way to go about installing applications.

If you do not wish to help with these issues, do NOT help...but please, do not belittle folks for apparently horrific system configurations they have...tell me, are you running a multi-core setup, did you try SMP before deploying ACPI.PSD solution, do you know how the SMP mode impacts memory utilization and can you tell me what is so horribly misconfigured on my machine that my 6-core box simply will not nicely boot up? Does it have anything to do with mulit-disk and a large HPFS386 cache configuration? Do you really think there is a RPM/YUM solution for that too???

My DLL tracker is sometimes useful, but a bad, dirty hack, not a silver bullet.

Quite frankly, your DLL tracker is a great tool...I only wish that it was more prominently "published" and/or showcased as part of releases like Firefox...because it has the potential to help that part of our community who needs it.

Dude, do you really even read the issue tickets?

Each and every day...I'm on the FF mailing list, so yeah, sometimes tens of emails a day, I read them all...because maybe one of them may have something to do with an issue I have seen, or perhaps I can help someone on there by providing positive feedback as I first attempt to understand their challenge.

Here is an example, why is JoopN having such a strange issue with downloads??? Maybe libc DLL problem...but it sure looks like he worked through that and yet the problem persists...what now??? Are you going to write that off as a RPM/YUM problem as well, regardless of what is the actual root cause???

What about the 100% CPU utilization symptom? I've seen that for quite some time now...happens regularly here when I do not run with SET NSPR_OS2_NO_HIRES_TIMER=1 option...there was a pretty extensive debug session once, I had logged a ticket on the 24.x release for this (as well as other issues)...is that a RPM/YUM issue too???

Here is a better one: take the official stdcpp6.dll RPM release file (libstdc++6-4.9.2.1-3.oc00.i386.rpm), the recently created moz_required_dlls_v1.03.zip has a different DLL in it altogether. Which one to use now?

libstdc++6-4.9.2.1-3.oc00.i386.rpm => 02/02/2015, 410187 bytes
moz_required_dlls_v1.03.zip => 01/02/2015 14:08, 388453 bytes

So...the point being again: be helpful and therefore productive in your help, merely saying that someone is incapable of configuring their system because they are seeing a problem/symptom you do not see on your machine is very much quite the opposite of helping!

1335
Article Discussions / Re: Choice of update channel for eCS / OS2
« on: August 02, 2015, 02:13:29 am »
...Otherwise I do not understand how spending dmik's time on solving problems of users which are caused only by their incapability to manage their system environment themselves and their blind refusal to use a tool that does just this for them....This causes pain to me. Every time I see somebody searching (in WGet distributions on Hobbes!..) a library or a dependency (I have even made this...), or somebody with a whole shitload of different versions of everything everywhere on their systems... it hurts. And then they post issues at GitHub.

Boris,
That is simply an incredible statement from someone who proclaims to want to advocate for the OS/2 platform and is interested in improving OUR lot.

Were you honestly "born to OS/2" yesterday? I'm serious...your opinion on the subject of managing DLLs seems to be not only incredibly naive but borderline derogatory. Do you honestly belive that we, the left-over OS/2 users are a bunch of amateur hacks and newbies? Please recognize that for anyone to be still a part of OS/2 community today means he/she has to be knowledgable enough about the system to be able to troubleshoot, setup, manage, maintain, upgrade their environments as needed, with very little, if any, external support. So whatever "problem" exists on anyone's machine probably has a lot to do with previous attempts to install new releases, as they become available, as many different DLLs float around, as there is no "silver bullet" to fix all these issues today, even though you apparently claim to have developed this "silver bullet" in the case of your DLL tracker.

So please, do not insult the likes of us who have been attempting to keep the OS/2 platform viable by suggesting we are our own problem due to "...their incapability to manage their system environment themselves and their blind refusal to use a tool that does just this for them....", dear sir, you could not be farther from the truth!!!

IF it bothers you that the end-users out there do NOT have the matching OS/2 configuration you do, and therefore it makes your volunteer effort to help that much more difficult, I suggest you question whether you are volunteering in the right community? Perhaps you are looking for something much easier? Where there is a lot more of black and white and a lot less gray.

Pages: 1 ... 87 88 [89] 90 91 ... 94