similar to: Message from Wine: IOPL not enabled (again)

I get "IOPL not enabled" error when loading WINWORD.EXE. I have XP installed on a NTFS partition, and "office pro 2003" version. Anybody ran on this problem?? jose -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.winehq.org/pipermail/wine-users/attachments/20060315/86ceb3e2/attachment.htm

Being a new Ubuntu 10.10 user, I am trying to get Wine to work in order to access some of my previous WIN XP programs. When I try to use Outlook (from which it is still difficult to migrate to an appropriate Linux Prog), I always get the "IOPL not enabled" message. I have tried the fix with adding the gdiplus in libraries and changing it. But there is no effect. If the

With this patch, x86 and x86-64 share ioport.c, fixing LTP iopl and ioperm testcase failures (on both). We found an iopl testcase failing even on x86 xenlinux. Now x86-64 xenlinux should have the same results regarding the LTP testcases (as far as we tested). Signed-off-by: Li B Xin <li.b.xin@intel.com> Signed-off-by: Jun Nakajima <jun.nakajima@intel.com> Jun --- Intel Open Source

On Sun, 2 Nov 2014 09:33:01 -0800 Josh Triplett <josh at joshtriplett.org> wrote: > On the vast majority of modern systems, no processes will use the > userspsace IO syscalls, iopl and ioperm. Add a new config option, > CONFIG_X86_IOPORT, to support configuring them out of the kernel > entirely. Most current systems do not run programs using these > syscalls, so X86_IOPORT

On Sun, 2 Nov 2014 09:33:01 -0800 Josh Triplett <josh at joshtriplett.org> wrote: > On the vast majority of modern systems, no processes will use the > userspsace IO syscalls, iopl and ioperm. Add a new config option, > CONFIG_X86_IOPORT, to support configuring them out of the kernel > entirely. Most current systems do not run programs using these > syscalls, so X86_IOPORT

It doesn't look like iopl() is working. I'm taking an exception on every IO instruction. inl(0xde04) = 00000100 eip:765e eax:0100 ebx:0000 ecx:0320 edx:de04 esi:03f5 edi:0087 ebp:0000 esp:6b62 cs:c000 ss:c000 es:0000 ds:c000 fs:0000 gs:0000 eflags:00000246 exception: code at 0x000c7661: 66 ef 5a 59 66 58 9d c3 53 bb 02 00 e8 5e ff 5b c3 53 bb 05 00 e8 55 ff 5b c3 53

> > This isn't unreasonable but there are drivers with userspace helpers that > > use iopl/ioperm type functionality where you should be doing a SELECT of > > X86_IOPORT. The one that comes to mind is the uvesa driver. From a quick > > scan it may these days be the only mainstream one that needs the select > > adding. > > Should kernel drivers really

> > This isn't unreasonable but there are drivers with userspace helpers that > > use iopl/ioperm type functionality where you should be doing a SELECT of > > X86_IOPORT. The one that comes to mind is the uvesa driver. From a quick > > scan it may these days be the only mainstream one that needs the select > > adding. > > Should kernel drivers really

Hi Josh, On Tue, Oct 22, 2013, at 3:35, Josh Triplett wrote: > On the vast majority of modern systems, no processes will use the > userspsace I/O syscalls, iopl and ioperm. Add a new config option, > CONFIG_X86_IOPORT, to support configuring them out of the kernel > entirely. Since these syscalls only exist to support rare legacy > userspace programs, X86_IOPORT does not depend

Hi Josh, On Tue, Oct 22, 2013, at 3:35, Josh Triplett wrote: > On the vast majority of modern systems, no processes will use the > userspsace I/O syscalls, iopl and ioperm. Add a new config option, > CONFIG_X86_IOPORT, to support configuring them out of the kernel > entirely. Since these syscalls only exist to support rare legacy > userspace programs, X86_IOPORT does not depend

Hi, I?ve installed wine on Ubuntu 6.10 64bit using the following guide : http://www.ubuntuforums.org/showthread.php?t=185557 but, when I type winecfg in Terminal I get the following error : exec: 29: /usr/bin/wine: not found Dunno if it may help, but here?s a terminal shot of when wine was getting installed. matt@ubuntu:~/Desktop$ dpkg -x lib libartsc0_1.3.2-3_amd64.deb

On the vast majority of modern systems, no processes will use the userspsace IO syscalls, iopl and ioperm. Add a new config option, CONFIG_X86_IOPORT, to support configuring them out of the kernel entirely. Most current systems do not run programs using these syscalls, so X86_IOPORT does not depend on EXPERT, though it does still default to y. In addition to saving a significant amount of

On the vast majority of modern systems, no processes will use the userspsace IO syscalls, iopl and ioperm. Add a new config option, CONFIG_X86_IOPORT, to support configuring them out of the kernel entirely. Most current systems do not run programs using these syscalls, so X86_IOPORT does not depend on EXPERT, though it does still default to y. In addition to saving a significant amount of

I found a clever way to make the extra IOPL switching invisible to non-paravirt compiles - since kernel_rpl is statically defined to be zero there, and only non-zero rpl kernel have a problem restoring IOPL, as popf does not restore IOPL flags unless run at CPL-0. Subject: IOPL handling for paravirt guests Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 8110943fd7ad

I found a clever way to make the extra IOPL switching invisible to non-paravirt compiles - since kernel_rpl is statically defined to be zero there, and only non-zero rpl kernel have a problem restoring IOPL, as popf does not restore IOPL flags unless run at CPL-0. Subject: IOPL handling for paravirt guests Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 8110943fd7ad

Hi Nithya, I applied the workarround for this bug and now df shows the right size: [root at stor1 ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/sdb1 26T 1,1T 25T 4% /mnt/glusterfs/vol0 /dev/sdc1 50T 16T 34T 33% /mnt/glusterfs/vol1 stor1data:/volumedisk0 101T 3,3T 97T 4% /volumedisk0 stor1data:/volumedisk1

Hi Nithya, My initial setup was composed of 2 similar nodes: stor1data and stor2data. A month ago I expanded both volumes with a new node: stor3data (2 bricks per volume). Of course, then to add the new peer with the bricks I did the 'balance force' operation. This task finished successfully (you can see info below) and number of files on the 3 nodes were very similar . For volumedisk1 I

Hi, Some days ago all my glusterfs configuration was working fine. Today I realized that the total size reported by df command was changed and is smaller than the aggregated capacity of all the bricks in the volume. I checked that all the volumes status are fine, all the glusterd daemons are running, there is no error in logs, however df shows a bad total size. My configuration for one volume:

Hi Nithya, Below the output of both volumes: [root at stor1t ~]# gluster volume rebalance volumedisk1 status Node Rebalanced-files size scanned failures skipped status run time in h:m:s --------- ----------- ----------- ----------- ----------- ----------- ------------

Hi Jose, There is a known issue with gluster 3.12.x builds (see [1]) so you may be running into this. The "shared-brick-count" values seem fine on stor1. Please send us "grep -n "share" /var/lib/glusterd/vols/volumedisk1/*" results for the other nodes so we can check if they are the cause. Regards, Nithya [1] https://bugzilla.redhat.com/show_bug.cgi?id=1517260