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

For talk and support relating specifically to Puppy derivatives
Message
Author
mistfire
Posts: 1411
Joined: Wed 05 Nov 2008, 00:35
Location: PH

#796 Post by mistfire »

@peebee where I can find that kernel alternative (precompiled not source code)?

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

#797 Post by peebee »

Interim delta to LxPupSc-17.09.21T-k64 - kernel 4.13.0-lxpup64 with hibernation enabled as requested (hopefully)....
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

#798 Post by mistfire »

@peebee you forgot to compile a 32-bit version of that kernel.

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

#799 Post by Marv »

:) LxPupSc-17.09.1T-k64 Grub4Dos frugal install on the S761 laptop above updated to LxPupSc-17.09.21T-k64 using the delta. md5sum of the iso generated is correct, video, sound, PWF 4.5 wireless connection, lid and button suspend to RAM, redshift, Slimjet 15.1.2.0 from SFS (I run Ghostery and Click&Clean on it), glxgears FPS (at 10,000) all are good. CD (Mahler :) ) and DVD (The adventures of Milo and Otis :lol: ) mount and play tested and continue to work correctly. CPU at idle is at 1 to 2% and base memory use is roughly 120Mb on this hardware and install. I really haven't noticed any change in that as you have worked through the 4.9 to 4.13 kernel range. I am using Yassm 4.1 to connect to the NAS box currently running 17.08.24T and X-Slacko 4.3 alternately as I chase a large (0.5 Gb +) file transfer quirk, probably disc cache related. The PcManFm tools also connect correctly but I haven't yet gotten it to remember my password so lazyfingers prefers Yassm.

I'm using and updating the 2nd gen i3 based Fujitsu laptop first partly cause I love it and also because it seems to be much more particular hardware wrt timing/boot/suspend/Fn buttons/touchpad than either the core 2 duo laptops or the Bay Trail desktops are.

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.

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#800 Post by rcrsn51 »

Marv wrote:I am using Yassm 4.1 to connect to the NAS box currently running 17.08.24T and X-Slacko 4.3 alternately as I chase a large (0.5 Gb +) file transfer quirk, probably disc cache related.
I'm guessing that this is over WiFi? I have had problems with this in the past.

It isn't a YASSM issue - YASSM just uses the mounting tools provided by the host Puppy. After that, it's the job of the Puppy file manager and the target Samba server to maintain a connection.

I found this to be fragile over WiFi with large files, even with ROX as the file manager. Do the built-in PcManFm tools work any better?

[Edit:] However, I notice that some Puppies are still using the mountcifs-1.5.pet package from 2011.

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

#801 Post by Marv »

rcrsn51 wrote:
Marv wrote:I am using Yassm 4.1 to connect to the NAS box currently running 17.08.24T and X-Slacko 4.3 alternately as I chase a large (0.5 Gb +) file transfer quirk, probably disc cache related.
I'm guessing that this is over WiFi? I have had problems with this in the past.

It isn't a YASSM issue - YASSM just uses the mounting tools provided by the host Puppy. After that, it's the job of the Puppy file manager and the target Samba server to maintain a connection.

I found this to be fragile over WiFi with large files, even with ROX as the file manager. Do the built-in PcManFm tools work any better?

[Edit:] However, I notice that some Puppies are still using the mountcifs-1.5.pet package from 2011.
Neither Yassm nor PcManFM have any trouble connecting and once connected I see the behavior irrespective of which I've used. I also see it in XFCE4/Thunar based pups.The NAS box is wired but the clients are wireless. I'll try it with a wired client but because so far it seems pup invariant at both the server side and client side, seems slightly a function of drive and connection type used for the shares on the server box, and never shows up for multiple small files, even adding to the .5 Gb total, I lean toward a cache issue. At any rate, it's more a natter than a problem and there are several variables to sort out so I will eventually figure it out but at it's own pace. I do use the attached shares multiple times in a day and just hit Yassm mount and go. Small to 50Mb sized files then go very very quickly and reliably. It's just the bigger iso transfers that do eventually complete but crawl toward the end. In general the partitions I transfer isos to and from are EXT2, with an occasional larger SFS to or from a fat32 partition.
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.

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

#802 Post by peebee »

mistfire wrote:@peebee you forgot to compile a 32-bit version of that kernel.
Hi mistfire
My 32-bit builds of >4.10 seem to have problems with cd's on laptops so I'll be sticking to 64-bit builds - which can be used with 32-bit systems - have you tried the 64-bit kernel??
Last edited by peebee on Mon 11 Sep 2017, 22:27, 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:

#803 Post by peebee »

Interim delta to LxPupSc-17.09.22T-k64

- Kernel 4.13.1-lxpup64

- Slackware-Current to Fri Sep 8 17:56:01 UTC 2017

- updated adrv and fdrv

- some tweaks to build system

n.b. I've started adding some build notes to post #2
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:

#804 Post by peebee »

Interim delta to LxPupSc-17.09.23T-k64

- Kernel 4.13.2-lxpup64

- Slackware-Current to Tue Sep 12 22:18:51 UTC 2017
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

Rangan Masti
Posts: 37
Joined: Tue 01 Jan 2013, 19:23
Location: Germany, Berlin

#805 Post by Rangan Masti »

Hi, thank you for the latest Kernel. Have a nice evening.

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

#806 Post by Marv »

@peebee 21T updated to 22T, then to 23T on the Fujitsu S761 referenced above. Nothing to report wrt sound, connection, video resolution and speed, CD & DVD detection, Redshift etc. All-in-all it continues to be rock solid here. The S761 computer at the farm is a few versions back but post 64b kernel and I continue to get raves from Mary on it.

I did notice and don't really note when it started, that running acpi-cpufreq with a conservative governor that the CPU/Fan control seems fine but both inxi and hardinfo report all CPUs at a fixed high speed (2491). The fan use, the /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq value (800 right now), and the 'time in state', below, seem to indicate that the governor is working correctly.

Code: Select all

2500000 1073
2000000 1382
1800000 1585
1600000 2956
1400000 5669
1200000 9466
1000000 17012
800000 701498
inxi reports:

Code: Select all

CPU:       Dual core Intel Core i5-2520M (-HT-MCP-) cache: 3072 KB 
           clock speeds: max: 2501 MHz 1: 2491 MHz 2: 2491 MHz 3: 2491 MHz
           4: 2491 MHz
My hardware or a general issue?

@rcrsn51 I pretty much have the NAS box transfers sorted to my satisfaction. The chief culprit was the wired/wireless router (an older Buffalo Airstation running Tomato firmware) throughput on a local file transfer. WAN to LAN was fine, wireless connections were rock solid, wired throughput ok but mediocre, but I bumped the wireless to wired local throughput by 6X swapping in a hardly state of the art TP-Link C50 router. Backing up a 250MB iso to the NAS box running samba went from a flakey 3 minutes to a solid 30 second transfer using rsync to check. I can happily live with that. Could have been either CPU speed or available memory for buffering in the router.
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.

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

#807 Post by norgo »

Really bad news.
Intel Power-state frequency scaling driver is faulty since three years, that's known.
But we never had before trouble with acpi-cpufreq driver which is used in this case :-(
I can't detect a frequency regulation.
Usage of governor powersave let the frequency stick at 800 Mhz all the time.
Under useage of governor performance frequency is sticking between 3800-3900 Mhz ( but 3100 Mhz is max frequenzy for the cpu)
under conservative frequency almost always at 800 Mhz and under ondemand absolutely indefinable.
In other words, cpu frequency scaling doesn't work.
It's not recommended to use this kernel in my opinion.

@peebee
Nevertheless very good job
Thank you very much

update:
LxPupSC-17.09.22T-k64
Kernel 4.13.1

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

#808 Post by Marv »

Hi norgo, what hardware are you running?

I looked again at the contents of the control registers above in both 21T and 23T both at system idle and using glxgears to goad the cpus into action. In both pups and using both ondemand and conservative govs, the actual contents of the system control registers on my hardware (all intel 2nd gen i3 laptop referenced above) do seem to behave in a governed manner. The fan and glxgears FPS both seem to confirm this.
In both pups above the inxi, hardinfo, and pupsysinfo reporting doesn't reflect this. It is stuck at 2491 out of 2501 for my CPUs. Seems like a reporting issue from here, unlike the Intel Power-state frequency scaling driver fiasco on most hardware. I'll go a bit further back and see what I see as well as looking at some different hardware.

Update1: LxPup-Sc 17.07.1 - Linux 4.11.8-lxpup-32-pae i686 tested on the same hardware and reporting (Conservative governor and PupSusinfo used) is correct. Same drill as above, check at idle, use glxgears to raise CPU speed, check system registers and update report. Nothing between done yet.

Update2: LxPup-Sc 17.08.1 - Linux 4.12.4-lxpup64 x86_64, IIRC pretty much the first 64b kernel other than swap-ins to test, is reporting the CPU speed correctly. Tested exactly as above.

Update3: Went back and rechecked LxPup-Sc 17.09.23 - Linux 4.13.2-lxpup64 x86_64, pristine frugal boot with only timezone, firewall and SNS wireless connection (no adrv used, posting from portable QtWeb). No change, it fails to report correctly.
A pristine frugal boot of LxPup-Sc 17.09.1 - Linux 4.12.10-lxpup64 x86_64 reports correctly. So, up to 17.09.1 is ok, 17.09.21 is not.


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.

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

#809 Post by peebee »

post superceded...
Last edited by peebee on Sat 16 Sep 2017, 19:18, 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:

#810 Post by peebee »

Kernel was changed from 4.12.10 to 4.13.0 at 17.09.21....

Reverting to 4.12.10.... inxi -C shows varying cpu speeds with 17.09.23

So is a kernel problem....

Config did change between 4.12.10 and 4.13.x - hibernation was enabled as requested by @mistfire - perhaps I should revert that change??
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:

#811 Post by peebee »

OK - rebuilt k4.13.2 without hibernation config change - same behaviour so that isn't the culprit....

Looks like it's a 4.13 kernel problem but google doesn't produce any clues in my searches....

Options seem to be:
- live with it - are there any downsides to this?
- revert to k4.12.10 from 17.07.1
- use one of the alternative 32-bit kernels 4.9.x etc.
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

#812 Post by Marv »

peebee wrote:OK - rebuilt k4.13.2 without hibernation config change - same behaviour so that isn't the culprit....

Looks like it's a 4.13 kernel problem but google doesn't produce any clues in my searches....

Options seem to be:
- live with it - are there any downsides to this?
- revert to k4.12.10 from 17.07.1
- use one of the alternative 32-bit kernels 4.9.x etc.
Since this is 'testing' and I see no other problems with the 4.13 I say live with it with a warning in the thread. 4.12.10 would be my second choice. The problem is that /proc/cpuinfo is not being generated correctly by the kernel. Here is the core of a watch script that does work in 4.13.

Code: Select all

#!/bin/sh

# Fails in 4.13 kernel
# lxterminal --geometry=27x3 --title=CPU_watch -e watch -n1 -t "cat /proc/cpuinfo | grep "^[c]pu MHz""  

# Works on cpu0, could be expanded 
lxterminal --geometry=27x3 --title=CPU_watch -e watch -n1 -t "cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq"
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.

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

#813 Post by peebee »

Marv wrote:The problem is that /proc/cpuinfo is not being generated correctly by the kernel.
Thanks Jim - that was the clue that google wanted .... :wink:
https://www.phoronix.com/scan.php?page= ... Management
- x86 systems will no longer try to export their current CPU frequency to /proc/cpuinfo. There's also a way to rework how the CPU frequency is exported via sysfs too, using the registers for computing the current frequency rather than relying upon the CPUFreq driver.
http://lkml.iu.edu/hypermail/linux/kern ... 01366.html
- Stop trying to export the current CPU frequency via /proc/cpuinfo
on x86 as that is inaccurate and confusing (Len Brown).

- Rework the way in which the current CPU frequency is exported by
the kernel (over the cpufreq sysfs interface) on x86 systems with
the APERF and MPERF registers by always using values read from
these registers, when available, to compute the current frequency
regardless of which cpufreq driver is in use (Len Brown).
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

#814 Post by Marv »

Hi peebee,
In your next kernel build could you change

Code: Select all

# CONFIG_CPU_FREQ_GOV_SCHEDUTIL is not set
to

Code: Select all

CONFIG_CPU_FREQ_GOV_SCHEDUTIL=m
? In reading about the power management changes in 4.13 I came across it. schedutil is supposed to be the replacement for conservative, is actively supported, and what benchmarks I've seen look quite good.
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.

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

#815 Post by norgo »

I'm using
CPU: Quad core Intel Core i7-4770S (-HT-MCP-) speed/max: 800/3101 MHz
tested for confirmation:

17.09.21T K4.13.0 - the same faulty behave like K4.13.1
17.09.1T K4.12.10 - works without problems

Post Reply