Bug 625041

> 2. as root set Driver to fbdev via /etc/X11/xorg.conf.d/50-d*

Why are you doing this?

This line refers to /etc/X11/xorg.conf.d/50-device.conf which I thought to be the standard place to add <Driver "fbdev"> 
to choose that driver, in case it is more stable than vesa or cirrus.

fbdev does actually work after disabling /etc/X11/xorg.conf.d/50-vmmouse.conf
even though vmmouse works with cirrus.

Sure, but isn't using cirrus faster than vesa/fbdev? Also now you see a crash in vmmouse when using fbdev.

Yes, cirrus is faster. Still, this indicates there's a bug in the vmmouse module that could also surface under different conditions.

This is related to bug 604966. An equivalent call to iopl(3) as in attachment 366092 [details] works in this case as well.

Alex, do you know why qemu in *some* cases behaves differently here?

If you don't, we probably should use a different patch which only sets iopl(3) while sending the command, and reverts this effect afterwards directly afterwards. Still, I don't see where in vmmouse_proto.c the io port is actually accessed...

Also I don't know how to detect the current iopl level, so you can re-set it afterwards again.

agraf proposed to give SLE11-SP1 kernel + appropriate kvm kernelmodule package
a try on the 11.1 host system.

No difference with the SP1 kernel, though it is much more stable otherwise.

I would suggest adding the call again in the vmmouse driver.

Any improvements with latest updates from obs://X11:XOrg and obs://Kernel:HEAD?

zypper ar -f \
  http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_11.3/ \
  Kernel:HEAD
zypper ar -f \
  http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_11.3/ \
  X11:XOrg
zypper mr -p 90 Kernel:HEAD
zypper mr -p 90 X11:XOrg
zypper ref -r Kernel:HEAD
zypper ref -r X11:XOrg
zypper dup -r Kernel:HEAD
zypper dup -r X11:XOrg
zypper in xorg-x11-server-debuginfo xorg-x11-server-debugsource \
          xorg-x11-driver-video-debuginfo xorg-x11-driver-video-debugsource \
          xorg-x11-driver-input-debuginfo xorg-x11-driver-input-debugsource \
          libpixman-1-0-debuginfo libpixman-1-0-debugsource \
          libpciaccess0-debuginfo libpciaccess0-debugsource

Created attachment 398872 [details]
Xorg log with full debug+backtrace

This is from a crash on a current Factory with above repos+rpms added within a kvm-0.12.4 on my Debian/lenny host (can only try SLES11-SP1 on Monday)

Ok. Thanks for the update.

(In reply to comment #5)
> This is related to bug 604966. An equivalent call to iopl(3) as in attachment
> 366092 works in this case as well.
> 
> Alex, do you know why qemu in *some* cases behaves differently here?
> 
> If you don't, 

Seems so. :-(

> we probably should use a different patch which only sets iopl(3)
> while sending the command, and reverts this effect afterwards directly
> afterwards. 

That would be in shared/vmmouse_proto.c:VMMouseProto_SendCmd() right before/after calling VMMouseProtoInOut(). Makes perfectly sense to me.

> Still, I don't see where in vmmouse_proto.c the io port is  actually 
> accessed...

Obviously that's in VMMouseProtoInOut(...) 
  __asm__ __volatile__(

Or what do you mean exactly?

> Also I don't know how to detect the current iopl level, so you can re-set it
> afterwards again.

Me not either. Can we assume that the Xserver runs as a "normal process"?

# man iopl
[...]
The I/O privilege level for a normal process is 0.
[...]

Then it would be easy, but I doubt that. Maybe it's Level 1, maybe it's level 2.

Sorry, I talked to Matthias in person a while back about this. Apparently information flow stopped there :).

I'm not aware of any way to detect the current io privilege level. I'm missing the requirement for it though. Why would you need to change it back when setting it to 3? Just let X access any io port when we have the vmmouse drive in use.

Btw, the levels seem to indicate the rings in the x86 cpu. Ring 0 is kernel space, ring 3 is user space. Rings 1 and 2 are unused on i386 and are non-existent on x86_64.

Thanks for the input, Alex. I'm just wondering, whether it's a good idea to switch the Xserver in between to user space. I still would expect problems when trying to do that. Therefore it might be better to switch back to kernel space.
Jiri Kosina sent me a code snippet how to detect the current I/O privilege level.

Created attachment 398903 [details]
0001-To-access-i-o-ports-above-0x3ff-we-need-to-be-in-iop.patch

Proposal.

Patch is now included in X11:XOrg/xorg-x11-driver-input. Package has been rebuilt and is now available via

  http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_11.3/

RPM changelog entry:

Sun Nov  7 12:05:53 UTC 2010 - sndirsch@novell.com
- xf86-input-vmmouse-iopl-driver.diff
  * switch to I/O privilege level 3 also for the driver itself
    (bnc #625041)

Please install also the -debug* packages. In any case please attach the new
logfile, since I've added some debug messages and would like to know how often
the I/O privilege level is changed.

Created attachment 398904 [details]
fbdev Xorg log with full debug+backtrace

This works much better now, running KDE4, konsole and glxgears without problems... it only crashed on logout.

forgot to clear NEEDINFO flag.

(In reply to comment #19)
> Created an attachment (id=398904) [details]
> fbdev Xorg log with full debug+backtrace

Well, apparently the new code I've added didn't get active at all. Either you didn't update the xorg-x11-driver-input package or I patched dead code. Also there is no crash any longer in vmmouse_drv.

> This works much better now, running KDE4, konsole and glxgears without
> problems... it only crashed on logout.

That's a complete different crash in glx module it seems.

Bernhard, could you please verify that the following is part of the output when
running 'rpm --changelog -q xorg-x11-driver-input'?

Sun Nov  7 12:05:53 UTC 2010 - sndirsch@novell.com
- xf86-input-vmmouse-iopl-driver.diff
  * switch to I/O privilege level 3 also for the driver itself
    (bnc #625041)

Argh. VMwareLog(()) is only useful, if VMX86_DEVEL is defined, which apparently is not. I'm going to replace it with xf86Msg(X_INFO, ...).

(In reply to comment #23)
> Argh. VMwareLog(()) is only useful, if VMX86_DEVEL is defined, which apparently
> is not. I'm going to replace it with xf86Msg(X_INFO, ...).

... which I can't that easily since the code is shared between the driver and the standalone tool. :-(

I had used your lines from comment #9 to update. The changelog does indeed have your "Nov 7 2010" entry, so it was just the extra logging not working. The bugfix for the original fbdev+vmmouse issue is good.

Also added your update script to http://en.opensuse.org/openSUSE:Bugreport_X since it is pretty useful for debugging and testing.

Created attachment 398908 [details]
xf86-input-vmmouse-iopl-driver.diff

Use fprintf(...) instead of VMwareLog((...)) for debug messages. Possibly these debug messages will occur in /var/log/xdm.errors or /var/log/kdm.log instead of /var/log/Xorg.0.log.

Looks like fprintf() also goes to /dev/null when used in Xserver (modules). :-(

Created attachment 398913 [details]
vmmouse_drv.so

Please copy this file (vmmouse_drv.so) manually to /usr/lib/xorg/modules/drivers/. Now the debug messages should occur in the X logfile like

Current I/O privilege level: ...
Switching to I/O privilege level 3.
Switching back to previous I/O privilege level ...

Please attach the new logfile.

Created attachment 398920 [details]
fbdev Xorg log with full debug+backtrace

There are 27614 entries about Switching in a 90-second test, often only one millisecond apart.

Thanks a lot. That's what I was afraid of. I guess we don't want these switches. At least not that often. AFAIK they are rather CPU expensive.

Nevetheless I've now submitrequested an updated xorg-x11-driver-input for factory, since that's still better than a crashing Xserver due to the vmmouse usage.

-------------------------------------------------------------------
Mon Nov  8 14:57:59 UTC 2010 - sndirsch@novell.com

- merged xf86-input-vmmouse-iopl.diff/
  xf86-input-vmmouse-iopl-driver.diff and removed fprintfs

-------------------------------------------------------------------
Sun Nov  7 21:14:34 UTC 2010 - sndirsch@novell.com

- xf86-input-vmmouse-iopl-driver.diff
  * Use fprintf(...) instead of VMwareLog((...)) for debug messages. 

-------------------------------------------------------------------
Sun Nov  7 12:05:53 UTC 2010 - sndirsch@novell.com

- xf86-input-vmmouse-iopl-driver.diff
  * switch to I/O privilege level 3 also for the driver itself
    (bnc #625041)

Ok. Let's live with that approach. Matthias told me that these iopl() calls aren't that expensive as I thought first.

Reopening because of bug #743401.

Created attachment 489411 [details]
Enable hardware access during vmmouse preinit.

This patch enables hardware access using Xserver's xf86EnableIO function. It is the same approach as in xf86-input-keyboard.

This should be used instead of xf86-input-vmmouse-iopl.diff, results:
* The iopl is no longer called before and after every outl.
* It won't accidentally switch to iopl(0) because of wrong EFLAGS value in XEN
  in VMWARE. (bug #743401).

Closing as resolved because of bug #743401.

This is an autogenerated message for OBS integration:
This bug (625041) was mentioned in
https://build.opensuse.org/request/show/196893 Factory / xf86-input-vmmouse