Slackware 15 — 4
One of the irregularities while testing 15.0 were error messages when starting the rc.alsa script. Some research indicated this startup script no longer is needed on most systems. Not being active in testing Slackware Current means I missed receiving that memo. Disabling that script (chmod -x) resolved the nuisance messages. Curiously the alsamixer and alsactl store commands still seem functional and necessary.
Another oddity was a boot message SGX disabled by BIOS. The message appeared only with the office system. In the BIOS the respective configuration is SW Guard Extension. The only options are Software controlled and Disabled. Neither option eliminated the boot message. Because the Slackware kernel is configured with SGX support built-in rather than as a module, the only way to stop the annoying useless message was using the nosgx boot parameter. The less palatable option is compiling my own kernel with the option as a module and then blacklisting the module.
On the Lenovo T400 laptop there is the infamous [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun boot spew that sporadically appears. Nobody on this planet seems to have a cure. As a best guess I added the boot parameter intel_idle.max_cstate=3. To derive the number of 3 I used grep . /sys/devices/system/cpu/cpu0/cpuidle/state*/name to determine the maximum number of levels for that system. All for naught because the error message still appears every 20 boots or so. Do not dare say the message is harmless. Annoying messages should be resolved or not exposed at all.
The Unknown key identifier ‘zoom' silliness resurrected with the T400 laptop. After several passes of testing 15.0 on the T400 I thought I had eliminated the nonsense after deleting /etc/udev/hwdb.bin and letting udev rebuild the file. Yet the silly message appears about every 20 boots or so. I again created a sledge hammer with a custom 60-keyboard.hwdb file, this time commenting out six entries. Yet the message still appears every 20 boots or so.
After the T400 laptop has been powered off for a while, powering on always results with the screen backlight being dim. Once upon a time I fixed this in rc.local, but with the new kernel the problem now seemed persistent rather than intermittent. I am hoping the following udev rule resolves the annoyance:
# Set backlight level to 15 (maximum):
SUBSYSTEM=="backlight", ACTION=="add", KERNEL=="acpi_video0", ATTR{brightness}="15"
As I continue my traditional way of booting to console, on all systems there is a nominal pause with the new startx script before actually launching X. Not long enough to scream about but a pause. Someday I will have to investigate further.
Another spasm was midnight commander (mc). This was not caused directly by 15.0 but became annoying while testing 15.0. Sometimes there is a notable delay launching mc. I have seen this problem before but not in a long while. This time the delay became annoying because I did not see the delay on all test systems. Using strace the culprit pointed toward the loss of the house network DNS server. In some of my test scenarios the DNS server is unavailable. Apparently mc is designed to query a DNS server when launching. If the DNS server is unavailable, as might be the case with testing, then mc polls several times before fully launching. Some sleuthing revealed that disabling SMB support might resolve the problem. This requires recompiling without that support option. SMB support is not needed on Linux systems in the house network and this strategy seemed palatable. This trickery seemed to succeed, but I have to test further. This seems to indicate the DNS query is only part of the SMB code. This is all kind of weird because mc works fine in runlevel 1 when there are no network services running, but perhaps mc is designed to detect the network.
The oddities of mc did not end there. When I rebooted from the 15.0 testing to the 14.2 stable partition, mc stopped functioning correctly. For example, I could not change directories. I discovered the user’s ini file had changed. Seems the newer version changed many verbal settings of true and false to binary settings of 1 and 0. The specific culprit seemed to be the command_prompt option changing from true to 1. Restoring that specific option to true resolved the problem.
On the office computer the ethtool command does not display network controller information unless network services are running or the device link explicitly initiated. I cannot replicate this behavior on other systems, which includes Nvidia MCP77 (forcedeth), Intel 82567LM (e1000e), and Qualcomm Atheros QCA8171 (alx). This is annoying because ethtool is a handy troubleshooting tool. Network controller information should always be accessible. I lacked data but I suspected the problem happens only with Realtek controllers. My office system has a Realtek RTL8111/8168/8411.
On one of the AMD test systems the new kernel always spews the following error: i2c i2c-3: sendbytes: error -110. This is related to sensors and fan control. How can a system function fine for more than a decade then a new kernel says the system is broken?
Regressions.
Posted: Category: Usability Tagged: Slackware
Next: Slackware 15 — 5
Previous: Slackware 15 — 3