>> Perhaps the enclosed patch (against 2.1.131ac13) would come in
>> useful here. It basically adds a configuration option in
>> "Processor type and features"...
>> --- linux/include/asm-i386/page.h.orig Thu Apr 9 02:05:18 1998
>> +++ linux/include/asm-i386/page.h Thu Dec 17 20:58:28 1998
> have you ever tried it? It can not do anything useful - please read
> the comment in linux/include/asm-i386/page.h :
> * IF YOU CHANGE THIS, PLEASE ALSO CHANGE
> *
> * arch/i386/vmlinux.lds
> *
> * which has the same constant encoded..
I have to admit that I'd missed that comment, and I don't know enough
about the ld scripting language to patch the said file anyway, so that
patch has to be regarded as being incomplete as a result...
Perhaps somebody could give me a quick run-through of the ld scripting
language, then I should be able to deal with that aspect of it as
well...
> But I do not agree that even with this change it's enough - do you
> (to all kernel developers) have access to any machine with more
> than 1G RAM?
As I've clearly stated on several occasions, I have at best 128M of
RAM, so couldn't test things like that anyway. All I can do is to
suggest possible patches and ask people with suchlike facilities to
test them and report on the results...
> Do you tested it with patches you suggest?
I test everything I write to the maximum extent that I can...
> We are now running 4/SMP with 1G and except normal patches (more
> processes, MegaRAID, ...) we must also apply other patches to make
> it work (well, 2.0.29 worked ok, but we loose our power).
> I can make all of our patches available somewhere when requested.
Please do so...
> Any comments.
Only what I've made above...
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/