The well-known limitation of BeOS to crash when too much memory is installed is now hacked around by some people in the community. The first patch, patches the kernel to “think” that only 64 MB is installed in the machine. We would advise the team to make multiple hack packages for 64, 128, 256, 384, 512, 640 and 768 MBs of RAM (the right amount is different for each user because it depends on the MBs the graphics card reports to the PCI level, not just how much RAM and gfx RAM is actually installed). This hack is for BeOS 5.x systems.
BeOS Memory Limitation Work-around Achieved
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
If these guys can hack in a fix with a binary only copy of the kernel what in the world is Zeta doing then?
Seems like a good way to go about it would be to use an installer which calculates the amount of RAM on the video and sound cards, then install the appropriate valued patch.
If it happens for real, then it will make YellowTab not look good because it kinds of show the proof of that they don’t have the kernel source code (or aren’t allowed to hack in kernel source code).
I thought this patch was made available a couple months ago? Guess it’s just me…anyways, Zeta is an interesting project so who knows what they can and cannot do. I think the only way to get a real answer to this is to contact Palm and see what they have to say.
…I believe this was part one of the ultimate fix. First they had to find the spot where they could trick the OS into thinking there was a different amount of RAM than there was… next is to find a way to allow the OS to make USE of the RAM? No? Am I smoking some bad weed here?
Mike
“Zeta (yT) was just waiting for someone else to make this patch, duh! watch, it’ll be in RC3.”
I don’t know who made it in the end (the site doesn’t open) but one of the most active developers on that patch was mmu_man, witch works for YellowTab (as far as I know).
Gein
Sorry about the wrong closing tag.
The way I understand it, the limit exists because it was easier for the developers to make the kernel with a 1GB limit, and to change this behaviour you’d need to redesign parts of the kernel. So it will be practically impossible to make a binary patch that would allow BeOS to use more memory, unless they use the leaked sourcecode. But that would be illegal.
Four years ago 1GB RAM was pretty rare on the desktop. They probably went for the quick fix, and thought that they would fix it later. But Be wen’t under and the problem was never fixed.
Good Job!
I think this is a good work around. It is better than using a dos tsr or a virtual drive to take up the extra. Hopefully it will work on my server.
Eugenia,
They are going to have a higher patch memory level, perhaps, but they are only doing this till they can get a full engineering fix.
So, all those sizes, are really not nessicary. Just maybe a final patch, while they’re working on the final solution which is currently in progress.
Btw, I can tell you’ve been out of the community mainstream for a while.
Why?
They probably are working on a fix, but it probably isn’t ready.
Whereas the person who made this hack has released early and is not the final fix.
I am not saying Yellow Tab has done what I am saying it is that I am trying to put the view across that people are just bagging YellowTab for nothing.
I believe yellowtabs main goal is to bring applications to Zeta in there first release, and package these apps as part of the OS, so that people can get a good out of box experience. The only thing I can bag YEllow Tab about is that possibly they may have too many applications by default, like a Linux distro.
So it will be practically impossible to make a binary patch that would allow BeOS to use more memory, unless they use the leaked sourcecode. But that would be illegal.
Pardon my ignorance — but is this implying that BeOS source code has been leaked?
It is of my understanding that the R5.1 or later source was leaked even before Dano itself was leaked.
Speculation had it that Dano was built from the leaked code.
Have I seen any of this leaked code? Yes.
But as soon as I realized what it was (about 3 seconds into readin the top of the file where it said (C) Copyright 1999-2001 Be, Incorperated), I destroyed the two files that were given to me by someone I will not name to prove that the code was trully leaked.
I avoid the code do to my high intra-community profile.
–The loon
and you will see that it is a reverse engineering of the BeOS boot process – specifically the boot floppy.
It has *nothing* to do at all with leaked source code.
It’s a temporary workaround until the real thing is fixed.
cheers
peter
Wow. Thanks, I never knew it was leaked. Just did some googling, even found an article here about it back in October 2001. Not sure how I missed the news about that when it happened.
We have had a small collection of people hacking away at multiple directions. Zadig helped on our initial attempt with the main kernel binary. Unfortunately, even though we managed to patch the value of installed memory the low-level boot loader stage passes to the kernel, it had already effected several mechanisms, meaning that even though we had changed the amount of RAM that appears in the About box, it had already mapped the original amount.
The next attempt was with zadig continuing his hacking in the kernel. MMU_Man then started on a DOS TSR that hooked the Bios calls that tell an OS about installed memory. We wanted to hook the call, and fake the values, however the boot loader seemed to bypass the TSR, or just fail with the modified values. (Modifying the ACPI E820 table).
However the later experiment told us that the memory was detected by the boot loader stage2 (zbeos). It is then passed to kernel at a later date. Therefore the stage2 boot loader was extracted. It is a gzip’d file in the zbeos binary. On disassembling this file I made a mistake on the command line parameters, which meant I couldn’t find the key identifiers I was looking for. Caz corrected this mistake, and I found the point in the code I was looking for. From there it was a matter of making the advanced bios hooks fail until the chain resorted to the oldest method available which can only handle 64MB.
Simple as that.
As for the future development. I think we will look into re-instating the original bios hooks, patching in a check for the memory size and cropping as appropriate. I think that a single value of 512MB will be suitable for all systems. There are some devices drivers that map huge areas of RAM, causing some systems to have slightly different amounts of RAM to fail (Radeon’s used to map 256MB). I think these drivers should be corrected or adjusted as required.
Ok… Cool one…
I emailed you in the email address you provided, please check your email.
will crash just because you add more memory for it?
If Windows had a problem like that, what would the comments be?
two possible situations:
1. yellowtab has the beos source code but they are not able to cange something in the kernel.
2. yellowtab didn’t has the dano sorces and they sell a 2001 beos with some bebits apps around.
bye yellowtab, they are dead until R1 is out.
There was an article on the Inquirer awhile back how Windows does have a similar limitation, but in processor speed instead.
They ran a CPU at 4.8mhz, and XP considered it being 10mhz. Apparently XP’s highest mhz limit is currently 2^32.
snyd:
As i have seen the evolution of Zeta, the RC1 was a Dano with SVG and dockbert with bebits apps. The main cool thing of this is that you can now buy an “official” Dano. Do not forget the USB support
SP1 was the same with new themes and some things added (like the personnal settings and more SVG icons)
SP2 is making the OS more stable that the SP1 was. Themes are cleaner and the network panel is a great add ! USB support is now working pretty well.
Don’t forget it’s a RC !!
Will YT be dead before R1 or R2 ? I hope not ! Cause the marketing work there are doing, as good as it is, is a good thing for making the OS noticed by the most.
Personnal view … i can be wrong !
For now, at the installation, would it be possible to make a install patched or not. Like you know, if Installer check and find = or > 512 DDR Mo, it apply the patch, and if not, it doesn’t apply it.
shouldnt this be a cool feature?
seriously this should be a cool feature yes?
you put in 1mb of ram and you should get 1gb in the end right?
wouldnt that be great rather than having suffient memory but it ends up as borked?
please correct me if im wrong
Zeta RC* is unusable with dual processor…
WHY ???
What the hell were they thinking when they made the Media OS? I don’t remember this being in the BeOS Bible.
NEW BEDOPER ONLINE
> 1. yellowtab has the beos source code but they are not
> able to cange something in the kernel.
Interestingly, JBQ commented on the fix to the memory issues… See the BeOSJournal forum thread…
What he said was very telling: Reading between the lines, if YT had the source code to the kernel, it would be *extremely* easy for them to pay *any* ex-Be engineer with *some* knowledeg of the kernel space to get it to compile and ignore any extra memory bar that which would get the OS running. Translation, if Zeta’s kernel source was available to YT, they could get it to run with 1GB.
Now JBQ didn’t out and out say they didn’t have the source, but the implication is still very much there.
http://www.livejournal.com/users/jbq/36413.html?thread=45373#t45373
Especially the paragraph that starts “Allowing BeOS to boot and ignore any memory beyond 512MB shouldn’t be hard at all for anybody who has access to the kernel source …”
Hmmmm
To help the censoring process
First off, this is excellent news. The 1GB limit, more than anything else, was preventing use of BeOS on modern hardware. I’ll be in the new computer market within the next month or two and would be sad if I couldn’t dual-boot BeOS alongside Linux and Windows.
Second, I’d like to see the project progress continue to allow what Eugenia suggests, a variable about of memory. Or just a second patch for 256 or 384…
Third, it isn’t necessary for BeOS to ‘use’ more than 1 GB – it doesn’t need it. And the amount of re-working it would take to accomplish that simply isn’t worth it. Might not even be possible anyway without the kernel source code. And won’t it cause problems with existing apps?
Fourth, why would Zeta need to write this patch themselves? They can just include this one…
Best Wishes,
-Bob
I used to be able to get BeOS to boot on this exact (well, nearly) system, but no longer, not even with VMWare, where I limit the memory down to 256mb.
I’ve tried stripping the system of all the new componants and still get the same problem… oh well.
We shall see if Zeta will fix my problems.
Third, it isn’t necessary for BeOS to ‘use’ more than 1 GB – it doesn’t need it.
It depends on what you are planning to do with BeOS. Since Refraction doesn’t have a diskcache-system it needs to load an entire image into RAM. Now take an image of some megapixels and add a few layers to it. Out of memory.
Even if this problem is solved (the IDE driver was too slow or something like that), there is still needs for a large amount of memory to be able to work on large files.
Sorry, but I am working with big pictures already, and Refraction does not handle 4096 by 4096 if you have more than one layer and try to translate one of the layers. It seems Refraction uses the video chips/memory to do all the work.
I have tested a number of BeOS paint programs and so far all fail once I reach that size which makes sense as my video card is only 64Meg in size. And a 4K*4K*24Bits = 48Megabytes. My computer however is 768Meg and Virtual is greater still. More than enought if CPU memory was used.
The problem is so bad I am considering writing my own paint program that does not use the video card to hold the entire image, but I expect it to be slow in operation.
Earl Colby Pottinger
If Be was making a brand new 32-bit OS and their phylosophy was “to do everything right” and the 32-bit systems have a memory limit of 4 Gigs, wouldn’t it “be right” to build BeOS to support up to 4 Gigs or RAM? Wouldn’t it make scence?
Hehe, you know I have only 8MB on my videocard, still I can open 50MB images without a problem.
I don’t know where you got that idea from.
However, Xentronix are aware of the problem and has investigated writing a diskcache-system for Refraction. But IIRC they came to the conclusion that the current IDE driver was to slow for this. Perhaps they will solve it in the future. I sure hope so.
Anyway, reinventing the wheel wouldn’t help. If you want to contribute, talk to Xentronix about it.
Yes, it makes sense, but it was an act of lazyness or perhaps getting it out fast. It would have been fixed a long time ago if Be was still around.
This is great news. I plan to use BeOS as my main os soon.