Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Dave Yeo

Pages: 1 ... 236 237 [238] 239 240 ... 242
3556
Networking / Re: e1000e driver - test updates
« on: January 19, 2014, 10:50:08 pm »
I have
Code: [Select]
Vendor 8086h Intel Corporation
 Device 104Ah 82566DM Gigabit Network Connection

Quickly testing all your builds seem to work the same as the official driver unluckily.
I have IRQ problems with the driver, under Warp V4 it only works if I disable sound and the PATA interface (dvd burner), otherwise can not bind to tcp/ip and under eCS it only seems to work if I power off the system when rebooting otherwise it receives but does not transmit.
I'll test more on eCS including moving some large files later.

3557
Applications / Re: Updates at http://os2ports.smedley.id.au
« on: January 19, 2014, 07:26:15 pm »
Do you know what version of Firefox the Tor Browser Bundle uses? Also wasn't using a Firefox security hole how the FBI broke into the Silk Road?

3558
Patch.exe is the program to use. Quickly looking on Hobbes all I found is http://hobbes.nmsu.edu/download/pub/os2/dev/util/patch212.zip which is probably good enough though I'm sure there are newer versions around.
Use is patch.exe -p0 < foo.diff, sometimes need -p1 instead and always -p1 for git formatted patches.. I usually test with patch.exe --dry-run -p0 < foo.diff and also add --binary to keep unix line endings so patch.exe -p0 --dry-run --binary < the_patch.diff
If the patch doesn't cleanly apply you will get rej files and they will need to be applied by hand.

3559
Programming / Re: Closed source parts of eComStation
« on: January 16, 2014, 10:13:38 pm »

The whole address space, on OS/2, that you can use with A LOT of processes (programs), is limited to 4 GiB.
So, even if you have the swapping feature enabled and large enough hard disk, you cannot run 500 programs to allocate 500 GiB (one GiB per process).

You could if the swapfile wasn't limited in size and you could put up with the thrashing. In theory the limit is 64 TB minus kernel and hardware space. In practice I think the limit to the swap file is 2 or 4 GB.
Quote
While on Windows 32-bit, one program still cannot allocate more than 4 GiB, but you can swap on your hard disk and allocate 500 GiB with a lot of processes.

Generally Win32 can only use 2GB (3GB with the /3 switch) whereas  OS/2 before Ver4.5 could only use 512MB (drivers such as HPFS386 cache could use higher memory) while v4.5+ can use the 512MB low area (minus shared s really like 300MB) plus memory above 1 GB which depending on the VirtualAddressLimit setting and hardware can be another 2.5GBs. Not every program can use the high memory and 16 bit programs are limited to the lower memory.
In real life we could still link the Mozilla xul.dll while Windows first needed the /3 switch then had to go to the 64bit version to map out a full 4GBs.
See http://www.os2voice.org/VNL/past_issues/VNL0708H/feature_3.html for a decent overview.
Quote
So, the trick is to put the swapfile not on the harddisk, but on the ramdrive, which would be able to map the memory above the 4 GiB limit using PAE without affecting the rest of the system.

So, that is the limit I am talking about. It could be overcomed by reimplementing the memory management subsystem in the OS/2 kernel.

I tried allocatting 4.5 GBs here but with only 1.5GB of real memory I gave up after an hour and half of disk churning. It would be interesting to test on a system with 4GBs of memory and also to test with the swapper on a PAE ram disk.
Not being much of a programmer I simply modified allocmem to use high memory and not exit right away. Here it would allocate 900 MBs per instance and I tried launching 5 instances. Warp V4 froze pretty quick while eCS 2.1 thrashed for 1.5 hours before I reset the computer. So if testing be prepared for a crash. Here is the program.

3560
Another consideration when listing all the open source software is programs where OS/2 fixes have been merged in upstream and/or programs that just work after a simple re-compile (perhaps with the right flags). For example of programs I've recently put on Hobbes, nasm which has supported OS/2 for close to forever and just builds and works on OS/2 though the latest no longer builds with OpenWatcom. Flac which I got a couple of minor patches commited upstream and now just works on OS/2 excepting some minor libtool problems to build. FFmpeg/libav which are the basis of most of our video support where once again fixes are pushed upstream and just works on OS/2 v4.5 and needs very minor patching to work around PM bug on v4.52 including eCS.
Thing is these types of programs need maintaining so they don't break, meaning regular building and patches pushed upstream.

3561
Programming / Re: Closed source parts of eComStation
« on: January 15, 2014, 11:38:55 pm »
As far as I know, the 4 GB barrier is built into X86. We use 32 bit pointers which are limited to 4Gbs and while most CPU's are now capable of using 64 bit pointers the CPU has to be put into a different state where 16 bit code no longer works and OS/2 still has too much 16 bit code to ignore, especially as much of the 16 bit code is device drivers.
All 64 bit capable CPUs also do PAE and as has recently been shown, os2ldr can be rewritten to access that extra 60GBs but it is kinda like bank switching (actually if I understand it, it's back to segments). You can access different 4 GBs banks or segments, great for a ramdisk but not really extending the address space visible to a program. Perhaps it is possible to give different programs their own address space so eg Firefox has access to 4GBs of real ram minus whatever the kernel needs along with what the hardware needs and this would be an improvement. How hard this would be I don't know. I do know that MS gave up on the idea for client versions of Windows as too many device drivers were not happy with it.
As far as I know the swap file is also limited by 32 bit types, probably signed so limited to 2 GBs which means putting the swap file on the ram disk can only help so far.
If someone is really dealing with large bitmaps, video files etc, they really have to move to a 64 bit operating system and purchase more memory

3562
Programming / Re: OS/4 kernel and extended KEE
« 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.

3563
Programming / Re: OS/4 ? QSINIT ?
« on: January 05, 2014, 07:15:20 pm »
Ok - Microsoft still owns FAT, LE and some things like that and this is only one (and hypothetic) problem ;)

I always assumed that our OS/2 license includes rights to use FAT, LE and such.

3564
Setup & Installation / Re: Tweaking eCS for low memory system
« on: January 02, 2014, 06:55:51 pm »
It's been so long since I've thought about it :) One thing that comes to mind is to lower the number of threads in config.sys

3565
Programming / Re: OS/4 kernel and extended KEE
« 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.

3566
Games / Re: MAME 0.151 ROMs
« on: December 31, 2013, 03:58:59 am »
Hi Ivan.

Well, my point is that I'm trying to make a case that IBM's OS/2 installers can be turned for public preservation on archive.org. (and in a legal way)

If anybody will like to discuss this point of view I will welcome it.

Regards

Considering that the bank machine at my bank seems to use OS/2 along with various other pieces of infrastructure and such also using it I doubt that it would be considered obsolete.  Same with the hardware,  floppy drives are still sold and hardware isn't that much different then what OS/2 is designed to use, as eCS shows it just needs updated drivers and it runs well.
Compare to the Mame roms which I understand mostly ran on specialized arcade systems that haven't been made in years and often the company itself is long gone.

3567
Programming / Re: Test build of GCC 4.7.3 available
« on: December 30, 2013, 05:19:49 pm »
Don't suppose you have a diff with this already in place? I don't fancy modifying multiple source files due to time constraints...

I posted a patch here on the 21st. Here it is again freshly rebased. If you have problems with git, eg complaining about not being able to merge when pulling or cloning try
git fetch --force && git reset --hard origin/master
BTW I tested 4.5.4 and had the same failures even with optimizations turned off. Just tried 3.3.5, had to use pthreads as GCC is too old to have atomics and disable sse and mmx but it actually passed. I'll do some more experimenting later today.

3568
Programming / Re: Test build of GCC 4.7.3 available
« on: December 23, 2013, 03:37:50 am »

Hi Dave - were you able to test with 4.7.3 at al? I'm curious when the regression started as it may help in the debugging.

Hi Paul, tested 4.7.3 and had similar results.

3569
Setup & Installation / Re: ecs2.2 beta refresh
« on: December 22, 2013, 09:36:54 pm »
The problem is that OS/2 is old and particular about partitions starting on cylinder boundries while all other operating systems know that cylinders don't even exist anymore. You used Windows to change partition size and the boundaries ended up wrong. Same with Linux with the added problems that Linux will use the same reserved areas as the OS/2 LVM thus destroying the LVM info.
The advice has always been, only use OS/2 tools to do anything to the partitions except changing the partition ID.
There used to be howtos shipped with Linux including this, http://www.ru.j-npcs.org/usoft/WWW/HOWTO/mini/Linux+DOS+Win95+OS2 and some similar ones. Perhaps it needs updating and included with eCS.

3570
Programming / Re: Test build of GCC 4.7.3 available
« on: December 21, 2013, 06:58:39 am »

GCC 4.8.2 binaries now at http://os2ports.smedley.id.au

I'll get the source up at github when i get a spare afternoon

Finally tested the C part by running the FFmpeg FATE suit which consists of about 2000 tests.  http://ffmpeg.org/fate.html.
While GCC 4.4.6 usually passes all tests (I get failures on 2 HEVC (H265) compliance tests after a few days of up time, see http://fate.ffmpeg.org/history.cgi?slot=x86.os2.446 and for comparison fate.ffmpeg.org), 4.8.2 failed between 24 and 30 tests and ffmpeg.exe and especially ffprobe.exe froze multiple times forcing me to kill them. There's still something wrong, I'd guess alignment issues.
If you want to test, you need to configure with cpu=i486 or higher to pull in the GCC atomics (could they be broken?) and I'll attach a patch for eCS to work around the buggy PMSHELL. Note this also tests your environment as things like diff not supporting stdin or a bad bc will cause falures. Need to use [k]sh to run configure as well due to buggy ash (doesn't set CWD).
Anyways thanks for the great work and I wish I knew how to debug some of this stuff.

Pages: 1 ... 236 237 [238] 239 240 ... 242