Firefox 3.7a4pre available
Rich Walsh
I've posted a recent build of the next version of Firefox to my
website. You can download it from:
http://e-vertise.com/warpzilla/firefox-37a4pre.zip
This version contains several OS/2 enhancements and fixes:
Enhancements:
- scrolling should require 25-50% less CPU usage than previously;
there are other less noticable improvements in display speed
- previously, switching to a new tab before the page loaded
(i.e. getting a blank screen before anything was displayed)
consumed an extra 1-3mb of memory for the life of that tab;
this memory usage has been eliminated
- there's a new OGG decoder as well as changes in the OS/2 audio
component that make it far less likely that normal system
activity will interrupt the audio stream
Fixes:
- users of Matrox video drivers should see a normal, non-slanted
display; however, video performance will be considerably
slower/more CPU-intensive than would be the case with SNAP
- users of FlashBlock will no longer see a floating rectangle
that fails to move or update when scrolling
Please let me know if you see any bugs or have other problems.
--
== == almost usable email address: Rich AT E-vertise.Com == ==
___________________________________________________________________
|
| DragText v3.9 with NLS support
Rich Walsh | A Distinctly Different Desktop Enhancement
Ft Myers, FL | http://e-vertise.com/dragtext/
___________________________________________________________________
inv...@invalid.invalid
minimised and I clicked on a link in TB, FF created a new tab and the
link was in the URL box, but the window was empty and transparent so
you always had to reload the page.
Martin
(ATI Radeon with Snap)
kbr_n...@guzzi.demon.nospam.nl
at 12:37 AM, "Rich Walsh" <spamyo...@127.0.0.1> said:
I'm happy to report that the problem I had with the 3.6 versions in which
new text lines that scrolled on to the screen is no longer present in this
version.:-)
>I've posted a recent build of the next version of Firefox to my website.
>You can download it from:
> http://e-vertise.com/warpzilla/firefox-37a4pre.zip
>This version contains several OS/2 enhancements and fixes:
>Enhancements:
>- scrolling should require 25-50% less CPU usage than previously;
> there are other less noticable improvements in display speed
>- previously, switching to a new tab before the page loaded
> (i.e. getting a blank screen before anything was displayed)
> consumed an extra 1-3mb of memory for the life of that tab;
> this memory usage has been eliminated
>- there's a new OGG decoder as well as changes in the OS/2 audio
> component that make it far less likely that normal system
> activity will interrupt the audio stream
>Fixes:
>- users of Matrox video drivers should see a normal, non-slanted
> display; however, video performance will be considerably
> slower/more CPU-intensive than would be the case with SNAP
>- users of FlashBlock will no longer see a floating rectangle
> that fails to move or update when scrolling
>Please let me know if you see any bugs or have other problems.
Cheers, Bjorn.
--
-----------------------------------------------------------
k...@guzzi.demon.nl
-----------------------------------------------------------
Ilya Zakharevich
Rich Walsh
<spamyo...@127.0.0.1>], who wrote in article <brddYgxvE0gm-pn2-3S4GJvRusdMB@fong>:
> - there's a new OGG decoder as well as changes in the OS/2 audio
> component that make it far less likely that normal system
> activity will interrupt the audio stream
Thanks a lot. BTW, yesterday I was trying to fight with hiccups of
mplayer (tested on JFS with 64MB cache; only at start of a video,
never later; mplayer's cache is about 80% full of 8MB), so I would
like to know on how you achieve this. Elevated priority? To which
level? Does it depend on having the focus?
Thanks,
Ilya
Rich Walsh
> Rich Walsh wrote in article <brddYgxvE0gm-pn2-3S4GJvRusdMB@fong>:
>
> > - there's a new OGG decoder as well as changes in the OS/2 audio
> > component that make it far less likely that normal system
> > activity will interrupt the audio stream
>
> Thanks a lot. BTW, yesterday I was trying to fight with hiccups of
> mplayer (tested on JFS with 64MB cache; only at start of a video,
> never later; mplayer's cache is about 80% full of 8MB), so I would
> like to know on how you achieve this. Elevated priority? To which
> level? Does it depend on having the focus?
mplayer's audio backend is based on libdart which (IMHO) is really
poorly crafted, so I always expect the worst & I'm never disappointed.
The previous OGG decoder (liboggplay) didn't permit much buffering
(about 1/4 second, max). If you tried to buffer more, the video
would stop. In order to minimize interruptions, I had to increase
the decode thread's priority from 2-00 (i.e. normal) to 2-08.
The new, Mozilla-written decoder encourages buffering by decoding
audio several seconds ahead of need and by feeding the data to the
backend using a dedicated thread. On OS/2, we now buffer about
1.8 seconds and don't change any priorities at all.
Rich Walsh
>
> I'm happy to report that the problem I had with the 3.6 versions in which
> new text lines that scrolled on to the screen is no longer present in this
> version.:-)
Could you give me a little more detail? I'm not sure what problem was fixed.
inv...@invalid.invalid
> visible and nearly entirely off-screen, positioned at the top of the
> display. I have to select those windows from the Task Manager, RMB and
> select "Cascade" or "Tile" to get their title bars to show, to
> reposition them.
I have seen something similar: small windows which are opened by
javascript are positioned to much ähm topper then top? the top
position is -100 instead 0.
JMS
Ilya Zakharevich
Rich Walsh
> The previous OGG decoder (liboggplay) didn't permit much buffering
> (about 1/4 second, max). If you tried to buffer more, the video
> would stop. In order to minimize interruptions, I had to increase
> the decode thread's priority from 2-00 (i.e. normal) to 2-08.
Hmm, so this won't work if any CPU intensive application has a focus
(AFAIK, to match the "focussed priority" you need to go ABOVE 2-*...)...
> The new, Mozilla-written decoder encourages buffering by decoding
> audio several seconds ahead of need and by feeding the data to the
> backend using a dedicated thread. On OS/2, we now buffer about
> 1.8 seconds and don't change any priorities at all.
Hmm again.... *Here* JFS flush (or at least I assume it is...) of
64MB cache may create a hiccup up to about 5sec long. I do not see
how having 1.8sec buffer would help with this...
Thanks,
Ilya
Steve Wendt
> I'll miss the Session Manager add-on, though. FF 3.7 says it's
> incompatible :(
You can try turning off the compatibility checks, or hacking the
compatibility strings in the plugin.
kbr_n...@guzzi.demon.nospam.nl
>On Thu, 15 Apr 2010 17:46:27 UTC, kbr_n...@guzzi.demon.nospam.nl
>wrote: >
>> I'm happy to report that the problem I had with the 3.6 versions in which
>> new text lines that scrolled on to the screen is no longer present in this
>> version.:-)
>Could you give me a little more detail? I'm not sure what problem was
>fixed.
Oops, half the sentence is missing..... again:
I'm happy to report that the problem I had with the 3.6 versions in which
new text lines that scrolled on to the screen are compressed and only half
visible until I either use the scroll bar or move another window over the
firefox window is no longer present in this version.:-)
kbr_n...@guzzi.demon.nospam.nl
at 10:09 PM, "Rich Walsh" <spamyo...@127.0.0.1> said:
Send me an email to grt screen shotd to clarify
>On Thu, 15 Apr 2010 17:46:27 UTC, kbr_n...@guzzi.demon.nospam.nl
>wrote: >
>> I'm happy to report that the problem I had with the 3.6 versions in which
>> new text lines that scrolled on to the screen is no longer present in this
>> version.:-)
>Could you give me a little more detail? I'm not sure what problem was
>fixed.
Cheers, Bjorn.
--
-----------------------------------------------------------
k...@guzzi.demon.nl
-----------------------------------------------------------
inv...@invalid.invalid
> - users of FlashBlock will no longer see a floating rectangle
> that fails to move or update when scrolling
It seems that flashblock does not work any longer in this version.
inv...@invalid.invalid
the bookmark window showed only a few folders...
But this may not be os/2 specific...
Rich Walsh
I wouldn't have written the above if I hadn't installed F/B and
confirmed that it worked without any side-effects (I also tested
it without the fix to confirm the nature of the problem).
Can you identify a particular page where it doesn't work?
Alan Beagley
>
> I've posted a recent build of the next version of Firefox to my
> website. You can download it from:
> http://e-vertise.com/warpzilla/firefox-37a4pre.zip
Some of the same problems as with 3.6.3 -- reported earlier:
1. I get the "error message" sound when I start the program, but no
error message is displayed.
2. A "zombie thread" of the program apparently continues to run after I
exit the program, accompanied by considerable but intermittent CPU
usage. CAD (with CADH installed) allows me to execute the TOP program
and kill that thread so that I can invoke FF once again -- but the FF
icon often is still grayed out.
No such problems with 3.5.9.
-=-
Alan
Dave Saville
<spamyo...@127.0.0.1> wrote:
> 1) The windows that were previously minmized wouldn't display any menus
> until they were minimized again then restored. The reason was that
> FF thought they were currently minimized, so it suppressed all popup
> windows. I'm surprised no one reported this.
I never cease to be amazed at some of the bugs I have found in
ClipView, usually when working on another feature, that no one
reported to me and potentially affected *all* users. *Somebody* must
have tripped over it. I think some of it is the belief that code is
cast in stone and can't be changed - so they live with it. An attitude
encouraged by software companies in my experience. :-)
--
Regards
Dave Saville
Dariusz Piatkowski
set to 2048 normally. But with this version within 1 day PMMail closes and
leaves a zombie process running which can not be killed (reboot is the only way
to cure this). This also occurs with 3.5.9...but not for about 4-5 days of
normal usage. In addition to this, the overall system stability seems to have
decreased...I am basing this on the amount of other apps shutting down
unexpectedly.
So...to test I dropped the setting to 1536...stability increased, PMMail is
still affected but not until day 2 or 3, other unexplained crashes seem to have
gone away.
I will try 1024 next.
Thanks!
-Dariusz
William L. Hartzell
I understand that some think using JFS as their primary boot disk is
cool, but it is plain not smart. With JFS block size being 4Kay bytes
and most files on OS/2--eCS boot volume smaller than than 1 kay bytes,
the waste of disk space is huge. This adds to the boot time as there is
more real estate on the drive to cover to get the data. I've come to
the conclusion that with some SATA drives being over ten times faster
than IDE drives of five years ago, that good old HPFS is the only way to
go. Here from Trevor's Sysbench are results from my old Athlon XP 2000
machine, along with someone else's machine, and my current Phenom2 machine:
--------- Athlon XP ---------
Disk I/O disk 0-1: 38162 MB - WDC WD400BB-32AUA1
Avg. data access time : 13.800 milliseconds
Cache/Bus xfer rate : 82.728 Megabytes/second
Track 0 xfer rate fwd : 32.047 Megabytes/second
Middle trk rate fwds. : 31.029 Megabytes/second
Last track rate bwds. : 19.465 Megabytes/second
Average Transfer rate : 27.514 Megabytes/second
Disk use CPU load : 6.070 percent
-----------------------------------------------------------------------
Total : 161.707 Disk I/O-marks
Disk I/O disk 0-2: 28624 MB - QUANTUM FIREBALLP LM30
Avg. data access time : 11.300 milliseconds
Cache/Bus xfer rate : 53.401 Megabytes/second
Track 0 xfer rate fwd : 25.606 Megabytes/second
Middle trk rate fwds. : 23.973 Megabytes/second
Last track rate bwds. : 17.905 Megabytes/second
Average Transfer rate : 22.495 Megabytes/second
Disk use CPU load : 2.820 percent
-----------------------------------------------------------------------
Total : 137.037 Disk I/O-marks
-------- Someone else --------------------------------
Disk I/O disk 1-1: 152625 MB - ST3160815AS
Avg. data access time : 14.800 milliseconds
Cache/Bus xfer rate : 116.769 Megabytes/second
Track 0 xfer rate fwd : 75.088 Megabytes/second
Middle trk rate fwds. : 61.101 Megabytes/second
Last track rate bwds. : 35.296 Megabytes/second
Average Transfer rate : 57.161 Megabytes/second
Disk use CPU load : 2.260 percent
-----------------------------------------------------------------------
Total : 343.217 Disk I/O-marks
Disk I/O disk 2-2: 610508 MB - NetCell SyncRAID(TM) SR5000 X
Avg. data access time : 16.200 milliseconds
Cache/Bus xfer rate : 82.825 Megabytes/second
Track 0 xfer rate fwd : 77.652 Megabytes/second
Middle trk rate fwds. : 77.631 Megabytes/second
Last track rate bwds. : 72.555 Megabytes/second
Average Transfer rate : 75.946 Megabytes/second
Disk use CPU load : 3.140 percent
-----------------------------------------------------------------------
Total : 436.058 Disk I/O-marks
---------------- Phenom2 ------------
Disk I/O disk 0-1: 61052 MB - KINGSTON SNVP325S264GB
Avg. data access time : 0.100 milliseconds
Cache/Bus xfer rate : 198.737 Megabytes/second
Track 0 xfer rate fwd : 179.692 Megabytes/second
Middle trk rate fwds. : 188.913 Megabytes/second
Last track rate bwds. : 195.452 Megabytes/second
Average Transfer rate : 188.019 Megabytes/second
Disk use CPU load : 3.480 percent
-----------------------------------------------------------------------
Total : 1593.188 Disk I/O-marks
Disk I/O disk 0-2: 953855 MB - SAMSUNG HD103UJ
Avg. data access time : 13.600 milliseconds
Cache/Bus xfer rate : 194.117 Megabytes/second
Track 0 xfer rate fwd : 96.180 Megabytes/second
Middle trk rate fwds. : 83.009 Megabytes/second
Last track rate bwds. : 47.454 Megabytes/second
Average Transfer rate : 75.548 Megabytes/second
Disk use CPU load : 2.540 percent
-----------------------------------------------------------------------
Total : 453.198 Disk I/O-marks
Disk I/O disk 1-3: 190780 MB - ST3200822A
Avg. data access time : 15.000 milliseconds
Cache/Bus xfer rate : 85.324 Megabytes/second
Track 0 xfer rate fwd : 62.359 Megabytes/second
Middle trk rate fwds. : 50.819 Megabytes/second
Last track rate bwds. : 32.360 Megabytes/second
Average Transfer rate : 48.513 Megabytes/second
Disk use CPU load : 0.900 percent
-----------------------------------------------------------------------
Total : 325.879 Disk I/O-marks
Boot is on the SSD. The 1 TB disk holds data. The 200 GB disk is
Windows. I have JFS volumes on the 1 TB drive.
--
Bill
<Thanks, a Million>
Ilya Zakharevich
William L. Hartzell
<wlhar...@tx.rr.com>], who wrote in article <Wr-dndDpQoPMyXrW...@mozilla.org>:
> I understand that some think using JFS as their primary boot disk is
> cool, but it is plain not smart.
Might be, but who cares? What I wrote had no relationship to "using
JFS as a primary boot disk".
> I've come to the conclusion that with some SATA drives being over
> ten times faster than IDE drives of five years ago, that good old
> HPFS is the only way to go.
Using HPFS with larger than 1.5TB of storage is just "simply out of
the question".
Myself, I boot from, keep programs, and keep "hot" non-MM data on
HPFS. The rest goes to JFS. And:
I saw MUCH more problems with JFS in 2-3 years of usage than I
EVER saw with HPFS;
on the other hand, my data acquisition rate now is SEVERAL orders of
magnitude more than what I had on HPFS;
so it may be just "more data, more data loss" logic, not "HPFS is
more reliable than JFS" one.
Wish I knew more,
Ilya
Mike O'Connor
> Sir:
<snipped>
> I understand that some think using JFS as their primary boot disk is
> cool, but it is plain not smart. With JFS block size being 4Kay bytes
> and most files on OS/2--eCS boot volume smaller than than 1 kay bytes,
> the waste of disk space is huge. This adds to the boot time as there is
> more real estate on the drive to cover to get the data. I've come to the
> conclusion that with some SATA drives being over ten times faster than
> IDE drives of five years ago, that good old HPFS is the only way to go.
> Here from Trevor's Sysbench are results from my old Athlon XP 2000
> machine, along with someone else's machine, and my current Phenom2 machine:
> --------- Athlon XP ---------
> Disk I/O disk 0-1: 38162 MB - WDC WD400BB-32AUA1
<snipped>
Total : 325.879 Disk I/O-marks
>
> Boot is on the SSD. The 1 TB disk holds data. The 200 GB disk is
> Windows. I have JFS volumes on the 1 TB drive.
> --
> Bill
> <Thanks, a Million>
Hi Bill,
Although it's true JFS has 4KB blocks, as the default, for smaller files
it re-uses "free" space within that already allocated in a granular
manner, so there is no problem of huge waste!
I boot exclusively with JFS here, and have been doing so since September
2004, and on the very rare occasion that a catastrophy has happened,
I've been able to recover the data successfully.
I don't have any volumes that span disks, or even multiple partitions on
one disk. Any time there has to be a dirty shutdown (e.g. Mozilla hard
lockups), the JFS volumes (up to 30 bootable on this system [many have
to be "hidden from OS/2" due only 21 volume-letters normally available
for HDD volumes, due A,B,S,Z & R (Ramdisk)]) all come up clean, whilst
all HPFS volumes have to have a full chkdsk!
I also always long-format all of my volumes, whether HPFS or JFS, and
now with the two-pass (format + verify) 6x faster jfsfmt32.exe, that's
much less of a pain for large data volumes!
WRT OS/2 and "most files on OS/2--eCS boot volume smaller than than 1
kay[K!]bytes" - that's absolute unadulterated BS. You might want to
rethink that in light of the following from typical full-installation of
eCSV2.0RC7 Silver:
IBMCOM - 300 files average 22466 bytes
IBMLAN - 258 files average 45968 bytes
MUGLIB - 30 files average 29696 bytes
OS2BOOT - 191 files average 22688 bytes
OS2\DLL - 329 files average 87453 bytes
MPTN - 212 files average 51953 bytes
SNAP - 10 files average 1390080 bytes
TCPIP - 517 files average 47137 bytes
LANGUAGE\CODEPAGE - 143 files average 7948
MMOS2 - 426 files average 56846 bytes
OS2\SYSTEM - 179 files average 38700
PSFONTS - 67 files average 698673 bytes
Entire OS2
TREE - 2637 files average 69787 bytes
ECS\BIN - 117 files average 55383 bytes
ECS\BOOT - 7 files average 37888
ECS\ACPI - 19 files average 15467 bytes
ECS\DLL - 64 files average 171232 bytes
ECS\SYSTEM - 361 files average 64421 bytes
and there's very little variance shown from that in MCP2/ACP2/W4 and eCS 1.x
Regards,
Mike
Doug Bissett
<wlhar...@tx.rr.com> wrote:
> Sir:
>
...snip...
> I understand that some think using JFS as their primary boot disk is
> cool, but it is plain not smart.
I beg to differ. IMO, continuing to use HPFS with large disks is not
smart.
> With JFS block size being 4Kay bytes
> and most files on OS/2--eCS boot volume smaller than than 1 kay bytes,
> the waste of disk space is huge.
On a 100 meg disk, the waste is "huge". On a 100 GB disk, it is
nothing.
> This adds to the boot time as there is
> more real estate on the drive to cover to get the data.
I find that boot time is REDUCED by close to 20%, when using JFS. The
main difference is in the usable cache size. With the latest updates,
I am using much larger cache (128 meg, or 256 meg, depending on memory
size), while HPFS is restricted to 2 meg. It does make a HUGE
difference. I think there is also a much better method to locate data
on the disk too.
> I've come to
> the conclusion that with some SATA drives being over ten times faster
> than IDE drives of five years ago, that good old HPFS is the only way to
> go.
I have come to the opposite conclusion. SATA drives are still very
slow, compared to memory access. The larger cache makes a HUGE
difference. I have also found that the initial CHKDSK that occurs
after a crash, almost never finds anything to "fix", while it almost
always "fixes" something on an HPFS drive. True, the JFS CHKDSK can
take a little longer, if it does find something to investigate, but it
rarely does (perhaps one crash/boot in 1000).
One other major advantage, is that you no longer need to load the HPFS
IFS. That saves a significant amount of shared memory, and we all know
that shared memory is one of the main problems with OS/2.
...snip...
>
> Boot is on the SSD. The 1 TB disk holds data. The 200 GB disk is
> Windows. I have JFS volumes on the 1 TB drive.
> --
> Bill
> <Thanks, a Million>
The bottom line is, that I have abandoned HPFS in favor of JFS, and it
would take some serious argument to make me go back.
I should note, that the JFS that was produced by IBM is not really
safe to use with more than 64 meg of cache (and it is not bootable).
It is also not safe to use more than 64 meg of cache, without one of
the very latest JFS versions (available with eCS Software
Subscription, before eCS 2.0 GA comes out). However, 64 meg of cache
is a definit performance boost over 2 meg of cache.
Just my $.02
--
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
Trevor Hemsley
<wlhar...@tx.rr.com> wrote:
> I understand that some think using JFS as their primary boot disk is
> cool, but it is plain not smart. With JFS block size being 4Kay bytes
> and most files on OS/2--eCS boot volume smaller than than 1 kay bytes,
> the waste of disk space is huge.
Your boot drive is different to mine then. Excluding 0 byte files, I have 6951
files and
1853 of those are < 1024 bytes
1300 are between 1024 and 3584
3798 are > 3584 bytes
The vast majority of files less than 4KB are trivial things like mouse pointers
and files under my \netscape directory (4.61 I think which I still keep lying
around because feature installer requires it).
According to my calculations, if the same size files were on a JFS disk with 4KB
block size then they'd be wasting around 10% of the allocated space.
--
Trevor Hemsley, Brighton, UK
Trevor dot Hemsley at ntlworld dot com
Dave Yeo
> I have also found that the initial CHKDSK that occurs
> after a crash, almost never finds anything to "fix", while it almost
> always "fixes" something on an HPFS drive. True, the JFS CHKDSK can
> take a little longer, if it does find something to investigate, but it
> rarely does (perhaps one crash/boot in 1000).
>
The current hard disk drive is: J:
The type of file system for the disk is JFS.
The JFS file system program has been started.
CHKDSK Block size in bytes: 4096
CHKDSK File system size in blocks: 15677424
CHKDSK *Phase 0 - Replay Journal Log
CHKDSK *Phase 1 - Check Blocks, Files/Directories, and Directory Entries
JFS0148: CHKDSK Unrecoverable error reading M from j:. CHKDSK CANNOT
CONTINUE.
...|.....
>chkdsk h: /f
The current hard disk drive is: H:
The type of file system for the disk is JFS.
The JFS file system program has been started.
CHKDSK Block size in bytes: 4096
CHKDSK File system size in blocks: 4094559
CHKDSK *Phase 0 - Replay Journal Log
CHKDSK *Phase 1 - Check Blocks, Files/Directories, and Directory Entries
CHKDSK *Phase 2 - Count Links
CHKDSK *Phase 3 - Rescan for Duplicate Blocks and Verify Directory Tree
CHKDSK *Phase 4 - Report Problems
CHKDSK *Phase 5 - Check Connectivity
CHKDSK *Phase 7 - Rebuild File/Directory Allocation Maps
CHKDSK *Phase 8 - Rebuild Disk Allocation Maps
JFS0148: CHKDSK Unrecoverable error reading M from h:. CHKDSK CANNOT
CONTINUE.
Dave
Mike O'Connor
Hi Dave,
Did you do a LONG-format on those two volumes** when they were created.
Try disabling them in config.sys - autocheck only specific other
volumes, not using "*", then when system booted run "chkdsk J: /F:3".
I have found that that will clear up that sort of previous result.
If you have a SSS with Mensys, the later faster format/PMformat are 6x
faster (on the restricted Betazone).
** I always do, whether JFS or HPFS!
Regards,
Mike
Doug Bissett
wrote:
I am not sure what that is trying to tell you. Let's start with:
What version of JFS do you have installed?
What version of JFS were you using when you formatted the volumes?
There was a version from IBM, some time ago, that created something
incorrectly, and the volumes had to be reformatted to fix the problem,
after the driver was updated.
Have you tried a recent version of DFSEE, to see if that finds
something?
There is also a problem if you have more than 24(?) drive letters,
that should be fixed by the latest JFS from eCS Software Subscription.
inv...@invalid.invalid
> cool,
After bad experiences with HPFS as boot disk and the dirty flag beeing
set after a crash, I went back to a FAT boot partition. After a crash,
I do not need a CHKDSK from floppy.
Also, in case of system problem, I can boot from floppy and correct
the problem.
JMS
Dave Yeo
E:\OS2>bldlevel JFS.IFS
Build Level Display Facility Version 6.10.480 Oct 6 2000
(C) Copyright IBM Corporation 1993-2000
Signature: @#IBM:14.105#@ IBM OS2 JFS retail bld
Vendor: IBM
Revision: 14.105
File Version: 14.105
Description: IBM OS2 JFS retail bld
>
> What version of JFS were you using when you formatted the volumes?
Same.
> There was a version from IBM, some time ago, that created something
> incorrectly, and the volumes had to be reformatted to fix the problem,
> after the driver was updated.
>
> Have you tried a recent version of DFSEE, to see if that finds
> something?
It crashes on my main volume with a trap E in OS2DSAD.DMD. Running it on
my maintainence partition it will clean things up so sometimes I can
mount the partitions then these errors come back.
I think this is a symptom of a sick drive, so while I have backed up
everything important there is still more stuff that I'd like to get off
of it (MP3's, some source code, things that are easy to replace but
easier to xcopy).
Unluckily my attempt to use a SATA drive on this old system has been a
failure so far.
Dave
Dave
William L. Hartzell
Ilya Zakharevich wrote:
> [A complimentary Cc of this posting was sent to
> William L. Hartzell
> <wlhar...@tx.rr.com>], who wrote in article<Wr-dndDpQoPMyXrW...@mozilla.org>:
>> I understand that some think using JFS as their primary boot disk is
>> cool, but it is plain not smart.
>
> Might be, but who cares? What I wrote had no relationship to "using
> JFS as a primary boot disk".
>
>> I've come to the conclusion that with some SATA drives being over
>> ten times faster than IDE drives of five years ago, that good old
>> HPFS is the only way to go.
>
> Using HPFS with larger than 1.5TB of storage is just "simply out of
> the question".
I think you are real lucky to have a 1.5 TB volume using HPFS. Where
can I get this driver? :-/ Truth is my really large volumes are on my
Samsung drive and is is not a SSD; thus I do use JFS. I do have a 20
GiB volume of Applications on the SSD and it is HPFS. The slowest part
of the boot process is for the two drivers to find the volumes on the
Samsung, not the check disk operation. Here I blame the LVM manager and
I have no multi-partition volumes. Does not help that the LVM manager
is checking the Win 7 drive, which it cannot read. I think Microsoft
has already gone over to UEFI disk format when it can, and which is
mandatory (in Win 7) for larger than 2.2 TB disks. Hint to all who have
Win 7 on a separate disk, Boot Manager will show "--> LVM", which is the
Win 7 restore partition. DO NOT EVER CLICK upon it. You will have to
re-install Win 7 if you do! Do not even attempt to hide it or assign a
drive letter to it. You'll have the Same problem. I've installed Win 7
six times testing this! And this is the reason that I believe Microsoft
is using the UEFI disk format.
>
> Myself, I boot from, keep programs, and keep "hot" non-MM data on
> HPFS. The rest goes to JFS. And:
>
> I saw MUCH more problems with JFS in 2-3 years of usage than I
> EVER saw with HPFS;
>
> on the other hand, my data acquisition rate now is SEVERAL orders of
> magnitude more than what I had on HPFS;
>
> so it may be just "more data, more data loss" logic, not "HPFS is
> more reliable than JFS" one.
Agree.
Steven Levine
wrote:
Hi Dave,
> CHKDSK *Phase 1 - Check Blocks, Files/Directories, and Directory Entries
> JFS0148: CHKDSK Unrecoverable error reading M from j:. CHKDSK CANNOT
> CONTINUE.
This a nasty one. What it says is that chkdsk failed attempting to
read some type of meta data. There are a couple of these awaiting my
attention in the eCS Bugtracker, but they will have to wait until
after eCS 2.0 goes GA.
The error can occur for a number of reasons. The most likely is
corrupted data in some other block that resolves to a illegal disk
block address.
What you might try is the undocumented /D parameter and see if this
provides any clues as to what the actual bad block address is.
> CHKDSK *Phase 8 - Rebuild Disk Allocation Maps
> JFS0148: CHKDSK Unrecoverable error reading M from h:. CHKDSK CANNOT
> CONTINUE.
Very odd. Hard to say how both volumes got corrupted at the same
time.
As others have recommended, dfsee might be able to find the bad
metadata.
Steven
--
---------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
William L. Hartzell
Mike O'Connor wrote:
> On 2010-05-10 10:33 (AEST), William L. Hartzell wrote:
>> Sir:
> <snipped>
>
>> I understand that some think using JFS as their primary boot disk is
>> cool, but it is plain not smart. With JFS block size being 4Kay bytes
>> and most files on OS/2--eCS boot volume smaller than than 1 kay bytes,
>> the waste of disk space is huge. This adds to the boot time as there is
>> more real estate on the drive to cover to get the data. I've come to the
>> conclusion that with some SATA drives being over ten times faster than
>> IDE drives of five years ago, that good old HPFS is the only way to go.
>> Here from Trevor's Sysbench are results from my old Athlon XP 2000
>> machine, along with someone else's machine, and my current Phenom2
>> machine:
>> --------- Athlon XP ---------
>> Disk I/O disk 0-1: 38162 MB - WDC WD400BB-32AUA1
> <snipped>
>
> Total : 325.879 Disk I/O-marks
>>
>> Boot is on the SSD. The 1 TB disk holds data. The 200 GB disk is
>> Windows. I have JFS volumes on the 1 TB drive.
> Hi Bill,
>
> Although it's true JFS has 4KB blocks, as the default, for smaller files
> it re-uses "free" space within that already allocated in a granular
> manner, so there is no problem of huge waste!
>
You have a different JFS driver than I. I am using the last one
released by Scott G. I had my Mozilla repository on JFS. When I switch
to HPFS for it, the space consumed dropped 60%. (Went from an
out-of-space condition to 60% free using the same size volume.)
> I boot exclusively with JFS here, and have been doing so since September
> 2004, and on the very rare occasion that a catastrophy has happened,
> I've been able to recover the data successfully.
> I don't have any volumes that span disks, or even multiple partitions on
> one disk. Any time there has to be a dirty shutdown (e.g. Mozilla hard
> lockups), the JFS volumes (up to 30 bootable on this system [many have
> to be "hidden from OS/2" due only 21 volume-letters normally available
> for HDD volumes, due A,B,S,Z & R (Ramdisk)]) all come up clean, whilst
> all HPFS volumes have to have a full chkdsk!
> I also always long-format all of my volumes, whether HPFS or JFS, and
> now with the two-pass (format + verify) 6x faster jfsfmt32.exe, that's
> much less of a pain for large data volumes!
>
The point I am making is SSD are so much faster than spinning disks,
this fact alone has made chkdsk times moot for volumes on the SSD.
Also, I believe you do NOT need to long format SSD. SSD will on itself,
clear space not used when you delete a partition or create a partition
and would do so for existing partitions if OS/2's various file drivers'
format function used the trim command (does jfsfmt32 use the trim
command?). Thus, I delete the partition and create it on the SSD: Much
faster than a long format, even on a SSD. I'm tooting the horn for SSD.
Consider them for your next disk purchase. Just think that 256GiB
drives were not all that common the last time OS/2 was updated by IBM.
SSD of that size are comparable in cost to the 200GB drives of 2002.
William L. Hartzell
To come back to this, can you do an experiment for us? On a disk
allocate a one GiB partition. Format it HPFS and xcopy your boot drive
there. On the same disk to eliminate disk geometry differences,
allocate another one GiB partition. Format if JFS and xcopy the same
boot drive there. Run chkdsk on both and report the quantity of free
space on both. The differences should be only due to the block size of
the two file systems. Double check that the same number of files are
copied (Xcopy reports this).
Paul Ratcliffe
<ste...@nomail.earthlink.net> wrote:
>> CHKDSK *Phase 8 - Rebuild Disk Allocation Maps
>> JFS0148: CHKDSK Unrecoverable error reading M from h:. CHKDSK CANNOT
>> CONTINUE.
>
> Very odd. Hard to say how both volumes got corrupted at the same
> time.
>
> As others have recommended, dfsee might be able to find the bad
> metadata.
This happened to me a few years ago and it was a right struggle to
recover from. I ended up using DFSEE to mark the volume as clean and
it then mounted OK - this was on a spanned volume created out of 2
partitions which was even more of a worry (I forget the exact detail now).
I managed to XCOPY most stuff onto various other drives as I didn't
have enough space anywhere for the whole contents of the defective one.
Then I just long formatted it and copied everything back eventually.
Doug Bissett
wrote:
> Doug Bissett wrote:
...snip...
> >
> > I am not sure what that is trying to tell you. Let's start with:
> >
> > What version of JFS do you have installed?
>
> E:\OS2>bldlevel JFS.IFS
> Build Level Display Facility Version 6.10.480 Oct 6 2000
> (C) Copyright IBM Corporation 1993-2000
> Signature: @#IBM:14.105#@ IBM OS2 JFS retail bld
> Vendor: IBM
> Revision: 14.105
> File Version: 14.105
> Description: IBM OS2 JFS retail bld
That seems to be the latest IBM version...
> > What version of JFS were you using when you formatted the volumes?
>
> Same.
Okay, that leaves out the old version prooblem...
>
> > There was a version from IBM, some time ago, that created something
> > incorrectly, and the volumes had to be reformatted to fix the problem,
> > after the driver was updated.
> >
> > Have you tried a recent version of DFSEE, to see if that finds
> > something?
>
> It crashes on my main volume with a trap E in OS2DSAD.DMD. Running it on
> my maintainence partition it will clean things up so sometimes I can
> mount the partitions then these errors come back.
> I think this is a symptom of a sick drive, so while I have backed up
> everything important there is still more stuff that I'd like to get off
> of it (MP3's, some source code, things that are easy to replace but
> easier to xcopy).
It certainly dosn't sound good...
> Unluckily my attempt to use a SATA drive on this old system has been a
> failure so far.
If it is an old system, I suspect that you might be better off to stay
with an IDE drive.
...snip...
Dave Yeo
showed up.
Steven Levine wrote:
> On Tue, 11 May 2010 03:49:04 UTC, Dave Yeo<dave....@gmail.com>
> wrote:
>
> Hi Dave,
>
>> CHKDSK *Phase 1 - Check Blocks, Files/Directories, and Directory Entries
>> JFS0148: CHKDSK Unrecoverable error reading M from j:. CHKDSK CANNOT
>> CONTINUE.
>
> This a nasty one. What it says is that chkdsk failed attempting to
> read some type of meta data. There are a couple of these awaiting my
> attention in the eCS Bugtracker, but they will have to wait until
> after eCS 2.0 goes GA.
>
> The error can occur for a number of reasons. The most likely is
> corrupted data in some other block that resolves to a illegal disk
> block address.
>
> What you might try is the undocumented /D parameter and see if this
> provides any clues as to what the actual bad block address is.
Interesting, the volumes ended up being mounted with /D, excepting W:
where chkdsk complains about checking a mounted volume but get the drive
was improperly stopped dialog.
H: ends with
(chklog) CHKDSK Unrecoverable error reading M from h:. CHKDSK CANNOT
CONTINUE.
(chklog) CHKDSK Fatal error (-10093,23) accessing the filesystem
(1,1867776,16384,16384).
(chklog) CHKDSK processing terminated: 5/12/108.2.35 with return code:
-10093.
(chklog) CHKDSK DosClose returned rc = 0
J:
(chklog) CHKDSK Unrecoverable error reading M from j:. CHKDSK CANNOT
CONTINUE.
(chklog) CHKDSK Fatal error (-10015,23) accessing the filesystem
(1,7974912,16384,0).
(chklog) CHKDSK processing terminated: 5/12/1015.38.23 with return code:
-10015.
(chklog) CHKDSK DosClose returned rc = 0
W: and V: are similar to J:
>
>> CHKDSK *Phase 8 - Rebuild Disk Allocation Maps
>> JFS0148: CHKDSK Unrecoverable error reading M from h:. CHKDSK CANNOT
>> CONTINUE.
>
> Very odd. Hard to say how both volumes got corrupted at the same
> time.
Actually all 4 on the hard drive which seems to be dieing. I've stopped
using the drive even though the HPFS partitions seem fine, just haven't
got around to replacing it yet.
>
> As others have recommended, dfsee might be able to find the bad
> metadata.
After trying to use dfsee to check the partitions a couple of times
(dfsee reported success) now I get a trap E in os2dasd while dfsee is
loading. Dfsee still works fine from my maintainence partition even
though everything is the same level.
Anyways the /D seems to mount most of the partitions and even though all
the important stuff is backed up, there's some other stuff I'd like to
xcopy from the broken partitions.
Dave
Mike O'Connor
> Sir:
>
<SNIPPED>
> To come back to this, can you do an experiment for us? On a disk
> allocate a one GiB partition. Format it HPFS and xcopy your boot drive
> there. On the same disk to eliminate disk geometry differences, allocate
> another one GiB partition. Format if JFS and xcopy the same boot drive
> there. Run chkdsk on both and report the quantity of free space on both.
> The differences should be only due to the block size of the two file
> systems. Double check that the same number of files are copied (Xcopy
> reports this).
> --
> Bill
> <Thanks, a Million>
Bill,
Don't need to - I already know from previous testing that converting an
HPFS volume to JFS-bootable results in a maximum of approximately 5%
additional space allocated, which I'm willing to trade against the
massive cache and speed increase.
I never, ever use xcopy.exe - I use zip (-rS), as I can and always do
validate it both as a complete archive with zip.exe, and also with unzip
as individual files, and then generate a listing file from unzip. I keep
a template of a universal command-file to perform all above operations,
with pauses on completion of each operation.
When, prior to the official release of bootable JFS, I was converting
pre-installed HPFS-formatted boot volumes to JFS, I zipped the HPFS
volume, long formatted the partition as JFS, sysinstx'd it as JFS, then
unzipped all but the os2boot (updated by sysinstx) back to it.
Mike
Ilya Zakharevich
William L. Hartzell
> > Using HPFS with larger than 1.5TB of storage is just "simply out of
> > the question".
> I think you are real lucky to have a 1.5 TB volume using HPFS. Where
> can I get this driver?
Ships starting with OS/2 v1.1, IIRC.
> I have no multi-partition volumes. Does not help that the LVM manager
> is checking the Win 7 drive, which it cannot read. I think Microsoft
> has already gone over to UEFI disk format when it can, and which is
> mandatory (in Win 7) for larger than 2.2 TB disks. Hint to all who have
> Win 7 on a separate disk, Boot Manager will show "--> LVM", which is the
> Win 7 restore partition. DO NOT EVER CLICK upon it. You will have to
> re-install Win 7 if you do! Do not even attempt to hide it or assign a
> drive letter to it. You'll have the Same problem.
I suspect the fix must be very simple: upgrade to FDISK-based partitioning...
Yours,
Ilya
P.S. 64GB*(26-2) ~ 1.5TB
William L. Hartzell
The reason I asked is I am wonder about your statement that the newer
JFS driver sub allocates files within blocks. I would think that would
be very much work for little gain.
William L. Hartzell
There is a problem with fdisk on disk with size in excess of 2.2
trillion bytes. It seems that according to Microsoft, et al. that fdisk
tables won't span the drive. If Microsoft has not embraced and extended
Intel's UEFI disk format, 128 visible partitions can be created with the
new disk setup. Since I gave Win 7 the entire disk, Microsoft has the
right to do whatever it wants thereon, even though it is only 200
billion bytes. I am not going back just to fix this. However, I'll
keep this in mind if I ever have to do seventh install of Win 7. PS.
Still won't be able to boot Win 7 from Boot Manager from one attempt to
install Win 7 at the end of the 1 TB drive. Barf-ville. Both systems
fought over the MBR, not to mention that OS/2 won't boot from a 1 TB
drive (seems to hang in the boot loader). Still won't with OS/2 on the
200 GB drive. It is one of the reasons that I purchased the SSD, then
cleared off the 200 GB drive. With Win 7 on a separate disk, I can do
the BIOS who's-on-first with the disk order to boot either. ( I am
leaving out the fact that I trashed my first SSD and the 1 TB drive by
mispluging the modular power cable.)
Steven Levine
wrote:
Hi Dave,
> Strange, I posted 2 responses to this thread yesterday and they never
> showed up.
You might check google groups to see if they got posted.
> Interesting, the volumes ended up being mounted with /D, excepting W:
> where chkdsk complains about checking a mounted volume but get the drive
> was improperly stopped dialog.
> H: ends with
> (chklog) CHKDSK Unrecoverable error reading M from h:. CHKDSK CANNOT
> CONTINUE.
> (chklog) CHKDSK Fatal error (-10093,23) accessing the filesystem
> (1,1867776,16384,16384).
> (chklog) CHKDSK processing terminated: 5/12/108.2.35 with return code:
> -10093.
> (chklog) CHKDSK DosClose returned rc = 0
You need to boot to a maintenance setup that does not mount anything
but the boot volume.
A bit of digging through the code and the gory details are revealed.
FWIW, this part of the code is mostly unchanged compared IBM's GPL
release of JFS.
> (chklog) CHKDSK Fatal error (-10093,23) accessing the filesystem
> (1,1867776,16384,16384).
This says you got a crc error (i.e. 23) attempting to read 16384 bytes
from block#1867776 which confirms that the drive or cabling has
issues.
> Anyways the /D seems to mount most of the partitions and even though all
> the important stuff is backed up, there's some other stuff I'd like to
> xcopy from the broken partitions.
It's interesting that /D has this effect. Perhaps it changes the
timing in some way that allows more of the I/O to succeed. I don't
recall that /D relaxes the rules for allowing the mount to occur.
Mike O'Connor
> There is a problem with fdisk on disk with size in excess of 2.2
> trillion bytes. It seems that according to Microsoft, et al. that fdisk
> tables won't span the drive. If Microsoft has not embraced and extended
> Intel's UEFI disk format, 128 visible partitions can be created with the
> new disk setup. Since I gave Win 7 the entire disk, Microsoft has the
> right to do whatever it wants thereon, even though it is only 200
> billion bytes. I am not going back just to fix this. However, I'll keep
> this in mind if I ever have to do seventh install of Win 7. PS. Still
> won't be able to boot Win 7 from Boot Manager from one attempt to
> install Win 7 at the end of the 1 TB drive. Barf-ville. Both systems
> fought over the MBR, not to mention that OS/2 won't boot from a 1 TB
> drive (seems to hang in the boot loader). Still won't with OS/2 on the
> 200 GB drive. It is one of the reasons that I purchased the SSD, then
> cleared off the 200 GB drive. With Win 7 on a separate disk, I can do
> the BIOS who's-on-first with the disk order to boot either. ( I am
> leaving out the fact that I trashed my first SSD and the 1 TB drive by
> mispluging the modular power cable.)
> --
> Bill
> <Thanks, a Million>
Bill,
I have booted Warp4 from a primary partition 200GB into a 250GB SATA
disk, with it on the IBM BM Menu, so above is a load of rubbish!
I can send you the FDISK output on it if you want, as seen by Warp4,
also the view of it from the eCS Installation Volume Manager!
It was documented by IBM in the os2dasd.dmd docs several years ago that
there is a limitation of 512GB on bootable-OS/2 volumes, a 1TB or larger
disk can be used to boot from, with the /BOOTABLE switch, but the
balance beyond 512GB will not be usable.
Mike
Mike O'Connor
> The reason I asked is I am wonder about your statement that the newer
> JFS driver sub allocates files within blocks. I would think that would
> be very much work for little gain.
> --
> Bill
> <Thanks, a Million>
Bill,
I didn't say that was only with newer JFS drivers. It's always been that
way. Read the documentation.
Mike
Mike O'Connor
<snipped>
> You have a different JFS driver than I. I am using the last one released
> by Scott G. I had my Mozilla repository on JFS. When I switch to HPFS
> for it, the space consumed dropped 60%. (Went from an out-of-space
> condition to 60% free using the same size volume.)
Scott's driver has long been superseded (years), both for additional
features and bugs existing in it. and has been incorporated in all
editions of eComStation for a number of years.
Revisiting the above, did you perchance have the JFS filesystem set up
as a "sparse" filesystem? That feature was intended for use in database
situations, and pre-allocated space within the filesystem, based upon
the intended size of the database, irrespective of possibly having only
a minute fraction of it actually populated with records.
HPFS doesn't have that facility, and accordingly if your JFS filesystem
was set-up in such a manner, yes, you would have an apparently very
large increase of available space on the replacement HPFS filesystem.
Mike
Dariusz Piatkowski
<dariusz@_NO-SPAM_mnsi.net> wrote:
> Here are a few remarks regarding stability, I run my system with virtualaddress
> set to 2048 normally. But with this version within 1 day PMMail closes and
> leaves a zombie process running which can not be killed (reboot is the only way
> to cure this). This also occurs with 3.5.9...but not for about 4-5 days of
> normal usage. In addition to this, the overall system stability seems to have
> decreased...I am basing this on the amount of other apps shutting down
> unexpectedly.
>
> So...to test I dropped the setting to 1536...stability increased, PMMail is
> still affected but not until day 2 or 3, other unexplained crashes seem to have
> gone away.
>
> I will try 1024 next.
Well, got an incredibly nice uptime of about 20 days (day to day usage of the
WPS, etc)...which is quite a bit more robust then the typical 5-7 days I have
seen in the past.
I am now running with 1024 just to see if there is any real difference.
Dave Yeo
Running SeaMonkey 2.1a2pre with all of the fixes that are in 3.7a4pre
I'm finding my system is more stable then it has been since NS 4.61 came
out. For years I consistently was lucky to get 10 days uptime before
things got flaky and the WPS would freeze as well as certain other
applications no longer launching.
Right now I'm on day 12 and things are still very stable.
This is with virtualaddress set to 1536.
Dave
William L. Hartzell
I have booted MCP from all over the place on my 200 GB drive. It does
not matter if it is primary or not. I don't know where you get any
statement from my earlier post for you make or assume that I said that
one could not boot under 512 GB. It matters not if it is a SATA or not.
Have you tried using FDISK on a disk that was larger than 2.2 TB in
size? You do know that Tb is larger than GB? There are now a few disks
that are larger than 2.2 TB in size. Also there is no where in my above
statement that says that I could not boot OS/2 using BOOT MANAGER when
it was in an useable location. I did say DON'T try to boot Win 7 with
it in circumstances that match what I tested.
>
> It was documented by IBM in the os2dasd.dmd docs several years ago that
> there is a limitation of 512GB on bootable-OS/2 volumes, a 1TB or larger
> disk can be used to boot from, with the /BOOTABLE switch, but the
> balance beyond 512GB will not be usable.
>
Did you not just confirm what I said? The 512 GiB limitation applies to
the location of the bootable volume on an oversized disk, not its boot
partition size,if any wants to misconstrue that. The boot sequence did
not even get to the loading of OS2DASD.DMD, it did not even get to the
loading of the basedevs. It got to a leading underscore and a black
screen, even with ALTF2ON.$$$ in the root of boot. Since the last time
we had a location/size of drive issue, it was the bootloader that was
fixed, that is what I assume is wrong now, since I had attempted to use
a primary partition near the start of 1 TB disk, a partition only 1 Gb
in size. BTW, what /BOOTABLE switch does is change the geometry of the
drive so that it is only 512 GiB in useable size, not stop access at 512
GiB limit with the great unknown beyond. I know this from attempting to
clone my 200 GB drive onto the 1 TB drive. FDISK will create partitions
all over that 1 TB drive without changing the geometry from one that
will show 1 TB drive size. And format will install file systems onto
every partition. Just don't try to make any of them OS/2 bootable.
William L. Hartzell
I did not use any allocation sparse, don't think the IBM version of JFS
ever could do that.
William L. Hartzell
Care to load a test version of Seamonkey as you describe to Netlabs?
Dave Yeo
> Care to load a test version of Seamonkey as you describe to Netlabs?
> --
Actually I was just updating the tree thinking of doing that. One thing
is that the last couple of personal builds I've done have had
ac_add_options --enable-optimize=-march=athlon
which of course is only good for us Athlon users. I don't know if this
has helped stability (instructions being aligned is one possible benefit
I could imagine).
I'm wondering if we should optimize for something better then an i386.
While i486 would be the most compatible I was thinking that perhaps P5
would be a good compromise for all the different CPU's.
Dave
ps Will take a day or more including testing locally.
Mike O'Connor
Bill,
You know what thought did!
Who do you think wrote JFS, and JFS2 for AIX, on which eCS(OS/2) JFS is
based, and specifically included that feature? It wasn't the FOSS people
who had it donated to them by IBM, if that's what you are basing your
knowledge on.
From some of your statements, it seems to me like you know nothing
whatsoever about JFS for OS/2 or eCS, so why don't you invest some time
in reading all the information freely available in eCS/MCPx/ACPx, and on
the www.
Mike
Ilya Zakharevich
William L. Hartzell
> There is a problem with fdisk on disk with size in excess of 2.2
> trillion bytes.
The correct limit is 2^32 sectors = 2TiB. But I have not yet seen
individual disks of more than 2TB capacity; so currently the limit is
applicable only to hardware RAID configurations. Does not worry me -
for a year or more... Anyway, LWM on OS/2 has the same limitation, AFAIK...
Yours,
Ilya
Ilya Zakharevich
<maj...@gmail.com>], who wrote in article <EJCdnZ8MhJ7MqnDW...@mozilla.org>:
> Revisiting the above, did you perchance have the JFS filesystem set up
> as a "sparse" filesystem? That feature was intended for use in database
> situations, and pre-allocated space within the filesystem, based upon
> the intended size of the database, irrespective of possibly having only
> a minute fraction of it actually populated with records.
>
> HPFS doesn't have that facility, and accordingly if your JFS filesystem
> was set-up in such a manner, yes, you would have an apparently very
> large increase of available space on the replacement HPFS filesystem.
Your arguments looks very much reversed... Anyway, I won't think that
copying using OS/2 software would preserve sparsity of files...
Yours,
Ilya
Mike O'Connor
(as previously sent via PM, which I 'assumed' from the headers would
make its way here too)
Hi Ilya,
You're right of course on both points. I shouldn't respond to postings
at the end of a 36-hour 'day'.
Regards,
Mike
Mike O'Connor
> Sir:
> Mike O'Connor wrote:
>
>> Bill,
>
>> I have booted Warp4 from a primary partition 200GB into a 250GB
>> SATA disk, with it on the IBM BM Menu, so above is a load of
>> rubbish!
>> I can send you the FDISK output on it if you want, as seen by
>> Warp4,
>> also the view of it from the eCS Installation Volume Manager!
> I have booted MCP from all over the place on my 200 GB drive.
> It does not matter if it is primary or not. I don't know where
> you get any statement from my earlier post for you make or assume
> that I said that one could not boot under 512 GB.
Well, what is one supposed to make of your previous statement in this
thread:
>>> not to mention that OS/2 won't boot from a 1 TB drive
>>> (seems to hang in the boot loader).
>>> Still won't with OS/2 on the 200 GB drive.
> It matters not if it is a SATA or not.
Even SCSI too. Did you think I didn't know that? I only mentioned
SATA as my 250GB Samsung disk is the only one I have that is roughly
equivalent to the 200GB disk you mentioned:
"Still won't with OS/2 on the 200 GB drive".
My next largest is (only!) a Seagate 120GB (PATA), and I wasn't
inferring that it could be accomplished only when using SATA.
I did that test with Warp4FP15, 4 years ago, because <someone> on
the OS/2 groups/lists said it wasn't possible to do so, and I knew
it was, and proved it.
> Have you tried using FDISK on a disk that was larger than 2.2 TB in size?
As Ilya said there aren't any currently, and you have the OS/2 size limit
wrong!
I only mentioned using FDISK in the context of my test, as FDISK does
not run under eComStation or MCP2 or ACP2, when LVM is installed, and
I provided it's "/query" output list to verify that it was indeed running.
Apart from that test I have never used FDISK since 2000, prior to
installing original MCP, so I don't know why you are still using and
quoting it.
> You do know that Tb is larger than GB?
Oh yes. If we want to be pedantic, it's 128 times larger as 1 x Tb =
12.5% x 1TB.
> There are now a few disks that are larger than 2.2 TB in size.
Can you quote any? More importantly do you need one that size?
if so I suggest that you refer to the following from IBM:
(IBMiSCSIBootCommander_v3.1.4_setupwin32.msi)
(iSCSI_Boot_Commander_Tutorial_314.pdf)
(ReadMe_v3.1.4.HTML) below - ultra long URL!
and also read the article at the following URL:
http://ask.slashdot.org/story/10/05/14/2355207/Best-Solutions-For-Massive-Home-Hard-Drive-Storage
and note the helpful suggestions in the associated comments!
> Also there is no where in my above statement that says that
> I could not boot OS/2 using BOOT MANAGER when it was in an
> useable location.
And what do you define as a usable location?
> I did say DON'T try to boot Win 7 with it in circumstances
> that match what I tested.
I have absolutely zero intention of _ever_ installing/booting
_Win7_!
I use eCS|OS/2!
>
>> It was documented by IBM in the os2dasd.dmd docs several
>> years ago that there is a limitation of 512GB on
>> bootable-OS/2 volumes, a 1TB or larger disk can be used
>> to boot from, with the /BOOTABLE switch, but the balance
>> beyond 512GB will not be usable.
>
> Did you not just confirm what I said?
Definitely not!
> The 512 GiB limitation applies to the location of the
> bootable volume on an oversized disk, not its boot
> partition size,if any wants to misconstrue that.
I said absolutely nothing about boot partition sizes whatsoever.
> The boot sequence did not even get to the loading of
> OS2DASD.DMD, it did not even get to the loading of the
> basedevs. It got to a leading underscore and a black
> screen, even with ALTF2ON.$$$ in the root of boot.
So why should we be surprised at that, in view of the
documented os2dasd.dmd switches from 2006?. altf2on.$$$
isn't going to make any difference, if you don't get to
the Blob!
> Since the last time we had a location/size of drive
> issue, it was the bootloader that was fixed, that is
> what I assume is wrong now, since I had attempted to
> use a primary partition near the start of 1 TB disk,
> a > partition only 1 Gb in size.
The limitation without switches was 512GB, not twice that!
> BTW, what /BOOTABLE switch does is change the geometry
> of the drive so that it is only 512 GiB in useable size,
> not stop access at 512 GiB limit with the great unknown
> beyond.
I haven't had the opportunity to examine the revised
geometry, but whether it just limits the maximum 48-bit
LBA to the equivalent of 512GB, or accesses the drive's
firmware registers to set them to that same value, I
don't know.
> I know this from attempting to clone my 200 GB drive
> onto the 1 TB drive. FDISK will create partitions all
> over that 1 TB drive without changing the geometry
> from one that will show 1 TB drive size.
Why are you still persisting with using last century's
FDISK in this LVM (volume) era?
> And format will install file systems onto every
> partition.
Possibly - I don't have the wherewithal to check that statement.
> Just don't try to make any of them OS/2 bootable.
I wouldn't _ever_ consider it in the first place, even
if I deemed it necessary to have a 1TB disk, which I
don't personally, as if I had such a disk I'd use it
for data storage, not for booting from!
Regards,
Mike
Dave Yeo
> On Thu, 13 May 2010 02:47:13 UTC, Dave Yeo<dave....@gmail.com>
> wrote:
>
> Hi Dave,
>
>> Strange, I posted 2 responses to this thread yesterday and they never
>> showed up.
>
> You might check google groups to see if they got posted.
Rebuilding the summary fixed it.
>
>> Interesting, the volumes ended up being mounted with /D, excepting W:
>> where chkdsk complains about checking a mounted volume but get the drive
>> was improperly stopped dialog.
>> H: ends with
>> (chklog) CHKDSK Unrecoverable error reading M from h:. CHKDSK CANNOT
>> CONTINUE.
>> (chklog) CHKDSK Fatal error (-10093,23) accessing the filesystem
>> (1,1867776,16384,16384).
>> (chklog) CHKDSK processing terminated: 5/12/108.2.35 with return code:
>> -10093.
>> (chklog) CHKDSK DosClose returned rc = 0
>
> You need to boot to a maintenance setup that does not mount anything
> but the boot volume.
I'll try this later.
>
> A bit of digging through the code and the gory details are revealed.
> FWIW, this part of the code is mostly unchanged compared IBM's GPL
> release of JFS.
Probably why the Linux version spat out almost exactly the same message.
>
>> (chklog) CHKDSK Fatal error (-10093,23) accessing the filesystem
>> (1,1867776,16384,16384).
>
> This says you got a crc error (i.e. 23) attempting to read 16384 bytes
> from block#1867776 which confirms that the drive or cabling has
> issues.
Well I picked up a new 160 GB replacement, just have to install and move
everything.
I'd think that a bad cable would give random errors whereas my errors
are pretty consistent.
>
>> Anyways the /D seems to mount most of the partitions and even though all
>> the important stuff is backed up, there's some other stuff I'd like to
>> xcopy from the broken partitions.
>
> It's interesting that /D has this effect. Perhaps it changes the
> timing in some way that allows more of the I/O to succeed. I don't
> recall that /D relaxes the rules for allowing the mount to occur.
I did screw up and only use the /D option instead of /f /D which gave
more info, but definitely after running with /D the drives seem to be
marked clean even though chkdsk still failed.
Dave
Ilya Zakharevich
Mike O'Connor
> > Since the last time we had a location/size of drive
> > issue, it was the bootloader that was fixed, that is
> > what I assume is wrong now, since I had attempted to
> > use a primary partition near the start of 1 TB disk,
> > a > partition only 1 Gb in size.
> The limitation without switches was 512GB, not twice that!
> > BTW, what /BOOTABLE switch does is change the geometry
> > of the drive so that it is only 512 GiB in useable size,
> > not stop access at 512 GiB limit with the great unknown
> > beyond.
>
> I haven't had the opportunity to examine the revised
> geometry, but whether it just limits the maximum 48-bit
> LBA to the equivalent of 512GB, or accesses the drive's
> firmware registers to set them to that same value, I
> don't know.
We had this discussion on Usenet recently. The 512GB statement is
claimed to be a lie. The *real* limitation is 65K cylinders. The
"newer" fdisk's and lvm's know how to "limit" stuff to this; e.g., my
750GB drive (partitioned with FDISK) is shown as
Unit:1 Status:OK SMS:16 LBA BusMaster UltraDMA4/PIO4 BPB
Model:ST3750640A 3.AAE
OS2:log phys BPB/BIOS IDE:log phys Total Sectors
C 45241 65535 65535 16383 Avail 1465149168
H 255 16 255 16 16 OS2 1465129785
S 127 63 127 63 63 % Used 99.99
with DANI drivers. So OS/2 is claimed to be able to boot from such
drives - with S>63 in BPB (note that I did not try to boot from this
drive!). However, other OSes may have problems booting from this
(such as Win*).
Ilya
William L. Hartzell
Thanks. The Pentium is kind of old. Very few of those machine would be
in common use by now. P7/K7 is okay by me. Think all the 64-bit
machines are compatible with them.
Mike O'Connor
Hi Ilya,
Precisely, I thought everyone who knows about disk partitioning already
understood that.
Back in 1979/1980, when I had a 5MB Acropolis disk, I wrote my own
direct disk editor, on an S100-bus CP/M 2.2 system (Vector Graphics MZ
system - 4MHz Zilog Z80A!) in assembler of course. The manual from
Micropolis cost me AU$750!
I was working in those days though! (until I had to resign in October
1995 for medical reasons).
AFAIK Modern Operating systems per se don't use the CHS values in
practice, they all work exclusively on LBA addressing - it's only the
older utilities that do so. However going to the MSFT logic where
cylinders >64K are legal on their later OS versions (Vista/Win7), and
with NTFS using 64-bit addressing, stops them being backward compatible.
OS/2 (eCS) could go that same route, but it would need a considerable
amount of work.
I've no idea what age Bill is, but I'm only 72 and maybe because I've
only been working with communications gear/computers since 1958, I'm
still young enough to migrate to and accept newer & in my opinion better
technologies like LVM, which he doesn't seem to be willing to do.
Regards,
Mike
William L. Hartzell
Mike O'Connor wrote:
<snip>
> I've no idea what age Bill is, but I'm only 72 and maybe because I've
> only been working with communications gear/computers since 1958, I'm
> still young enough to migrate to and accept newer & in my opinion better
> technologies like LVM, which he doesn't seem to be willing to do.
>
Bill is old enough to have work on SAGE. And what does your thread
drift BS have to do with the fact that SSD make the principle touted
advantage for the JFS moot, namely the fast check disk time? Nothing!
Mike O'Connor
bill,
It's not a moot point unless you use 386HPFs, with its similar large
cache to JFs, as HPFS CHKDSK will always take times the time that JFS does.
Not being familiar with SAGE, it was interesting to read on the page at
williamson-labs.com that:
"Today a seven dollar throw-away hand calculator will easily out perform
the SAGE computer; and use watch batteries to do it. --How Things have
Changed!"
Mike
Mike O'Connor
Should have read "many times the time that JFS does"
Mike
Steven Levine
wrote:
Hi Dave,
> I'd think that a bad cable would give random errors whereas my errors
> are pretty consistent.
Probably true.
> I did screw up and only use the /D option instead of /f /D which gave
> more info, but definitely after running with /D the drives seem to be
> marked clean even though chkdsk still failed.
I made a note to review this and document what actually happens.
William L. Hartzell
SAGE was a computer that a thousand people could walk around inside. It
still has something you won't find a seven dollar hand calculator, 3D
displays or bugs that you could physically remove (moths & etc.).
SSD is one large cache. I time it roughly with Win 7 to take eight
seconds to the sign on screen and another four seconds to the desktop
that was visible. And another eight seconds until all the extras to
finish loading. Wish I could say OS/2 loads that fast, but it stops at
OS2LVM.DMD, again checking JFS partitions, and when it does driver
complete processing, and at PMshell load. The desktop loads about as
quickly as Win 7's desktop. I previous speculated what was the slow up
causes: ie. the OS2LVM.DMD was barfing over UEFI drive format, JFS
because all of them are on the spinning disk, the other two are normal
OS/2 slow-ups. OS/2 takes about three minutes assuming clean shutdown.
I'll grant that Win 7 is probably hiding some of its program load with
the sign-on screen, which OS/2 does not have. But even when I set Win 7
to use no password, I didn't see a noticeable increase in time. I am
most definitely going to purchase another SSD to put Win 7 back on, and
I'll try using Windows' fdisk or LVM to partition that drive so that
UEFI will not be installed (not saying that Win 7 will install).
Dave Yeo
> Do you have> 20 partitions (driveletters) active, when all is OK ?
> Your problem sounds exactly like you have that - but IBM's JFS
> drivers have never been able to handle this, and trashes all JFS
> partitions, in such situations.
>
No, I'm pretty sure it's a flaky disk which I'm now in the process of
replacing, partition by partition
Dave
Dave Yeo
> I tested this, creating 3 partitions of 1GB size:
> 1 hpfs
> 1 JFS
> 1 JFS (512 byte block size)
>
> After copying approxx 710MB files from a boot drive to these,
> the number of free bytes is like this:
> HPFS: 287M
> JFS: 264M
> JFS(512): 291M
How much was free before copying the files? IIRC HPFS preallocates space
for subdirectories (also for bad blocks?) which would throw the test off.
>
> As you can see, JFS is always the better choice, you just
> have to adapt it to your needs.
Unluckily anything besides the defaults stops JFS from being cross-platform.
Dave
William L. Hartzell
William L. Hartzell wrote:
<snip>
Somewhere in this thread was mentioned about 3 TB drives not existing.
<http://www.theinquirer.net/inquirer/news/1649131/seagate-confirmed-3tb-drive>
This is a non announcement of 3 TB drive full of FUD. See for yourselves.
Mike O'Connor
Bill,
Read on, thet 3TB will be later this year, they're not in production
yet, and will be followed by 4TB disks!
Mike
Mike O'Connor
> Sir:
> SAGE was a computer that a thousand people could walk around inside.
But don't wear too many layers of clothing!
It
> still has something you won't find a seven dollar hand calculator, 3D
> displays or bugs that you could physically remove (moths & etc.).
>
> SSD is one large cache.
Not comparable to speed of cache memory by a long way!
I time it roughly with Win 7 to take eight
> seconds to the sign on screen and another four seconds to the desktop
> that was visible. And another eight seconds until all the extras to
> finish loading.
Is it completely usable at that stage, like OS/2-eCS, or has the
wait-pointer just stopped showing?
What version of Windows7 is that?
Wish I could say OS/2 loads that fast, but it stops at
> OS2LVM.DMD, again checking JFS partitions, and when it does driver
> complete processing, and at PMshell load. The desktop loads about as
> quickly as Win 7's desktop.
And how many windows partitions are visible on that system to Windows7,
i.e. how many native partitions is it processing?
I previous speculated what was the slow up
> causes: ie. the OS2LVM.DMD was barfing over UEFI drive format, JFS
Is that the 32-bit UEFI or the 64-bit?
> because all of them are on the spinning disk, the other two are normal
> OS/2 slow-ups. OS/2 takes about three minutes assuming clean shutdown.
That's monstrous for OS/2!
> I'll grant that Win 7 is probably hiding some of its program load with
> the sign-on screen, which OS/2 does not have. But even when I set Win 7
> to use no password, I didn't see a noticeable increase in time. I am
> most definitely going to purchase another SSD to put Win 7 back on, and
> I'll try using Windows' fdisk or LVM to partition that drive so that
> UEFI will not be installed (not saying that Win 7 will install).
Does that motherboard have both legacy BIOS and UEFI?
> --
> Bill
> <Thanks, a Million>
Regards,
Mike
Mike O'Connor
>
> I've posted a recent build of the next version of Firefox to my
> website. You can download it from:
> http://e-vertise.com/warpzilla/firefox-37a4pre.zip
>
> This version contains several OS/2 enhancements and fixes:
>
> Enhancements:
> - scrolling should require 25-50% less CPU usage than previously;
> there are other less noticable improvements in display speed
>
> - previously, switching to a new tab before the page loaded
> (i.e. getting a blank screen before anything was displayed)
> consumed an extra 1-3mb of memory for the life of that tab;
> this memory usage has been eliminated
>
> - there's a new OGG decoder as well as changes in the OS/2 audio
> component that make it far less likely that normal system
> activity will interrupt the audio stream
>
> Fixes:
> - users of Matrox video drivers should see a normal, non-slanted
> display; however, video performance will be considerably
> slower/more CPU-intensive than would be the case with SNAP
>
> - users of FlashBlock will no longer see a floating rectangle
> that fails to move or update when scrolling
>
> Please let me know if you see any bugs or have other problems.
>
>
Although originally I had no problem viewing video using the Flash10 TP
I'm now getting a lot of the following - with immediate exits:
> 05-20-2010 22:51:22 SYS3175 PID 0083 TID 0001 Slot 00c2
> K:\FIREFOX-37A4PRE\FIREFOX-37A4PRE\FIREFOX.EXE
> c0000005
> 1020ef49
> P1=00000001 P2=00000000 P3=XXXXXXXX P4=XXXXXXXX
> EAX=00000030 EBX=00000001 ECX=10386444 EDX=00830001
> ESI=00000030 EDI=00000000
> DS=0053 DSACC=f0f3 DSLIM=ffffffff
> ES=0053 ESACC=f0f3 ESLIM=ffffffff
> FS=150b FSACC=00f3 FSLIM=00000030
> GS=0000 GSACC=**** GSLIM=********
> CS:EIP=005b:10212f2b CSACC=f0df CSLIM=ffffffff
> SS:ESP=0053:0011ff64 SSACC=f0f3 SSLIM=ffffffff
> EBP=0011ffb4 FLG=00210206
>
> KERNEL32.DLL 0001:0001ef49
>
> ------------------------------------------------------------
>
> 05-20-2010 22:52:41 SYS3175 PID 0085 TID 0001 Slot 00c8
> K:\FIREFOX-37A4PRE\FIREFOX-37A4PRE\FIREFOX.EXE
> c0000005
> 1020ef49
> P1=00000001 P2=00000000 P3=XXXXXXXX P4=XXXXXXXX
> EAX=00000030 EBX=00000001 ECX=10386444 EDX=00850001
> ESI=00000030 EDI=00000000
> DS=0053 DSACC=f0f3 DSLIM=ffffffff
> ES=0053 ESACC=f0f3 ESLIM=ffffffff
> FS=150b FSACC=00f3 FSLIM=00000030
> GS=0000 GSACC=**** GSLIM=********
> CS:EIP=005b:10212f2b CSACC=f0df CSLIM=ffffffff
> SS:ESP=0053:0011ff64 SSACC=f0f3 SSLIM=ffffffff
> EBP=0011ffb4 FLG=00210206
>
> KERNEL32.DLL 0001:0001ef49
>
> ------------------------------------------------------------
>
> 05-20-2010 22:55:55 SYS3175 PID 0087 TID 0001 Slot 00cb
> K:\FIREFOX-37A4PRE\FIREFOX-37A4PRE\FIREFOX.EXE
> c0000005
> 1020ef49
> P1=00000001 P2=00000000 P3=XXXXXXXX P4=XXXXXXXX
> EAX=00000030 EBX=00000001 ECX=10386444 EDX=00870001
> ESI=00000030 EDI=00000000
> DS=0053 DSACC=f0f3 DSLIM=ffffffff
> ES=0053 ESACC=f0f3 ESLIM=ffffffff
> FS=150b FSACC=00f3 FSLIM=00000030
> GS=0000 GSACC=**** GSLIM=********
> CS:EIP=005b:10212f2b CSACC=f0df CSLIM=ffffffff
> SS:ESP=0053:0011ff64 SSACC=f0f3 SSLIM=ffffffff
> EBP=0011ffb4 FLG=00210206
>
> KERNEL32.DLL 0001:0001ef49
>
> ------------------------------------------------------------
>
> 05-20-2010 22:56:36 SYS3175 PID 0089 TID 0001 Slot 0085
> K:\FIREFOX-37A4PRE\FIREFOX-37A4PRE\FIREFOX.EXE
> c0000005
> 0f43ef49
> P1=00000001 P2=00000000 P3=XXXXXXXX P4=XXXXXXXX
> EAX=00000030 EBX=00000001 ECX=100f6444 EDX=00890001
> ESI=00000030 EDI=00000000
> DS=0053 DSACC=f0f3 DSLIM=ffffffff
> ES=0053 ESACC=f0f3 ESLIM=ffffffff
> FS=150b FSACC=00f3 FSLIM=00000030
> GS=0000 GSACC=**** GSLIM=********
> CS:EIP=005b:0f442f2b CSACC=f0df CSLIM=ffffffff
> SS:ESP=0053:0011ff64 SSACC=f0f3 SSLIM=ffffffff
> EBP=0011ffb4 FLG=00210206
>
> KERNEL32.DLL 0001:0001ef49
>
> ------------------------------------------------------------
>
> 05-20-2010 23:10:01 SYS3175 PID 008c TID 0001 Slot 00ce
> K:\FIREFOX-37A4PRE\FIREFOX-37A4PRE\FIREFOX.EXE
> c0000005
> 1051ef49
> P1=00000001 P2=00000000 P3=XXXXXXXX P4=XXXXXXXX
> EAX=00000030 EBX=00000001 ECX=10616444 EDX=008c0001
> ESI=00000030 EDI=00000000
> DS=0053 DSACC=f0f3 DSLIM=ffffffff
> ES=0053 ESACC=f0f3 ESLIM=ffffffff
> FS=150b FSACC=00f3 FSLIM=00000030
> GS=0000 GSACC=**** GSLIM=********
> CS:EIP=005b:10522f2b CSACC=f0df CSLIM=ffffffff
> SS:ESP=0053:0011ff64 SSACC=f0f3 SSLIM=ffffffff
> EBP=0011ffb4 FLG=00210206
>
> KERNEL32.DLL 0001:0001ef49
Any thoughts/suggestions?
Mike
Mike O'Connor
Dave Yeo
>>
>> KERNEL32.DLL 0001:0001ef49
>
>
> Any thoughts/suggestions?
It is crashing in Odin, so you should file a bug where ever you got Flash.
Dave
Mike O'Connor
Hi Dave,
Close - it's the (BetaZone) eCS Flash10 Technology Preview which has an
\Innowin\ directory branch under \Programs\.
In that Innowin branch in addition to innowin.dll, msvcrt.dll,
iwquery.exe, tzconfig.exe, system.ini, win.ini, readme.txt there is only
the following single file:
[deployment.properties:]
#
# 30 Aug 2009 07:02:57
deployment.javaws.jre.0.registered=true
deployment.javaws.jre.0.platform=1.4
deployment.javaws.jre.0.osname=OS/2
deployment.javaws.jre.0.path=X\:\\PROGRAMS\\JAVA142\\bin\\javaw.exe
deployment.javaws.jre.0.product=1.4.2_09
deployment.javaws.jre.0.osarch=x86
#deployment.javaws.cache.dir=
deployment.javaws.jre.0.enabled=true
---------------
[win.ini]
[windows]
device=FxPrint,Fax,LPT3
---------------
[system.ini]
[mci]
cdaudio=mcicda.drv
---------------
Should there be other entries in the above two - similar to when I had
an ODIN installation (this is in eCSV2.0RC7)?
Regards,
Mike
Peter Brown
Mike O'Connor wrote:
> On 2010-05-21 01:55 (AEST), Dave Yeo wrote:
>> Mike O'Connor wrote:
>>>>
>>>> KERNEL32.DLL 0001:0001ef49
>>>
>>>
>>> Any thoughts/suggestions?
>>
>> It is crashing in Odin, so you should file a bug where ever you got
>> Flash.
>> Dave
>
> Hi Dave,
>
> Close
More than close - this Flash10 uses an updated "odin wrapper".
If using a multicore cpu system then this build is liable to cause
problems including total system crash.
Maybe ecS will get this fixed before websites switch to using HTML5 :-)
Regards
Pete
Mike O'Connor
> Hi Mike
>
> Mike O'Connor wrote:
>> On 2010-05-21 01:55 (AEST), Dave Yeo wrote:
>>> Mike O'Connor wrote:
>>>>>
>>>>> KERNEL32.DLL 0001:0001ef49
>>>>
>>>>
>>>> Any thoughts/suggestions?
>>>
>>> It is crashing in Odin, so you should file a bug where ever you got
>>> Flash.
>>> Dave
>>
>> Hi Dave,
>>
>> Close
>
>
> More than close - this Flash10 uses an updated "odin wrapper".
>
> If using a multicore cpu system then this build is liable to cause
> problems including total system crash.
>
> Maybe ecS will get this fixed before websites switch to using HTML5 :-)
>
> Regards
>
> Pete
Hi Pete,
Thanks for the thoughts. Definitely not dual/many-core related here as
this is only an AMD Athlon64 3200+ Uni-core CPU.
This has only just started occurring with 3.7a4pre. I did note in the
FLASH10 directory (since) that there was an except.log, but that has no
new entries since early last month, when they came from earlier FF/TB
versions.
Of course at the same time I realised that the entries I was thinking of
in relation to win.ini and system.ini were of course in odin.ini in that
FLASH10 directory along with the DLLs!
Mike
Dave Yeo
> On 2010-05-21 01:55 (AEST), Dave Yeo wrote:
>> Mike O'Connor wrote:
>>>>
>>>> KERNEL32.DLL 0001:0001ef49
>>>
>>>
>>> Any thoughts/suggestions?
>>
>> It is crashing in Odin, so you should file a bug where ever you got
>> Flash.
>> Dave
>
> Hi Dave,
>
> Close - it's the (BetaZone) eCS Flash10 Technology Preview which has an
> \Innowin\ directory branch under \Programs\.
Innowin is Odin (actually a fork), just a lot of it combined into one DLL.
I doubt it as most Win32 programs don't use system.ini/win.ini. Don't
know about the deployment stuff, though be good to double check the paths.
Dave
Mike O'Connor
Hi Dave,
Thanks for the rapid response. As I mentioned in a later post, I was
confusing the entries in odin.ini with system.ini and win.ini, and all
the entries in odin.ini looked all OK. Javaw.exe path is correct. So
it's just YAFP (yet another Flash problem)!
Regards,
Mike
Dave Yeo
> So it's just YAFP (yet another Flash problem)!
I similar posted all the time in forums. Doesn't seem to matter which
operating system, Flash has a habit of crashing and taking the browser
with it.
Browsers are now starting to run Flash in a separate process so only the
tab dies.
Dave
Mike O'Connor
Hi Dave,
Yes I've been aware for a long time that it wasn't anything like an
OS/2-eCS-specific problem. Good to know about sorta sandboxing it!
Mike
Mike O'Connor
Now I finally remembered (after doing an initial installation of
flash10TP on an eCs1.2R voume) why I stopped using run!.exe - it was
because Flash10TP is incompatible with LIBSTRICTPATH.
As soon as I ran Firefox directly from firefox.EXE, all of the crashes
went away, and 720P Youtube etc.,[but non-streaming]video was OK again,
cautionary warning from .wpi as documented in its readme.txt!
So it's back to trials with SeaMonkey 2.x for me.
Mike
William L. Hartzell
Mike O'Connor wrote:
> On 2010-05-17 08:21 (AEST), William L. Hartzell wrote:
>> Sir:
>
>> SAGE was a computer that a thousand people could walk around inside.
>
> But don't wear too many layers of clothing!
The cooling system was a monster to behold. Even still it can get warm
when the system is up. NOT like one could just open a window if it got
too hot, the walls were several meters thick & bomb proof.
> It
>> still has something you won't find a seven dollar hand calculator, 3D
>> displays or bugs that you could physically remove (moths & etc.).
>>
>> SSD is one large cache.
>
> Not comparable to speed of cache memory by a long way!
Oh no, not even comparable. It is slower than DRAM of any type. Plus
it has to go over a bus and a bridge to get to the CPU, before anything
can be done with it. Cache is something that Linux has over OS/2, all
unused memory is cache. The SSD has 32 MiB of cache built-in, compared
to 8-16 MiB the spinning disks have.
>
> I time it roughly with Win 7 to take eight
>> seconds to the sign on screen and another four seconds to the desktop
>> that was visible. And another eight seconds until all the extras to
>> finish loading.
>
> Is it completely usable at that stage, like OS/2-eCS, or has the
> wait-pointer just stopped showing?
I measured to after the wait pointer went away and no more icon
appeared. Have to do that many times to get the feel of when no more
icons would appear. The gadgets are the last to appear. I could mouse
around before then, but the time is so short that nothing practical
could be done.
>
> What version of Windows7 is that?
I am using Win 7 Home Premium OEM.
>
> Wish I could say OS/2 loads that fast, but it stops at
>> OS2LVM.DMD, again checking JFS partitions, and when it does driver
>> complete processing, and at PMshell load. The desktop loads about as
>> quickly as Win 7's desktop.
>
> And how many windows partitions are visible on that system to Windows7,
> i.e. how many native partitions is it processing?
There are nine partitions, of which one is NTFS, one is NTFS2, four are
fat16-32 (flash drives), one fat32, two CD/DVD depending upon media.
OS/2 sees all except the NTFS2, plus its own HPFS & JFS volumes.
>
> I previous speculated what was the slow up
>> causes: ie. the OS2LVM.DMD was barfing over UEFI drive format, JFS
>
> Is that the 32-bit UEFI or the 64-bit?
>
I assume that it is 64-bit as the system is 64-bit.
>> because all of them are on the spinning disk, the other two are normal
>> OS/2 slow-ups. OS/2 takes about three minutes assuming clean shutdown.
>
> That's monstrous for OS/2!
It is a whole lot better than before with my Athlon XP 2000 machine when
it was several minutes longer, though then the partitions were a lot
smaller (and the disks slower).
>
>> I'll grant that Win 7 is probably hiding some of its program load with
>> the sign-on screen, which OS/2 does not have. But even when I set Win 7
>> to use no password, I didn't see a noticeable increase in time. I am
>> most definitely going to purchase another SSD to put Win 7 back on, and
>> I'll try using Windows' fdisk or LVM to partition that drive so that
>> UEFI will not be installed (not saying that Win 7 will install).
>
> Does that motherboard have both legacy BIOS and UEFI?
>
Its documentation only proclaims Legacy BIOS. The UEFI that MS uses is
only with the drives, something it can do without BIOS support. Do know
that MBR is different than anything OS/2 or DFsee understands. DFsee
also says that the partition tables it does not understand. However,
the reserve partition that Windows creates, which has its boot manager &
loader, is plain Jane NTFS, which all read as HPFS. Win 7 documentation
says its partitioning is EFI and 128 visible partitions can be used. I
assume that it is compatible with MAC Snow Leopard.
William L. Hartzell
The FUD applies to why they are not shipping today.
Dave Yeo
> On Tue, 18 May 2010 01:35:44 UTC, Dave Yeo<dave....@gmail.com> wrote:
>
>> Allan wrote:
>>> I tested this, creating 3 partitions of 1GB size:
>>> 1 hpfs
>>> 1 JFS
>>> 1 JFS (512 byte block size)
>>>
>>> After copying approxx 710MB files from a boot drive to these,
>>> the number of free bytes is like this:
>>> HPFS: 287M
>>> JFS: 264M
>>> JFS(512): 291M
>>
>> How much was free before copying the files? IIRC HPFS preallocates space
>> for subdirectories (also for bad blocks?) which would throw the test off.
>
> The testcase was asked to be a 1GB partition.
> All 3 partition was 1GB before formatting.
>
> Afaiks, this test just shows Bill's claim to be all wrong.
It still depends on things like how many subdirectories, average size of
files etc.
To me it seems that they are both close enough, with JFS wining on usual
usage and HPFS perhaps being better if there are lots of small files
spread over many subdirectories, which of course is not normal usage.
>
>> Unluckily anything besides the defaults stops JFS from being cross-platform.
>
> I have no idea if AIX or Linux do not support all features of OS/2 JFS, as I never
> have used any of the others. I do however kind of doubt, that IBM invented new
> features on OS/2, that is not available on AIX.
I don't think JFS2 is compatible with JFS so how interoperable with AIX
it be is a good question. But IBM did write JFS2 for OS/2 then I believe
ported it to AIX and being a rewrite may well of had more features.
> If the Linux port does not have all the features of the OS/2 or AIX version, I can not
> really see, why the OS/2 version should be flamed for that.
>
Actually it is that the Linux port has had more development then the
original OS/2 version. No flames intended but OS/2 can not read Linux
JFS and Linux can only read the OS/2 default.
Linux also supports case sensitivity, hard links, symbolic links and
true Unix permissions.
Linux actually supports symbolic links and Unix permissions on HPFS in a
way that is compatible with programs compiled with KLibc (GCC 3.3.5+) on
OS/2.
Dave
Ilya Zakharevich
Allan
<all...@warpspeed.dyndns.dk>], who wrote in article <YEdw17zDmnZd-pn2-JV9RW71sdK0H@localhost>:
> Well, I tested precisely what you asked for (a 1GB partition with a copy of an eCS Install).
No you did not.
> The result showed JFS superiour to HPFS.
BS.
> I think it is time you select the options for JFS, that fits what you need,
> instead of just using standard options, and claiming it doesn't work like
> you like.
Irrelevant. Non-standard size is not cross-platfrom, hence not
suitable for most situations (e.g., given how fragile OS/2
implementation of JFS is, I prefer to have an option of access from
emergency Knoppix boot. Also helps to copy large amount of data
JFS-->FAT32 or JFS-->NTFS.)
Hope this helps,
Ilya
John Small
<spamyo...@127.0.0.1> wrote:
>
> I've posted a recent build of the next version of Firefox to my
> website. You can download it from:
> http://e-vertise.com/warpzilla/firefox-37a4pre.zip
>
> This version contains several OS/2 enhancements and fixes:
>
> Enhancements:
> - scrolling should require 25-50% less CPU usage than previously;
> there are other less noticable improvements in display speed
>
> - previously, switching to a new tab before the page loaded
> (i.e. getting a blank screen before anything was displayed)
> consumed an extra 1-3mb of memory for the life of that tab;
> this memory usage has been eliminated
>
> - there's a new OGG decoder as well as changes in the OS/2 audio
> component that make it far less likely that normal system
> activity will interrupt the audio stream
>
> Fixes:
> - users of Matrox video drivers should see a normal, non-slanted
> display; however, video performance will be considerably
> slower/more CPU-intensive than would be the case with SNAP
>
> - users of FlashBlock will no longer see a floating rectangle
> that fails to move or update when scrolling
>
> Please let me know if you see any bugs or have other problems.
I got around to trying this out. It seems that the "Copy link
location" is still broken. It still "copies" the url with several
seemingly random characters missing.
I use "Copy link location" often, in conjunction with AWGet's
clipboard monitor, to simplify downloading. So this bug is extremely
annoying to me.
--
John Small
inv...@invalid.invalid
Martin
Dave Yeo
> Is there already a newer version fixing the bookmarking problems?
>
I'm hoping to upload a newer version in the next day or so for webm
testing. Quickly testing the bookmarks window shows all my folders.
Dave