LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Kernel 3.14.4 and the Nvidia Drivers (and WINE). (https://www.linuxquestions.org/questions/slackware-14/kernel-3-14-4-and-the-nvidia-drivers-and-wine-4175504913/)

cwizardone 05-13-2014 10:37 PM

Kernel 3.14.4 and the Nvidia Drivers (and WINE).
 
The 337.19 (beta) installs without error, but WINE does not work.

The 331.67 driver repeatedly issued this error,

Quote:

Unable to determine the architecture of the file '/usr/lib64/libEGL.la,' which has an architecture-specific conflict.

during installation, but was bootable. WINE also does not work
with this driver.

The 331.49 and 325.15 versions of the driver would not build. Period.

The 304.121 driver installed without error, but WINE would not work.

cwizardone 05-14-2014 12:04 AM

Following up:
WINE has worked with previous kernels and Nvidia drivers and as recently as a few hours ago with the 3.10.30 kernel and the 325.15 Nvidia driver.
Now, with the 3.14.4 kernel and the Nvidia 337.19 driver this error is reported when trying to start WINE,

Quote:

env WINEPREFIX="/home/username/.wine" wine "C:\AHDW\AHD3.EXE"
modify_ldt: Invalid argument
modify_ldt: Invalid argument
modify_ldt: Invalid argument
modify_ldt: Invalid argument
modify_ldt: Invalid argument
err:module:attach_process_dlls "krnl386.exe16" failed to initialize, aborting
err:module:LdrInitializeThunk Main exe initialization for L"C:\\windows\\system32\\winevdm.exe" failed, status c0000005

ondoho 05-14-2014 12:45 AM

is your system working otherwise?

the last error message says nothing about nvidia or even graphics.

shouldn't you post to http://forum.winehq.org/ ?

Alien Bob 05-14-2014 02:03 AM

Seems to be a known issue with kernels >= 3.14.3 : https://lkml.org/lkml/2014/5/7/145
I'll try to run Wine at home tonight and see what happens.

Eric

cwizardone 05-14-2014 09:57 AM

@ondoho,
Yes, other than that, the system is working fine.

@Alien Bob,
It appears to have something to do with 16-bit vs 32-bit. There are two versions of the same program on the CD. In one directory, labeled, win, there is the 16-bit version and in the directory labeled, win32 is, of course, the 32-bit version. The 16-bit will not run. The 32-bit version will run off of the CD, but since the setup program is 16-bit I cannot install the program to the hard disk.

Edit in: Just read the post at the link in your message above. Apparently this problem is also effecting some 32-bit win programs.
Just another day in paradise. :)

Edit in: Apparently wine-pipelight is also affected.

cwizardone 05-14-2014 10:58 AM

Just re-installed the 3.10.30 kernel and the Nvidia 325.15 driver and things have returned to what passes for normal around here.

We'll try again with the next kernel "upgrade."
:)

Alien Bob 05-15-2014 04:26 PM

Quote:

Originally Posted by cwizardone (Post 5170746)
@ondoho,
Yes, other than that, the system is working fine.

@Alien Bob,
It appears to have something to do with 16-bit vs 32-bit. There are two versions of the same program on the CD. In one directory, labeled, win, there is the 16-bit version and in the directory labeled, win32 is, of course, the 32-bit version. The 16-bit will not run. The 32-bit version will run off of the CD, but since the setup program is 16-bit I cannot install the program to the hard disk.

Edit in: Just read the post at the link in your message above. Apparently this problem is also effecting some 32-bit win programs.
Just another day in paradise. :)

Edit in: Apparently wine-pipelight is also affected.

I tried the SilverLight test page http://bubblemark.com/silverlight2.html and watched a bit of television in the Widevine plugin, both are still working just fine with the 3.14.4 kernel in am running on this slackware64-current box.

Eric

cwizardone 05-16-2014 10:20 AM

By disabling the plug-ins and un-installing pipelight and then re-installing and re-enabling, I was able to get them to work with the 3.14.4 kernel.

I hope "they" fix the WINE problems as suggested by Mr. Torvalds.
:)

Alien Bob 05-16-2014 12:45 PM

cwizardone, if you are the C. Wizard who is posting on my blog, you seem to have an installation which has been mangled (or just customized) so much that nothing works as advertised any longer. In this wine case too, I did not experience these issues you describe, and they have nothing to do with KDE4 even!


Eric

cwizardone 05-16-2014 01:33 PM

Some 32-bit ms-windows applications will work in WINE with the 3.14.4 kernel, but 16-bit ms-windows apps will not.

As pointed out via the link in your message, #4, above,

Quote:

Originally Posted by Alien Bob (Post 5170500)
Seems to be a known issue with kernels >= 3.14.3 : https://lkml.org/lkml/2014/5/7/145 ....

Quote:

From Sven Joachim <>
Subject Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
Date Wed, 07 May 2014 11:18:49 +0200


On 2014-04-14 09:48 +0200, Alexandre Julliard wrote:

> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> On Fri, Apr 11, 2014 at 11:45 AM, Brian Gerst <brgerst@gmail.com> wrote:
>>>
>>> I haven't tested it recently but I do know it has worked on 64-bit
>>> kernels. There is no reason for it not to, the only thing not
>>> supported in long mode is vm86. 16-bit protected mode is unchanged.
>>
>> Afaik 64-bit windows doesn't support 16-bit binaries, so I just
>> assumed Wine wouldn't do it either on x86-64. Not for any real
>> technical reasons, though.
>>
>> HOWEVER. I'd like to hear something more definitive than "I haven't
>> tested recently". The "we don't break user space" is about having
>> actual real *users*, not about test programs.
>>
>> Are there people actually using 16-bit old windows programs under
>> wine? That's what matters.

It seems that at least some 32-bit programs are also broken, since after
upgrading the kernel to 3.14.3 I can no longer start my old chess
database program:

,----
| % file CB70.exe
| CB70.exe: PE32 executable (GUI) Intel 80386, for MS Windows
| % LANG=C wine CB70.exe
| modify_ldt: Invalid argument
| modify_ldt: Invalid argument
| modify_ldt: Invalid argument
| modify_ldt: Invalid argument
| modify_ldt: Invalid argument
`----
And here it just hangs, with wineboot.exe taking 100% CPU. I had to
kill first wineboot.exe and then CB70.exe. :-(

> Yes, there is still a significant number of users, and we still
> regularly get bug reports about specific 16-bit apps. It would be really
> nice if we could continue to support them on x86-64, particularly since
> Microsoft doesn't ;-)

I would rather not set up a virtual machine just for wine (I don't have
Windows anymore).

Cheers,
Sven

As it is a kernel problem, you are correct, KDE has nothing to do with it.

And, just for the record, this installation, from scratch, is almost brand new. The only thing added are your multilib files, java files, wine-pipelight, etc. In fact, everything added after the new complete installation were from either -current or your repositories.

Alien Bob 05-16-2014 02:33 PM

I was referring to your "Edit in: Apparently wine-pipelight is also affected". But if only 16-bit Windows applications are affected, that will not influence the pipelight plugins, at least that is my observation.
In your fresh installation, do you retain your original homedirectory or do you start your user account from scratch (i.e. no old data in .kde , .local , .config and all those other dot directories)?

I was not trying to mock you. In all honesty, I am trying to wrap my head around the completely opposite user experience you describe, compared to my own observations and those of some of my friends. I just can not understand what it is that messes up your computer.

Eric

cwizardone 05-16-2014 03:38 PM

Mr. Joachim, as quoted in post #10, seems to think some 32-bit apps are also affected.

"From scratch" means a freshly formated partition.

zbreaker 05-18-2014 04:57 PM

I run 32 bit -current. When I started to read the forums regarding the new kernel and Nvidia/Wine I got nervous. I use wine primarily to run some old games from the past I still occasionally enjoy, the original Unreal series. When I got to the bottom of this thread it seemed I might be safe! Did slackpkg upgrade-all
and reinstalled Nvidia 331.67. Wine working flawlessly for me. Whew...!

storkus 05-18-2014 07:25 PM

I can't speak for anyone else, but this isn't just Wine or other user programs: Since upgrading this afternoon from 3.14.3 to 3.14.4, Nouveau is no longer working for me. There seems to be some race condition in its initial load during boot where it fires up the framebuffer: in 5 boots on my Acer Aspire laptop since the upgrade, I've got twice with no backlight, twice with backlight but nothing being displayed, and only once with a normal boot and display where I was able to start X and XFCE. Looking at the X server logs I could see nothing special; I didn't think to look in the kernel logs at the time, and now I can't (the normal boot was the third).

The way I see it, the only way out after seeing all the problems everyone else is having is, if I can, blacklist Nouveau from LILO before boot and then use Slackpkg to roll it back to 3.14.3.

Also, FWIW, this is a big "I told you so!" for me as I was afraid of something like this when all the open drivers insisted on KMS at boot--until now, it was just annoying, but now I don't have a working machine.

Update: aaaand...the system is borked. Tried to compile 3.14.4, obviously I screwed something up big time as it panicked before it even got to mounting anything. Sigh...compiling a kernel wasn't this hard in years past...

Oh, and I did reset Slackpkg's "delall" variable to off in slackpkg.conf...helpful for the future, not so much right now.

cwizardone 06-01-2014 06:16 PM

Sorry to report the 3.14.5 kernel does not fix the previously mentioned WINE problem. Back to 3.10.30.

storkus 06-01-2014 10:26 PM

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?)

WhiteWolf1776 06-02-2014 06:31 AM

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.

cwizardone 06-02-2014 08:28 AM

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.

cwizardone 06-07-2014 11:53 PM

Just found this in the change log for the 3.14.6 kernel:

Quote:

commit 461a8fe47232a42c5ba9e2ac57eed37df331a2e3
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed May 14 16:33:54 2014 -0700

x86-64, modify_ldt: Make support for 16-bit segments a runtime option

commit fa81511bb0bbb2b1aace3695ce869da9762624ff upstream.

Checkin:

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 ;)

Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/r/CA%2B55aFw9...mail.gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cwizardone 06-18-2014 12:14 PM

The 3.14 Kernel and WINE problem finally hit the "press,"

http://news.softpedia.com/news/Linux...s-447273.shtml

cwizardone 07-20-2014 12:57 PM

The 3.14.12 kernel does not solve the problem/regression. We'll have to wait for the 3.15.x kernel.

1337_powerslacker 07-23-2014 08:45 PM

Quote:

Originally Posted by cwizardone (Post 5206866)
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.

cwizardone 07-24-2014 07:16 AM

Quote:

Originally Posted by mattallmill (Post 5208664)
@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.

That did the trick!
Thank you very much!
:hattip:

1337_powerslacker 07-24-2014 08:48 AM

Quote:

Originally Posted by cwizardone (Post 5208865)
That did the trick!
Thank you very much!
:hattip:

You are welcome. Always glad to help whenever I can. :)

Pithium 07-24-2014 12:56 PM

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 :D) 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 :)

1337_powerslacker 07-24-2014 03:14 PM

Quote:

Originally Posted by Pithium (Post 5209021)
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 :D) 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.

1337_powerslacker 08-07-2014 10:09 PM

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.

cwizardone 08-09-2014 06:59 AM

Quote:

Originally Posted by mattallmill (Post 5217290)
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!

Alien Bob 08-09-2014 09:12 AM

Quote:

Originally Posted by cwizardone (Post 5217960)
The WINE problem has been fixed in the 3.14.16 kernel.
Thanks!

So it is good news that that kernel just landed in Slackware-current.

Eric

cwizardone 08-09-2014 10:38 AM

Quote:

Originally Posted by Alien Bob (Post 5218019)
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!
:hattip:


All times are GMT -5. The time now is 08:25 AM.