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.
Sorry, BUT disabling the freaking Power Management in that poor video-card is really a epic bad idea. Better to stay on a lower version kernel.
Does disabling DPM mean you do not have power management at all ? I had the impression that you get the older implementation of dynpm (which sucked majorly compared to dpm of course).
Quote:
Originally Posted by gmgf
yes tested all 4.9 série, 4.9.5 need this command.
I use 4.9 from the beginning and i never had such a problem of not being able to reboot (or any other problem for that matter). My card is 6750 which is also evergreen so if you want me to test something, please tell me. Here is my kernel config if you want to compare options.
Does disabling DPM mean you do not have power management at all ? I had the impression that you get the older implementation of dynpm (which sucked majorly compared to dpm of course).
It does mean that you are back to manual power management, with echoing the powerlevel into a file in sysfs, IIRC.
Does disabling DPM mean you do not have power management at all ? I had the impression that you get the older implementation of dynpm (which sucked majorly compared to dpm of course).
I use 4.9 from the beginning and i never had such a problem of not being able to reboot (or any other problem for that matter). My card is 6750 which is also evergreen so if you want me to test something, please tell me. Here is my kernel config if you want to compare options.
finally i have tested two other distro, one with openrc and one with systemd, same problem, with 4.9.
finally i have tested two other distro, one with openrc and one with systemd, same problem, with 4.9.
Weird. My card is practically the same (the only difference i remember between 6 and 5 series is more powerful uvd for video decoding). Is it possible that there is a change in v4.9 that only triggers on your particular implemention's firmware ? Mine is Sapphire.
If you have the time/patience you could bisect the kernel and find the relevant commit.
Code:
# git bisect start -- drivers/gpu/drm
# git bisect good v4.8
# git bisect bad v4.9
.. compile - install - test kernel ..
# git bisect good/bad depending on outcome.
You compile and test each kernel and if the machine shuts down correctly you mark it "good" otherwise you mark it "bad". The "-- drivers/gpu/drm" part will limit the bisection to commits touching only directories below drivers/gpu/drm so it will be way quicker but it may not find the correct commit if the offending change was on another subsystem.
On my system, the Sandisk Cruzer USB Stick has file names in /dev/disk/by-id/, that contain
colons: this causes lilo to fail when using one of these files as a boot disk. This patch
replaces the failure with a warning.
--- ./src/geometry.c.orig 2015-11-21 18:50:18.000000000 -0500
+++ ./src/geometry.c 2016-12-28 18:27:24.322516088 -0500
@@ -1357,16 +1357,12 @@
int geo_open(GEOMETRY *geo,const char *name,int flags)
{
- char *here;
- int user_dev,block_size;
+ int user_dev = -1,block_size;
struct stat st;
- if ((here = strrchr(name,':')) == NULL) user_dev = -1;
- else {
- *here++ = 0;
- warn("%s:BIOS syntax is no longer supported.\n Please use a "
- "DISK section.", name);
- user_dev = to_number(here);
+ if (strrchr(name,':') != NULL) {
+ warn("%s:BIOS syntax is no longer supported: "
+ "Treating as a device file.", name);
}
if ((geo->fd = open(name,flags)) < 0)
die("open %s: %s",name,strerror(errno));
What do I have to do to get this patch included in Slackware?
Thanks Cwizardone. Actually this could have been posted in the [Slackware Security] thread as this release contains a fix for a tagged Critical vulneribility that "can be used to run attacker code and install software, requiring no user interaction beyond normal browsing.".
I don't see how, as that's the whole point of the /dev/disk/by-* hierarchy. But it doesn't matter. Was only a suggestion.
If you want your patch included you'll have to argue your case with Pat I guess.
If you have a machine with one disk, /dev/sda, and you plug in a thumb drive, the real path for the thumb drive will be /dev/sdb; if you have another machine with two disks, /dev/sda and /dev/sdb, and you plug in the thumb drive, the real path will be /dev/sdc. The real paths are different, but the sym link in /dev/disk/by-id will be the same on both machines.
It's not available yet, but please watch for the next version of Flex and update to it as soon as possible. There's an issue in Flex that prevents an unpatched WINE 2.0 from being built:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.