Mike, thanks for all the info! however, working on possible kernel bugs and even driver bugs is WAY over my head! i will submit a bug report to the via8233 driver maintainer though. i have gotten ALSA up and running though....i can finally listen to some music. Kai
On Thursday 25 April 2002 10:50 am, you wrote: > Kai, > > I'm going to rearrange some things... > > On Wed, Apr 24, 2002 at 09:15:51PM -0700, Kai Harris wrote: > > 1. the ac97 device driver is being loaded on startup: > > Via 686a audio driver 1.9.1 > > ac97_codec: AC97 Audio codec, id: 0x414c:0x4710 (ALC200/200P) > > via82cxxx: board #1 at 0xE800, IRQ 11 > > > > via_audio: ignoring drain playback error -11 > > Okay quick scan says that when the driver is being unloaded, it waits > around to play the last of the audio that is queued for the device. > If the device was open in non-blocking mode, then it will allow an > application to release the device before the buffer is really empty, > -11 or (-EAGAIN) i what it returns if this happens. > > There is an obvious endless loop inside the kernel if the device was > opened in standard blocking mode and any audio was sent to it, and there > is something wrong... because the loop looks like the last chunk below. > The only reason your machine doesn't lock solid in this loop is there > is a "schedule()" call inside which allows the kernel to do something > else if it thinks there is something to do. > > ./drivers/sound/via82cxxx_audio.c > # * via_dsp_drain_playback - sleep until all playback samples are > flushed # * > # * Sleeps until all playback has been flushed to the audio > # * hardware. > > /usr/include/asm/errno.h: > # #define EAGAIN 11 /* Try again */ > > ./drivers/sound/via82cxxx_audio.c > # for (;;) { > # __set_current_state(TASK_INTERRUPTIBLE); > # if (atomic_read (&chan->n_frags) >= chan->frag_number) > # break; > # > # if (nonblock) { > # DPRINTK ("EXIT, returning -EAGAIN\n"); > # ret = -EAGAIN; > # break; > # } > [...] > # } > > > 4. top shows multiple copies of aRtsd running and I cannot kill them. > > They continue to run after I log out of KDE and X and cannot be killed by > > their owner (me), or by root. If I completely log out and then log in as > > root, they are still running. One of these processes uses a significant > > amount of CPU% (80-90%). > > > > It seems to me that this is a very likely culprit. Is it possible for > > aRtsd to bork so that it won't even respond to a kill signal? where > > would I go to look for reasons for such a freeze? > > aRtsd must open the device in blocking mode, combined with the code above > it explains the following... > > The process that is using 90% of the CPU is the first one to open the > device and play the login greeting for KDE (or whatever)... since it sent > some audio to the device there is something in the buffer, which is trying > to be played but can't, so when aRtsd tried to close the device you hit > that endless kernel loop. > > The reason the other processes are using none of the CPU is standard > kernel sound drivers create open once devices... the first open causes > anyone else to block waiting for the caller to close the device before > they can continue... if the first process exited *then* the others would > have a chance to go. > > If you send a "kill -9" and the process does not die instantly, then > you have a kernel bug... there is no way to "block" or "hide" from kill -9. > However, do not start killing things with -9, many programs have cleanup > operations they need to run when exiting, by using -9 they never get > to run their shutdown things, and that might mess up those programs on > the next start. So only try kill -9 on things that you tried a normal > kill and 5 seconds later they are still around. > > So you have a kernel bug. > > > 5. when playing an mp3 using mpg123 directly after a reboot, mpg123 > > plays without returning an error message. however, there is no sound. > > Ctrl-c mpg123 and run it again returns an error message: > > audio: Resource temporarily unavailable > > Something odd about this report is the > "Resource temporarily unavailable" message > is a EAGAIN thing, which you should only get if mpg123 opens something > non-blocking, the fact that when you hit cntl-c you get a prompt back > means that it is not hitting the same bug as above ... my copy mpg123 > opens /dev/dsp in blocking mode so you might have another mpg123 variant. > > It appears there might be another bug in the audio driver in that it > doesn't make the device available again to the next program after the > first closes. > > > 2. the soundcard is setup as a module. > > from /etc/modules.conf: > > alias sound-slot-0 via82cxxx_audio > > The dmesg output explains which drive you are using, this contains > nothing new. Good to include that file in bug reports though, so > people know nothing is wrong there. > > > 6. Logging into X and KDE gives error message: > > error: Error while initializing the sound driver: > > device /dev/dsp can't be opened (Resource temporarily unavailable) > > The sound server will continue, using the null output device > > > > I do not know what to do. I have looked for help at the Mandrake Support > > center and done multiple google searches on everything from my particular > > error messages to generic ac97 support. I have searched VIA's support > > center. Anybody have an idea? > > I checked out the ALSA sound driver for that card is _completely_ > different code from the kernel version you are running. Which means > there is a fair chance that it will work... try that next, I think > Mark gave you some pointers. > > The other thing would be to report to the kernel developer in question > your results (possibly this email). Since I don't have your hardware > and I'm not a kernel hacker, I'd be pretty useless trying to figure > out how to fix that problem. > > /usr/src/linux/MAINTAINERS > # VIA 82Cxxx AUDIO DRIVER > # P: Jeff Garzik > # L: [EMAIL PROTECTED] > # S: Odd fixes > > /usr/src/linux/Documentation/DocBook/via-audio.sgml > # Please send bug reports to the mailing list [EMAIL PROTECTED] > # To subscribe, e-mail [EMAIL PROTECTED] with "subscribe linux-via" > # in the body of the message. > > Anyway here is an archive of that mailing list: > http://marc.theaimsgroup.com/?l=linux-via&r=1&w= > I don't see alot of activity there... but check it out. > > Sounds like there are three drivers for that chipset: > kernel, ALSA, OSS... maybe one will work. > _______________________________________________ > vox-tech mailing list > [EMAIL PROTECTED] > http://lists.lugod.org/mailman/listinfo/vox-tech _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech