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

[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.

[Marv]

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"

[peebee]

The problem is that /proc/cpuinfo is not being generated correctly by the kernel.

Thanks Jim - that was the clue that google wanted ....
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).

[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.

[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]

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/

[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

[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,

[peebee]

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

[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

[peebee]

LxPupSc-17.10.1T-k64 is a 32-bit woof-ce 'testing' branch build with a 64-bit kernel (therefore only compatible with 64-bit capable processors)

LxPupSc-17.10.1T-k64.iso {devx} - (devx does not include kernel sources or headers) {kernel 4.13.4-lxpup64 sources}
iso md5 = c1aa378bb649ef6dc658e7d224a97d9f

Delta from 17.09.1T is available

- kernel 4.13.4 64-bit (alternative 32-bit kernels 3.16.x 4.4.x & 4.9.x also available - all need firmware in the fdrv)
- Made from Slackware-Current as of Fri Sep 29 22:58:54 UTC 2017
- BUILD_FROM_WOOF='testing;3b243afd;2017-09-30 22:50:06 +0800'
- web browser in adrv is light-48.0
- firmware is in fdrv
- alternative fall-back xorg is in ydrv (no need to install unless needed)

**N.B. the 64-bit kernel means that any kernel drivers have to be built in a true 64-bit system - slacko64 with it's own devx is suggested but use the kernel sources above

Woof-CE build repository is: http://smokey01.com/peebee/slackocurrent/

Chromium, Firefox, Palemoon and Seamonkey are in the repository and installable via Internet -> Get Web Browser

The versions of the browsers as of 29-sep-2017 with their md5sums are:
chromium-61.0.3163.100+pepper_27.0.0.130 :ca66b7319051449bb86e344a6eeca705
firefox-52.4.0esr :b98370e14612b90d2d69b5775a423504
palemoon-27.5.0 :79c6305526f567792be7d3f3d4d61a2f
seamonkey-2.48 :05b91afef8b60bda21343a45da0aae49

firefox-56, vivaldi and min are also available

[Marv]

Updated 17.09.24 to LxPupSc-17.10.1T-k64 using the 17.09.1 to 17.10.1 delta. Didn't see the iso md5sum, just that for the devx iso? Anyway, update went perfectly on the i5 based laptop.

The oddity I posted on here regarding FM copies to a YASSM mounted samba server continues with the 4.13.4 kernel. Time to complete is 3 to 4 minutes for a 256MB savefile with the 4.13.4 kernel and 22 seconds with the 4.12.10 LxPupSc 64b kernel swapped in LxPupSc 17.10.1, Pretty much in line with what I saw there.

[rcrsn51]

Hi Marv:

Just out of curiosity, if you didn't mount the share in YASSM and let gvfs handle everything, does it make a difference?

Bill

[peebee]

Updated 17.09.24 to LxPupSc-17.10.1T-k64 using the 17.09.1 to 17.10.1 delta. Didn't see the iso md5sum, just that for the devx iso? Anyway, update went perfectly on the i5 based laptop.

The oddity I posted on here regarding FM copies to a YASSM mounted samba server continues with the 4.13.4 kernel. Time to complete is 3 to 4 minutes for a 256MB savefile with the 4.13.4 kernel and 22 seconds with the 4.12.10 LxPupSc 64b kernel swapped in LxPupSc 17.10.1, Pretty much in line with what I saw there.

Oops - fixed md5 for iso...above

There have been kernel changes - hibernation, your cpu frequency module, some BarryK suggestions from his blog....??

[Marv]

Updated 17.09.24 to LxPupSc-17.10.1T-k64 using the 17.09.1 to 17.10.1 delta. Didn't see the iso md5sum, just that for the devx iso? Anyway, update went perfectly on the i5 based laptop.

The oddity I posted on here regarding FM copies to a YASSM mounted samba server continues with the 4.13.4 kernel. Time to complete is 3 to 4 minutes for a 256MB savefile with the 4.13.4 kernel and 22 seconds with the 4.12.10 LxPupSc 64b kernel swapped in LxPupSc 17.10.1, Pretty much in line with what I saw there.

Oops - fixed md5 for iso...above

There have been kernel changes - hibernation, your cpu frequency module, some BarryK suggestions from his blog....??

Seems to occur pretty sharply with the 4.12 to 4.13 kernel transition so far as I can see. I'll have a look at the 4.13.0 dotconfig, I think it predates most of those other changes and still shows the anomaly. I also see identical behavior in battleshooters 4.13.x series kernels and in yours. I also have installed gvfs 1.30.4 (from an 0ubuntu deb) with no change in behavior. I'm running the 4.12.10-lxPup64 kernel in LxPupSc 17.10.1T-64 right now.

[belham2]

Hi Peebee,

Can you tell me what I did (or does it come like this?) that causes my laptop's "Up" arrow key (see pic below) to launch mtpaint-screensnapshot? This is driving me nuts. I don't want a screensnapshot; I want to use the "Up" arrow key for what it is intended for--moving the cursor up. Thus, I want to re-map the key, or disable it, and I cannot figure out which file in lxde/openbox (I'm not in jwm)---is it one of the two files in /root/.config/openbox, either 'lxde-rc.xml' or 'rc.xml'----where I can achieve this? I looked at both files, and I cannot see in them where the Up arrow key has been re-mapped to the mtpaint-screensnapshot launch? I found in jwm where mtpaint-screensnapshot is mapped to the "Print" keyboard key, but like I said, I'm not using jwm. I am always pretty much in the LxPupSc environment the way it comes out of the box, because the way you set everything up is ideal for me like it is. Thanks!



P.S. Thanks for latest LxPupSc delta update.

[belham2]

Hi Peebee,

Can you tell me what I did (or does it come like this?) that causes my laptop's "Up" arrow key (see pic below) to launch mtpaint-screensnapshot? This is driving me nuts. I don't want a screensnapshot; I want to use the "Up" arrow key for what it is intended for--moving the cursor up. Thus, I want to re-map the key, or disable it, and I cannot figure out which file in lxde/openbox (I'm not in jwm)---is it one of the two files in /root/.config/openbox, either 'lxde-rc.xml' or 'rc.xml'----where I can achieve this? I looked at both files, and I cannot see in them where the Up arrow key has been re-mapped to the mtpaint-screensnapshot launch? I found in jwm where mtpaint-screensnapshot is mapped to the "Print" keyboard key, but like I said, I'm not using jwm. I am always pretty much in the LxPupSc environment the way it comes out of the box, because the way you set everything up is ideal for me like it is. Thanks!



P.S. Thanks for latest LxPupSc delta update.

Just wanted to followup on the question I posted above: figured this much out. One of the files in /root/.config/openbox is the rc.xml file & it seems to be involved in this problem (editing the lxde-rc.xml seems to do nothing). I found an entry in it for 'mtpaint' mapped to key "0x6F", whatever that is. Putting a # before all the lines for this entry mapping stopped 'mtpaint -s' from launching when hitting the "Up" key. But then the "Up" is no longer functional, does nothing. And the bigger problem is, on reboots, my changes to this 'rc.xml' are getting wiped and the launching of 'mtpaint -s' is back again on my "Up" arrow key.

Anyone can steer me in the right direction to fix this permanently? Thank you.


[Edit: fixed, made changes in both lxde-rc.xml & rc.xml, and both held with reboots. Also re-mapped this laptop's F2 thru F6 functions keys: now have working F2 (sound on/off), F3 (sound decrease), F4 (sound increase), F5 (redshiftgui-screen brightness decrease) and F6 (redshiftgui-screen brightness increase). And the "Up" arrow is now blessedly functioning as normal; goodbye to the 'mtpaint -s' launching madness ]

[Marv]

Hi Marv:

Just out of curiosity, if you didn't mount the share in YASSM and let gvfs handle everything, does it make a difference?

Bill

Sorry, I just saw this now. I did connect directly from PCManFM using gvfs and test. I get the same slow 3 minute or more transfer time for the 256Mb savefile. I 'think' that gvfs is the problem but I've checked its versions as well as libsmbclient etc. and they are all either the most recent or updating them gave no change in speeds. Kernel 4.13 did change the default cifs mount to SMB3 from SMB1 but locking my samba server to SMB1, SMB2, or SMB3 gives me no change in the speeds. I normally run with it locked to SMB3 to minimise negotiation and with strict allocate =yes. cli, rsync and Rox-Filer transfers always great no matter what the configuration. Thunar and PCManFM slow. The only common denominator I see is gvfs/kernel interaction but I'm kind of stuck there for now.

Jim

[peebee]

Can you tell me what I did (or does it come like this?) that causes my laptop's "Up" arrow key (see pic below) to launch mtpaint-screensnapshot

Hi - I don't see this problem on LxPupSc..... I checked with a pristine frugal install and the keys all worked as expected.

Was your install using an existing save folder? What had you installed? Have you done any theme changes in LXDE or in JWM?

[muggins]

Can you tell me what I did (or does it come like this?) that causes my laptop's "Up" arrow key (see pic below) to launch mtpaint-screensnapshot?

I also have this on my keyboard. I just edit /root/.config/openbox/rc.xml and
find the lines that call mtpaint and change it to:

Code: Select all

<keybind key="111">
      <action name="Execute">
        <startupnotify>
          <enabled>true</enabled>
          <name>Print Screen</name>
        </startupnotify>
        <command>mtpaint -s</command>
      </action>
    </keybind>

Then restart window manager.