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: Slackware64-current with "True Multilib."
Posts: 7,578
Original Poster
Rep:
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
Distribution: Slackware64-current with "True Multilib."
Posts: 7,578
Original Poster
Rep:
@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.
Last edited by cwizardone; 05-14-2014 at 10:16 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.
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.
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!
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.
Last edited by cwizardone; 05-16-2014 at 01:55 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.
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...!
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.
Last edited by storkus; 05-18-2014 at 10:42 PM.
Reason: Bork! Bork! Bork!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.