slacko-700 rc3

[prehistoric]

My wifi problems with different systems are relative, not absolute. They seem more likely to happen on this slow machine with a recent system. Several things make me suspect timing. I tried to install Peasy WiFi 4.2 and probably screwed it up. I never could get a scan showing any networks.

I still don't understand why I can sometimes connect if I go back to interface setup before trying to connect, when repeated attempts to use an existing profile fail.

[mavrothal]

Re: Wifi issues
There is an informative thread regarding Slackware and dropped connections in the linuxquestions forum
Suspects:
Driver/firmware for the problematic wifi card (Identify and make sure is the latest for your kernel)
dhcpcd (replace with dhcpclient that appears ok)
11n wifi band (inactivate in module.conf)
IPv6 (inactivate in modules.d)
Regional settings (set correctly with "iw reg set <2 letter country code>)

However, my first guess would be to change "slaac private" to "slaac hardware" in /etc/dhcpcd.conf or comment it out totally as it both hits on dhcpcd and IPv6

[bigpup]

Wifi issue.

Slacko 6.9.9.9 32bit

Based on mavrothal's post.

I looked at the /etc/dhcpcd.conf in Xenialpup 7.0.8.1.
It is much smaller and has less commands in it, than the one in Slacko 6.9.9.9.

So, I replaced /etc/dhcpcd.conf with the one from Xenialpup 7.0.8.1.

So far it seems to be working.
Wifi is working OK with no problems.

I will test for some time and see how it does!!!

This is the /etc/dhcpcd.conf I am now using:

Code: Select all

# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Inform the DHCP server of our hostname for DDNS.
hostname
# To share the DHCP lease across OSX and Windows a ClientID is needed.
# Enabling this may get a different lease than the kernel DHCP client.
# Some upstream DHCP servers may also require a ClientID, such as FRITZ!Box.
#clientid

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Most distributions have NTP support.
option ntp_servers
# Respect the network MTU.
option interface_mtu
# A ServerID is required by RFC2131.
require dhcp_server_identifier

# A hook script is provided to lookup the hostname if not set by the DHCP
# server, but it should not be run by default.
nohook lookup-hostname

UPDATE:
After 3rd reboot.
Wifi is back to not working correctly.
Slow and cuts off and on.
So, this did not fix it.

Seems strange that several things I have tried, seem to fix it, but not for long term.

I have had the best results using the 4.9.13 kernel.

[zigbert]

/root/.packages/woof-installed-packages contains cd-paranoia.

Code: Select all

libcdio-paranoia-10.2+0.93+1|libcdio-paranoia|10.2+0.93+1|1|BuildingBlock|240K|slackware64/l|libcdio-paranoia-10.2+0.93+1-x86_64-1.txz|+libcdio|CD paranoia libraries from libcdio|slackware64|14.2||

Can't see any apps depending on this.
The ripper included in Slacko is a pMusic frontend, and it does not use cdparanoia..

[prehistoric]

Wifi issue.

Slacko 6.9.9.9 32bit
...
Seems strange that several things I have tried, seem to fix it, but not for long term.

...

This strongly suggests a nondeterministic problem involving multiple processes and race conditions. It might be fixed on individual installations by inserting delays, but this will vary as you go to different hardware.

I am particularly puzzled by a number of situations in which scanning for networks doesn't find anything in an environment with half a dozen networks seen on another device next to this machine. Even when networks are found they are surprisingly weak, even though the router/AP is in an adjacent room. When the machine succeeds in negotiating a connection I always find signal strength higher than seen during the scan. What???

The machine is problematic, even running other systems, but it isn't completely unusable. The probabilities change.

[rcrsn51]

@bigpup: If you suspect that the problem is caused by dhcpcd and want to rule it out as the culprit, you should try a connection manager that doesn't use it, like PWF.

[bigpup]

rcrsn51,

I did not know that about PWF.

I will try it and report back.

Thanks for your contributions to Puppy!!

[01micko]

rerwin updated his dhcpcd-dropwait sources so I built them for 32 and 64. Probably best to save the pet somewhere and install it in a pristine boot before configuring the network. The dhcpcd.conf is a bit simpler but if you use frisbee that has its own dhcpcd.conf anyway.

Make sure you get the correct version for your system. If not sure run uname -m in a terminal.

[bigpup]

01micko,

Wifi issue.

I will try that new dhcpcd and test to see if it helps with my issues.
Playing with dhcpcd did help, just not 100%.
Maybe your new pet will do it.

I will report findings.

I have not 100% determined this is not something to do with the rtl8821ae firmware.
Newer kernels seem to help and they are probably using newer firmware drivers.
This driver has had issues in the past and not sure they all got corrected.

I think I will also try the newer firmware idea and see how that works.

I am so happy I have my computer in a room with no windows.
It would not be in that room, if there was a window!

[bigpup]

@bigpup: If you suspect that the problem is caused by dhcpcd and want to rule it out as the culprit, you should try a connection manager that doesn't use it, like PWF.

Tried PWF

It helped to make improvement in WIFI issue, but not 100% fix.

I am starting to think I may be dealing with rtl8821ae firmware issues.
Newer Linux kernels, seem to work better, and a Google search brings up a lot of the same issues, I see, for this rtl8821ae firmware driver.

Any ideas on how to get a newer firmware driver?

My best results are when using the 4.9.13 kernel.
That is the newest one I have tried.

[rcrsn51]

If you go here and look under rtlwifi, there is a version of rtl8821aefw_29.bin dated 2017-01-06.

[prehistoric]

@bigpup,

I'm encountering some weirdness with the rt2500, for which the firmware should be stable. Part of the problem is not your firmware. Nothing prevents multiple layers of problems.

I've now installed the 32-bit i686 version of dhcpcd 01micko provided, and things look better. We'll see how this holds up. At the moment I'm not using PeasyWiFi on this installation because I want to test dhcpcd.

Running tahrpup 32 6.0.5 on this same machine I reached the point where I have decent WiFi management with either the Dougal network tool or PeasyWiFi 4.2. Ran for several hours.

If this one holds up as well, I'd say we're ready to release.
Added: on this one problematic machine it has now been working for several hours.

Minor problem which may be strictly personal: the activity graph on the panel is almost invisible. Running on a slow machine with no blinken-lights for disk activity, (because there is no disk,) I need some visual cue to tell if a browser is eventually going to wake up. Launching two instances of a browser that would like all RAM is painfully slow and confusing.

Another very minor quibble: how long should it take to update the status of the drive icons? I've seen a drive icon sitting there for over a minute after I had unmounted and removed the drive. Eventually, I restarted the X-server to refresh the drive icons.

[01micko]

@bigpup - you can actually try the 64 bit k4.9.30 in 32 bit on your box - if nothing else it will tell us it might work better - or not! If it does work then I can compile 4.9.3x for 32 bit and probably ditch the palemoon isos and use firefox. I doubt firmware will make a difference because the kernel-kit build script has an option to get latest firmware which I always use. Also, there probably exists a manufacturer driver on github - I have an rtl8192eu dongle that has no in kernel tree driver and I just built it for 64 bit, posting from it now.

@prehistoric - I have dillo browser built but not uploaded - although I see there is a version in slackware-extra repo if you search ppm. It's tiny and fast but not altogether compliant with these new fancy web-pages so I suppose it would depend on what you want to to do with it; netsurf is also available.

As for icons not refreshing - yes I have seen it on slower kit. jlist did do some work on those so I'll raise an issue on github.

@zigbert

Code: Select all

# ldd `which mplayer` | grep paranoia
	libcdio_paranoia.so.2 => /usr/lib64/libcdio_paranoia.so.2 (0x00007fc4dc25d000)

[Sailor Enceladus]

As for icons not refreshing - yes I have seen it on slower kit. jlist did do some work on those so I'll raise an issue on github

I saw it happen in a new build of Stretch yesterday too, when clicking on my fat32 drive. I'm quite sure it's the "two pinboards" bug again, because if I go to /root/.pup_event, the icons are mounted correctly there, and afterwards, changing the wallpaper complains about the wrong pinboard. Before it used to happen when you change the hostname in PUPMODE 5, but now it seems to have taken on a new form, possibly in savefiles... but I haven't found a consistent way to trigger this new version yet.

[mavrothal]

Tried a bit slacko64 on my MacBook
To begin with here is the Broadcom wl wifi driver, as b43 does not work on Macs
It also needed to force the "uxa" AccelMethod for the intel driver and disable some pesky gpe interrupts that flood the CPU.
One think I could not manage is to get it detect the touchpad properly or even just load the synaptics driver. Not sure if it is Xserver, udev or kernel. I should just point out that Mint handles it perfectly and fd710 adequately. Slacko's is unusable really (cmon Mick, I know you have a macbook at home )

One other thing. Cryptsetup is not in the main sfs so the LUKS encryption option is not offered at shutdown.
I also compiled the broadcom facetime camera driver but although is loaded fine and activates the camera is giving no image and a lot of GPU complains. If anyone wants to take a further look let me know so I upload the pet (or try it yourself compiling from source)

That's it for Pup MacSlack

[radky]

Re: testing slacko-6.9.9.9-k3.16-4G-FF-ABI

The following scenario is reproducible:

1 - With ROX-Filer, click-mount any sfs and choose 'view contents'
2 - Go to Nathan's wallpaper setter to change background
3 - At this point, Rox creates a second pinboard (/root/.config/rox.sourceforge.net/ROX-Filer/pb_Default) and clicking the desktop will alternate between the original pinboard and this new pb_Default pinboard.
4 - Restarting X is required to reclaim the normal pinboard
5 - No problem with the ROX pinboard in current iterations of tahrpup or tahrpup64

[bigpup]

Wifi issue.

Something to think about while I continue to try ideas.

For now I am only testing 32bit version of Slacko.

I am still testing ideas and trying different things.

Note:
This seems to be common to every version of Slacko 6.9.9.9 32bit.
I wonder if this has something to do with loading all the sfs layers when it boots.
Maybe timing issue.
Something that is in one sfs, needing something that is in another sfs, and whatever not getting loaded at the time it needs to.

This is what I see:

ininitial boot of a frugal install of Slacko 6.9.9.9 32bit.
Setup wifi network connection.
Seems to work OK.
No problems.

Make a save.

Reboot using the save and Wifi starts having problems.
Slow and cuts off and on.

Using the save is just one more layer added to the layered filesystem.
This seems to cause the wifi problem to start happening.

Any ideas

Example:
I am posting this from an initial boot of Slacko 6.9.9.9 32bit K4.4.70
Have not made a save.
Wifi is working OK, no problems.

[prehistoric]

Re: testing slacko-6.9.9.9-k3.16-4G-FF-ABI

The following scenario is reproducible:

1 - With ROX-Filer, click-mount any sfs and choose 'view contents'
2 - Go to Nathan's wallpaper setter to change background
3 - At this point, Rox creates a second pinboard (/root/.config/rox.sourceforge.net/ROX-Filer/pb_Default) and clicking the desktop will alternate between the original pinboard and this new pb_Default pinboard.
4 - Restarting X is required to reclaim the normal pinboard
5 - No problem with the ROX pinboard in current iterations of tahrpup or tahrpup64

This is exactly what happened in an earlier test of mine. I stopped chasing that bug because the Wifi bug was crippling operation.

I've long wanted to rewrite the Nathan wallpaper setter for a different reason, but now see that I am never going to regain the ability to deal with convoluted code.

The problem which originally bothered me was the discovery that Nathan made a copy of the background file which was renamed "original", and then modified the true original to fit the screen. This raised a red flag because many people will use the tool to add photos from a flash drive rather than copy them to /usr/share/backgrounds. You don't want to deal with a photographer who has just had a large and irreplaceable photo resized to 1024x768. The wallpaper setter should only modify pictures in a private directory where people are unlikely to place images they want to keep.

Aside: my problem with browsers above was less about lightweight browsers like dillo than about indicators of activity while waiting for big programs to start on slow machines. I couldn't tell whether or not I had actually launched a browser, and more than once launched a second instance. Another solution would be to quickly launch a placeholder that would be on the screen until the real program came up and replaced it.

The way the Internet is changing, I doubt that any lightweight browser will function properly on a large percentage of popular sites. With current phone and tablet designs all past the limitation to 1 GB of RAM I doubt there is any way back. This is ominous for other reasons. I doubt that any program as large as 1 MB has ever been completely debugged. Programs using 1 GB are at least 1,000 times less likely to be debugged, and this is without mention of malicious use of those programs.

Here's an example of just how ridiculous a Turing-complete language can be, and it doesn't even include Word or Excel macros. Customization features probably make many large programs Turing-complete, which means they could do anything. Consider this when you think about which code you can trust.

[Sailor Enceladus]

@bigpup: I might have missed this, but does Slacko 6.9.9.8 or 6.9.9.6 work normally, or 6.9.6.7?

The problem which originally bothered me was the discovery that Nathan made a copy of the background file which was renamed "original", and then modified the true original to fit the screen. This raised a red flag because many people will use the tool to add photos from a flash drive rather than copy them to /usr/share/backgrounds. You don't want to deal with a photographer who has just had a large and irreplaceable photo resized to 1024x768. The wallpaper setter should only modify pictures in a private directory where people are unlikely to place images they want to keep.

I agree. A better solution might be to rename the stretched/scaled/altered image to something new, like default.[extension].

Aside: my problem with browsers above was less about lightweight browsers like dillo than about indicators of activity while waiting for big programs to start on slow machines. I couldn't tell whether or not I had actually launched a browser, and more than once launched a second instance. Another solution would be to quickly launch a placeholder that would be on the screen until the real program came up and replaced it.

Agree here too, big browsers should have a message ("Opening Firefox...") to let you know what's going on. I don't think I've used any computer where Firefox, IE, Chrome opened instantly the first time. I blame big browser devs for this oversight.

[rcrsn51]

@bigpup: Is your WiFi problem with the actual WiFi connection or with a browser running over WiFi?

Here is a quick WiFi speed test:

Code: Select all

ping -I wlan0 -c 20 192.168.2.1

Use the IP address of your router. Check the summary at the end.

If would be useful if you had a separate USB WiFi adapter that you could test for comparison purposes.