LxPupSc: Woof-CE, Slackware-Current, LXDE build 13-Jun-2020

For talk and support relating specifically to Puppy derivatives
Message
Author
User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

Re: pmcputemp

#676 Post by peebee »

Rodney Byne wrote:Could you please investigate & test much more
deeply this problem.
Hi RB

There is no "problem"....

The pet is made by 01micko and is not constructed to meet your expectations...

Don't use urxvt - use LXTerminal....

Restart WM is a button on the Session Control menu....

Attached is a modified .pet which should meet your expectations ;-)
Attachments
pmcputemp-0.50-i686_lx.pet
(7.99 KiB) Downloaded 168 times
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

Rodney Byne
Posts: 247
Joined: Fri 31 Jan 2014, 14:12

Re pmcputemp

#677 Post by Rodney Byne »

PB,

The .pet runs, but when the green box appears, the laptop
fan speeds up and then the green box turns red.
The laptop top plate gets unnaturally hotter.

So I have decided to stand down on this issue
and have uninstalled the .pet to status quo.
The pc fan now just ticks over normally.

My original expectation was led by BK's earlier
xenial xerus 7.0.1 which temp indicator works normally.

One thing I have noticed when trying out distros, if the OS
has two alternative window managers, such that the
unselected WM & vice-versa still runs in the background,
the fan screams fast enough to threaten tearing out its bearings.

This situation is totally unacceptable as the dual-core processors
are obviously heat-overloaded.
Cheers.

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

Re: Re pmcputemp

#678 Post by peebee »

Rodney Byne wrote:...the laptop fan speeds up and then the green box turns red.

.....if the OS has two alternative window managers, such that the
unselected WM & vice-versa still runs in the background,
Hi RB

My laptop does not exhibit that behaviour.....

There is no other window manager running in LxPup - use the Task Manager - you will see no sign of jwm running.....
Last edited by peebee on Mon 10 Apr 2017, 08:26, edited 1 time in total.
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#679 Post by peebee »

There is a new version of libbluray been added to Slackware which I would like to switch to but have no way of testing.

Can anybody check if bluray discs play in mplayer when the attached ydrv sfs (false .gz) is installed please?

Ta.
Attachments
ydrv_LxPupSc_17.04.21.sfs.gz
remove false .gz and rename appropriately if required
(172 KiB) Downloaded 153 times
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

mistfire
Posts: 1411
Joined: Wed 05 Nov 2008, 00:35
Location: PH

#680 Post by mistfire »

Hi @peebee does your lxpup kernel supports "forcepae" option? If yes how to use this option on grub or syslinux?

User avatar
Marv
Posts: 1264
Joined: Wed 04 May 2005, 13:47
Location: SW Wisconsin

#681 Post by Marv »

mistfire wrote:Hi @peebee does your lxpup kernel supports "forcepae" option? If yes how to use this option on grub or syslinux?
@mistfire - Both the current 4.10.x kernels and the 'alternative' 4.4.x kernels fully support forcepae, as IIRC do all kernels since 4.x.x or so. I routinely run the 'alternative' kernels and test the 'regular' ones in LxPupSc and LxPupXenial on my Pentium M laptops which require forcepae. I use Grub4Dos only and pass forcepae as a kernel parameter in the menu.lst entry there so I can't help with the exact parameter placement in a grub or syslinux install.

My reasons for using the 'alternative' kernels in the forcepae Pentium Ms are twofold. One, they lock up on suspend with any of the 4.10.x kernels and the other is that the video FPS is 3x lower with the 4.10 series than with the 4.4 series. The 4.9.x kernel in LxPupXenial is intermediate in that it suspends correctly but still has the poorer video performance.
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.

belham2
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

#682 Post by belham2 »

Hi PeeBee,

Just wanted to give you a heads up, on the latest LxPupSc release, that even with the alt-Xorg and alt-kernel, once again I lost my dual monitors, redshift abilities and few other things (as we had talked about a few months ago). To rectify the situation, since the alt kernel and Xorg provided did not work, I again went to a recent Slacko32 build I did (a woof-CE build I did a couple of weeks ago) and grabbed it's vmlinuz and kernel. I then put them into this latest LxPupSc (always frugal installed) and..... sure enough.........everything worked as it should again.

What I find strange is out of all pup iterations here on murga----which I sample (and use) a lot of---these problems (losing dual monitors, xorg, redshift, etc) only appears with two distros: LxPupSc and now mistfire's X-Slacko-Slim. I've had to let Mistfire's go, as I don't have time to keep trouble shooting it. But for yours, I'll keep at it, flopping in the whatever the latest vmlinuz & kernel is in Micko's Slacko32 latest builds, and everything should be good. As always, thanks so much for keeping LxPupSc always fresh and up-to-date! :wink:

User avatar
norgo
Posts: 388
Joined: Fri 13 Nov 2015, 17:19
Location: Germany
Contact:

libbluray 2.0.0

#683 Post by norgo »

Hello @peebee,

removed old libbluray ( 1.4.0 ) package,
converted your SFS to a PET and tested this under use of LxPup-Sc 17.03.2 and Mplayer 1.3.0

worked without problems,
thank you very much.

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

Re: libbluray 2.0.0

#684 Post by peebee »

norgo wrote:Hello @peebee,

removed old libbluray ( 1.4.0 ) package,
converted your SFS to a PET and tested this under use of LxPup-Sc 17.03.2 and Mplayer 1.3.0

worked without problems,
thank you very much.
Hi norgo

Great - thanks for testing - will go into the next build....
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

User avatar
Marv
Posts: 1264
Joined: Wed 04 May 2005, 13:47
Location: SW Wisconsin

#685 Post by Marv »

@belham2 - Just for information purposes if it's not too much trouble could you swap in the 4.9.13 kernel from the most recent LxPupXenial and see if it passes or fails your 'redshift etc.' test? The last couple of versions of mistfires X-slacko Slim have been using the LxPupSc 4.10.x kernel so it's not surprising they act similarly wrt that.

Thanks,
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.

Sailor Enceladus
Posts: 1543
Joined: Mon 22 Feb 2016, 19:43

#686 Post by Sailor Enceladus »

Marv wrote: The last couple of versions of mistfires X-slacko Slim have been using the LxPupSc 4.10.x kernel so it's not surprising they act similarly wrt that.
Interesting, I didn't know that. That one I tried a few months ago came with 3.14.56 (not as a zdrv) I think.

belham2
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

#687 Post by belham2 »

Marv wrote:@belham2 - Just for information purposes if it's not too much trouble could you swap in the 4.9.13 kernel from the most recent LxPupXenial and see if it passes or fails your 'redshift etc.' test? The last couple of versions of mistfires X-slacko Slim have been using the LxPupSc 4.10.x kernel so it's not surprising they act similarly wrt that.

Thanks,

@Marv,

Downloaded the 4.9.13 kernel from ibiblio----thanks to peebee, as I wasn't sure what you were referring to since LxPupXenial latest kernel is 4.1.31 in the latest -16-Sept-2016-release of LxPupXenial.

Anyhow, putting the 4.9.13 kernel in (with its vmlinuz) into LxPupSc-17.04.1 (with no savefile, and a frugal boot) was/is a disaster. Wireless Mouse stopped working upon hitting the desktop, had to go grab a wired (which worked), tried to set up an internet connection, and no LAN connection can be seen---no active network adapters can be seen, which, lol, is a very first for any pup I've tried over the past several years using my systems. Tried even loading the module for the gigabyte board, but it wouldn't work.

So, i stopped right here since no functioning network interface ability puts a kabosh on doing anything else.

If it helps you to know, I've done XenialPup64 build with the 4.9.15 kernel (in fact, use it a lot of my chess playing), and have no problems with it whatsoever. So if I can do builds with the 4.9.15 kernel in it, have full dual screens, redshift, and no xorg problems, then what is going on in LxPup (and Mistfire's X-Slacko) that I can continually have to resort back to using whatever Micko puts in his latest Slacko32 builds.....which as I noted, is exactly what I did and then LxPup-17.04.1 (and all iterations) run fine. Heck, I even run Micko's latest Slacko32 and 64 builds, and have zero problems with the latest kernels he puts in.

Something is screwy here....but I've no time at the present to hunt this down, so i just trashed-can Mistfire's creation and for Peebee's, I just grab the last kernel & vmlinuz from a slacko32 build, and I am good to go in LxPup any-version. (The latest Slacko32 build I did, just some days ago, I chose the old battle-proven 3.14.78 huge kernel specifically because I knew it had to do double-duty in subbing in for what I am getting with LxPupSc).

I don't think Peebee (or you) should waste any time on this. I guess I must be an outlier with my 5-6 year old 3 Gigabyte AMD motherboards, 7 year old 2 Biostar AMD motherboards and 2 ASUS AMD 3-4 years motherboards. Quite honestly, even the crazy dpup builds I have done, I never have any problems like this that I do with LxPupSc. I continue with LxPupSc only for one reason: how Peebee integrates PCManFM....once I figure out how to do that in my own builds, and/or Phil (or others) start doing it to the degree that Peebee does it so well, only then will I leave LxPupSc and the headache of always having to revert back to older kernels and xorg servers.

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#688 Post by peebee »

belham2 wrote:I've done XenialPup64 build with the 4.9.15 kernel (in fact, use it a lot of my chess playing), and have no problems with it whatsoever. So if I can do builds with the 4.9.15 kernel in it, have full dual screens, redshift, and no xorg problems, then what is going on in LxPup
Hi @Belham2 & @Marv

I have just tested LxPupSc-17.04.x (32-bit) with kernel huge-4.9.15-xenialpup64 (64-bit) and it works just fine.....(apart from strange tunl0 device....)

Keep the LxPupSc fdrv even though firmware is in the zdrv as it adds some firmware like b43.

Please test.
Thanks
peebee
Attachments
Screenshot(1).png
(38.44 KiB) Downloaded 271 times
Screenshot.png
(8.69 KiB) Downloaded 246 times
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

belham2
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

#689 Post by belham2 »

Hi Peebee,

I'll give the 64bit 4.9.15 kernel a go tonight or early tomorrow morning, Just for my own curiousity, I just did (today) a Slacko32 build using the 4.1.11 kernel. Had never tried this one. I also inserted radky's FbBox-4.0 in the build, and then let it all rip. Sure enough, the result was great and everything works immediately-----dual monitors was even recognized on the initial boot (which is nice, as I had to do nothing), same for redshift (which I had inserted too in the build). Here's a screenshot, realize it might be hard to read so here's what "PupSysInfo" shows:

▶—— Linux Kernel ——◀

Kernel Release: 4.1.11
Build Date: Mon Oct 26 21:32:35 AEST 2015
OS Support: GNU/Linux
Architecture: i686
SMP Enabled: Yes
PAE Enabled: Yes


....and the terminal showing both screens (hdmi and vga, each 1280x1024).

I can't get any of the above in either LxPupSc (or Mistfire's) Slacko....unless I do the switcheroo with kernels and the Xorg. Note, the Xorg in this 4.1.1 I believe is not that problematic 1.19, but the 1.11. Either way, I just don't understand what is going on with this relentless push to constantly upgrade kernels (and such) when it is causing a lot of problems operationally and these kernels are not ready? I did some Google searches and murga-searches, is anyone aware of the number of problems over the past 4-5 months being reported that are directly related to this kernel upgrade madness?? I am not trying to be ungrateful, please don't take this that way. I am just saying "slow down", maybe even "stop", until you have the major issues solved. There is NO way in any linux universe (puppy included) that my 5-7 year old Gigabyte, Asus and Biostar motherboards (7 in all) should ALL---all 7 of them---be having problems with the new kernel releases from puppy----and I am talking about the canyon jump of the kernels up to the 4.10.9/4.10.10, the 4.9.21 and the 4.4.60.

I now understand what DryFalls (Just Lighthouse 64) was referring to when last year he wrote this in the 2nd msg of his JL-64 release:

"Finally, I personally use the 4.1.11 kernel. It just doesn't seem wise to have so many demons running amok. If the kernel folks don't slow down on their continual "upgrades", there may never be a stable Slackware 14.2. That is, unless they at slackware revert to the earlier approach of sticking with one kernel till the bugs are worked out. "


In sum, imho, somebody needs to say something to the woof-CE gang. They have let this kernel canyon-jumping madness go amok. Additionally, I get tired of people posting (testing) saying how wonderful the new kernels are with a build they've done, yet they don't use that build much at all, don't fully put them through their paces, then incredibly a few days later they go on to do other builds and once again trumpet how great the new kernels are, yet they don't put those builds thru the ringer either. It is folly! The new kernels, in their present form, are NOT great. Please, woof-CE gang, when it comes to Slacko and Tahrs, slow down and stop making huge jumps like this with kernels & such...and then expecting us users to act like Microsoft-bludgeoned customers who are forced to work out the bugs and make switches & patches ourselves to get things to work. This is the surefire way to drive people from puppy :?




P.S. Peebee, thanks for all your help.....I saw your message in the other thread....seriously, this isn't your war and/or battle, and it shouldn't be. You already put something great out. The fact that this huge jumping in kernels, xorgs, etc is going on has nothing to do with you.
Attachments
Fri-14-APR-2017-woof-CE-Slacko32-build-with-4.1.11-kernel-everything-working.png
(99.5 KiB) Downloaded 2063 times

User avatar
Marv
Posts: 1264
Joined: Wed 04 May 2005, 13:47
Location: SW Wisconsin

#690 Post by Marv »

64 bit 4.9.15 kernel run sucessfully in LxPupSc 17.04.1 on the all intel core 2 duo laptop. No extraneous IO ports on this hardware. As it is 64 bit, the Pentium M machines will not run it.

As usual looking at kernels, Swapping is fast, I have a little cleaner script that scrubs a savefile before updating or changing kernels which speeds that aspect up and renaming isn't much. Then I look for a clean boot sequence and WM and panel load post X; reasonable time from X start to desktop display, correct video resolution and driver use, at CPU and memory use at idle, check that services and boot processes I normally run have started cleanly and have a look for stray processes... delayedrun is the chief offender lately. Then check the IO ports and drivers and connect wirelessly and wired to see that the kernel drivers and firmware are ok. glxgears is not perfect but for comparison purposes quickly shows up any glaring problems with kernel video drivers and Xorg. My browsers/office suite/ video player, etc. are all SFS so that loading is checked. redshift and zarfy also in the mix recently. If in doubt about any prog in particular, start it from terminal and check for error messages. Suspend, both from button and lid and shutdown checked. My background is hardware and drivers, not look'n'feel so that gets shorted a bit. What I value is solidity. Same boot same responses to the operator every time over a long time. Reboots optional.

All in all it's clearly a compromise between timelyness and thoroughness for a first look, then I use it as a daily.

That said, I've run the 4.9.15 above, the 4.1.11, 4.1.30 and 31, 4.4.45, 4.4.52, 4.9.13, 4.10.3-8 recently on my stable of intel machines circa 2003 through 2015. Lots more kernels over time. For a while now I have not used the 3 series kernels as forcepae support may or may not be present there and it wastes a boot to find out.

Starting with the 2003 era Pentium Ms. The 64 bit 4.9.15 will of course not run on them. Anything 4.9.13 and newer has a pretty severe FPS hit on them though all the software including redshift and zarfy is ok. The 4.10.6 or so and newer lock up solid on suspend there. 4.1.11, 4.4.45 and 4.4.52 all run perfectly in all respects on them. 4.1.11 has a slight edge on idle CPU and memory use and 4.4.52 an edge on FPS. Suspend is normal on these three. Fan and power management pretty much irrelevant on these machines as the CPU has about a 9 watt TDW. On this hardware I favor (and run) 4.4.52 on LxPupSc and 4.1.30/31 on other older pups.

Next the 2007 era core 2 duos. Absolutely everything above runs perfectly on them. Redshift, zarfy, slimjet, chromium, printing, scanning, office suites, some CAD, basically everything I do. From a standpoint of video FPS the 64 bit 4.9.15 and the 32 bit 4.10.8 are equal and great. CPU and memory use are a bit lower with 4.10.8. Fan and power management seem about equal between the two. No real reason to drop back to older kernels here though the 4.4.52 is a close second, suffering only a bit in video FPS.

The 2015 era BayTrail desktops just burp and say the newer the better wrt kernels - at least so far -. They need at least a 4.x.x for USB support so I bump the older pups to 4.1.30/31 but LxPupSc (all the 4.10.x series) just works. I haven't run the 64 bit kernel on them yet as one is the main workhorse where it lives and the other is my NAS box...

@belham2, I heartily second the motion of sticking to a kernel for longer so fighting the kernel doesn't swamp other things that need ironing out. Problem as I see it is where to stick as it is so very hardware dependent. I've learned what I need for the various vintages but for a random box, random hardware, random age and new user what is best :?:

Edited once for grammar.
Last edited by Marv on Sun 16 Apr 2017, 02:28, edited 1 time in total.
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.

belham2
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

#691 Post by belham2 »

Hi Peebee and Marv,

Well, I hate to provide alternatives to what Marv wrote, but I had eye opening experiences yesterday. I did numerous woof-CE builds using slacko32. I used over 6 different kernels, even putting together the frankenstein builds of using the latest 'xenial-4.9.15-64bit' kernels in the Slacko builds. Guess what? Every one of the kernels worked since I was sticking to doing Slacko32 woof-CE builds (though with slight problems, for example, in some builds that were using a 'xenial' 64-but kernel in a 32-bit slacko---like using PPM to install anything).

Now, I took every one of those kernels that are past the 4.1- series kernels and the 4.2 kernels and put them in the latest LxPupSc 17.04.1. Every one of them had problems: no dual screen ability, mouse problems, no redshift, xorg screwing with tons of stuff, etc, and etc. I tried these across all of my ASUS, Gigabyte and Biostar motherboards. What surprised me most is the inability to not even see the included bult-in network lan on the motherboards. No other pup I can ever remember using has done this.

Next, thinking I was nuts, I callled a neighbor friend who is a Tahr pup user and asked him to download LxPupSc 17.04.1. In 30 mins, he calls me back and reports nearly every problem I am seeing. Now, for the 1st time, I know it is not just me....he said in LxPupSc 17.04.1 he has no ability to set up dual screens, couldn't even get a network going, redshift, etc, etc. I then asked him to swap in (he frugal boots too) any older kernel and also another xorg (any that are not the problematic 1.19 version). Lo and behold, sometime later, he calls back and says, after doing this, all is fine. And this guy uses Intel systems, and I am fully on AMD systems. This behavior is displayed with LxPupSc and weirdly awhile ago with Mistfire's X-slacko (where it never before had a problem).

Now here it gets weird....even if we both logged out of LxPupSc-17.04.1 and switched the xorg-conf back to the 1.11.3 provided fallback-version, the problems STILL PERSISTED across the board. Also, why does the Xorg-1.18.3 work flawlessly when it is with a woof-CE slacko32 build, but not with LxPupSc or Mistifre's? Thus, overall, tell me how any build of any slacko32 I do can work across all my systems with no problems and no care for the kernel and/or xorg included in the woof-CE build, yet in---ONLY--in LxPupSc and now Mistifre's the problems I discuss are persistent (and repeatable by others on totally different systems) and specifically designated??


Below is a bunch of tas shots: the first three are from yest's slacko32 build using the 4.9.15-xenial kernel-64 bit. Amazingly, everything runs fine. Of course, trying to use PPM having a 64-kernel is out of the question, lol. But notice in the first three pics how dual monitors are working, redshift, network, etc (plz note, i build with radky's fbbox-4.0 as the default desktop environment, and not jwm).

Now, look at the following 3 pics: they are LxPupSc-17.04.1 with the exact same kernel above, and look at the problems. This is repeated over and over across everything unless I specifically go grab a woof-CE build kernel and its xorg files, and insert them into LxPupSc. Only then will LxPupSc run normally. And remember, this behavior is repeated by another who is on totally different systems (and newer ones than me!).

So something is amiss in the LxPupSc builds, and I don't know quite what it is. It cannot just be my systems now. Anyhow, no one else posts here, and still today, not many people use dual monitors (except billtoo & me, that I see here), redshift, etc. So problems aren't going to be reported. But problems there are, and they are unlike any I've run across in other pups and pup-related OSes I've tried here. On a positive note, I messed around with a build last night inserting pcmanfm into the pre-build process, and trying to get it set up close to what Peebee excellently does in LxPupSc. I got close, so this exercise or frustration for me with LxPupSc will soon be over, for as I've stated before, the only reason I loved using LxPupSc was the great integration of pcmanfm.

Anyhow, here's the pics:
Attachments
Yesterays-woof-CE-build-slacko32-kernel-4.9.15xenial.png
(92.58 KiB) Downloaded 2098 times
the-stable-Xorg-1.18.3-in-this-yest-build.png
(108.37 KiB) Downloaded 2129 times
redshift-also-working-in-this-yest-build.png
(46.53 KiB) Downloaded 2125 times
LxPupSc-17.0.4-same-kernel-4.9.15xenial-no-dual-monitors-no-redshift-etc-etc.png
(39.75 KiB) Downloaded 2094 times
all-LxPupSc-new-kernel-versions-no-network-ability.png
(6.66 KiB) Downloaded 2073 times
LxPupSc-all-new-kernel-versions-with-no-network-ability.png
(171.22 KiB) Downloaded 2112 times

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#692 Post by peebee »

Hi Belham2

One difference between my kernel builds and others is that I don't put any extra firmware into the zdrv - I supply it as an fdrv in the iso.

Just checking - you are installing the fdrv aren't you?

If you are, could you try swapping the supplied fdrv with:
http://www.fishprogs.software/puppy/fir ... 170309.sfs

suitably renamed to fdrv of course.

Thanks
peebee

p.s. did you try the 4.9.15 64-bit kernel?
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#693 Post by peebee »

Interim delta 17.04.22T

- Kernel 4.10.10
- BUILD_FROM_WOOF='testing;4a267cc;2017-04-17 16:31:42 +1000'
- Slackware changes Thu Apr 13 21:19:45 UTC 2017
- some slacko-14.2 changes - in particular jwm-2.3.2-i686_s701.pet

Kernel 3.16.43 is also available.
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#694 Post by peebee »

Interim delta 17.04.23T

- Kernel 4.10.12
- Slackware changes Fri Apr 21 22:40:12 UTC 2017
- + some slacko-14.2 changes
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

User avatar
Marv
Posts: 1264
Joined: Wed 04 May 2005, 13:47
Location: SW Wisconsin

#695 Post by Marv »

17.04.21T updated to 17.04.23T on my all-Intel core 2 duo laptop. md5sums correct, wireless connection, glxgears FPS, redshift, zarfy, slimjet 14.0.1.0 (OscarTalks SFS), suspend and resume etc. and daily use all continue to be fine on this laptop. CPU idle at 3.5% with 'conservative' governor and memory use at idle (LxTask) at 166Mb for my configuration. It's high spring here so no time for the other machines right now...

video-info-glx 1.5.1 Sun 23 Apr 2017 on LxPup-Sc 17.04.23 Linux 4.10.12-lxpup-32-pae i686
2.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)

X Server: Xorg Driver: evdev
X.Org version: 1.19.3
dimensions: 1280x800 pixels (338x211 millimeters)
depth of root window: 24 planes

direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset x86/MMX/SSE2
OpenGL version string: 2.1 Mesa 17.0.4

Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz
Core 0: @800 1: @800 MHz

Cheers,
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.

Post Reply