Bug 32957 - Dell WS220 and WS330 Hangs initializing i810 audio (i810_audio not SMP-safe?)
Summary: Dell WS220 and WS330 Hangs initializing i810 audio (i810_audio not SMP-safe?)
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-03-23 22:25 UTC by Mick Tantasirikorn
Modified: 2005-10-31 22:00 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-04-03 16:47:49 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Mick Tantasirikorn 2001-03-23 22:25:47 UTC
when trying to login to KDE, the system hangs at initializing peripherals.
This happens intermittantly on all WS220 and WS330 systems.  Please try 
this at RedHat.

Comment 1 Mike A. Harris 2001-03-24 02:55:12 UTC
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.

Comment 2 Mick Tantasirikorn 2001-03-24 13:43:30 UTC
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

Comment 3 Bill Nottingham 2001-03-27 19:50:46 UTC
against 0322, no probem with 0319

Comment 4 Mick Tantasirikorn 2001-03-27 22:13:17 UTC
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.

Comment 5 Mick Tantasirikorn 2001-03-28 15:30:06 UTC
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.

Comment 6 Matt Wilson 2001-03-28 17:14:27 UTC
doug, please investigate.

Comment 7 Doug Ledford 2001-03-28 20:31:56 UTC
What kernel version are you using?

Comment 8 Mick Tantasirikorn 2001-03-28 21:08:56 UTC
kernel version:

Comment 9 Doug Ledford 2001-03-28 21:23:55 UTC
OK, that has the latest i810 sound driver.  This sounds like a spin_lock() being
used recursively problem.  I'll look into it.

Comment 10 Doug Ledford 2001-03-29 02:27:58 UTC
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?

Comment 11 Mick Tantasirikorn 2001-03-29 14:33:37 UTC
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 

Comment 12 Doug Ledford 2001-03-29 18:59:24 UTC
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?

Comment 13 Mick Tantasirikorn 2001-04-02 21:35:48 UTC
what arts package are you talking about?  please be more specific, I don't 


Comment 14 Doug Ledford 2001-04-03 09:07:42 UTC
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

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

Comment 15 Rogelio Noriega 2001-04-03 16:47:45 UTC
The current version we have is arts-2.1.1-3

Comment 16 Doug Ledford 2001-04-05 06:20:23 UTC
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);
 	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).

Note You need to log in before you can comment on or make changes to this bug.