Author Topic: New OS/4 kernel :: SVN4227  (Read 149059 times)

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: New OS/4 kernel :: SVN4222
« Reply #90 on: August 21, 2014, 11:25:21 pm »
I can easily think of a scenario where use of MTRRs become a problem compared to PAT.
MTRR mem. type regions have to be of size "power of 2" and there are restrictions regarding overlapping regions. PAT is fine granular down to the 4 kByte memory page and it can"override" the underlying MTRR memory type to a certain extent.

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: New OS/4 kernel :: SVN4222
« Reply #91 on: August 22, 2014, 12:34:17 am »
I can easily think of a scenario where use of MTRRs become a problem compared to PAT.
MTRR mem. type regions have to be of size "power of 2" and there are restrictions regarding overlapping regions. PAT is fine granular down to the 4 kByte memory page and it can"override" the underlying MTRR memory type to a certain extent.

to be fair, I haven't studied deeply how GRADD.SYS sets MTRR and I will belive you that it's sometimes a failure in setting. PAT in this case is much more convenient to use. But there is an issues here too - you have to have a proper bits in PTEs of each LFB mapping. Unfortunately when Panorama uses PAT for setting WC, then not all mapping get necessary bits in PTEs.

Sergey Posokhov

  • Full Member
  • ***
  • Posts: 169
  • Karma: +8/-6
    • View Profile
    • OS/2 API Research
Re: New OS/4 kernel :: SVN4221
« Reply #92 on: August 22, 2014, 02:16:56 pm »
I've got a bug on ThinkPad 510.
Something hangs when PM starts on, so I can only see a mouse pointer.

Finally, I removed from Config.sys:
Quote
RUN=C:\MMOS2\qrymmcd.exe

And bug has disappeared.
As usual, global variables, mutex semaphores and global shared memory are root of all evil.

walking_x

  • Full Member
  • ***
  • Posts: 101
  • Karma: +0/-0
    • View Profile
Re: New OS/4 kernel :: SVN4222
« Reply #93 on: August 22, 2014, 09:58:10 pm »
I can easily think of a scenario where use of MTRRs become a problem compared to PAT.
MTRR mem. type regions have to be of size "power of 2" and there are restrictions regarding overlapping regions. PAT is fine granular down to the 4 kByte memory page and it can"override" the underlying MTRR memory type to a certain extent.
There is no problems with MTRR usage, if do it right (not like it was done in panorama before PAT version).

In QSINIT - registers reprogrammed to entire address space of video card (get  it from PCI) for 1st CPU and these values copied to secondary CPUs on early init stage.

I have no any problems with such method. And no  requirements  in  "New And Special" version of panorama or new screen  driver  as  in  later  OS/4.  Even,  no  need of synchronization on multiple CPUs in code :)

Sergey Posokhov

  • Full Member
  • ***
  • Posts: 169
  • Karma: +8/-6
    • View Profile
    • OS/2 API Research
Re: New OS/4 kernel :: SVN4221
« Reply #94 on: August 28, 2014, 01:51:57 pm »
Once upon a time, I changed a string in "os2ldr.ini" and set:
Quote
timeout=0
And loader refused to boot anything, so I changed it to:
Quote
timeout=1
BTW, with 4225 previous bug has disappeared. Thanks.

Sergey Posokhov

  • Full Member
  • ***
  • Posts: 169
  • Karma: +8/-6
    • View Profile
    • OS/2 API Research
Re: New OS/4 kernel :: SVN4227
« Reply #95 on: October 02, 2014, 05:51:46 pm »
Version 4239 doesn't work:

TRAP0008

Internal processing error at location
##0168:fff9bfe0 - 000f:00090fe0
3464, 0 trap.asm

06860655 - (no datetime)
internal revision 15.1_SMP.4239

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: New OS/4 kernel :: SVN4227
« Reply #96 on: October 03, 2014, 05:13:03 pm »
I got 4243. It boots up to the GUI, then reboots, on my Lenovo ThinkPad L530 (UEFI). It does TRAP0008, almost immediately, on my Lenovo ThinkPad T510.

FWIW, I have quit using the OS/4 kernel, now that QSINIT has been fixed to work with our ACPI. Since it is easy to switch, I will continue to test, but I don't see any advantage to using OS/4, at the moment (even if it would work).

Sergey Posokhov

  • Full Member
  • ***
  • Posts: 169
  • Karma: +8/-6
    • View Profile
    • OS/2 API Research
Re: New OS/4 kernel :: SVN4227
« Reply #97 on: November 12, 2014, 05:56:37 pm »
Now 4248 works with Lenovo T410.

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: New OS/4 kernel :: SVN4227
« Reply #98 on: November 13, 2014, 03:50:53 am »
Quote
Now 4248 works with Lenovo T410.

Seems to work with my Lenovo ThinkPad T510, and L530, now.

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: New OS/4 kernel :: SVN4262
« Reply #99 on: December 03, 2014, 12:33:54 am »
started from SVN4262  -  needs patched acpi.psd (http://gus.biysk.ru/os4/Patches/acpipsdpatch.RAR) and /ST=0 in command line or os4apic.psd

started from SVN4250  is no more compatible with alternative loader



« Last Edit: December 11, 2014, 05:52:19 pm by OS4User »

guzzi

  • Sr. Member
  • ****
  • Posts: 331
  • Karma: +0/-0
    • View Profile
Re: New OS/4 kernel :: SVN4262
« Reply #100 on: December 03, 2014, 01:50:14 am »

started from SVN4250  is no more compatible with alternative loader

That's the second major compatibility break. Not a good thing, imho.

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: New OS/4 kernel :: SVN4227
« Reply #101 on: December 03, 2014, 04:27:36 am »
Quote
started from SVN4250  is no more compatible with alternative loader

I assume you mean that it is not compatible with QSINIT. Until that gets fixed, I have lost interest in OS/4.

Quote
needs patched acpi.psd

Another good reason to avoid OS/4, IMO.

Andreas Schnellbacher

  • Hero Member
  • *****
  • Posts: 827
  • Karma: +14/-0
    • View Profile
Re: New OS/4 kernel :: SVN4227
« Reply #102 on: December 05, 2014, 01:27:06 am »
Doug, the point is not about avoiding something, but about getting the best out of the available options. Actually, you can't compare directly one option with another, because each of them has its own case of usage.

guzzi

  • Sr. Member
  • ****
  • Posts: 331
  • Karma: +0/-0
    • View Profile
Re: New OS/4 kernel :: SVN4227
« Reply #103 on: December 05, 2014, 03:02:26 am »
Doug, the point is not about avoiding something, but about getting the best out of the available options. Actually, you can't compare directly one option with another, because each of them has its own case of usage.

Very true. However, I do think that loss of compatibility is in the end crippling for an alternative kernel. I'd like to see OS/4 develop as a 'drop in' kernel that remedies some of the limitations of the original one, much in the same way that QSinit is more or less a drop in replacement for the original loader. That would mean compatibility with ACPI and standard loader, com port debug output, etc.. The way it goes now the developers seem to divert more and more from the standard. No doubt they have good reasons for that, but imho it's a mistake.

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: New OS/4 kernel :: SVN4227
« Reply #104 on: December 05, 2014, 04:34:11 am »
Doug, the point is not about avoiding something, but about getting the best out of the available options. Actually, you can't compare directly one option with another, because each of them has its own case of usage.

So far, OS/4 has added nothing that seems to be useful. It does break system dumps, which is a major handicap for those who develop software for eCS. Add the questionable legal status, and I don't see any reason to use it. That doesn't mean that I will stop testing it, but I won't spend much time trying to figure out problems, until it offers some advantage. One must also remember that it is not guaranteed to work in all cases (or even work, at all). I find that those releases which work, work well. Those that don't work, are completely broken, but there is no clue what was changed, and it should be obvious to the programmers that there is a problem. It seems that they just make the package available, whether it works, or not.

Quote
The way it goes now the developers seem to divert more and more from the standard. No doubt they have good reasons for that, but imho it's a mistake.

If they are doing that to figure out exactly what works, and doesn't work, I cannot find fault (even when it doesn't work, at all). However, if they intend to make a proper release in that state, I agree that it is a mistake.

QSINIT, on the other hand has solved a serious problem with memory being limited to 512 meg (4 GB installed), on some machines. As a bonus, it adds the RAMDISK that uses memory above what OS/2 can normally access, which also offers the possibility of using that memory for other things. There is also no question about the legality, even though the license is not very good. I suspect that that is a misunderstanding on the author's part. The intent seems to be to prevent somebody from profiting from the project, but it puts the project into a gray area, where it is not clear if it is meant to prevent inclusion in eCS (which could be argued to be non profit), or if it is meant to prevent General Motors (for example) from using it to make a profit by using eCS with QSINIT. Either way, it makes QSINIT mostly useless, and therefore irrelevant because no business, or government, can take the chance on what a judge might think about it. Then again, the license is probably unenforceable anyway. Oh yeah, you can play a couple of games with it, but I am not too sure why anybody would want to do that. I can see the possibility of adding a "standard interface" to the machine, making things like video adapters, or disk drives, more compatible to the eCS drivers (much like what virtual machines do).