(old)Puppy Linux Discussion Forum

Now, apparently Karl Godt has compiled a PAE-enabled kernel, and got it to the point of working (based on the screenshot) - which is a step further than what I did. Karl, would you be willing to share the ISO with the rest of us? If you can compile the kernel with M586, it would be great I think (not everyone owns Core2 or Atom CPU ...) p310don is waiting and eager to test Smile

Apparently I got the actual 2.6.37.4 kernel working with everyone of the 6 compiles I've made until now .
It seems to need the bootparam acpi=force regadless of the BLACKLIST_YEAR to poweroff completely ( the standard 2.6.30.5 did also not but the 2.6.33.2 did ) together with ' acpi_enforce_resources=lax ' .
The sound seems to have probls with the default nodes at /dev
Error $? return codes
-2 : whole /dev/snd/* was missing
-19 : far too many at /dev/snd/* , needed just 8 nodes there
-25 : same as -19, exept /usr/local/bin/zmixer popped up but aplay did not work
^Unfortunately^ I enabled dynamic maintanance of /dev by the kernel at several of these compiles like it seems that many of the large distros do , and some of these with mounting /dev and some of these with CONFIG_DEBUG_BLOCK_EXT_DEVT=y
which was creating blockdevices with wierd maj=259 and min numbers like the userid=nobody , so the /dev/root looked like /dev/hdb8 b 259 65534 ....
I had to add several adjustments to rc.sysinit and rc.shutdown to take care if devnodes differ or are not available . So far until now rc.shutdown creates a database at /var/db which is read by rc.sysinit to make sure a non-dynamical-device-kernel gets its dev-nodes after shutting down a dyn-dev-kernel with the correct properties . This has the effect, that the boot can delay for 40 seconds ( last printk.time=1 stamp at /tmp/bootkernel.log between 100 and 110 seconds ) .

What I can do is to load up a tar.gz to ms-skydrive in some one or three weeks because I guess I will have to recompile the kernel at least 2 times . The latest Pentium-Classic M586TSC compile took double RAM usage after bootup to desktop ( 170-180MB ) than the MATOM , which is usually between 70-110 MB at standard Puppies . Because I mostly change more than 5 settings I don't exactly know , which could have caused this ...

@Karl Godt your work is going to help all of us along.

Now, apparently Karl Godt has compiled a PAE-enabled kernel, and got it to the point of working (based on the screenshot) - which is a step further than what I did. Karl, would you be willing to share the ISO with the rest of us? If you can compile the kernel with M586, it would be great I think (not everyone owns Core2 or Atom CPU ...) p310don is waiting and eager to test Smile

One thing to keep our minds on is to get a working kernel that will address anything which has 3.5GB+ of memory, as best we can, considering this problem.

gcmartin, sorry I need to correct you here.
Yes PAE is a hardware feature. But ...

I'm not convince that memory management within the OS requires that code management you speak of as requests for pages are handle via page-faults. Page-faults (a page frame request) are satisfied by hardware assistance....not software. As I remember it, system operation cycles to a page-fault; the request to satisfy this, is a hardware instruction with returns the frame location, the OS continues on as it does with all hardware instructions. These are just memory frame locations satisfying OS needs. This is the same no matter PAE doing the work because the hardware is enabled or non-PAE doing the work because the hardware was NOT enabled. If PAE is present and the OS is aware, it works the same as far as the OS is concerned. PAE just allow greater memory use. That's why there is no impact on system performance. No one loses anything if PAE is enabled and a NON-PAE OS is present (like we have here) or if PAE is enabled and a PAE OS is present; performance is the same. (In fact, compare the Puppy performance from those reporting 4GB recognition with those we've already reported in this thread that do NOT recognize 3.5GB+; this is an easy, simple "test-ament." of the non-impact I speak to.)

That's it! I've just exhausted my knowledge (probably over-extended). But, if necessary, I could construct a model to measure this. (But, its so much easier to take the vendors word for a 16 year old technology and an OS which will have its 20 Birthday this year.) I think we all, here, have a better understanding of the hand-shaking and companionship that needs to occur with Hardware and the OS.

By sharing this, I am merely trying to shed helpful information. I am not complaining about Puppy; I like Puppy. I'm am asking "why" this has been overlooked. And trying to contribute what I can that would be useful in resolution.

Thanks to everyone for, at least, helping me better understand this thread's problem.

Hope this helps

gcmartin wrote:@Karl Godt your work is going to help all of us along.

Now, apparently Karl Godt has compiled a PAE-enabled kernel, and got it to the point of working (based on the screenshot) - which is a step further than what I did. Karl, would you be willing to share the ISO with the rest of us? If you can compile the kernel with M586, it would be great I think (not everyone owns Core2 or Atom CPU ...) p310don is waiting and eager to test Smile

One thing to keep our minds on is to get a working kernel that will address anything which has 3.5GB+ of memory, as best we can, considering this problem.

gcmartin, sorry I need to correct you here.
Yes PAE is a hardware feature. But ...

I'm not convince that memory management within the OS requires that code management you speak of as requests for pages are handle via page-faults. Page-faults (a page frame request) are satisfied by hardware assistance....not software. As I remember it, system operation cycles to a page-fault; the request to satisfy this, is a hardware instruction with returns the frame location, the OS continues on as it does with all hardware instructions. These are just memory frame locations satisfying OS needs. This is the same no matter PAE doing the work because the hardware is enabled or non-PAE doing the work because the hardware was NOT enabled. If PAE is present and the OS is aware, it works the same as far as the OS is concerned. PAE just allow greater memory use. That's why there is no impact on system performance. No one loses anything if PAE is enabled and a NON-PAE OS is present (like we have here) or if PAE is enabled and a PAE OS is present; performance is the same. (In fact, compare the Puppy performance from those reporting 4GB recognition with those we've already reported in this thread that do NOT recognize 3.5GB+; this is an easy, simple "test-ament." of the non-impact I speak to.)

That's it! I've just exhausted my knowledge (probably over-extended). But, if necessary, I could construct a model to measure this. (But, its so much easier to take the vendors word for a 16 year old technology and an OS which will have its 20 Birthday this year.) I think we all, here, have a better understanding of the hand-shaking and companionship that needs to occur with Hardware and the OS.

By sharing this, I am merely trying to shed helpful information. I am not complaining about Puppy; I like Puppy. I'm am asking "why" this has been overlooked. And trying to contribute what I can that would be useful in resolution.

Thanks to everyone for, at least, helping me better understand this thread's problem.

Hope this helps

You continually keep posting that there has been an "oversight" or a problem......... there has been no oversight or problem.
If you download Ubuntu you will get a non PAE kernel that "sees" less than 4 Gb of ram if you have that much or more installed.Same for Fedora or Mandriva or PCLOS or take your pick.I guess all those "major" distros have been overlooking things too.

Those distros I just mentioned have PAE kernels available for the user to install if they choose, but the default kernels are just like Puppy kernels....... they all will "show" less than 4 gb of available ram, just like a Puppy kernel.

Must be a reason why all the major distros ship with the regular kernel?

I now leave this thread to you..... nothing personal, I'm just trying to point out a few facts.

James C wrote: You continually keep posting that there has been an "oversight" or a problem......... there has been no oversight or problem.
If you download Ubuntu you will get a non PAE kernel that "sees" less than 4 Gb of ram if you have that much or more installed.Same for Fedora or Mandriva or PCLOS or take your pick.I guess all those "major" distros have been overlooking things too.

Those distros I just mentioned have PAE kernels available for the user to install if they choose, but the default kernels are just like Puppy kernels....... they all will "show" less than 4 gb of available ram, just like a Puppy kernel. ... I now leave this thread to you..... nothing personal, I'm just trying to point out a few facts.

Thanks @James C for bringing that to all of our attention. I did shutdown and booted my Knoppix 6.4.4 in 32bit mode versus 64bit on that system. I see the same thing you report here.

Thank you for opeing our eyes.

Now, if we can figure our "Why?' I encourage all of us to share anything that can help our understanding.

Thanks, again

Some relevant links:

https://bbs.archlinux.org/viewtopic.php?pid=683192

http://www.phoronix.com/scan.php?page=a ... _pae&num=1

http://linux-mm.org/HighMemory

http://www.linuxquestions.org/questions ... it-723652/

Seems that from "real world" use, PAE isn't a major impact on normal machines' usage. On machines with higher memory, greater than 4gig, that's when the performance hits come in, but that is mostly vs 64bit, as 32bit regular won't see more than 3ish.

So, from here.

Who can make it?

I can't.

Who can test it?

I can.

What do we need to know?

Speed benchmarks. Stability. Compatibility.

Is it worth it? Does it break stuff? Will it affect puppy's primary goals of usability on older machines?

p310don wrote: ... Who can make it? ... Who can test it? ... Speed benchmarks. Stability. Compatibility. ... Is it worth it? Does it break stuff? Will it affect puppy's primary goals of usability on older machines?

P310don has done all of us a favor by getting us to this point. I'll try to give my perception (although it may not be accurate) of his questioning and what we should expect.

Who can make it?

Barry and Distro owners. Barry really does pull rank here. Everyone trusts him for guidance. (including me) Without Barry's support, there is little to no chance of ever seeing a Puppy (other than those already mentioned) with support for PAE hardware.

Who can test it?

If it ever shows up, every distro owner will jump on the bandwagon and as such, a huge groundswell of users (including me) come on board.

Speed benchmarks. Stability. Compatibility

I would like to see some meaningful tools in place for this and other kernel changes. Meaningful tools gives all a reference point for evaluating impacts.

Is it worth it?

3-4 years ago, no; but today, YES! More and more people have 32bit 4GB+ platforms in our premises and surroundings. And, its increasing. 32bit Vista and System7 has brought about the immediate need. Linux and Puppy just benefit as these machines because available for non-MS use.

Does it break stuff?

Probably not but nay-sayers will be ever present.

Will it affect puppy's primary goals of usability on older machines?

Of course it will in a very positive way. It will extend the life of 32bit machines and their use in the Puppy Linux environment. Puppy's stated mission is older PCs. Since no one is running 16bit machines anymore, older should be redefined to mean 32bit.

FATDOG is the only PUP that does NOT have a stated mission. It is wide-open. And, has the greatest potential for future growth of PUPs. Since it is 64bit, it runs on most all new PCs and its memory model (real and virtual) is beyond the scope on anything we'll ever see in 32bit PUPs. That model, alone, makes turning a single PC into a simultaneous multi-user system with enough cycles and memory to satisfy small doghouses and worlds. Additionally, "multi-purposed" as well.

Hope this helps

I started this thread with the suggestion of using high memory enable devices in a 32bit environment, as puppy is.

Throughout the threads evolution, it has become apparent that enable PAE is the solution to the "problem" as it is. However, through research, especially through the phoronix link in my earlier post, I am beginning to wonder if 32 bit is an avenue worth pursuing for higher end hardware. All indicators say 64bit is the way to go, with higher memory capability, speedier response etc. The only place where it seems to be let down is in non-open source stuff that hasn't been made specifically for 64bit. That seems to mostly mean Flash.

How have other people's experience with 64bit linux been? I used 64bit ubuntu since 7.04, and I can absolutely say that 32bit puppy out races it in everything it does, especially flash.

I tried FATDOG last night, and in the tiny usage I've had so far, I was not overly impressed. Firstly, I say this knowing that it is not fair, as it has only been in a livecd environment, without installing the correct video drivers for my system. Using it certainly SEEMED snappier than my 5.2 lupu install, and video worked seemingly better. I got flash to fail very easily with it, which is probably because its 64bit. The other thing I didn't like was the mix of software, I have gotten used to 5.2!!

So, in the context of this thread, whilst PAE is possibly a good option for 32 bit puppy, is an official 64bit puppy a better option for use with the newest hardware?

As gcmartin has answered, Barry is ultimately responsible for making puppy. Should we suggest / pressure / request an official 64bit version, probably with the help of Kirk, but with greater support and larger software range? Is that a viable option instead of PAE?

What do you guys think?

I'm fine with 32 bits. I don't use my computer for anything that would benefit noticeably from going to 64 bits. Is GIMP available in an optimized 64 bit version?

I only mentioned FATDOG because 64bit systems get around this 32bit issue. In the PUPs community, it is a PUP, too. But, bred differently.

I am not mentioning FATDOG as a competitor nor am I mentioning it as a push to any of us to abandon 32bit. I meant, only, to mention it as information that can help us position the PUP family.

Thanks to this discussion, we should have a better understanding on PUP family. Seems that the PUP family is broken into 3 different categories when running as a RAM based system (probably should be mentioned in Wiki):

• 32bit < 3.5GB of RAM on Official PUPs
  32bit > 3.5GB of RAM on some unOfficial PUPs
  64bit = FATDOG

Note: This chart intends to assist understanding of which PUPs will make use of installed physical system RAM.

Hope this clarifies my comments' use.

Flash wrote: ... Is GIMP available in an optimized 64 bit version?

Yes, its on the desktop.

Hope this helps

Flash wrote:I'm fine with 32 bits. I don't use my computer for anything that would benefit noticeably from going to 64 bits. Is GIMP available in an optimized 64 bit version?

Yes, GIMP is part of Fatdog64.

p310don wrote:So, in the context of this thread, whilst PAE is possibly a good option for 32 bit puppy, is an official 64bit puppy a better option for use with the newest hardware?

It depends on the apps you use. Remember, with PAE, even though you can use all the available memory, each individual app is *still* limited to 4GB. PAE is fine for the original usage brought up on this thread - use it as a ramdrive, etc. But it's useless convincing GIMP to edit a 32-bit 40K x 40K image (that's a 1600 Mpixels image) for example - the 4GB address space is simply not enough to hold the data. If the application is smart enough, it can probably use PAE just like DOS programs used EMS, but it's very kludgey. 64-bit OS doesn't have any of this limitation - all the memory is directly addressable to every application, if it so wishes.

As gcmartin has answered, Barry is ultimately responsible for making puppy. Should we suggest / pressure / request an official 64bit version, probably with the help of Kirk, but with greater support and larger software range? Is that a viable option instead of PAE?

Suggestion/request works. Pressure doesn't. And some other people have used 64-bit packages from Debian / Ubuntu in Fatdog64 - they mostly works.

What do you guys think?

PAE-enabled Wary 511 is available at http://mydrive.ch, under puppy32 folder, the filename is wary-511-hugemem.iso. Username is dotpet@puppyshare, password is puppylinux. It only contains the basic drivers - I didn't compile the extra modem drivers etc. Enjoy.
EDIT: md5sum is 350990e629fdb0f58c0dd65bbf2c2f49
EDIT: For reference, everything inside that iso is Wary511. Kernel is 2.6.32.28 based on Barry's kernel-2.6.32.28.sfs. DOTconfig is based on Barry's DOTconfig-6FEB2011, I only change the CPU architecture to 586 and enable HIGHMEM64GB.

jamesbond wrote:

p310don wrote:So, in the context of this thread, whilst PAE is possibly a good option for 32 bit puppy, is an official 64bit puppy a better option for use with the newest hardware?

It depends on the apps you use. Remember, with PAE, even though you can use all the available memory, each individual app is *still* limited to 4GB. PAE is fine for the original usage brought up on this thread - use it as a ramdrive, etc. But it's useless convincing GIMP to edit a 32-bit 40K x 40K image (that's a 1600 Mpixels image) for example - the 4GB address space is simply not enough to hold the data. If the application is smart enough, it can probably use PAE just like DOS programs used EMS, but it's very kludgey. 64-bit OS doesn't have any of this limitation - all the memory is directly addressable to every application, if it so wishes.

As gcmartin has answered, Barry is ultimately responsible for making puppy. Should we suggest / pressure / request an official 64bit version, probably with the help of Kirk, but with greater support and larger software range? Is that a viable option instead of PAE?

Suggestion/request works. Pressure doesn't. And some other people have used 64-bit packages from Debian / Ubuntu in Fatdog64 - they mostly works.

What do you guys think?

PAE-enabled Wary 511 is available at http://mydrive.ch, under puppy32 folder, the filename is wary-511-hugemem.iso. Username is dotpet@puppyshare, password is puppylinux. It only contains the basic drivers - I didn't compile the extra modem drivers etc. Enjoy.
EDIT: md5sum is 350990e629fdb0f58c0dd65bbf2c2f49
EDIT: For reference, everything inside that iso is Wary511. Kernel is 2.6.32.28 based on Barry's kernel-2.6.32.28.sfs. DOTconfig is based on Barry's DOTconfig-6FEB2011, I only change the CPU architecture to 586 and enable HIGHMEM64GB.

I'm don't really think a PAE puppy is needed but since you went to the trouble to do the work and upload it I figured someone should test and give some basic feedback.


-Computer-
Processor : 4x AMD Athlon(tm) II X4 620 Processor
Memory : 3884MB (164MB used)
Operating System : Puppy Linux 0.51
User Name : root (root)
Date/Time : Wed 06 Apr 2011 10:52:21 PM CDT


# free
total used free shared buffers
Mem: 3884968 465488 3419480 0 54988
Swap: 0 0 0
Total: 3884968 465488 3419480
#


I'm only running 2 x 2 gb DDR2 on this box at the moment.

Thanks James C.

Is there a significant difference on the memory recognised between standard Wary and PAE Wary? I have two 4 GB machines - on one machine, the difference is minimal (3.8GB vs 3.9GB), on the other one, it's very significant (2.9GB vs 3.8GB).

Regular Wary 511 ....................

-Computer-
Processor : 4x AMD Athlon(tm) II X4 620 Processor
Memory : 2854MB (143MB used)
Operating System : Puppy Linux 0.51
User Name : root (root)
Date/Time : Wed 06 Apr 2011 11:23:29 PM CDT
-


# free
total used free shared buffers
Mem: 2854960 399640 2455320 0 54688
Swap: 0 0 0
Total: 2854960 399640 2455320
#


Pretty big difference here too.

Windows 7 Ultimate 64 bit naturally shows all the ram, the poor old XP Pro 32 bit only registers 2.7 gb.......

Thanks. Yeah that's a big difference - we gain extra 1.1 GB in exchange with an overhead of ~20MB (your memory used in PAE is 164MB and in regular wary is 143MB), which is meaningless in multi-GB machines.

Now it's really up to p310don to test on his lower end machines (lower CPU and lesser RAM) and see what kind of impact he gets between this and PAE kernel. I don't think we need to be scientific here, just do some real-world operation such as editing documents with libreoffice, watching some flash videos, editing with gimp/mtpaint, etc. As long as the difference is not perceptible - then for all practical purposes there is no impact.

If all looks good, perhaps we can suggest this to Barry - but this require him to move the base platform up from 486 to 586 at the very least, so I'm not sure whether he's comfortable with that.

I guess the point of PAE is for those who wants to stick to 32-bit puppies because of backward of compatibility reasons (wealth of ready-made pets, etc) but still want to maximise the usage of memory.

Myself, I'd recommend going straight to the 64-bit path if you have more than 3GB of memory ...

Hi guys,

I've been having a wealth of issues with my 'net connection at home, so haven't had the chance to try out the PAE sample wary. Will get onto it as soon as I can.

Hopefully the PAE kernel won't be too significant to the performance on the old pcs.

Obviously we can see that extra gig or so in the big machines, which is where this thread is aimed, but if the performance figures are on par on the old machines, then that's something to talk to Barry about including in future "standard" puppies.

I guess the point of PAE is for those who wants to stick to 32-bit puppies because of backward of compatibility reasons (wealth of ready-made pets, etc) but still want to maximise the usage of memory.

I agree absolutely with this statement. 32bit OS's have better stability in my experience, probably due to longer development histories, but without a doubt 64bit is the future.

jamesbond wrote: Myself, I'd recommend going straight to the 64-bit path if you have more than 3GB of memory ...

For what its worth, I agree.

Since I already have a frugal install of Regular Wary 511 on my old P3 test box ( a fast 733 Mhz cpu with a whopping 256 Mb of ram and 1 Gb of swap) I just did a quick frugal install of your 511 PAE to compare.
Might be interesting......

First interesting observation, Wary 511 PAE absolutely refuses to make a save file.Goes through the motions then doesn't save.

Copied the save file over from the regular Wary install........shouldn't matter to the kernel.

Quick comparison before bedtime.....
Wary 511 PAE....... Firefox open here on forum.

-Computer-
Processor : Pentium III (Coppermine)
Memory : 254MB (109MB used)
Operating System : Puppy Linux 0.51
User Name : root (root)
Date/Time : Thu 07 Apr 2011 01:07:40 AM CDT

-Version-
Kernel : Linux 2.6.32.28 (i686)
Compiled : #2 SMP Mon Apr 4 20:39:31 GMT-10 2011

# free
total used free shared buffers
Mem: 254264 248564 5700 0 23308
Swap: 1020088 0 1020088
Total: 1274352 248564 1025788
#



Let me reboot into regular Wary 511......

Regular Wary 511.... same conditions.

-Computer-
Processor : Pentium III (Coppermine)
Memory : 254MB (99MB used)
Operating System : Puppy Linux 0.51
User Name : root (root)

-Version-
Kernel : Linux 2.6.32.28 (i686)
Compiled : #1 SMP Sat Feb 5 11:15:25 GMT-8 2011


# free
total used free shared buffers
Mem: 254352 244976 9376 0 24328
Swap: 1020088 0 1020088
Total: 1274440 244976 1029464
#


Very unscientific, but it's a start.