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

For talk and support relating specifically to Puppy derivatives
Message
Author
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

foxpup
Posts: 1132
Joined: Fri 29 Jul 2016, 21:08

connecting wifi

#816 Post by foxpup »

Peebee

I am on a new laptop. I tried fatdog64, but soon moved to the RC's for xenialpup and slacko. I even tried debian stretch and slackware current (live).
Recently I turned to your LxPupSc which is excellent for new machines, not to say the best. It also brings back a bit the feel of saluki/carolina to me; I don't know why exactly. Thank you for this.

On version 17.08.23 I had to choose "CRD: 00 UNSET" for wifi. I still had to link /usr/local/simple_network_setup/rc.network in /root/Startup/ to have connection on startup. I also tried "CRD: BE Belgium", but automatic startup did not work, not even with the link, and in SNS "connect now" did not work (the profile seemed lost), so SNS had to scan for wifi connections every time again.

I am on version 17.09.21 now, and the above now works fine: "CRD: BE Belgium", persistence in SNS and even automatic connection on startup (without the link in ~/Startup).
However, the connection takes a long time. I had discovered before on version 17.08.23, executing rc.network in terminal with --verbose, that with "CRD: BE Belgium" /usr/sbin/connectwizard_crd is executed and the following errors occur:
/usr/sbin/connectwizard_crd: line 15: iw: command not found
/usr/sbin/connectwizard_crd: line 21: iw: command not found
....
The second error is repeated a lot of times and this takes a long time.
I comment this line out fttb, because I do not know how to correct the command.
EDIT: I cannot say connection time is shorter though: it remains around 1 minute.

Just one other thing puzzles me: I found another rc.network file at /etc/rc.d/

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

#817 Post by peebee »

Interim delta to LxPupSc-17.09.24T-k64

- Kernel 4.13.3-lxpup64 including @Marv's requested CONFIG_CPU_FREQ_GOV_SCHEDUTIL

- Slackware-Current to Tue Sep 19 20:49:07 UTC 2017

iw has been added as reported by @foxpup
Last edited by peebee on Thu 21 Sep 2017, 20:06, edited 1 time in total.
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

#818 Post by Marv »

23T updated to 24T using the delta. md5sum correct, nothing of note in the update so far. Radkys PupSysInfo 2.7.3 now reports CPU speeds correctly in 4.13 kernels, as does the little cpuwatch I used in my post above (cpu* replaces cpu0). Inxi, hardinfo and wcpufreq don't as yet. The schedutil governor now shows up and runs (Thanks!). It will take a bit to see how I like it but at first glance I think it is a bit more 'adaptive' than conservative. The difference in PupSysinfo and cpuwatch speeds is because the PupSysInfo information was grabbed before starting glxgears and the cpuwatch is dynamic with a 1 sec grab time.

Update: radkys fix applied to wcpufreq also allows it to display speeds correctly. I have a .diff but don't know who maintains that.

Cheers,
Attachments
screenshot.png
(204.7 KiB) Downloaded 1351 times
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:

#819 Post by peebee »

Marv wrote:Update: radkys fix applied to wcpufreq also allows it to display speeds correctly. I have a .diff but don't know who maintains that.
Cheers,
Thanks @Marv - wcpufreq was apparently developed by tazoc who sadly hasn't been on the forum since 2013....

The .pet is in noarch-official so if you send me the changes I'll upload a new version....

Cheers
peebee
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:

#820 Post by peebee »

Anybody else noticed that the 64-bit kernel makes lsmod report module size differently to the 32-bit kernel? First 64-bit 'oddity' that I've noticed - doesn't seem to have any further ramifications??
Kernel 4.9.50 32-bit gives:

Code: Select all

Module                  Size  Used by
iptable_filter          1379  0
ip_tables               9625  1 iptable_filter
snd_hda_codec_via       9338  1
snd_hda_codec_generic    49158  1 snd_hda_codec_via
rt2800usb              16439  0
rt2x00usb               7961  1 rt2800usb
rt2800lib              69770  1 rt2800usb
rt2x00lib              32058  3 rt2800lib,rt2800usb,rt2x00usb
mac80211              328553  3 rt2800lib,rt2x00lib,rt2x00usb
cfg80211              220211  2 rt2x00lib,mac80211
crc_ccitt               1195  1 rt2800lib
rfkill                  8235  1 cfg80211
usblp                   9474  0
snd_pcsp                6269  0
nouveau              1313442  2
mxm_wmi                 1203  1 nouveau
wmi                     6184  2 mxm_wmi,nouveau
i2c_algo_bit            4516  1 nouveau
ttm                    64138  1 nouveau
drm_kms_helper         99176  1 nouveau
k10temp                 2160  0
syscopyarea             2990  1 drm_kms_helper
hwmon                   6646  2 k10temp,nouveau
Kernel 4.13.3 64bit gives:

Code: Select all

Module                  Size  Used by
iptable_filter         16384  0
ip_tables              24576  1 iptable_filter
cpufreq_ondemand       16384  2
snd_hda_codec_via      20480  1
snd_hda_codec_generic    53248  1 snd_hda_codec_via
arc4                   16384  2
joydev                 20480  0
rt2800usb              24576  0
rt2x00usb              20480  1 rt2800usb
rt2800lib              90112  1 rt2800usb
rt2x00lib              40960  3 rt2800lib,rt2800usb,rt2x00usb
mac80211              303104  3 rt2800lib,rt2x00lib,rt2x00usb
cfg80211              221184  2 rt2x00lib,mac80211
usblp                  20480  0
rfkill                 20480  1 cfg80211
crc_ccitt              16384  1 rt2800lib
nouveau              1359872  2
k10temp                16384  0
mxm_wmi                16384  1 nouveau
wmi                    20480  2 mxm_wmi,nouveau
video                  32768  1 nouveau
hwmon                  16384  2 k10temp,nouveau
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

Post Reply