If I were going to make more WAGs (Wild Assed guesses), I'd hazard a guess that this was due to my Alsa sound system (running on the AC97 codec on my Asus motherboard).
I tried to walk the stack back, but didn't get very far (after the first time of wrongly computing the hex offset from a .s file, I gave off, stomped off to look for a better disassembler and gave up).
If you have the 'vmlinux' file, try objdump --disassemble vmlinux
My best guess is that we're coming through dentry_open (xc012e7fe)/ chrdev_open (0xc012f66c) /soundcore_open (0xc01bbf71). However, I wasn't seeing a familiar EBP/EIP pattern, so I'm possibly just pulling random symbols out of the air.
Yes, this appears to the proper trace: c0108d7f system_call c012ea2c sys_open c012e732 filp_open c012e7fe dentry_open c012f66c chrdev_open c01bbf71 soundcore_open d0826a42 <module> d087ce3e <module> c0107aa4 __down_failed c010794f __down ........ schedule
[I am assuming that you have 256MB main memory. Correct?]
Now, the question is still, who is sleeping on that semaphore and why?
From the call trace, it would seem that some sound-related
module is loaded, which does a down() on some semaphore in its open() routine. We even know which semaphore: cff267ac. (This does not help much, as this is would appear to be somewhere in kmalloc()ed memory ...)
We can continue to track in two directions.
First, we can try to locate the point within the Wine application where the open() syscall is performed.
From the trace we see that the system call instruction
is located at 40303a24, and the stack pointer points to 405c6638. The system call itself is an open( 41610240, O_WRONLY|O_NDELAY )
[The stack pointer value is rather weird, I'd say ...]
This particular open mode occurs in the Wine source only in dlls/winmm/wineoss/audio.c, which confirms the sound hypothesis.
The next time you reproduce the bug, could you please add the output of /proc/<pid>/maps for the hanging Wine process? This way, we could further analyse these pointers to Wine user space ...
The more promising way to track the problem, however, is to find out which module those d* addresses above reside in. If the modules are still loaded, the output of /proc/ksyms should at least give a hint. For a more refined symbol lookup, it is best to use the 'ksymoops' tool, which correlates the /proc/ksyms output with the ELF symbols read from the object modules themselves. To do so, write this:
Call Trace: [<d0826a42>] [<d087ce3e>]
to a file and pipe the file through ksymoops.
In any case, this would seem to be clearly a bug in that sound module. I don't know, however, why only Wine would trigger that bug ...
Bye, Ulrich
On Thu, Mar 29, 2001 at 01:23:59AM +0200, Ulrich Weigand wrote:
In any case, this would seem to be clearly a bug in that sound module. I don't know, however, why only Wine would trigger that bug ...
Bye, Ulrich
Any progress on that one ?
BTW, we just had our first operating system lesson on Thursday (tcshisms and such), and this was when a Linux box managed to fall flat on its face... (a colleague mounted a zip, accessed it via konqueror and... hung ! :) Imagine their funny faces... "haha, Linux... CRASHED ! :)" kill -9 didn't help, of course, as the processes were in D state (uninterruptible sleep). I intended to investigate the problem (it must be a kernel bug), but my colleague got uneasy: the drive was being accessed at all times, so his disk got hotter and hotter...
I resorted to rebooting the machine.
I'm going to try to reproduce it next time, though.
This was a RedHat Fisher machine, BTW.
-
Andreas Mohr -
Ulrich Weigand