Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sun 10 Dec 2017, 22:45
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Derivatives
LxPupSc - Woof-CE, Slackware-Current, LXDE experiment
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 55 of 58 [865 Posts]   Goto page: Previous 1, 2, 3, ..., 53, 54, 55, 56, 57, 58 Next
Author Message
peebee


Joined: 21 Sep 2008
Posts: 3033
Location: Worcestershire, UK

PostPosted: Sat 16 Sep 2017, 04:41    Post subject:  

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.

_________________
LxPup = Puppy + LXDE
Back to top
View user's profile Send private message Visit poster's website 
Marv


Joined: 04 May 2005
Posts: 918
Location: SW Wisconsin

PostPosted: Sat 16 Sep 2017, 09:58    Post subject:  

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:
#!/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 Very Happy LxPupSc, X-slacko 4.4 and X-tahr 2.0 for my users; LxPupSc, LxPupArtful, ArtfulPup & XFCE_XenialPup64 for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.
Back to top
View user's profile Send private message 
peebee


Joined: 21 Sep 2008
Posts: 3033
Location: Worcestershire, UK

PostPosted: Sat 16 Sep 2017, 11:10    Post subject:  

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=news_item&px=Linux-4.13-Power-Management
Quote:
- 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/kernel/1707.0/01366.html
Quote:
- 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).

_________________
LxPup = Puppy + LXDE
Back to top
View user's profile Send private message Visit poster's website 
Marv


Joined: 04 May 2005
Posts: 918
Location: SW Wisconsin

PostPosted: Sat 16 Sep 2017, 12:01    Post subject:  

Hi peebee,
In your next kernel build could you change
Code:
# CONFIG_CPU_FREQ_GOV_SCHEDUTIL is not set
to
Code:
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 Very Happy LxPupSc, X-slacko 4.4 and X-tahr 2.0 for my users; LxPupSc, LxPupArtful, ArtfulPup & XFCE_XenialPup64 for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.
Back to top
View user's profile Send private message 
norgo


Joined: 13 Nov 2015
Posts: 166
Location: Germany

PostPosted: Sat 16 Sep 2017, 12:38    Post subject:  

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
Back to top
View user's profile Send private message Visit poster's website 
foxpup


Joined: 29 Jul 2016
Posts: 273
Location: europa near northsea

PostPosted: Sat 16 Sep 2017, 16:25    Post subject: connecting wifi  

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/
Back to top
View user's profile Send private message 
peebee


Joined: 21 Sep 2008
Posts: 3033
Location: Worcestershire, UK

PostPosted: Thu 21 Sep 2017, 12:05    Post subject:  

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

_________________
LxPup = Puppy + LXDE

Last edited by peebee on Thu 21 Sep 2017, 16:06; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website 
Marv


Joined: 04 May 2005
Posts: 918
Location: SW Wisconsin

PostPosted: Thu 21 Sep 2017, 13:04    Post subject:  

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,
screenshot.png
 Description   
 Filesize   204.7 KB
 Viewed   1198 Time(s)

screenshot.png


_________________
Pups currently in kennel Very Happy LxPupSc, X-slacko 4.4 and X-tahr 2.0 for my users; LxPupSc, LxPupArtful, ArtfulPup & XFCE_XenialPup64 for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.
Back to top
View user's profile Send private message 
peebee


Joined: 21 Sep 2008
Posts: 3033
Location: Worcestershire, UK

PostPosted: Thu 21 Sep 2017, 15:58    Post subject:  

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

_________________
LxPup = Puppy + LXDE
Back to top
View user's profile Send private message Visit poster's website 
peebee


Joined: 21 Sep 2008
Posts: 3033
Location: Worcestershire, UK

PostPosted: Sun 24 Sep 2017, 13:17    Post subject:  

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

_________________
LxPup = Puppy + LXDE
Back to top
View user's profile Send private message Visit poster's website 
peebee


Joined: 21 Sep 2008
Posts: 3033
Location: Worcestershire, UK

PostPosted: Sun 01 Oct 2017, 10:09    Post subject: LxPupSc-17.10.1T-k64  

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
Screenshot.png
 Description   
 Filesize   121.34 KB
 Viewed   809 Time(s)

Screenshot.png


_________________
LxPup = Puppy + LXDE

Last edited by peebee on Sun 01 Oct 2017, 13:24; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website 
Marv


Joined: 04 May 2005
Posts: 918
Location: SW Wisconsin

PostPosted: Sun 01 Oct 2017, 12:19    Post subject:  

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.

_________________
Pups currently in kennel Very Happy LxPupSc, X-slacko 4.4 and X-tahr 2.0 for my users; LxPupSc, LxPupArtful, ArtfulPup & XFCE_XenialPup64 for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.
Back to top
View user's profile Send private message 
rcrsn51


Joined: 05 Sep 2006
Posts: 11736
Location: Stratford, Ontario

PostPosted: Sun 01 Oct 2017, 12:55    Post subject:  

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
Back to top
View user's profile Send private message 
peebee


Joined: 21 Sep 2008
Posts: 3033
Location: Worcestershire, UK

PostPosted: Sun 01 Oct 2017, 13:29    Post subject:  

Marv wrote:
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....??

_________________
LxPup = Puppy + LXDE
Back to top
View user's profile Send private message Visit poster's website 
Marv


Joined: 04 May 2005
Posts: 918
Location: SW Wisconsin

PostPosted: Sun 01 Oct 2017, 14:30    Post subject:  

peebee wrote:
Marv wrote:
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.

_________________
Pups currently in kennel Very Happy LxPupSc, X-slacko 4.4 and X-tahr 2.0 for my users; LxPupSc, LxPupArtful, ArtfulPup & XFCE_XenialPup64 for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 55 of 58 [865 Posts]   Goto page: Previous 1, 2, 3, ..., 53, 54, 55, 56, 57, 58 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Derivatives
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1468s ][ Queries: 13 (0.0791s) ][ GZIP on ]