trying to run dungeon siege 2 via wine, intro plays fine and then hangs , found a radeon problem to be the cause. dmegs output: [ 7230.283645] radeon 0000:00:01.0: evergreen_cs_track_validate_cb:477 cb[0] bo too small (layer size -2147483648, offset 0, max layer 1, bo size 4096, slice 4194303) [ 7230.283665] radeon 0000:00:01.0: evergreen_cs_track_validate_cb:481 problematic surf: (32 8388608) (0 8 1 0 0 0 0) [ 7230.283675] radeon 0000:00:01.0: evergreen_packet3_check:2096 invalid cmd stream 783 [ 7230.283684] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! [ 7231.299423] radeon 0000:00:01.0: evergreen_cs_track_validate_cb:477 cb[0] bo too small (layer size -2147483648, offset 0, max layer 1, bo size 4096, slice 4194303) [ 7231.299434] radeon 0000:00:01.0: evergreen_cs_track_validate_cb:481 problematic surf: (32 8388608) (0 8 1 0 0 0 0) [ 7231.299439] radeon 0000:00:01.0: evergreen_packet3_check:2096 invalid cmd stream 783 [ 7231.299444] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! the wine errors (don't know if helpfull at all) show a directdraw problem ]$ wine ./.wine/drive_c/Program\ Files/2K\ Games/Dungeon\ Siege\ 2\ Broken\ World/DS2VideoConfig.exe fixme:ddraw:DirectDrawEnumerateExA flags 0x00000007 not handled radeon: The kernel rejected CS, see dmesg for more information. fixme:win:EnumDisplayDevicesW ((null),0,0x33e048,0x00000000), stub! radeon: The kernel rejected CS, see dmesg for more information. fixme:win:EnumDisplayDevicesW ((null),0,0x33e114,0x00000000), stub! uname -a: 3.4.6-1-ARCH #1 SMP PREEMPT Fri Jul 20 08:21:26 CEST 2012 x86_64 GNU/Linux glxinfo: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD PALM OpenGL version string: 2.1 Mesa 8.0.4 OpenGL shading language version string: 1.20
what else do i need to submit and how to do it?
Please attach the /var/log/Xorg.0.log file. Which version of libdrm_radeon are you using?
Created attachment 65141 [details] varlog from startup untill crash of game
how to check the libdrm version?
Created attachment 66688 [details] Messages from dmesg after running BGMain.exe in fullscreen. Hello I am experiencing the same issue with Wine 1.5.12 and Baldur's Gate. The issue appears when BGMain.exe is launched fullscreen, without virtual desktop. In virtual desktop mode, it seems to be running fine. Also, if window switching is attempted (Ctrl+Tab) with game in fullscreen, tiny video output appears, occupying roughly 1/4th of screen resolution (which in full is 1280x1024) in top-left corner, the rest remaining black. It's very pixelated and shows game's main menu. With futher switching, it shows different desktop windows (if open), but latency is very low. Regardless of video output, sound is still played through alsa. In my case, output from running the executable is: radeon: The kernel rejected CS, see dmesg for more information. fixme:win:EnumDisplayDevicesW ((null),0,0x329c48,0x00000000), stub! fixme:d3d_surface:wined3d_surface_flip Ignoring flags 0x1. uname: Linux 3.5.3-2-ck x86_64 glxinfo: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD BARTS OpenGL version string: 2.1 Mesa 8.0.4 OpenGL shading language version string: 1.20 libdrm_radeon version is 1.0.1 Possible duplicate: https://bugs.freedesktop.org/show_bug.cgi?id=47244
Created attachment 66689 [details] X.org server varlog
Created attachment 67811 [details] radeon errors in dmesg while playing DC Universe Online in wine As I run the game, wine is complaining of: radeon: The kernel rejected CS, see dmesg for more information dmesg reports the errors shown in the attachment. OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD CEDAR OpenGL version string: 2.1 Mesa 8.0.4 OpenGL shading language version string: 1.20 OpenGL extensions:
Is this still an issue with a newer version of mesa? git master or a 9.0 snapshot?
Created attachment 68018 [details] dmesg with Mesa 9.1 Same errors with Mesa 9.1. Wine complains of: radeon: The kernel rejected CS, see dmesg for more information. dmesg attached.
Make sure you update your 32 bit 3D driver as you appear to be using a 64 bit distro and wine requires a 32 bit 3D driver.
(In reply to comment #10) > Make sure you update your 32 bit 3D driver as you appear to be using a 64 > bit distro and wine requires a 32 bit 3D driver. This issue appeared for me in 2D games/applications, too. Haven't yet tested with newer mesa.
(In reply to comment #11) > (In reply to comment #10) > > Make sure you update your 32 bit 3D driver as you appear to be using a 64 > > bit distro and wine requires a 32 bit 3D driver. > > This issue appeared for me in 2D games/applications, too. Haven't yet tested > with newer mesa. If they are 32-bit games, you'll hit the same issue.
(In reply to comment #12) > If they are 32-bit games, you'll hit the same issue. Not meaning to question your expertise, but would you care to explain: if "wine requires 32-bit 3D driver" why virtual desktop (i.e. non-fullscreen) mode is running just fine? In my layman view this would mean wine's perfectly able to handle the 2D rendering and display on it's part without having to install 32-bit 3D driver (which in my case would require complete switch to closed source catalyst package and I'm a bit reluctant to do so).
(In reply to comment #13) > (In reply to comment #12) > > If they are 32-bit games, you'll hit the same issue. > > Not meaning to question your expertise, but would you care to explain: if > "wine requires 32-bit 3D driver" why virtual desktop (i.e. non-fullscreen) > mode is running just fine? In my layman view this would mean wine's > perfectly able to handle the 2D rendering and display on it's part without > having to install 32-bit 3D driver (which in my case would require complete > switch to closed source catalyst package and I'm a bit reluctant to do so). You can install a 32 bit version of the open source 3D driver as well. Just because the graphics in a game do not appear to be 3D, they generally still use a 3D API (OpenGL or Direct3D) which requires a 32 bit 3D driver since the apps are 32 bit. Also there seem to be several possibly unrelated issues now piled onto this bug.
(In reply to comment #14) > You can install a 32 bit version of the open source 3D driver as well. Just > because the graphics in a game do not appear to be 3D, they generally still > use a 3D API (OpenGL or Direct3D) which requires a 32 bit 3D driver since > the apps are 32 bit. Also there seem to be several possibly unrelated > issues now piled onto this bug. You've focused on minor point about the inability of having open source 32-bit driver alongside 64-bit one. I don't know the cause of it, I only know that my distribution provides this kind of setup for closed source catalyst package: https://wiki.archlinux.org/index.php/Wine#Graphics_Drivers To clarify, I do have 32-bit DRI Mesa drivers installed - the lib32-ati-dri package mentioned in the link above - but I assume you mean xorg kind of drivers. If this is some sort of distro-related bug, please state it so I can nag other people about it ;-) At the same time, I see my main point about display being fine in virtual desktop mode has been ignored? To reiterate: it doesn't seem to me that, since Wine is capable of rendering and display on the very same setup in different mode, there are some unfullfilled requirements that block said display. After all, as I described before, even in fullscreen mode there was some kind of output, albeit buggy to the point of being unusable. But without the crucial part of plumbing there would be no output at all.
(In reply to comment #15) > You've focused on minor point about the inability of having open source > 32-bit driver alongside 64-bit one. I don't know the cause of it, I only > know that my distribution provides this kind of setup for closed source > catalyst package: > https://wiki.archlinux.org/index.php/Wine#Graphics_Drivers I'm not following. You can have both 32-bit and 64-bit versions of the open source driver installed. If your distro doesn't allow it, it's broken. If other 32-bit and 64-bit libs also cannot both be installed, you may have bigger problems. > > To clarify, I do have 32-bit DRI Mesa drivers installed - the lib32-ati-dri > package mentioned in the link above - but I assume you mean xorg kind of > drivers. If this is some sort of distro-related bug, please state it so I > can nag other people about it ;-) Is the 32-bit driver a recent version? Often distros only provide out of date 32-bit drivers on 64-bit distros. > > At the same time, I see my main point about display being fine in virtual > desktop mode has been ignored? To reiterate: it doesn't seem to me that, > since Wine is capable of rendering and display on the very same setup in > different mode, there are some unfullfilled requirements that block said > display. After all, as I described before, even in fullscreen mode there was > some kind of output, albeit buggy to the point of being unusable. But > without the crucial part of plumbing there would be no output at all. The symptoms you are experiencing are commonly seen with an out of date 32-bit 3D driver. If your 32-bit 3D driver is old, you may still be experiencing the problem. Also, there are several people on this bug report and the solution may still be relevant for them even if it doesn't help in your case.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/415.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.