wine users - Nov 2005 - Fedora Core 4 system lockup with wine 200506.. - 0.9.1

System specs:
Fedora Core 4
2.6.13-1.1532_FC4smp
ATI Radeon 9200 SE
P4 2.4Ghz (hyperthreading)
xorg 6.8.2
Aureal Semiconductor Vortex 2 sound card
Intel 82801EB chipset

wine-20050524 FC3 rpm works just fine on my FC4 system.  But any 
versions after that lockup my system when running wine.  For the 200506 
- 200510 versions of wine I have compiled them from scratch so I assumed 
it was something I was doing wrong.  I have been waiting for an official 
RPM from winehq to make sure that the problem still exists and now that 
0.9.x RPMs for FC4 are available I have now verified that the lockups 
still persist.

Interestingly I remember seeing someone in a discussion forum with the 
same problem I do and interestingly he had the same video card (ATI 
9200se).  I can not seem to find a link for that anymore though.

If I run wine it says creating configuration directory ... for the first 
time but after a few seconds my system locks up(keyboard does not 
respond(caps, etc)).  The I have tried using the xorg ATI driver and the 
proprietary ati drivers and even running the non SMP kernel(I have a P4 
hyperthreading CPU) but I still get the same lockups.

The old 20050524 version of wine works without locking up my system.

The .wine config directory does seem to be created:

[user@host ~]$ ls -al .wine
total 312
drwxrwxr-x    4 agibson agibson   4096 Nov  9 17:38 .
drwx--x--x  148 agibson agibson  32768 Nov 11 15:42 ..
drwxrwxr-x    2 agibson agibson   4096 Sep  6 09:44 dosdevices
drwxrwxr-x   11 agibson agibson   4096 Nov  9 15:14 drive_c
-rw-rw-r--    1 agibson agibson 225409 Nov  9 17:28 system.reg
-rw-rw-r--    1 agibson agibson   1470 Nov  9 17:28 userdef.reg
-rw-rw-r--    1 agibson agibson   6816 Nov  9 17:38 user.reg
[user@host ~]$ ls -al .wine/dosdevices/
total 68
drwxrwxr-x  2 agibson agibson 4096 Sep  6 09:44 .
drwxrwxr-x  4 agibson agibson 4096 Nov  9 17:38 ..
lrwxrwxrwx  1 agibson agibson   13 Sep  6 09:41 a: -> /media/floppy
lrwxrwxrwx  1 agibson agibson    8 Sep  6 09:41 a:: -> /dev/fd0
lrwxrwxrwx  1 agibson agibson   10 Sep  6 09:41 c: -> ../drive_c
lrwxrwxrwx  1 agibson agibson   10 Sep  6 09:41 com1 -> /dev/ttyS0
lrwxrwxrwx  1 agibson agibson   10 Sep  6 09:41 com2 -> /dev/ttyS1
lrwxrwxrwx  1 agibson agibson   10 Sep  6 09:41 com3 -> /dev/ttyS2
lrwxrwxrwx  1 agibson agibson   10 Sep  6 09:41 com4 -> /dev/ttyS3
lrwxrwxrwx  1 agibson agibson   12 Sep  6 09:43 d: -> /media/cdrom
lrwxrwxrwx  1 agibson agibson   10 Sep  6 09:44 d:: -> /dev/cdrom
lrwxrwxrwx  1 agibson agibson    8 Sep  6 09:41 lpt1 -> /dev/lp0
lrwxrwxrwx  1 agibson agibson    4 Sep  6 09:41 x: -> /tmp
lrwxrwxrwx  1 agibson agibson   13 Sep  6 09:42 y: -> /home/agibson
lrwxrwxrwx  1 agibson agibson    1 Sep  6 09:41 z: -> /

Anyone have any ideas that could track down the cause of the lockups? 
You can't really debug much when the whole system locks up.  I have to 
hit the reset button to get things running again.  I have not 
experienced any other lockup issues running any other apps with this 
system for the past year.

On Fri November 11 2005 3:58 pm, Adam Gibson wrote:
> Anyone have any ideas that could track down the cause of the lockups?
> You can't really debug much when the whole system locks up. ?I have to
> hit the reset button to get things running again. ?I have not
> experienced any other lockup issues running any other apps with this
> system for the past year.
Can't offer you any solutions, but I have 20050830  running on an FC4 2.8GHz
P4 box with a Radeon 9200Se. I am not running the SMP kernel, and I'm 
currently on 2.6.14-1.1637_FC4. Just tried IE to make sure, and it opened 
right up. 
-- 
Claude Jones
Bluemont, VA, USA

On Fri, 11 Nov 2005 15:58:19 -0500, in gmane.comp.emulators.wine.user
you wrote:
>Anyone have any ideas that could track down the cause of the lockups? 
>You can't really debug much when the whole system locks up.  I have to 
>hit the reset button to get things running again.  I have not 
>experienced any other lockup issues running any other apps with this 
>system for the past year.
Did you look in your /var/log files ?

As a very long shot you can try if the trouble comes from the default
audio driver that wine is choosing: around that time some important
changes in that area were made in wine.

Stop all wine processes;
edit your ~/.wine/system.reg and look for something like:
  [Software\\Wine\\Config\\Winmm] 1101586916
  "Drivers"="wineoss.drv"

Try changing "wineoss" to "winealsa", something else or even
to "none".

Rein.

Adam Gibson schrieb:
> Anyone have any ideas that could track down the cause of the lockups?
> You can't really debug much when the whole system locks up.  I have to
> hit the reset button to get things running again.  I have not
> experienced any other lockup issues running any other apps with this
> system for the past year.
If you have another pc around you could check if the box is still reacheable via
ping
after the lockup, which might indicate that it's just X which died. In that
case its
probably really related to your video card( or its driver).
Maybe you could try with the standard vesa driver.

You might also try with another kernel(best the vanilla one from kernel.org).
Doesn't Fedora ships his kernels with lots of security stuff(memory
protection, selinux,
dunno what else) enabled?

Perhaps playing with sysrq could help you to get more infos where it locked up
I never used that myself, but there is a documentation in the kernel
sources(linux/Documentation/sysrq.txt). Or just google ;)

Last possibility i can imagine is a hardware failure(RAM, power supply). But as
it only
happens with wine this seems relative unlikely.

Rein Klazes wrote:
>On Sat, 12 Nov 2005 11:39:42 -0500, in gmane.comp.emulators.wine.user
>you wrote:
>  
>
-- cut
>>>Stop all wine processes;
>>>edit your ~/.wine/system.reg and look for something like:
>>> [Software\\Wine\\Config\\Winmm] 1101586916
>>> "Drivers"="wineoss.drv"
>>>
>>>Try changing "wineoss" to "winealsa", something
else or even to "none".
>>>
>>>Rein
>>>      
>>>
-- cut
>>I did not see an entry for Software\\Wine\\Config\\Winmm.  I did a grep 
>>-i Winmm of the system.reg file and I did not find anything.  I tried 
>>running winecfg but of course my system just locks up :).
>>    
>>
>
>Just add the two line snippet that I quoted to the end of the
>system.reg. The idea is that wine will take the default driver
>wineoss.drv if there is no such section. If that driver is causing
>crashes or worse, some manual intervention is needed.
>
>Rein.
>  
>
I have a feeling you are on the right track.  I will be able to test 
this out Monday when at work.  The vortex2 card was never supported by 
default with OSS under Fedora Core 3 so I have a feeling that it is only 
supported in FC4 through the alsa OSS emulation.  With FC3 I had to 
compile the driver from sourceforge for OSS because alsa was not shipped 
with FC3.  With Fedora Core 4 the vortex2 card is supported using alsa 
so I never bothered installing the OSS driver.  Maybe the OSS emalation 
for the vortex2 is not quite up to snuff and the newer wine code 
triggers the driver bug.  OSS emulation using alsa for other apps works 
fine though.  The sound card is the only thing that is questionable as 
far as drivers go I think.

Thanks for all the information.  I have a feeling the info above will work.

Adam Gibson wrote:
> Rein Klazes wrote:
> 
>> On Sat, 12 Nov 2005 11:39:42 -0500, in gmane.comp.emulators.wine.user
>> you wrote:
>>  
>>
> -- cut
> 
>>>> Stop all wine processes;
>>>> edit your ~/.wine/system.reg and look for something like:
>>>> [Software\\Wine\\Config\\Winmm] 1101586916
>>>> "Drivers"="wineoss.drv"
>>>>
>>>> Try changing "wineoss" to "winealsa",
something else or even to "none".
>>>>
>>>> Rein
>>>>     
Using "Drivers"="winealsa.drv" or "none" did allow
wine to start without
parameters where before it would crash but launching a wine app locked 
things up again so things were a little better.

I finally decided to just remove the Diamond monster sound vortex2 card 
and just use the built in motherboard audio(which was disabled) and now 
wine works just fine.  It is a problem with the vortex driver it seems. 
  It is strange that setting Drivers to none for Winmm still caused a 
crash though.  You would think it would just ignore audio.

The vortex cards were abondonded years ago by diamond (199?).  It was 
the first card that came out that supported multiple audio streams(even 
before sb live) so I have stuck with the card because it was just there. 
  Time for it to be retired I guess.

Thanks for the help

Rein Klazes wrote:
> On Mon, 14 Nov 2005 09:36:32 -0500, in gmane.comp.emulators.wine.user
> you wrote:
> 
> 
>>>>>>Stop all wine processes;
>>>>>>edit your ~/.wine/system.reg and look for something
like:
>>>>>>[Software\\Wine\\Config\\Winmm] 1101586916
>>>>>>"Drivers"="wineoss.drv"
>>>>>>
>>>>>>Try changing "wineoss" to
"winealsa", something else or even to "none".
>>>>>>
>>>>>>Rein
>>>>>>    
>>
>>Using "Drivers"="winealsa.drv" or "none"
did allow wine to start without
>>parameters where before it would crash but launching a wine app locked 
>>things up again so things were a little better.
> 
> 
> Oops, I made a mistake with the registry key. The one I mention seems to
> be out of use now. It should have been:
> 
> [Software\\Wine\\Drivers] 1121776151
> "Audio"="oss"
> 
> To disable enter change "oss" to ""
> 
> 
>>I finally decided to just remove the Diamond monster sound vortex2 card 
>>and just use the built in motherboard audio(which was disabled) and now 
>>wine works just fine.  It is a problem with the vortex driver it seems. 
>> It is strange that setting Drivers to none for Winmm still caused a 
>>crash though.  You would think it would just ignore audio.
>>
>>The vortex cards were abondonded years ago by diamond (199?).  It was 
>>the first card that came out that supported multiple audio streams(even 
>>before sb live) so I have stuck with the card because it was just there.
>> Time for it to be retired I guess.
> 
> 
> If you still have the card around, and can compile wine form source then
> it would be nice if you could test the attached patch. It works on a
> similar problem with a vortex card I have here
> 
The patch made no difference.  I did find out that if the driver is set 
to alsa or "", wine works just fine.  "oss" is what breaks
it.  I copied
a default .wine directory from another system to find that out and just 
added the Drivers entry above to the user.reg file.  Interestingly i 
have to set gstreamer to use the alsa "oss" compatibility device to
get
good sound or it is distorted.  Go figure.  ALSA mode for wine.  OSS 
mode for gstreamer.  ALSA or OSS work in xmms.

The lockup problem is resolved now though however.  It appears the 
latest kernel from Fedora updates fixes the lockup problem completely. 
Previously I was using kernels from april timeframe of FC4 to the 
previous released kernel-2.6.13-1.1532_FC4 with the lockup problem issue 
still there.  It just so happens that the latest 
kernel-2.6.14-1.1637_FC4 fixes the problem.

So to make a long story short... if you have a lockup in wine with a 
monster sound vortex card in FC4, make sure you have the latest or newer 
kernel from Fedora updates.
> Rein.
> 
> 
> ------------------------------------------------------------------------
> 
> --- wine/dlls/winmm/wineoss/audio.c	2005-10-04 15:40:14.000000000 +0200
> +++ mywine/dlls/winmm/wineoss/audio.c	2005-11-17 20:03:45.000000000 +0100
> @@ -1019,6 +1019,7 @@ static void OSS_WaveFullDuplexInit(OSS_D
>          for (c = 1; c <= MAX_CHANNELS; c++) {
>              arg=c;
>              rc=ioctl(ossdev->fd, SNDCTL_DSP_CHANNELS, &arg);
> +            if( rc < 0) break;
>              if (rc!=0 || arg!=c) {
>                  TRACE("DSP_CHANNELS: rc=%d returned %d for
%d\n",rc,arg,c);
>                  continue;

On Mon, 14 Nov 2005 09:36:32 -0500, in gmane.comp.emulators.wine.user
you wrote:
>>>>> Stop all wine processes;
>>>>> edit your ~/.wine/system.reg and look for something like:
>>>>> [Software\\Wine\\Config\\Winmm] 1101586916
>>>>> "Drivers"="wineoss.drv"
>>>>>
>>>>> Try changing "wineoss" to "winealsa",
something else or even to "none".
>>>>>
>>>>> Rein
>>>>>     
>
>Using "Drivers"="winealsa.drv" or "none" did
allow wine to start without
>parameters where before it would crash but launching a wine app locked 
>things up again so things were a little better.
Oops, I made a mistake with the registry key. The one I mention seems to
be out of use now. It should have been:

[Software\\Wine\\Drivers] 1121776151
"Audio"="oss"

To disable enter change "oss" to ""
>I finally decided to just remove the Diamond monster sound vortex2 card 
>and just use the built in motherboard audio(which was disabled) and now 
>wine works just fine.  It is a problem with the vortex driver it seems. 
>  It is strange that setting Drivers to none for Winmm still caused a 
>crash though.  You would think it would just ignore audio.
>
>The vortex cards were abondonded years ago by diamond (199?).  It was 
>the first card that came out that supported multiple audio streams(even 
>before sb live) so I have stuck with the card because it was just there. 
>  Time for it to be retired I guess.
If you still have the card around, and can compile wine form source then
it would be nice if you could test the attached patch. It works on a
similar problem with a vortex card I have here

Rein.
-------------- next part --------------
--- wine/dlls/winmm/wineoss/audio.c	2005-10-04 15:40:14.000000000 +0200
+++ mywine/dlls/winmm/wineoss/audio.c	2005-11-17 20:03:45.000000000 +0100
@@ -1019,6 +1019,7 @@ static void OSS_WaveFullDuplexInit(OSS_D
         for (c = 1; c <= MAX_CHANNELS; c++) {
             arg=c;
             rc=ioctl(ossdev->fd, SNDCTL_DSP_CHANNELS, &arg);
+            if( rc < 0) break;
             if (rc!=0 || arg!=c) {
                 TRACE("DSP_CHANNELS: rc=%d returned %d for
%d\n",rc,arg,c);
                 continue;