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.
Agreed, it made a slight behavior change, but otherwise still the same problem. I've submitted a bug report to Nouveau about it.
HOWEVER, I noticed something else was changed at this same time: LibELF. Since its the same version, I might dig out the DVD and install the old one again and see if anything happens. I don't see how since this all happens before any drives get mounted, but its the only other thing that was changed. (It doesn't help that, even after reading about it, I'm still not entirely sure what LibELF is used for: is it for messing with objects at run-time, at compile time, or what? And what do you do with those objects?)
I'm running 3.14.5, i.e. latest -current (including libelf updates) and having no issues at all... Also using Alien's multilib, etc... did you maybe forget or not update some of the compat32 packages? Working on -current, you may need to update these yourself using his massconvert32.sh script.
I do however use the nvidia binary drivers as Nouveau is just slightly less useful than a stick in the eye imho. Not sure if that is a difference or not given previous posts in this thread.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,117
Original Poster
Rep:
From what I can tell from what has been posted elsewhere by others (see post #10, above) and my own experiences, 16-bit ms-windows applications and some 32-bit ms-windows applications will not run with WINE with the 3.14.4 or 3.14.5 kernels. Re-install the 3.10.30 kernel and the same applications run just fine, as they have for all the years prior to the 3.14.4 kernel.
Last edited by cwizardone; 06-02-2014 at 08:36 AM.
b3b42ac2cbae x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
disabled 16-bit segments on 64-bit kernels due to an information
leak. However, it does seem that people are genuinely using Wine to
run old 16-bit Windows programs on Linux.
A proper fix for this ("espfix64") is coming in the upcoming merge
window, but as a temporary fix, create a sysctl to allow the
administrator to re-enable support for 16-bit segments.
It adds a "/proc/sys/abi/ldt16" sysctl that defaults to zero (off). If
you hit this issue and care about your old Windows program more than
you care about a kernel stack address information leak, you can do
echo 1 > /proc/sys/abi/ldt16
as root (add it to your startup scripts), and you should be ok.
The sysctl table is only added if you have COMPAT support enabled on
x86-64, but I assume anybody who runs old windows binaries very much
does that
The 3.14.12 kernel does not solve the problem/regression. We'll have to wait for the 3.15.x kernel.
@cwizardone and all others who are interested:
Put the following in /etc/rc.d/rc.local:
Code:
echo 1 > /proc/sys/abi/ldt16
This suggestion is per a thread in the WineHQ forums. Caveat: This only works in 3.14.6 and above. In short, if you are running the latest kernel on -current, this will fix the problem. It did for me.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,117
Original Poster
Rep:
Quote:
Originally Posted by mattallmill
@cwizardone and all others who are interested:
Put the following in /etc/rc.d/rc.local:
Code:
echo 1 > /proc/sys/abi/ldt16
This suggestion is per a thread in the WineHQ forums. Caveat: This only works in 3.14.6 and above. In short, if you are running the latest kernel on -current, this will fix the problem. It did for me.
Just curious, where did the OP see the original error message? I'm on 3.14.7 (14.1 upgraded, not brave enough for current ) and I've never seen such a strange message for the nVidia driver.
nvidia 331.67 running great currently... I have an issue with a game in wine that I wrote off as an audio issue. If it turns out to be this well then, uh, holy ****!
Just curious, where did the OP see the original error message? I'm on 3.14.7 (14.1 upgraded, not brave enough for current ) and I've never seen such a strange message for the nVidia driver.
nvidia 331.67 running great currently... I have an issue with a game in wine that I wrote off as an audio issue. If it turns out to be this well then, uh, holy ****!
Thanks for the insights
You can just upgrade the kernel bits (-generic/-huge, (depending on which you use), -modules, -source, -firmware, & -headers) without upgrading anything else. I do that all the time. It won't hurt anything.
EDIT: And, by the way, the audio issue might well be the lack of a program (OpenAL). You can find both versions (x86 & x86_64) at Alien BOB's repository.
Last edited by 1337_powerslacker; 07-24-2014 at 03:23 PM.
Reason: Possible solution for audio issue
Just as an addendum to this thread: kernel 3.16.x does not require this workaround, as WINE will work automatically. If you have this kernel running, you may remove the workaround from /etc/rc.d/rc.local.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,117
Original Poster
Rep:
Quote:
Originally Posted by mattallmill
Just as an addendum to this thread: kernel 3.16.x does not require this workaround, as WINE will work automatically. If you have this kernel running, you may remove the workaround from /etc/rc.d/rc.local.
The WINE problem has been fixed in the 3.14.16 kernel.
Thanks!
Last edited by cwizardone; 08-09-2014 at 07:01 AM.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,117
Original Poster
Rep:
Quote:
Originally Posted by Alien Bob
So it is good news that that kernel just landed in Slackware-current...
This is what I meant, i.e., the regression has been fixed in the latest kernel in -current.
From what I've read it didn't appear that the problem was fixed until the 3.15 kernel, so, perhaps, Mr. Volkerding was kind enough to patch the 3.14.16 kernel?
If so, Many Thanks!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
) and I've never seen such a strange message for the nVidia driver. 
