You are not logged in.
Previously I was running OrCAD 10.5 suite flawlessly under Wine in my 64 Arch Install. To make one of the programs included in the suite work (layout.exe) I had to configure it to run as Windows 98, but that's all I needed to do to get the suite running.
In a recen system upgrade, it stopped working. All the programs in the suite excepting layout.exe work, but when I launch layout.exe, it eats 100% CPU, but doesn't start, and I get the following error on the terminal window:
WINEPREFIX=$OPATH wine layout.exe
modify_ldt: Invalid argument
modify_ldt: Invalid argument
modify_ldt: Invalid argument
modify_ldt: Invalid argument
modify_ldt: Invalid argumentAfter googling a bit, I found that it looks like there is a problem with 16 bit calls on latest kernel causing win16 programs to fail. I don't know if layout.exe is win16, but it might be. But as I only was experiencing the problem when Windows 9x mode was enabled (using winecfg), I decided to create a clean winebottle and do a simple test:
First create the clean winebottle:
$ WINEARCH=win32 WINEPREFIX=/home/doragasu/wine/test winebootAnd then run built-in commands that I suppose are 32-bit (is there a way I can know for sure?):
$ WINEPREFIX=/home/doragasu/wine/test winecfg
$ WINEPREFIX=/home/doragasu/wine/test wineconsoleBoth winecfg, wineconsole and others run as expected. Next step is running again winecfg to configure this winebottle to behave as Windows 98. Once this is done, I cannot start anything, neither winecft nor wineconsole work anymore, 100% cpu is taken by wine, and the "modify_ldt: Invalid argument" is again displayed on the terminal window. So it looks like not only win16 applications are broken, everything breaks if you set Windows 98 emulation...
Someone pointed out that there was an error on the wine arch package that was solved later, but I have not heard anything about it, and my system is upgraded as of today. Can anyone confirm this problem? Is it only kernel related? Is there a workaround? (e.g. an easy way to downgrade the kernel until this is hopefully fixed).
Offline
What was upgraded? Could you provide /var/log/pacman.log of the last upgrade?
fs/super.c : "Self-destruct in 5 seconds. Have a nice day...\n",
Offline
Unfortunately I'm not sure it broke in the last upgrade, I didn't use layout.exe at least for a month. Having a look to the log:
[...]
[2014-04-08 09:26] [PACMAN] upgraded linux (3.13.7-1 -> 3.13.8-1)
[2014-04-08 09:27] [PACMAN] upgraded wine (1.7.15-1 -> 1.7.16-1)
[...]
[2014-05-13 08:29] [PACMAN] upgraded linux (3.13.8-1 -> 3.14.3-1)
[2014-05-13 08:31] [PACMAN] upgraded wine (1.7.16-1 -> 1.7.18-1)
[...]
[2014-05-19 08:57] [PACMAN] upgraded linux (3.14.3-1 -> 3.14.4-1)
[2014-05-19 08:57] [PACMAN] upgraded wine (1.7.18-1 -> 1.7.19-1)
[...]
[2014-05-20 11:46] [PACMAN] upgraded wine (1.7.19-1 -> 1.7.19-3)
[...]EDIT: Tried downgrading wine yo version 1.7.14-1 and it doesn't work. Maybe I'll have to downgrade the kernel, and I don't know if it could have any side-effects.
Last edited by doragasu (2014-05-26 14:29:03)
Offline
Downgrading the kernel is not a problem unless if you start to rely on specific features in later versions.
fs/super.c : "Self-destruct in 5 seconds. Have a nice day...\n",
Offline
Win16 was broken to fix a security flaw in kernel 3.14. But starting with kernel 3.15 and later, we will be able to change ldt16 behaviour to the previous one, bringing back win16 compatibility (and leaving open the security flaw) by doing this:
$ echo 1 > /proc/sys/abi/ldt16I hope 3.15 kernel is rolled out soon ![]()
Offline
There was also some talk about a patch (i think it was called esp64fix) to solve the problem completely without reintroducing the security flaw.
No idea if/when that patch will be accepted.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Online