OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: OS4User on June 10, 2013, 08:37:23 pm

Title: OS/4 kernel and extended KEE
Post by: OS4User on June 10, 2013, 08:37:23 pm
Started from ver 4032 OS/4 kernel will load clock03b.sys instead of clock01.sys.

Clock03b uses Extended KEE, which includes KernSetIRQ and KernEOI (http://ru2.halfos.ru/core/docs/keeOS4.html)

Clock03b contains two drivers  CLOCK$ and TIMER0$ so timer0.sys  no more needed, it will not be loaded any way even if it will not be removed from config.sys

As you may guess Clock03b has  two _32_  bit only  interrupt service routines (for IRQ0 and IRQ8).

Clock03b  has many advantages comparative to pair clock01 + timer0  -  it is based on source code from clock01 by  Tsurgaev A.V. (Цургаев А.В.)

For those who is brave enough here is a link to download and test it. http://ru2.halfos.ru/core/downloads/kernel/os4/os2krnlSVN4032_unoff.zip
Title: Re: OS/4 kernel and extended KEE
Post by: OS4User on June 12, 2013, 12:14:30 am
A bug is fixed (freezing before switching to graphic mode)  http://ru2.halfos.ru/core/downloads/kernel/os4/os2krnlSVN4033_unoff.zip
Title: Re: OS/4 kernel and extended KEE
Post by: David McKenna on June 12, 2013, 01:30:00 pm
  I gave this (4033) a try and when booting I get this error: 'File not found or corrupted: acpi4.sys'. I don't have this file (eCS 2.1). It seemed to work well for about 5 minutes, but then my desktop froze and I had to hard reset. Is there anything in particular you want tested?
Title: Re: OS/4 kernel and extended KEE
Post by: OS4User on June 12, 2013, 02:22:04 pm
  I gave this (4033) a try and when booting I get this error: 'File not found or corrupted: acpi4.sys'. I don't have this file (eCS 2.1).

acpi4.sys  is optional  -  system just will not use it.

It seemed to work well for about 5 minutes, but then my desktop froze and I had to hard reset.

It would be great if you could show com port log, especially at the moment of such freeze.

Is there anything in particular you want tested?

Nothing special just stability and working in general.
Title: Re: OS/4 kernel and extended KEE
Post by: guzzi on June 13, 2013, 02:18:12 am
What is ACPI4.SYS?
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on June 13, 2013, 03:23:30 am
I gave 4033 a try on my Lenovo ThinkPad L530. When I select any option from OS2LDR, it starts, the screen goes black for about half a second, and the machine reboots.

Using showmem=1 causes it to show a bit of interesting data, but it goes black, and reboots, after pressing a key (even when I select to boot the normal kernel). No sign of a log file, and I don't have a com port to play with.

It is possible that I didn't set it up properly. The instructions are about as clear as mud.
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on June 13, 2013, 04:32:08 pm
This model has supplied with EFI BIOS and 1155 socket CPU?
Then this is the second side of famous 512Mb bug ;)

IBM OS2LDR does not see memory above this border - and this is bad :)

OS/4 loader can see it, but something wrong with memory tables or  BIOS or ACPI implementation on EFI... wrong in BIOS - the same bug exists on most of new chipsets... but I'm also saw messages about successful working of all 4Gb on EFI...

I'm think - OS/4 Team may trace kernel's execution on this place if they can get new PC with the same bug.

Just add MEMLIMIT=512 to OS2LDR.INI for now...
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on June 13, 2013, 05:55:41 pm
This model has supplied with EFI BIOS and 1155 socket CPU?
Then this is the second side of famous 512Mb bug ;)

It is EFI BIOS, I am not sure if it is 1155 socket CPU. Yes, it is the famous 512 MB bug.

IBM OS2LDR does not see memory above this border - and this is bad :)

Well, it is not real bad. eCS operates reasonably well in 512 MB.

OS/4 loader can see it, but something wrong with memory tables or  BIOS or ACPI implementation on EFI... wrong in BIOS - the same bug exists on most of new chipsets... but I'm also saw messages about successful working of all 4Gb on EFI...

I'm think - OS/4 Team may trace kernel's execution on this place if they can get new PC with the same bug.

Just add MEMLIMIT=512 to OS2LDR.INI for now...

From what I have found out, there is a 4KB memory hole, for some unknown reason, at the 512 MB location. The rest of the memory holes seem to be above the 3 GB mark.

Adding memlimit=512 to OS2LDR.INI changes nothing. I will try some other things, when I find the time (which may not be soon).
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on June 13, 2013, 07:03:30 pm
Just as a quick test, to be sure that I have it installed properly, I put this on my Lenovo ThinkPad T510. It seems to work fine, so I am now confident that I have installed it properly on the L530.
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on June 13, 2013, 07:31:26 pm
Adding memlimit=512 to OS2LDR.INI changes nothing. I will try some other things, when I find the time (which may not be soon).
This is actually strange, 512mb memory limit always helps.
May be 511 or 510? I'm don't know how it calculates - with or without 1st mb.
Title: Re: OS/4 kernel and extended KEE
Post by: OS4User on June 13, 2013, 11:38:25 pm
What is ACPI4.SYS?

It will be an acpi driver for os/4 kernel. Current kernel is trying to load it, but in case it is missing nothing fatal happens.
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on June 14, 2013, 12:04:18 am
Adding memlimit=512 to OS2LDR.INI changes nothing. I will try some other things, when I find the time (which may not be soon).
This is actually strange, 512mb memory limit always helps.
May be 511 or 510? I'm don't know how it calculates - with or without 1st mb.

I tried 500 too. Still the same problem.
Title: Re: OS/4 kernel and extended KEE
Post by: David McKenna on June 15, 2013, 12:13:23 am
  Since I last posted I have been using the OS4 kernel (retail) with no trouble. Maybe the freeze I got then was from something else (Flash??). I did have a POPUPLOG from DMISL.EXE which is something I've never had before...

  I have one question: Is os2krnl.ini necessary? I ask because I don't see anything in ___hlp$ that would make me think I need to add anything to os2krnl.ini, but maybe I don't understand the instructions....
Title: Re: OS/4 kernel and extended KEE
Post by: OS4User on June 18, 2013, 11:24:47 pm
  Since I last posted I have been using the OS4 kernel (retail) with no trouble. Maybe the freeze I got then was from something else (Flash??). I did have a POPUPLOG from DMISL.EXE which is something I've never had before...

would be interesting to see

  I have one question: Is os2krnl.ini necessary? I ask because I don't see anything in ___hlp$ that would make me think I need to add anything to os2krnl.ini, but maybe I don't understand the instructions....

OS/4 kernel with switched ON preload option will load all files which will be necessary on stage 1 of boot process into a kind of memory disk and then the hard drive will not be touched until the stage 2.

For this purpose kernel  builds a list of such files. This list includes  all BASEDEVs + PSD from config.sys,   BASEDEVs which loads without config.sys,  SNOOPERS from snoop.lst  and files mentioned in os4krnl.ini

Actually os4krnl.ini serves for a user to enable him to add files which are needed to be preloaded and about which the kernel didn't guess.

If during boot kernel will try to load some file which was not preloaded - user will receive a message something like  "Please add driver.sys to os4kernel.ini".

In majority of cases os4krnl.ini will be absent or empty. I personally can't imagine a situation when something has to be added there, but who knows.




Title: Re: OS/4 kernel and extended KEE
Post by: David McKenna on June 19, 2013, 04:51:47 pm
 Here's the POPUPLOG... always exactly the same, and I never get this with the eCS 2.1 kernel:

06-19-2013  10:34:26  SYS3175  PID 0021  TID 0002  Slot 0030
C:\OS2\DMISL.EXE
c0000005
00018b1a
P1=00000001  P2=0000001e  P3=XXXXXXXX  P4=XXXXXXXX 
EAX=00000000  EBX=17b20000  ECX=17b20000  EDX=00000000
ESI=17b20000  EDI=00000000 
DS=0053  DSACC=d0f3  DSLIM=5fffffff 
ES=0053  ESACC=d0f3  ESLIM=5fffffff 
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:00018b1a  CSACC=d0df  CSLIM=5fffffff
SS:ESP=0053:000d3e4c  SSACC=d0f3  SSLIM=5fffffff
EBP=000d3ef8  FLG=00010246

DMISL.EXE 0001:00008b1a

  I don't know what I do to cause it... I don't intentionally run DMISL and the POPUPLOG just appears every once in awhile.

  Thanks for the explanation of os2krnl.ini. I was not using preload=1 so that is why I didn't see any 'Please add..' messages. When I use preload=1, then I see a couple of 'Please add...' messages, mostly *.sym files which the retail kernel won't use anyway. Also, my boot drive is an SSD drive, which boots very fast with or without preload=1 (Intel CPU too).
Title: Re: OS/4 kernel and extended KEE
Post by: David McKenna on June 19, 2013, 05:32:18 pm
 I think I determined the origin of the POPUPLOG from DMISL...

 If I delete a FOLDER object from the workplace shell, it goes into the trashcan (I use Kai Sommerfeld's TrashCan 2.7.1). When I empty the trashcan (right click, choose 'Empty'), the POPUPLOG is created and trash is emptied. This is 100% repeatable when using the OS4 kernel (and never happens with the OS/2 kernel). If I then delete another folder object, then empty the trashcan no popuplog is created, but the trashcan doesn't empty and eventually (1 - 2 minutes) the WPS hangs. This may be what caused my original hang. Deleting files works fine, it is only folders that cause this.

 Another example: if I delete multiple folders, then empty the trashcan, the POPUPLOG is created, one folder is erased, but the others remain in the trashcan and eventually the WPS hangs.
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on December 31, 2013, 08:13:43 am
I gave 4033 a try on my Lenovo ThinkPad L530. When I select any option from OS2LDR, it starts, the screen goes black for about half a second, and the machine reboots.
Spent some time to find the source of this reboot on EFI PC, when all memory is visible....
And think, I found the issue - at least on available B75 motherboard 3.5Gb is visible and everything is ok - but only with QSINIT loader (http://212.12.30.18/other/QS_LDR.ZIP).

IBM code for PC memory init is ugly not only in OS2LDR, but in kernel too ;)

Second note: some kind of New Year gift available in fresh QSINIT builds - PAE ram disk :)
ADD driver, which subst all memory above 4Gb limit as another one HDD ;)

But, a bad news too... QSINIT is incompatible with later ACPIs. I tried to contact with David, but without answer... So OR ACPI + SMP OR full 3.5 Gb + RAM disk now... :(

And all of this - does not require OS/4 kernel ;) QSINIT can load any kernel, including Warp 3.
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on December 31, 2013, 10:41:56 pm
Quote
And think, I found the issue - at least on available B75 motherboard 3.5Gb is visible and everything is ok - but only with QSINIT loader.

Well, it also works on my Lenovo ThinkPad L530. This is only an initial test, but I do have almost 3 GB of memory available, out 4 GB total (I think it is running into a bunch of memory holes at about 3 GB). MUCH better than 512 meg.  :)

I did have to REM the ACPI stuff, or it just hangs at boot time. OS2APIC.PSD initializes both processors, but power control is pretty important on a laptop. The question now is, whether it is your work that needs to be fixed, or if it is ACPI that needs to be fixed. Possibly a combination.

I also need to try the RAMDISK, but not right now. If it works, I may have to buy more memory.   :D

Well done, and THANKS!   :D :D :D :D
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 01, 2014, 08:42:47 am
WOW! You do good work. The RAMDISK works perfectly, and gives me a 500 MB (or so) RAMDISK to work with, using memory that would otherwise be useless. It gets formatted as FAT, which is not ideal (JFS would be better), but it certainly shows that it can be done.

If my math works, that still leaves about 500 MB of memory unaccounted for, but this is certainly better than what I had before. I don't see much point in trying to put the swap file on the RAMDISK. I have never seen the swap file used, since I had 2 GB of physical memory. I need to do more testing, but the TEMP directory seems to work okay with it.

The main problem is that SysView does nothing. Even Alt-F3 is ignored. I need to Ctrl-Alt-Del to get out of it. That means that I can't start the RAMDISK automatically.
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on January 01, 2014, 12:05:50 pm
It gets formatted as FAT, which is not ideal (JFS would be better), but it certainly shows that it can be done.
JFS too large for common memory size ;) HPFS may be, but it requires HPFS format implementation in QSINIT - a bit complex task ;)

Quote
The main problem is that SysView does nothing. Even Alt-F3 is ignored. I need to Ctrl-Alt-Del to get out of it. That means that I can't start the RAMDISK automatically.
This app written on Turbo Vision, common keys = F10 - menu, Alt-X - exit  (help is incomplete ;))
Or keyboard not working at all? This can be too, EFI BIOS - is a full crate of bugs ;) It can send slightly wrong keyboard codes, for example...

The question now is, whether it is your work that needs to be fixed, or if it is ACPI that needs to be fixed. Possibly a combination.
Problem can be fixed only with David's help ...  He patch something or read from hardcoded offset in IBM`s OS2LDR... And when OS2LDR is not IBM's - it goes crazy...
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 01, 2014, 06:17:23 pm
Quote
JFS too large for common memory size ;) HPFS may be, but it requires HPFS format implementation in QSINIT - a bit complex task ;)

It is probably not that complex. Perhaps Jan van Wijk (of DFSEE fame), could suggest something, but there is no rush to get it done. Personally, I have quit using HPFS, and use JFS instead. The main problem with FAT is the (lack of) long name support, and FAT32 is very slow (although using memory as the media should speed it up).

I haven't tried it, but is it possible to format the drive?

Quote
Or keyboard not working at all?

The keyboard seems to be okay until I start SysView, then nothing works, except holding the power off button for more than 4 seconds. I am not sure if SysView gets completely initialized, or not. It looks okay. I need to try it on my Lenovo ThinkPad T510, which has slightly older hardware, and no UEFI.

Quote
Problem can be fixed only with David's help

I expect that David is still working to get eCS 2.2 beta III out the door (or he is taking a few days to regain a bit of sanity). I have always found that he is willing to work with others, but he does have priorities, and like the rest of us, only 24 hours in a day.   :(
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 01, 2014, 08:18:02 pm
Quote
Quote

    Or keyboard not working at all?

The keyboard seems to be okay until I start SysView, then nothing works, except holding the power off button for more than 4 seconds. I am not sure if SysView gets completely initialized, or not. It looks okay.

Interesting. After doing a cold start, I am not able to use the Function keys at the shell command line. However, I am now able to use F10 in SysView, and then it seems to work as expected, until I try to close it. Then, it is hung again, although F10 gets me back to the menu, where I can tell it to close, and it hangs again.

Quote
I haven't tried it, but is it possible to format the drive?

Answering myself... Yes you can format it (JFS), but then the drive is not usable.

Anyway, I can now boot eCS 2.2 beta II, on my Lenovo ThinkPad L530, and use about 3 GB of memory in the normal way, and I can use another 501 MB, of otherwise useless memory, as a RAMDISK. How well that works, remains to be seen, but I have seen no problems, yet.

It seems that there are a few details to work out, but it is a very impressive first release, and it seems to solve a very bad problem for OS/2.

Thanks again...
Title: Re: OS/4 kernel and extended KEE
Post by: Dave Yeo on January 01, 2014, 08:51:44 pm
It gets formatted as FAT, which is not ideal (JFS would be better), but it certainly shows that it can be done.
JFS too large for common memory size ;) HPFS may be, but it requires HPFS format implementation in QSINIT - a bit complex task ;)

What about using the ramfs filesystem, probably with modifications? The file system works for many uses and it is considered public domain.
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 01, 2014, 11:04:25 pm
Quote
What about using the ramfs filesystem, probably with modifications? The file system works for many uses and it is considered public domain.

RAMFS would probably work, but I don't think it could be used with the swap file. That is mostly academic anyway, since there would, presumably, be about 3 GB of real memory, which pretty well negates the need for a swap file.

Quote
I need to try it on my Lenovo ThinkPad T510, which has slightly older hardware, and no UEFI.

Well, it is not as important on the T510, because it can use about 3 GB of memory (4 GB total) anyway, but adding the RAMDISK works great, and it uses close to 1GB, of otherwise unusable memory.

The main problem, on both laptops, is that they run hot, without ACPI to keep them throttled back, and I am sure that battery life will be shorter. Hopefully, that problem can be resolved.

Some basic testing of the RamDisk shows that the performance is quite good. Both systems are using the FAT file system for the RamDisk.
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on January 02, 2014, 08:38:01 am
RAMFS would probably work, but I don't think it could be used with the swap file.
RAMFS uses kernel memory manager to get/release memory, but this is impossible for memory above 4Gb.
And another reason - i'm planning to add boot from this disk - like Veit's memdisk do.

Quote
Some basic testing of the RamDisk shows that the performance is quite good. Both systems are using the FAT file system for the RamDisk.
About sysview & keyboard... It is a great chance of EFI BIOS guilt ;) On my EFI motherboard at one of 3-5 warm reboots, text mode becomes monochrome! ;) Space key was not functional in eCS start screen - until BIOS update - and so on ;) Will try to change Turbo Vision to be more "friendly" to wrong key codes.

Answering myself... Yes you can format it (JFS), but then the drive is not usable.
Yes, JFS uses STRAT2 commands, but I did not realize it. ADD driver is simple (memdisk was used as reference). May be I'll fix it.

But found more funny thing yesterday. FAT32 trap D, so disable FAT32 formatting of ram disk temporary, until investigate....
This is not disk format (I've used FAT32 partitions, formatted in QSINIT with the FAT32.IFS).
I.e. large ram disk now will be unformatted, but this can be avoided by limiting disk size to 2Gb (to makes it FAT).
Title: Re: OS/4 kernel and extended KEE
Post by: RBRi on January 02, 2014, 10:40:02 am
Sounds great, and if you get it working with the latest ACPI driver form David i will give it a try.

BTW: Maybe FullFat can be used as basis (http://code.google.com/p/fullfat/) for the fat file system impl.

  RBRi
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 02, 2014, 06:59:55 pm
Quote
RAMFS uses kernel memory manager to get/release memory, but this is impossible for memory above 4Gb.
And another reason - i'm planning to add boot from this disk - like Veit's memdisk do.

Having worked with this a bit more, I think that FAT will do the job. I am not so sure that FAT32 has any advantage, other than being able to use more than 2 GB of memory. Since the disk is only temporary, one would not want to be storing modifiable data files, that need to be saved permanently, on it anyway, although there may be reasons to load it up at boot time, with often used programs, or static data. FAT32 also has the problem of being slow, although with memory as the media, it should be okay. I am pretty sure that OS/2 could not boot from FAT32, because the driver is not loaded in time.

Quote
About sysview & keyboard

It does appear that UEFI does something bad. SysView is much more consistent on the T510 (no UEFI), while it works sometimes on the L530. It would be good to add "help text", at the bottom of the screen, suggesting that F10 will enable the menu. The "Alt-X" text is grayed out, and doesn't seem to work when the program initially starts.

Quote
But found more funny thing yesterday. FAT32 trap D, so disable FAT32 formatting of ram disk temporary, until investigate....

That is likely to be a flaw in the FAT32 IFS, or more likely in the FAT32 cache. I find that FAT32 is much more reliable, and faster, when I REM the CACHEF32.EXE line in CONFIG.SYS. Using it with a memory disk, and cache, doesn't make a lot of sense anyway. That could also be true for FAT.

Quote
And another reason - i'm planning to add boot from this disk - like Veit's memdisk do.

Interesting thought. Of course, it would need to be in FAT format.

Quote
RAMFS uses kernel memory manager to get/release memory, but this is impossible for memory above 4Gb.

Not "impossible", just difficult. You would need to implement a new memory manager to mange memory above 4 GB, and make a new API, or expand on a current API, to access it. That memory would not be usable in the normal way, but it could be used by programs specifically written, or modified, to use it. You have the tools to access the memory, you just need a buffer in "real" memory to allow normal program access to the data, and a way to track the memory allocation. Basically, it would be a new memory pool, for private data, outside of the normal 512 meg that is available. That would be a partial cure for the "shared memory" problem.

Quote
Sounds great, and if you get it working with the latest ACPI driver form David i will give it a try.

It may be worth your time to try it anyway. It is not difficult to switch back to normal operation. Just set it up with the new OS2LDR, REM the ACPI stuff (add OS2APIC.PSD, for SMP support), and try it. To go back, put the original OS2LDR back, and enable ACPI (disable OS2APIC, if used). Leaving the new support in the root of the drive, is a little messy, but not harmful. Be sure to have an alternate boot system, so you can put it back to normal, if it won't boot.
Title: Re: OS/4 kernel and extended KEE
Post by: Andy Willis on January 02, 2014, 10:53:36 pm
I'll have to look at giving this a shot... I had suggested somewhere to use the memory above 4G as a RAM disk so I like the idea :)
Those trying this and having heat/battery concerns, you might try the hlt driver:
ftp://ftp.netlabs.org/incoming/hltdriver.zip
It does not require acpi to run... it will make the cpu monitor show 100% CPU usage (at least the single thread version... the others have hung systems with more than 2 CPUs) but the CPU "usage" is akin to the System Idle of the Windows task manager but unlike in windows where the System Idle is not factored into the CPU usage it is with our CPU monitors as there was no reason to remove it when they were created. 
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on January 03, 2014, 01:45:58 pm
BTW: Maybe FullFat can be used as basis (http://code.google.com/p/fullfat/) for the fat file system impl.
I've used FatFS (http://elm-chan.org/fsw/ff/00index_e.html) - with the same features, but BSD type license ;)

It does appear that UEFI does something bad.
Sometimes such problems solved in BIOS updates. I saw at least 2 motherboards (asus & intel) - with keyboard handler bugs and both have a fix.

Quote
That is likely to be a flaw in the FAT32 IFS, or more likely in the FAT32 cache.
Fixed :) As minor effect - JFS now works too ;)
At least one problem still exists - FAT32.IFS do not allow to format own partitions, but this is the one of its "common features" ;) By the way, one of keys in ram disk creation command allows to skip FAT32 format.

Quote
Not "impossible", just difficult. You would need to implement a new memory manager to mange memory above 4 GB, and make a new API, or expand on a current API, to access it.
Yes, difficult :) And such feature still be "bound" to loader (because it makes PC memory list with BIOS help).
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 03, 2014, 07:09:59 pm
Quote
Sometimes such problems solved in BIOS updates. I saw at least 2 motherboards (asus & intel) - with keyboard handler bugs and both have a fix.

Both of my laptops are at the latest BIOS (unless there was something new, in the last week, or so). They are Intel boards, and processors. If I open SysView on the T510, I can use Alt-X to close it, immediately, and it always works. On the L530 (with UEFI), Alt-X does nothing, unless some other SysView window is open. Once it gets back to no open windows, Alt-X usually does nothing, but sometimes it does cause it to close. F10 doesn't always work either, but it does work, most of the time.

Quote
Fixed :) As minor effect - JFS now works too ;)

GREAT. More testing to do...    ;D

I found another "problem" on the L530. If I use "RAMDISK R:" (from the shell), I get a 501 MB disk created above the 4 GB mark. If I read the instructions properly, I should be able to do "RAMDISK /MIN=800 R:" and it should take some memory from below the 4 GB mark, and give me a total size of 800 MB. This works on the T510 (using MIN=1200), but on the L530, it tells me that there is no memory available (or something like that). Putting the command in QSSetup.CMD, and booting, results in no RAMDISK being created. (Probably another UEFI trick).

Now, if David A. can find a few minutes to help sort out the ACPI problem..........
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 04, 2014, 12:41:12 am
Quote
Fixed :) As minor effect - JFS now works too ;)

Yes, it does. However, it seems that FORMAT will not run until after boot is finished. That causes a problem, because I want to set the usual %TEMP% entries in CONFIG.SYS, to point to the RAMDISK. You need to set the %TEMP% stuff in CONFIG.SYS, so it is permanent, and you cannot set them if the disk does not exist (or is not formatted). The solution is to let QSINIT create the disk as FAT, or FAT32, and set the %TEMP% stuff to point to it, with a directory (R:\TEMP). The directory does not need to exist at this point. Then, add this to the beginning of STARTUP.CMD:
Code: [Select]
FORMAT.COM R: /FS:JFS /V:RAMDISK < RAMFMTRESP.TXT
MD R:\TEMP
<anything else>
(I am using R: for the drive address). RAMFMTRESP.TXT is a file that contains the required responses for the FORMAT command. It contains the letter "Y" in the first position of line 1, followed by a blank line.

After the disk is formatted (takes a fraction of a second), you can do what you want with it. In the above example, I simply create the TEMP directory. You could put whatever you want to start with (including the TEMP directory), in a ZIP file, and unzip it.
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 04, 2014, 07:40:11 pm
I also see that some changes have been made to SysView. It works as it should on the T510, and works, most of the time, on the L530. The changes to the bottom line also helps, as does alternate ways to do things (like close).

A good improvement.  Thanks...   :)
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on January 04, 2014, 09:47:23 pm
I should be able to do "RAMDISK /MIN=800 R:" and it should take some memory from below the 4 GB mark, and give me a total size of 800 MB. This works on the T510 (using MIN=1200), but on the L530, it tells me that there is no memory available (or something like that).
I added the LOG command, so you can send me log of this story ;)

Something like:
ramdisk r: min=800
ramdisk r:
log save c:\log.txt

c:\ is internal QSINIT's drive letter, FAT format mounts disk to it (first available),  so after "ramdisk r:" FAT formatted R: will be mounted to QSINIT C:

You can create temp in this way:
ramdisk r:
md c:\temp
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 04, 2014, 11:17:52 pm
Quote
I added the LOG command, so you can send me log of this story ;)

Okay. I created a log, using your suggested commands (I did RAMDISK DELETE first). I will email it to the address in the readme.

Quote
You can create temp in this way:
ramdisk r:
md c:\temp

Hmmm. Lots of new tricks to learn.  8)

It looks like a zipped file could be unzipped to it, before the system boots, if there is a way to feed it the zipped file.
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on January 05, 2014, 04:05:03 pm
Okay. I created a log, using your suggested commands (I did RAMDISK DELETE first). I will email it to the address in the readme.
I have not PCs with odd number of pages, so I'm missed this bug :)
Fixed now.
Title: Re: OS/4 kernel and extended KEE
Post by: Gabriele on January 05, 2014, 05:51:00 pm
Doug,

how did you enable OS2APIC? I added it as PSD=OS2APIC.PSD in config.sys, but boot hangs at CLOCK01.SYS, both with standard loader and QSINIT. Any parameter required?

Bye
Gabriele
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 05, 2014, 07:47:24 pm
Quote
I have not PCs with odd number of pages, so I'm missed this bug :)
Fixed now.

I will download, and test, shortly.

Doug,

how did you enable OS2APIC? I added it as PSD=OS2APIC.PSD in config.sys, but boot hangs at CLOCK01.SYS, both with standard loader and QSINIT. Any parameter required?

Bye
Gabriele

I have tried OS2APIC.PSD on every SMP machine that I have ever owned. It has always worked, with no parameters. I doubt if the loader would have anything to do with that. It is possible, that you need to have it in an appropriate place in your CONFIG.SYS, and you do need to REM all of the ACPI parts (2 or 3 lines).

I have always used it with eCS, if you have something else, there may be missing updates. You also need to have the full SMP support properly installed (that also works in a single processor machine).
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 05, 2014, 08:07:33 pm
Quote
I will download, and test, shortly.

YES! that works.

I still have a lot of testing to do, but that will have to wait for a while. It is about -25C (-15F), and I need to go outside to move some snow.  :o
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on January 06, 2014, 07:18:46 am
I still have a lot of testing to do, but that will have to wait for a while. It is about -25C (-15F), and I need to go outside to move some snow.  :o
And we have here +3°C (instead of -7..-12) and no snow. Winter is migrating to Canada, may be? ;)
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 06, 2014, 07:08:34 pm
Quote
Winter is migrating to Canada, may be? ;)

We always have winter, especially where I live. This year, it seems that the "polar vortex" has slipped further south than normal (at least that is what the weather people are saying), but that is affecting the eastern part of North America more than the west.

You can have it back, if you want it.   ;D

I have done a bit more testing. The RAMDISK performs well, and the memory, that was unusable before, is making itself useful too. SysView is definitely more usable, but still shows a couple of strange things on the L530 (with UEFI). Interestingly, the new boot manager (Air Boot) has a feature where it will power off the machine, by pressing DEL at the menu. That works on all of my systems, except the L530, where it does nothing. I expect that it is related to the oddities found in QSINIT.

I hope the ACPI problem can be resolved.
Title: Re: OS/4 kernel and extended KEE
Post by: Lars on January 06, 2014, 08:34:53 pm
Doug,

how did you enable OS2APIC? I added it as PSD=OS2APIC.PSD in config.sys, but boot hangs at CLOCK01.SYS, both with standard loader and QSINIT. Any parameter required?

Bye
Gabriele

Why would you want to use OS2APIC.PSD ?  If you use the OS/4 kernel you might as well use OS4APIC.PSD which is contained in the OS/4 zip file. Or is there any good reason not to do so ?

OS2APIC.PSD is rather limited in that it does not support IRQs > 15 which I believe is equivalent to the /PIC (or maybe /VW) mode of David's ACPI.PSD. Also OS2APIC.PSD has not worked on my system. My system seems to have broken MP tables. It only works properly in symmetric mode (using the IOAPIC instead of the old-fashioned PIC).
I believe the /APIC switch of OS2APIC.PSD was never completely implemented. It just does nothing on my system.

Lars
Title: Re: OS/4 kernel and extended KEE
Post by: OS4User on January 06, 2014, 08:45:31 pm

Why would you want to use OS2APIC.PSD ?  If you use the OS/4 kernel you might as well use OS4APIC.PSD which is contained in the OS/4 zip file. Or is there any good reason not to do so ?

OS2APIC.PSD is rather limited in that it does not support IRQs > 15 which I believe is equivalent to the /PIC (or maybe /VW) mode of David's ACPI.PSD. Also OS2APIC.PSD has not worked on my system. My system seems to have broken MP tables. It only works properly in symmetric mode (using the IOAPIC instead of the old-fashioned PIC).
I believe the /APIC switch of OS2APIC.PSD was never completely implemented. It just does nothing on my system.

Lars

os/4 kernel loads CLOCK03a.SYS instead of CLOCK01.SYS   so I suspect that os/2 kernel is in use.

and I agree with you   -  it is almost impossible to find a comp where os2apic.psd could work with IOAPIC (it would work if  IRQ <=15)

Title: Re: OS/4 kernel and extended KEE
Post by: Gabriele on January 06, 2014, 08:54:30 pm

Why would you want to use OS2APIC.PSD ?  If you use the OS/4 kernel you might as well use OS4APIC.PSD which is contained in the OS/4 zip file. Or is there any good reason not to do so ?

Hi Lars,

any time I tried OS/4 kernel on this laptop, it always hanged at boot, while QSINIT loader worked fine at the first shot. Anyway, it was just for test purpose: until a driver for the Intel Centrino Wireless-N 1000 appears, eCS here works better in Virtualbox.
Title: Re: OS/4 kernel and extended KEE
Post by: Gabriele on January 06, 2014, 11:08:14 pm
Following Doug's suggestion, I tried ACPI.PSD /VW instead of OS2APIC: now I have 3,5 Gb of RAM, 2 processors running and APM. A full boot to WPS takes less than 30 seconds... if just a wireless driver existed :-(
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 07, 2014, 12:08:18 am
Following Doug's suggestion, I tried ACPI.PSD /VW instead of OS2APIC: now I have 3,5 Gb of RAM, 2 processors running and APM. A full boot to WPS takes less than 30 seconds...

Actually, I think that /VW was Lars' suggestion, but it was a good suggestion. ACPI does seem to work okay, with the /VW parameter. That probably means that the problem has something to do with IRQs above 15, which is a very minor thing compared to power control.

Now, both of my laptops are running with full memory, a RAMDISK that is using memory that is otherwise useless, and I have power control.

Using IRQs above 15 is "kind of nice", but totally unnecessary in almost all cases. There is probably a very small performance hit, but nothing that a user would ever notice. Hopefully, walking_x can look at his code, and spot a problem, but I think that /VW does a few other things too. Just for the record, I was NOT trying to use /APIC with OS2APIC.PSD.

Quote
if just a wireless driver existed :-(

You said you have an Intel device. Apparently, Intel will be the first on the list when Multimac gets around to producing a WiFi driver. Meanwhile, there are a LOT of people waiting for that (including me).
Title: Re: OS/4 kernel and extended KEE
Post by: Lars on January 07, 2014, 08:26:00 am
I got the SVN revision 4160 (assuming it's the most available up to date). I started off with a system that had the 14.104a_SMP debug kernel running (and therefore the SMP version of DOSCALL1.DLL installed) and also ACPI.PSD installed:

1) I copied OS4LOGO, OS4KRNL, OS4KRNLR, OS4KRNL.SYM, OS4KRNL.INI, OS2LDR, OS2LDR.INI to root directory

2) I copied CLOCK03B.SY? to \OS2\BOOT

3) I copied OS4APIC.PSD and OS4APIC.SYM to \OS2\BOOT

4) initially I did not copy DOSCALL1.DLL to \OS2\DLL but I tried later

5) I modified OS2LDR.INI (only the changed parts):
;dbport=0x3f8
;ctrlc=1
;fullcable=1
preload = 1
[kernel]
os2krnl      =  OS/2 debug,ALTF2
os4krnl      =  OS/4 debug using config.os4,LOGSIZE=4096,PRELOAD,CFGEXT=OS4,ALTF2,CTRLC
os4krnlr     =  OS/4 retail using config.os4,LOGSIZE=4096,PRELOAD,CFGEXT=OS4,ALTF2

6) in root dir I created a CONFIG.OS4, I removed all of ACPI.PSD, added OS4APIC.PSD /APIC, removed TIMER01.SYS, added BASEDEV=CLOCK03B.SYS

The result was an IPE for os4krnl as well as os4krnlr and a hang for os2krnl. It was the very same after I also replaced DOSCALL1.DLL with the one from the OS4 zip file.

What am I doing wrong ? I took a dump when the IPE for the os4krnlr happened (I have TRAPDUMP=R0,X: set in config.sys or config.os4, however this did not work for the os4krnl) but PMDF will not even let me read the created dump. Looks like PMDF cannot find a proper kernel revision string in the dump, after looking into the dump I identified it to be 15.1_SMP.4160 but I am not sure about that either.
Not being able to read a dump file is a severe limitation for me, I use this system as a MUT for device driver debugging.
By the way, does the debug kernel (os4krnl) support:
1) the full KDB command set ?
2) also work with UDP instead of serial interface ?


Lars
Title: Re: OS/4 kernel and extended KEE
Post by: OS4User on January 07, 2014, 08:59:24 am

added BASEDEV=CLOCK03B.SYS


you should not add  and you may leave TIMER0 in your config.sys

but it is not a big problem  - you will just have a  warrning

TRAPDUMP

probably it is no more supported in os/4

By the way, does the debug kernel (os4krnl) support:
1) the full KDB command set ?
2) also work with UDP instead of serial interface ?

1) yes

2) I do not know if anybody test it.


It would be great if you can show comport log.
Title: Re: OS/4 kernel and extended KEE
Post by: Gabriele on January 07, 2014, 09:11:30 am
Following Doug's suggestion, I tried ACPI.PSD /VW instead of OS2APIC: now I have 3,5 Gb of RAM, 2 processors running and APM. A full boot to WPS takes less than 30 seconds...

Actually, I think that /VW was Lars' suggestion, but it was a good suggestion.

Thanks to Lars then! (I'm getting lost in these threads :-)  And of course a special thanks to walking_x: I'm really impressed by QSINIT!


Quote

Quote
if just a wireless driver existed :-(

You said you have an Intel device. Apparently, Intel will be the first on the list when Multimac gets around to producing a WiFi driver.

I know. Let's hope.
Title: Re: OS/4 kernel and extended KEE
Post by: Lars on January 07, 2014, 09:17:58 am

By the way, does the debug kernel (os4krnl) support:
1) the full KDB command set ?
2) also work with UDP instead of serial interface ?

1) yes

2) I do not know if anybody test it.


It would be great if you can show comport log.

I do have a com port on this machine, unfortunately I don't have a com port on any other of my machines available. Therefore I cannot create a log.
That's why I am using ICAT via UDP and not via serial interface ...
ICAT via UDP DOES have a window to capture all KDB output, unfortunately it is limited in the way that the system must be fully up and running (network driver loaded, netbind.exe loaded ...)

Lars
Title: Re: OS/4 kernel and extended KEE
Post by: OS4User on January 07, 2014, 09:26:01 am

I do have a com port on this machine, unfortunately I don't have a com port on any other of my machines available. Therefore I cannot create a log.
Lars

you may try to use USB->COM adapter  for machine  with terminal

comport log is essential for such cases
Title: Re: OS/4 kernel and extended KEE
Post by: Lars on January 07, 2014, 09:42:38 am
Forgot to say:
1) I have IBM bootmanager installed as I have 2 OS/2 installations on this machine: 1 for debugging, 1 for normal use, both of which use the SMP kernel (debug and retail respectively). I replaced OS2LDR on the debugging partition.

2) the debugging partition where I tried to run OS/4 kernel is formatted to HPFS
Title: Re: OS/4 kernel and extended KEE
Post by: OS4User on January 07, 2014, 09:58:21 am
Forgot to say:
1) I have IBM bootmanager installed as I have 2 OS/2 installations on this machine: 1 for debugging, 1 for normal use, both of which use the SMP kernel (debug and retail respectively). I replaced OS2LDR on the debugging partition.

2) the debugging partition where I tried to run OS/4 kernel is formatted to HPFS

nothing special   -  should work
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on January 07, 2014, 02:40:03 pm
Interestingly, the new boot manager (Air Boot) has a feature where it will power off the machine, by pressing DEL at the menu. That works on all of my systems, except the L530, where it does nothing. I expect that it is related to the oddities found in QSINIT.
Yes, I am using APM to turn off PC, but APM removed from EFI BIOSes (or most of them). Another method to turn off - ACPI, but I avoid of touching it now - to avoid new problems ;)

Quote
I hope the ACPI problem can be resolved.
I hope too :)

Quote
You can have it back, if you want it.   ;D
I think, it will return itself, after this vacation :)
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 07, 2014, 07:10:25 pm
Quote
Yes, I am using APM to turn off PC

QSINIT shell does power the machine off (using the command). It is Air-Boot that doesn't (perhaps it does sometimes). That seems to follow what I see in QSINIT, where things like Alt-X won't always work. I just wanted to point out that your software isn't the only one affected.

Is there something, in the shell, that will trace keyboard scan codes? That may be useful information.

ACPI  3.22.03 is working well with the /VW parameter.

I have a couple of older machines, where I can try QSINIT. It is impossible to use the RAMDISK (not enough memory), but the loader should work.

I did try the loader and the RAMDISK on my main machine (Asus M3A78-EM motherboard, with quad core AMD Phenom processor). It currently has 3 GB of memory, so all of the RAMDISK came from that. It works fine. I have another memory stick that will work in it, but I don't remember if there is another slot for it.

So much to do, and so little time.   :(
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on January 07, 2014, 07:25:34 pm
I'm afraid it is a garbage in char code for Alt-X keys....
For F1..F10 i can clear it, but Alt-X with non-zero char code is X key itself.
You can create menu with 2 kernels and press keys in it. In "kernel selection" menu key codes are printed to log.
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 07, 2014, 08:59:24 pm
Quote
QSINIT shell does power the machine off (using the command)

I take it back. That doesn't work on the L530 (UEFI), or the T510.

Quote
You can create menu with 2 kernels and press keys in it. In "kernel selection" menu key codes are printed to log.

I am not sure what you mean here, but it isn't important. You seem to understand what the problem is.

Now, more snow to move, and then more testing, but I am running out of things to test.   :)
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 07, 2014, 09:22:00 pm
Quote
Quote

    QSINIT shell does power the machine off (using the command)


I take it back. That doesn't work on the L530 (UEFI), or the T510.

Again, I take part of that back. It is the pwroff command that does not work on either system (where did I get that command from??? Now I don't see it in the help, but it still pops up a window). Power off (reply y) does power off the T510. The L530 states that there is no APM.
Title: Re: OS/4 kernel and extended KEE
Post by: Sigurd Fastenrath on January 07, 2014, 09:49:02 pm
It is so interesting to follow this thread!

Encouraged by the success of Doug I started to change my Warp 4/eCS 2.2beta2 clone and add QSINIT. I customized OS2LDR.INI so that I can choose between 3 different kernel

14.106SMP
14.104aSMP
OS/4

and with three different ways in addition for each: "normal boot"; "Boot with drivers listed ALTF2", "Boot to recovery console ALTF1"

-> so alltogether 9 entries in the boot menue.

In addition I have entries for the OS/4 Loader and the eCS Loader, that makes it up to 11 :-)

So I started to play around wich constellation may work.

Is there a way (other than via kernel options) to add different config.sys directly to the boot menue? I need different for i.e. 14106SMP with "Mensys" ACPI, OS/4 kernel with OS/4 ACPI

What I noticed in the short period I was albe to test today:

- when I choose a different loader i.e. OS4 Loader the red OS/4 in the left upper corner shows up, but the menue stays and says "I am waiting for choosing something, otherwise will boot the normal one" -> or is this the right way? Is the Loader then already loaded and do I have to choose the kernel then?

- when using OS/4 kernel and OS4APIC.PSD the system right at the beginning while booting states that the ACPI4.SYS is missing. Unfortunately the systems allways hangs with this constellation, right before FAT32 drivers are loaded. But if I REM the RUN and IFS for Fat32 it still hang....

Well - I have a lot to learn and a lot to test, but it is that impressive to see these Prebootmenues once F9 i pressed....

Well done!
Title: Re: OS/4 kernel and extended KEE
Post by: OS4User on January 07, 2014, 10:45:01 pm

- when using OS/4 kernel and OS4APIC.PSD the system right at the beginning while booting states that the ACPI4.SYS is missing. Unfortunately the systems allways hangs with this constellation, right before FAT32 drivers are loaded. But if I REM the RUN and IFS for Fat32 it still hang....


can you show comport log of it ?
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on January 08, 2014, 11:27:26 am
It is the pwroff command that does not work on either system (where did I get that command from??? Now I don't see it in the help, but it still pops up a window). Power off (reply y) does power off the T510. The L530 states that there is no APM.
Yes, no APM on EFI :(
But pwroff - is a batch file, it calls the same "power off /q" command - so this is strange.
May be need to add ACPI power off (when you pressing it - there is no requirements in ACPI until next power on ;) and  I can do anything with it).
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 08, 2014, 05:05:58 pm
Quote
But pwroff - is a batch file,

AH! that's where I found it.

Pretty complicated batch file.  :)

On the T510 (it apparently does have APM support), POWER OFF reply y, does power the machine off. PWROFF pops up the Yes No window, I reply Yes nothing happens. If I reply No it powers off.

It looks like I misinterpreted the selection, or the logic is wrong somehow. I would suggest that the least destructive option (NO, don't power off, in this case) should be the default. The button highlight is confusing too. I assumed that white would be the selection, while it appears that yellow is the selection. Perhaps, gray would be a better color for the unselected button.

I will try the L530 later, using reverse logic.   ;D

You should now realize, that I am getting bored trying to find faults. QSINIT works great.   :)
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 08, 2014, 05:55:25 pm
Quote
I will try the L530 later, using reverse logic.

That was the problem. The L530 responds to pwroff yes with a red window, indicating no APM installed (as expected).

Simply pressing the power button powers it off anyway, on both machines.
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on January 08, 2014, 06:31:28 pm
You should now realize, that I am getting bored trying to find faults. QSINIT works great.   :)
;) But I found the one - HPFS formatted ram disk return "general read error" from time to time....
It looks like FAT & JFS have no such problem.
Not so easy to fix, but will try.
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 08, 2014, 07:40:29 pm
Quote
;) But I found the one - HPFS formatted ram disk return "general read error" from time to time....
It looks like FAT & JFS have no such problem.
Not so easy to fix, but will try.

I haven't tried HPFS, because I no longer use it. However, it should work, because others still use HPFS. I will prepare one of my systems to use HPFS on the RAMDISK.

I have now installed another memory stick in my main machine (for 4 GB total), and I have installed QSINIT, including the RAMDISK (using JFS). So far (a few minutes), no problems.   :)
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 08, 2014, 11:01:53 pm
Quote
;) But I found the one - HPFS formatted ram disk return "general read error" from time to time....
It looks like FAT & JFS have no such problem.
Not so easy to fix, but will try.

Interesting. If I try copying a directory, with a long file name, to HPFS, using the WPS drives object, it is translating long file names to short (8.3) file names (use DIR at the command line to see it). JFS is doing the same, and FAT is expected to do that.

If I try to copy the directory to FAT16, it fails. The error message is that the path cannot be found. I expect that it is trying to copy a file to the long directory name, which has been shortened.

Okay. If I do the copy to HPFS, using the command line, I do get long file names, BUT, the WPS Drives object does not show the directories that have long file names.

When I look at the RAMDISK, with JFS on it, using DFSEE, it doesn't recognize what is on the RAMDISK. It says it is all freespace. With HPFS, and FAT16, DFSEE sees that it is HPFS or FAT16.

Okay, so I used DFSEE to remove the partition, and make a new one for HPFS. Then, I formatted it as HPFS. Now, DFSEE show the drive as all free space, but it still has the same problem (using 8.3 file names).

I have NO IDEA how any of that could happen, or what can be done about it. I think that JFS would have the same problem that you saw, under the right circumstances.

WOW! is the RAMDISK ever fast! When I copy a directory from hard disk to it, it takes about 10 seconds. When I copy that same directory from the RAMDISK to the RAMDISK, it takes about 1 second.
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on January 09, 2014, 09:20:49 pm
You can try it now, looks much better ;)
At least, without "general read error".
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 09, 2014, 11:34:18 pm
You can try it now, looks much better ;)
At least, without "general read error".
I never saw a read error. I did see "file, or directory, not found" errors.

I am still puzzled that the WPS and the command line, can't agree on whether the disk can handle long file names, or not. JFS seems to handle it okay, while HPFS does not. FAT, of course, does not handle long file names at the command line.
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 10, 2014, 06:00:05 am
Quote
I am still puzzled that the WPS and the command line, can't agree on whether the disk can handle long file names, or not. JFS seems to handle it okay, while HPFS does not. FAT, of course, does not handle long file names at the command line.

This seems to be a serious problem. JFS and HPFS cannot be used reliably, because real directory/file names don't match the expected long names, when the WPS is doing things with them. The really strange part is that the command line does use long names, but then the WPS cannot "see" them. Something is not being set properly, somewhere.

I also note that FAT only works with short file names (as expected, although the WPS sees long file names, because of the EA support), but that severely restricts what it can be used for. I haven't seen any problem using it for the %TEMP% directory, but that could be pure luck. I expect that most (if not all) temporary file names would be 8.3.

Another "problem". I decided to try making the disk with no format, or partition (RAMDISK R: NOPT NOFMT) The disk is not visible to OS/2, although DFSEE sees it as a Large Floppy Format (it is about 895 MB). I can use DFSEE to make a partition, and give it the drive letter, but then I would need to reboot to make it active.  :(  Using just NOFMT lets me format it as JFS, but it still has the file name problem.

I would note, that DFSEE aligned the partition completely different from what the RAMDISK default is. That might have something to do with it.
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on January 10, 2014, 07:38:02 am
I am still puzzled that the WPS and the command line, can't agree on whether the disk can handle long file names, or not. JFS seems to handle it okay, while HPFS does not. FAT, of course, does not handle long file names at the command line.
This is WPS-related problem only ;) It remembers "partition type" on first start and unfortunately - "unformatted" looks like FAT too ;)
I'm just insert FORMAT command into MPTSTART.CMD (config.sys calls it before PM) - and problem disappeared :) I.e. disk must be formatted to filesystem with long names before PMSHELL - to use WPS copy on it.

Quote
I haven't seen any problem using it for the %TEMP% directory, but that could be pure luck. I expect that most (if not all) temporary file names would be 8.3.
No, any software, except WPS - will create files normally.

Quote
Another "problem". I decided to try making the disk with no format, or partition (RAMDISK R: NOPT NOFMT) The disk is not visible to OS/2, although DFSEE sees it as a Large Floppy Format (it is about 895 MB). I can use DFSEE to make a partition, and give it the drive letter, but then I would need to reboot to make it active.  :(  Using just NOFMT lets me format it as JFS, but it still has the file name problem.
Yes, unformatted disk looks like FAT and WPS "remember" this. You can create it in eCS's  MiniLVM and format - no reboot required and WPS will be happy, because found this disk at first time with HPFS.

Quote
I would note, that DFSEE aligned the partition completely different from what the RAMDISK default is. That might have something to do with it.
Partition(s) is cylinder-aligned, so even old LVM.EXE likes ram disk format ;)
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 10, 2014, 07:48:03 pm
Quote
I'm just insert FORMAT command into MPTSTART.CMD (config.sys calls it before PM) - and problem disappeared

This is difficult to explain...

It didn't change anything, for me. I tried running the format 4 different ways (including in MPTSTART.CMD). All of them had it done before the WPS was started, and I saw no change in the way it is working. HPFS and JFS seem to work the same.

If I format as JFS, or HPFS, the drive icon appears normal, The Properties show it as JFS, or HPFS. When I use the WPS to copy a file, with a long file name, to the RAMDISK, the file name shows as the correct long file name, in the WPS. However, if I then go to the command line, and do a DIR on the drive, the file name has been shortened. I can then use the command line to copy that same file, and the long file name shows when I do a DIR, and the WPS shows the long file name.

The problem arises, when I use the WPS to copy a directory to the RAMDISK. The directory name gets shortened. That seems to be okay with JFS, because the WPS still sees it as the long file name. With HPFS, on the other hand, I still see the long file name with a DIR, BUT, the WPS doesn't see it at all.

Quote
You can create it in eCS's  MiniLVM and format - no reboot required and WPS will be happy, because found this disk at first time with HPFS.

Well, no you can't. MiniLVM indicates that the drive letter has changed to what I want, but the change is not recognized until I reboot. Of course, reboot destroys whatever was done. If I start with the drive letter already assigned, I can create a new partition, and format it (HPFS, or JFS), but nothing changes. the problem is still there.

Quote
Partition(s) is cylinder-aligned, so even old LVM.EXE likes ram disk format

Well, yes, it doesn't complain.

I think this might work better, if the drive was marked as a removable drive.
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on January 11, 2014, 07:47:50 am
I know the difference. I'm using File Commander for everything, but you using WPS.

So, after you created this partition (on empty ram disk, made with NOPT key) in MiniLVM - you format it in WPS! And WPS on first use of unformatted disk - remember its "FAT" state.

When I tried the same - I call format in File Commander's command line - and then use in WPS first time.

And - tried to format it from \MPTN\BIN\MPTSTART.CMD - both on Aurora and eCS 2.0 rc 6 - disk is ready before WPS - and long names works fine (in WPS copy).

The solution, may be, just implement HPFS format in QSINIT, but this is a long story ;)
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 11, 2014, 05:25:29 pm
Quote
So, after you created this partition (on empty ram disk, made with NOPT key) in MiniLVM - you format it in WPS! And WPS on first use of unformatted disk - remember its "FAT" state.

No, that doesn't work, at all. The disk is never visible to OS/2. I think that is because there is no partition, therefore no LVM information, therefore, no disk. If I create the partition with QSINIT, I can format it, but the problem persists.

Quote
And - tried to format it from \MPTN\BIN\MPTSTART.CMD - both on Aurora and eCS 2.0 rc 6 - disk is ready before WPS - and long names works fine (in WPS copy).

Long names do work fine, in WPS copy, but when you use the command line the long names have been changed to short names. That is expected, and seems to work okay, for most things, with FAT, but it does not work properly with HPFS, or JFS. In addition, if you use the command line to copy a long file name to the RAMDISK, using HPFS, the command line shows the file, but WPS never sees it. For some reason, JFS is able to handle that situation, and it can see the long file name, when copied by the command line.

I need to do more work with this. Something is missing, somewhere.

Is there a way to force QSINIT to create a FAT32 drive, when using only about 500 meg of memory?

Quote
I know the difference. I'm using File Commander for everything, but you using WPS.

I am not sure if FC uses the WPS, or the command line support (probably the command line). If you only use that, you will never see the problem, but the system will, and some things do not work properly because of it.
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on January 11, 2014, 07:35:51 pm
Long names do work fine, in WPS copy, but when you use the command line the long names have been changed to short names.
Just try it again ;)

If MPTSTART.CMD called from config.sys - it works.
Here one shot (http://212.12.30.18/other/aa2.jpg) with such HPFS disk: WPS, command line and FC windows.

Quote
Is there a way to force QSINIT to create a FAT32 drive, when using only about 500 meg of memory?
You can format it with small cluster size, for example:
    format c: /a:4096 /f:1 /q
just after ramdisk command.

But I'm not sure about FAT32.IFS - it can deny FAT32 partition formatting.
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 11, 2014, 08:27:58 pm
Okay, I found another problem with the RAMDISK. I decided to see if I could force it to use FAT32, so I did:
Code: [Select]
RAMDISK min=2200 R:While in the QSINIT shell, it said it did it. When I boot OS/2, it hesitates for a second, or so, and reboots.

Quote
I need to do more work with this. Something is missing, somewhere.

Yes. I was able to reproduce the problem using a real disk. It is not the WPS that is doing it wrong. The drive must be in the proper format when OS/2 is booted (probably when the IFS is loaded).

I formatted a real partition as FAT, and it failed to work properly (it was JFS previously). I got errors when trying to copy a file, with a LFN to it. I then rebooted, and it worked as expected. Okay, so I formatted it to JFS, and it did exactly what the RAMDISK does. Reboot, and now it works properly.

It seems that you will have to create the proper format in QSINIT, to make it work properly, or make the drive removable, so it can be remounted, after formatting (not too sure how that will work, since it cannot be physically removed).

Unfortunately, FAT format is restricted to using short file names, even if the WPS can use long file names. That makes it of very limited use, and it won't work properly for the %TEMP% directory, unless every program happens to use short file names for the temporary files (which is, apparently, not the case). HPFS has serious problems. JFS, on the other hand, seems to handle the situation, and it does work, for most things, but very odd errors will pop up every once in a while when the WPS stores files with short file names. Hmmm. I wonder if that has something to do with the larger cache that JFS has. If the file is still in the cache, it might be retrieved with the LFN, while the file system has put the file on disk with the short name. I hate to think what that might do.   :'(

You say that FAT can be used for the swap file. I don't doubt that, but a swap file is only used with small memory configurations, which would rarely be the case when using QSINIT. There are very few other things that a FAT RAMDISK might be good for.

I would note, that HPFS is probably required for those who do not have bootable JFS. I don't have the old IBM JFS any more, so I don't know what might happen with that. The new bootable JFS works best, but can have problems because the WPS will write short file names, when it shouldn't, and the underlying support doesn't know that it should have a long file name.

FAT32 might actually work better, because the IFS is loaded later, and it already has LFN support. I doubt if it could be used for the swap file, but it might be usable for %TEMP%. Since it already has LFN support, at boot time, changing the format might work better.

Quote
If MPTSTART.CMD called from config.sys - it works.
Here one shot with such HPFS disk: WPS, command line and FC windows.

It does NOT work. A reboot, with the proper disk format, is required for the IFS to recognize that it can use LFN for the file names (and directories). You may also be seeing the cache, not the hard disk.

Quote
You can format it with small cluster size, for example:
    format c: /a:4096 /f:1 /q
just after ramdisk command.

Hmmm. That lets it boot, but the disk does not finish formatting to JFS, and the system hangs. The disk is 895 meg, on the system where I am testing. I will try without the format to JFS step. Yes, that seems to work, the FAT32 drive appears to work properly. Now, to try a format to JFS. No, that doesn't work. It is probably some sort of restriction in the FAT32 driver. I will need to experiment with using FAT32 for the %TEMP% directory.

I will need to find more time later...
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on January 12, 2014, 10:31:02 am
Code: [Select]
RAMDISK min=2200 R:While in the QSINIT shell, it said it did it. When I boot OS/2, it hesitates for a second, or so, and reboots.
This is kernel bug, in memory init....
I cover it in some cases - i.e. when OS/4 loader reboots, QSINIT works...
But bug still there.

You can send me log in following way:
Code: [Select]
  ramdisk min=2200 r:
  bootos2 os2krnl test
  ramdisk delete
  ramdisk min=500 r:
  log save c:\log.txt

Quote
It does NOT work. A reboot, with the proper disk format, is required for the IFS to recognize that it can use LFN for the file names (and directories). You may also be seeing the cache, not the hard disk.
And how was made screenshot above? ;)

The .LONGNAME EA usage and such ugly name conversion - is WPS-related thing only. So, if you  format partition before WPS - it works normally with it - because it detects it as "long-name-file-system" at the own startup.

I.e. I made 1200mb fat, format it to HPFS in MPTSTART.CMD and then, in PM - made a copy of some files via WPS.
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 13, 2014, 01:57:26 am
Quote
And how was made screenshot above? ;)

The .LONGNAME EA usage and such ugly name conversion - is WPS-related thing only. So, if you  format partition before WPS - it works normally with it - because it detects it as "long-name-file-system" at the own startup.

I don't know why your screen shot looks okay.

Try this:
Format the RAMDISK as HPFS, using whatever method you think works.
Use the WPS to copy a file with a LFN to the disk.

Now, see if it did it right:
The WPS shows the LFN.
Drop to a command line, and do a DIR on the RAMDISK. The file is stored with a short file name.

That is NOT correct. The DIR should show the LFN, because HPFS can store the file with the proper LFN. Only FAT needs to be managed by the short file name /EA long name kludge.

In addition, copy the file back to a normal disk. WPS still shows the LFN because of the EA, but DIR shows that it is saved as the short file name.

Then, use the command line to copy the file from the RAMDISK, using the LFN. You get File not found, because the file system knows that it contains the long file name, so no translation, using the EA, is necessary.

HPFS, and JFS, are supposed to store files using the LFN, not a shortened version of the name.  Both of them do store the LFN, if you use the command line (and FC is probably using that interface, which may explain why it works). However, The WPS seems to think that it needs to do the same as it does with FAT, and that is NOT correct operation. This is obviously a bug in the WPS, or the file system, or both. As I said, I can duplicate the problem on a real disk, switching between FAT format and JFS format. The problem persists until a reboot, then it gets it right.

I suspect that simply unmounting, and mounting, the drive would also fix the problem. YES! that does fix it. I started miniLVM (RMB on the Drives object, and select Manage Volumes). Use that to set the drive letter to <none>. Close miniLVM, saving the change. Open miniLVM again, and add the drive letter to the drive. Close miniLVM, saving the change (which will mount the drive). Now, it works properly. Now, to figure out how to do that with commands, which can be done after the WPS is active (preferably BEFORE the drive gets used), but even better would be BEFORE the WPS gets started.

The conclusion, that I come to, is that the proper format needs to be in place when the IFS starts, as well as when the WPS starts, or there will be a mismatch, and it will not work properly. Unmount then mount, causes the whole thing to be evaluated again, and it gets it right.

In addition, if I leave the format as FAT, and try to use the RAMDISK for %TEMP% I have problems if a program stores a temporary file, that should have a LFN. The file name gets shortened, and the program can no longer find the file that it stored (this is not unique to the RAMDISK, it also happens on a real disk that is formatted as FAT). That means that the disk needs to be either HPFS, or JFS, to be useful, and when it is one of those two formats, it doesn't work properly in all cases, until it gets unmounted, and mounted.

Quote
But bug still there.

I will have to look at this one later...
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 13, 2014, 05:25:36 am
Quote
Now, to figure out how to do that with commands, which can be done after the WPS is active (preferably BEFORE the drive gets used), but even better would be BEFORE the WPS gets started.

Well, that was an interesting adventure.

The LVM drive letter cannot just be hidden, and restored. It must be changed to something else, then changed back. This must also be done AFTER the WPS has started, or it gets ignored by the WPS. The format can be done BEFORE the WPS has started.

I want the RAMDISK to have letter R:, and be formatted as JFS, so my solution is:
In QSSETUP.CMD (root of the boot drive):
Code: [Select]
RAMDISK R:
MD C:\TEMP
log save c:\log.txt
RAMDISK R: makes a default size RAMDISK (only memory above 4 GB), and gives it LVM letter R:.
MD C:\TEMP makes a directory on that RAMDISK (remember that this command file works in the QSINIT shell, so the RAMDISK letter is C: )
log save c:\log.txt saves the log file to the RAMDISK (I need a file on the disk, to prevent a problem later on).

Next, I need a way to do the format to either HPFS, or JFS. I do that with makeR.CMD, which contains:
Code: [Select]
COPY R:\* M:\RTRACKER

FORMAT.COM R: /FS:JFS /V:RAMDISK < RAMFMTRESP.TXT

md R:\TEMP
COPY R:\* M:\RTRACKER This copies the files from the root of the RAMDISK to a directory RTRACKER (which must exist). I do this for two reasons: 1) to be able to transfer files from the shell to OS/2. 2) If there is no file, the boot will stop demanding an Enter.
FORMAT.COM R: /FS:JFS /V:RAMDISK < RAMFMTRESP.TXT This does the format to JFS, in this case, and adds a volume label. (Simply substitute HPFS for JFS, if you wish to use HPFS.) RAMFMTRESP.TXT contains the single letter "Y" (without the quotes) as the first letter in the first line, followed by a blank line (this automatically responds Yes to the format command).
md R:\TEMP Since the drive was formatted, I need to restore the contents. Here i simply make a directory. You could UNZIP a fixed set of files, and directories, if you wish. REMEMBER that all of this will go away with a system shutdown, or crash.

Next, I put the lines:
Code: [Select]
CALL=C:\OS2\CMD.EXE /Q /C C:\makeR.cmd
SET tmp=r:\temp
SET temp=r:\temp
SET tmpdir=r:\temp
at the end of CONFIG.SYS.
CALL=C:\OS2\CMD.EXE /Q /C C:\makeR.cmd runs makeR.CMD, as described above.
The SET commands should replace any that may already exist, for those environment variables (you may want to make sure that it all works, before actually trying to use it for %TEMP%).

Now, for the part that makes it work properly:
At the beginning of STARTUP.CMD (the file may not exist, if not, create it). I put:
Code: [Select]
lvm /driveletter:[ Vol.00 ],X:

lvm /driveletter:[ Vol.00 ],R:

<whatever else you have/need in STARTUP.CMD>
lvm /driveletter:[ Vol.00 ],X: This changes the RAMDRIVE letter to X:, which is a drive letter that I use, but it must never exist at boot time. Note the spaces in "[ Vol.00 ]".
lvm /driveletter:[ Vol.00 ],R: This changes the RAMDISK letter back to R:, which causes a new drive mount, which resolves the previous discrepancies.

Note, that I cannot just assign a different drive letter (X:) when QSINIT makes the drive, and then change it to the final letter (R:) to mount the drive. That works okay, BUT if I do that the SET variables won't be assigned when CONFIG.SYS is executed, and they will demand an Enter because the drive doesn't exist. If the variables are assigned, after the WPS starts (in STARTUP.CMD), they are not set in the permanent environment. The double drive letter change is the easiest way around that, that I have found.

It is somewhat messy, but it works properly (I think). Any suggestions, or comments are welcome.
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 13, 2014, 06:18:52 am
Quote
It is somewhat messy, but it works properly (I think).

Well, it worked on my Lenovo ThinkPad L530. It appears that I need to delay the LVM commands, in STARTUP.CMD, on my Lenovo ThinkPad T510, or it happens too fast (or something like that), and the mount fails to cause a reevaluation of the drive. I added a DIR command as the first entry in STARTUP.CMD, and now it is working. Obviously, a more elegant solution is needed.   :o
Title: Re: OS/4 kernel and extended KEE
Post by: Dave Yeo on January 13, 2014, 07:55:31 am
I use sleep for similar affects in startup.cmd, eg sleep 3 for a 3 second delay.
IIRC sleep is part of the binutils or now coreutils.
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 13, 2014, 05:11:59 pm
I use sleep for similar affects in startup.cmd, eg sleep 3 for a 3 second delay.
IIRC sleep is part of the binutils or now coreutils.

Thanks. I know about Sleep in REXX, I didn't realize that it was also a command (although I was wondering why not).

It also occurred to me, that LVM /hide, and then LVM /driveletter, should do the job. It does, as long as there is more time between the commands. On my L530, I can use a a one second delay, and it works. On the T510, I need a 2 second delay. So, change the STARTUP.CMD section to:
Code: [Select]
lvm /hide:[ Vol.00 ]
sleep 1s
lvm /driveletter:[ Vol.00 ],R:

<whatever else you have/need in STARTUP.CMD>

Under some circumstances, the sleep might need to be changed to 2s. A quick test is to use the Drives object to copy a file with a long file name to the RAMDISK, then go to a command line, and do DIR. If the file name is a shortened name, add another second, reboot, and try again. With HPFS, and JFS, the file name should always be the long file name. I suppose that a test, to be sure that the drive really got mounted properly, would be a good idea. If it doesn't get mounted properly, some very strange things can happen.

I think I just fixed the final problem, but more testing is required.

I think those who do not have sleep.exe would have enough of a delay when the system says it can't find the program, but that could be bit confusing.
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on January 15, 2014, 10:33:10 am
While in the QSINIT shell, it said it did it. When I boot OS/2, it hesitates for a second, or so, and reboots.
Try new version.... I am not sure - it will be worse or better.
This ugly "immediate reboot" bug buried somewhere in the deep of memory init and a kind of hero required to dig it out.

Code: [Select]
lvm /hide:[ Vol.00 ]

You can rename it to more friendly string in QSINIT (or I can make it - by default):
      lvm rename %ramdisk% 0 PAE_PT

And - this method is perfect, but I'm still does not understand - why HPFS is not ready from MPTSTART.
I'm added format after the :END label and that is all:
Code: [Select]
@ECHO OFF
....
CALL K:\MPTN\BIN\NBSETUP.CMD
:END
format q: /fs:hpfs <k:\mptn\bin\letter_y.txt
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 15, 2014, 08:39:26 pm
Quote
Try new version.... I am not sure - it will be worse or better.
This ugly "immediate reboot" bug buried somewhere in the deep of memory init and a kind of hero required to dig it out.

Well, the latest version is working now, on the T510 (where I had the problem). I will need to try it on the other systems later.

When I do get a FAT32 drive created, it is not possible to format the drive as either HPFS, or JFS, but the long file name problem does not exist. I don't know how well it would work if I use it for %TEMP%. The normal FAT32 speed problem doesn't seem to exist (I don't use the FAT32 cache, and I don't use EAs with FAT32).

Can you add an option to force the file system to be FAT32, even with a small RAMDISK?

Quote
You can rename it to more friendly string in QSINIT

The LVM name really doesn't matter, but a name that means something to the user might make it easier to figure out what it is.

Quote
And - this method is perfect, but I'm still does not understand - why HPFS is not ready from MPTSTART.
I'm added format after the :END label and that is all:
Code: [Select]

@ECHO OFF
....
CALL K:\MPTN\BIN\NBSETUP.CMD
:END
format q: /fs:hpfs <k:\mptn\bin\letter_y.txt

It doesn't seem to matter when the format is done, the drive needs to be unmounted (hide), and mounted (assign a letter) again (with a delay between them), before the file system, and the WPS get synchronized. It also seems that the synchronization is not complete, until the desktop is fully populated, and all programs in the STARTUP folder are finished initializing. That is probably some sort of bug in the file systems, and/or the WPS. Doing the hide, then assigning a letter, seems to successfully get it fixed (probably something in the LVM mount procedure that fixes the problem).

I have tried doing the format as the very first CALL statement. I have done it, as you suggest, in MPTSTART (which is probably not a good place to do it), and I have done it as the last thing before the WPS starts up. The timing of the format doesn't matter. I have also tried doing the LVM /HIDE, and  LVM /DRIVELETTER command in that same section. The sleep command does not work until the WPS starts up, and the problem is not fixed without it. Doing the HIDE and DRIVELETTER , with a one, or two second delay between them, as the first thing in STARTUP.CMD does seem to fix the problem.

I did make a REXX program to do a WPS copy to the drive, and then check to be sure that the long file name was used. I use RexxAutoStart to cause a delay of one second, before it starts each program in the STARTUP folder, with a 0.75 second delay between the startups. That still sees the short file name, until RexxAutoStart has finished. Then, the long file name starts to work.

I am sure that we are seeing the results of some patching to make mounting disks possible (mostly USB, but other things as well). Normally, it is not physically possible to remount a drive as fast as it is done in this case, so the problem would not exist. It is also likely, that the RAMDISK is seen as being a permanently mounted disk, so some rediscovery code may not be used, until it is forced.
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on January 16, 2014, 11:11:49 am
Can you add an option to force the file system to be FAT32, even with a small RAMDISK?
FAT32 can be made by reduction of cluster's size.
Only one thing defines type of file system - number of clusters.
If it greater 64k - it will be FAT32, if less 4096 - FAT12.
So, minimum FAT32 partition size - 32Mb (64k * 512) - and I can add key - "try to create FAT32 if possible".

p.s. i added key "fat32" for ramdisk - in new version.
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 16, 2014, 06:33:17 pm
Quote
p.s. i added key "fat32" for ramdisk - in new version.

Okay, I will try that later.

I have found that HPFS still shows a problem, that JFS does not show. I have a directory, on the real disk, that has various types of files, and a few directories. When I use the WPS to copy it to the HPFS RAMDISK, I quickly get a message that says "SYS0254: An incorrect extended attribute name was used." I can copy the same directory to a JFS RAMDISK, with no trouble.
Code: [Select]
SYS0254: An incorrect extended attribute name was used.

EXPLANATION: The extended-attribute name contains a character that is
incorrect.

ACTION: Correct the extended-attribute name and retry the operation.

Unfortunately, it doesn't tell me what it is trying to copy. I also see the problem when using XCOPY from the command line. That seems to indicate that unzip-6.0-5.zip is causing the problem. Looking at it with the FM2 EA editor, I don't see a long file name. I need to do more isolation, to see if I can figure this out. I also need to format a real partition to HPFS, and see if the problem happens there.
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 16, 2014, 11:44:18 pm
Quote
I also need to format a real partition to HPFS, and see if the problem happens there.

Okay, the EA problem happens on a real volume, formatted as HPFS, so it must be a compatibility problem between JFS and HPFS, and not the RAMDISK. I can't find any long name EA that looks like it might cause such an error, but I haven't isolated the actual cause yet.
Title: Re: OS/4 kernel and extended KEE
Post by: Doug Bissett on January 17, 2014, 12:04:34 am
Quote
p.s. i added key "fat32" for ramdisk - in new version.

Well, it works on the T510. FAT32 doesn't show the EA problem either, although I don't enable EAs in the FAT32 driver.
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on January 18, 2014, 02:10:46 pm
And one remark for all. If you downloaded QSINIT to "look at later" - update it.
At least for ram disk (a lot of serious bugs was fixed since "new year release" of it).
Title: Re: OS/4 kernel and extended KEE
Post by: Lars on January 18, 2014, 04:02:53 pm
And one remark for all. If you downloaded QSINIT to "look at later" - update it.
At least for ram disk (a lot of serious bugs was fixed since "new year release" of it).

It would be helpful to state where exactly the up to date version can be found.
There is one version here:
http://ru2.halfos.ru/core/downloads/qsinit/qs_ldr.zip

but obvously the current version can be found here:
ftp://212.12.30.18/public/QS/QS_LDR.ZIP

Are you going to move this latest version to http://ru2.halfos.ru ?

Lars
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on January 18, 2014, 04:17:51 pm
halfos.ru have some "hosting in change" problems now...
qs_ldr.zip on it - is VERY old.

ftp://212.12.30.18/public/QS/QS_LDR.ZIP or
http://212.12.30.18/other/QS_LDR.ZIP are always up to date.

On later versions bldlevel can print its number.
Title: Re: OS/4 kernel and extended KEE
Post by: Martin Iturbide on January 18, 2014, 04:24:26 pm
Hi walking_x

Do you think it can be possible to start labeling the version of QSLoader, like putting it "QS_LDR-20140118.zip" ?
Just an idea to see it easier which one is newer. You are also free to set up a release/versino number for it.

Regards
Title: Re: OS/4 kernel and extended KEE
Post by: walking_x on January 19, 2014, 07:17:38 am
Just an idea to see it easier which one is newer.Regards
I added Archive dir on ftp, where QS_LDR_rev.ZIP files will be stored.
But common link still the same - QS_LDR.ZIP, this is much more easy to use ;)