SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: VM Host: Slackware-current, VM Guests: Artix, Venom, antiX, Gentoo, FreeBSD, OpenBSD, OpenIndiana
Posts: 1,021
Rep:
Quote:
Originally Posted by kjhambrick
all --
Still running without CONFIG_ACPI_EC_DEBUGFS without any ill effects ...
Code:
# grep CONFIG_ACPI_EC_DEBUGFS /boot/config-*-6.1.12.kjh
/boot/config-generic-6.1.12.kjh:# CONFIG_ACPI_EC_DEBUGFS is not set
/boot/config-huge-6.1.12.kjh:# CONFIG_ACPI_EC_DEBUGFS is not set
I don't understand what are you saying. Have you red option description in the config file:
Quote:
Be aware that using this interface can confuse your Embedded Controller in a way that a normal reboot is not enough. You then have to power off your system, and remove the laptop battery for some seconds. An Embedded Controller typically is available on laptops and reads sensor values like battery state and temperature. The kernel accesses the EC through ACPI parsed code provided by BIOS tables. This option allows to access the EC directly without ACPI code being involved. Thus this option is a debug option that helps to write ACPI drivers and can be used to identify ACPI code or EC firmware bugs.
Clearly enabling this option can cause some issues if someone (developer) is using it.
Why confuse users who want to compile kernel. Enabled or not this option has no effect on kernel stability.
IOW, I turned off the Embedded Controller Debug Option because it sounds dangerous and I don't write ACPI Code that I need tp debug.
CONFIG_ACPI_EC_DEBUGFS was set as 'm' in the default Slackware Kernel Configs.
-- kjh
1) see @marav post above
2) this option is available since 5.x.x at least for one year now and probably always enabled by default in Slackware kernel and no reports about adverse effect were posted
3) if you browse kernel config there is a lot of dangerous options.
I think that users have no reason to get gloomy just because some options deemed potentially dangerous are enabled
If anyone is paying attention to this, the most recent kernel and most recent nvidia driver still do not cooperate. When quitting a KDE session (plasma) I never regain a command prompt in run level 3. I have to ssh into the box and reboot it.
If anyone is paying attention to this, the most recent kernel and most recent nvidia driver still do not cooperate. When quitting a KDE session (plasma) I never regain a command prompt in run level 3. I have to ssh into the box and reboot it.
Yeah, first time I had to REISUB out. 2nd time console popped back, but this is the 12th version of the 6.1 kernel, and there isn't a fix yet? I mean, I get that some bugs take time, but this one never should've seen the light of day. Honestly, it's been making AMD look really appealing. (I've been contemplating upgrading my video card for some time, but always seem to have other things to pay for first. Sucks being an adult.)
I think the newer kernels have demolished the schedutil scaling governor for my i7 3770. The performance and ondemand scaling governors work fine without programs becoming unresponsive for a moment.
I think the newer kernels have demolished the schedutil scaling governor for my i7 3770. The performance and ondemand scaling governors work fine without programs becoming unresponsive for a moment.
I think the newer kernels have demolished the schedutil scaling governor for my i7 3770. The performance and ondemand scaling governors work fine without programs becoming unresponsive for a moment.
Same here, random and I have to pkill the program.
I have an i7-10750H
Distribution: VM Host: Slackware-current, VM Guests: Artix, Venom, antiX, Gentoo, FreeBSD, OpenBSD, OpenIndiana
Posts: 1,021
Rep:
Quote:
Originally Posted by RadicalDreamer
I think the newer kernels have demolished the schedutil scaling governor for my i7 3770. The performance and ondemand scaling governors work fine without programs becoming unresponsive for a moment.
Not sure if this counts but in 6.2-rc8 schedutil works without hickups under (minor) stress e.g compiling kernel or other software.
Note (random)
heh I got windows 10 icon on the system that never booted to windows. That is good actually
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.