Bug 32957

You haven't provided much information at all about what the problem
you're having is.  KDE does not initialize peripherals, the kernel does.
KDE is just a desktop environment for X windows.  Most likely you're
experiencing a hardware or kernel bug.  This isn't related to XFree86
however from what you've said above.

What I mean is, during the KDE startup screen, there is a nice looking KDE dialog 
box that goes through the initialization.  The initialization screen is 
saying "initializing peripheral" and that is when it hangs.  This happens on 6 
different systems each with different hardware.  If this isn't related to the XFree86 
then please assign it to the right component.  I am now changing this to "kdebase" 
component.  again, this is my best guess.  This hangs only happens in KDE and not 
in Gnome.  Steps to reproduce:
1. use a Dell WS220 or WS330
2. have the system go directly to runlevel 5
3. in the log in screen select session -> KDE
4. log in the system
5. you will see the initialization screen.
6. during "initializing peripheral" the system hangs. (intermittently) abour 50% of 
the time

against 0322, no probem with 0319

I have tried installing qa0322 and then install the XFree86 packages from 
qa0319.  I was able to log in to KDE with no problem.  I have also installed a 
system with qa0319 entirely, just to reverify, and the problem was not there.  
When I use the UP kernel with the same machine that it hangs on, I did not see 
any more problem.  The problem is there only if we are using SMP kernel with 
dual proc machine.

We have narrowed the failure down to sound server in KDE being enabled on the 
i810 audio.  when we have an i810 based audio and sound server enabled the 
system will hang at the KDE log in.

doug, please investigate.

What kernel version are you using?

kernel version:
2.4.2-0.1.40

OK, that has the latest i810 sound driver.  This sounds like a spin_lock() being
used recursively problem.  I'll look into it.

Is the system hard hung when this happens (do you have to hit the power switch
or reset button) or will ctl-alt-backspace get you back to a login screen?

Also, I though the 330 was UP only, so why would it even have an SMP kernel to
hang with?

well, the dual proc and SMP was a bad assessment.  we believe it is the KDE 
sound server and the i810.
When this happens it is a hard hang, I need to press the reset/power button to 
reboot.

OK, let me see if I have this right now.  Up or SMP doesn't matter, it happens
on both.  It only happens with i810 audio and KDE startup.  It goes away if you
grab the X packages from 0319 (and presumably that includes the kde-sound
package and arts package).  If you put on a 0322 install, and then just put the
arts package from 0319 on there, does it go away?

what arts package are you talking about?  please be more specific, I don't 
understand.

Thanks

The KDE sound server is named artsd and the package that contains the sound
server is arts.  This isn't a generic arts package, arts *is* the name of the
package.

dledford@p330 dledford]$ rpm -q arts
arts-2.0.20010214-1
[dledford@p330 dledford]$ 

The current version we have is arts-2.1.1-3

After upgrading my system so that my copy of arts is the same as yours I can
reproduce the problem.  I've isolated the issue and created a patch to solve the
problem.  This is both an arts bug and a kernel bug, although the kernel bug
isn't in the i810 driver it's in the generic do_exit() code in the kernel (the
kernel is leaking an open file).

In short, artsd is calling close on the open sound device with the O_NDELAY flag
set.  However, it isn't checking for errors on the close.  When specifying the
O_NDELAY option, it shouldn't assume the sound driver will drain all sound
output and close the file instead of returning -EBUSY (which is perfectly
reasonable given that we are waiting for the sound output to drain out of the
device and they don't want us to hold up the close for that).  So, artsd is
exiting with the sound driver still open.  In the do_exit() portion of the
kernel, it should close all of artsd's open file descriptors as it tears the
process down, and it likely does (although I didn't confirm it), but it also
isn't checking for errors, so when the file does not get successfully closed,
the kernel is missing that failed return and treating the file as though it were
closed.  This would be OK, except that the internal state of the sound card
isn't cleared until we get a successful close, so on the next open attempt, you
get a device busy error because the sound driver thinks the original file is
still open.

This patch is sufficient to make things work again, but this just keeps the i810
sound driver from doing something perfectly legitimate because artsd isn't
checking for it and neither is other kernel code.

[dledford@aic-cvs dledford]$ more i810-release.patch 
--- linux/drivers/sound/i810_audio.c.save	Wed Mar 28 18:55:04 2001
+++ linux/drivers/sound/i810_audio.c	Thu Apr  5 00:57:38 2001
@@ -1814,11 +1814,7 @@
 	/* stop DMA state machine and free DMA buffers/channels */
 	if(dmabuf->enable == DAC_RUNNING ||
 	   (dmabuf->count && (dmabuf->trigger & PCM_ENABLE_OUTPUT))) {
-		if(drain_dac(state,file->f_mode & O_NDELAY)) {
-			up(&state->open_sem);
-			unlock_kernel();
-			return -EBUSY;
-		}
+		drain_dac(state,0);
 		stop_dac(state);
 	}
 	if(dmabuf->enable & ADC_RUNNING) {
[dledford@aic-cvs dledford]$ 

If this doesn't solve your problems, then please reopen this bug (I'm checking
the patch into what should become the 2.4.2-0.1.51 kernel).