Re: Tough nuts for "kill -9" (was Re: [vox-tech] ac97 sound problems)
On Thu, 25 Apr 2002 [EMAIL PROTECTED] wrote: > On Thu, Apr 25, 2002 at 12:36:02PM -0700, Jeff Newmiller wrote: > > On Thu, 25 Apr 2002, Peter Jay Salzman wrote: > > > begin [EMAIL PROTECTED] <[EMAIL PROTECTED]> > > > > 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. > > > > The process may also be a zombie... this has been discussed on this list > > and is a Unix FAQ ... > > Heh, zombie "processes" are already dead, which is why they can not be > killed. On Linux all of their resources are released and they only occupy a > few pages of memory for process state and return code, until their parent > calls wait on them (which "buries" them). I know, and you know, but this is not intuitively obvious to someone who doesn't know, so it is worth mentioning BEFORE concluding that they are dealing with kernel bugs. > > It's true that you can send them -9 and they will still appear in ps. > > Later, > Mike > > ... in another bold statement all processes become zombies just after > they exit. unless _maybe_ you are on a SMP machine... except maybe > init, and all those those pesky kernel threads... ;) When a process exits its parent may be waiting for it. I don't have time (and no guarantee I can succeed when I do) to dig into the kernel and see if this case is recognized and optimized out, but I would hope it is. > (I'm actually not certain of implementation, it could be that the kernel > may suspend the process that exits, before cleaning up after it and flaging > it as a Z state, to signal the parent... but that seems messy.) Something to look at sometime... --- Jeff NewmillerThe . . Go Live... DCN:<[EMAIL PROTECTED]>Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] ac97 sound problems
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 thoughi 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:
> # #defineEAGAIN 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
Re: [vox-tech] ac97 sound problems
begin [EMAIL PROTECTED] <[EMAIL PROTECTED]> > On Thu, Apr 25, 2002 at 11:05:43AM -0700, Peter Jay Salzman wrote: > > begin [EMAIL PROTECTED] <[EMAIL PROTECTED]> > > > 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. > > > > as you point out, processes in "uninterruptable sleep" can't be killed > > with SIGKILL. the process is put to sleep while the kernel waits for > > some event to happen. this corresponds to process status "D". > > It is true that processes in state D don't die instantly, I had not > considered them. Even processes in state D should die in a few seconds > or _maybe_ a minute for a very slow device... but I can't think of any > thing at the moment that is a _valid_ reason to lock a process in > uninterruptable sleep forever. state D processes *can* last forever. do a google group search on "uninterruptable sleep" (after you correct my spelling of uninterruptable which i no doubt got wrong). but putting aside google groups, *i've* seen state D processes last for weeks on my system. they only died after a reboot. you can certainly imagine a trivial scenario for such a thing -- consider a process which is waiting for a data page coming from swap. no data page, no scheduling. it's as simple as that. and signals won't help here -- you can't signal a process "hey, i just read your data, here it is". what you do is you put the process to sleep until the event occurs. if that happens to be an open() or write() for a user space process, then that process is stuck. > Realize that when the kernel exposes a method to become "stuck" forever > in that state a malicious program can do great evil things to the machine > by for example sucking up as much memory as possible and any other > critical resources it can get, then calling the magic "lock me" method > and the only way out would be a power cycle. maybe i'm not understanding you, but it sounds like this is a non-issue. a process which is in uninterruptable sleep is simply placed on a wait queue and not scheduled at all if you want to talk about evil stuff, then ... well sure. ALL kernel code is trusted code, starting with a simple call to printk() to code that modifies system calls. they ALL present dr. evil with the opportunity to wreak havoc. you certainly don't need a state D process for that! > Processes that get wedged in state D can also prevent the filesystems > from unmounting... sure. but *any* part of the kernel can put itself to sleep. it's as simple as passing a macro to a function call. > If you think of a few cases that locking the process is valid please > let me know, I probably overlooked something... well, i just gave one. but here's another. suppose you're some kernel code and you're waiting for some event to happen, so you put yourself to sleep. but suppose the event occurs AFTER you decide to put yourself to sleep but BEFORE you actually do go to sleep. poorly written code won't recover from this type of race condition. and then we need to debate whether poorly written code is a bug. > > as you point out, it can be kernel bug. often a race condition. > > but it can also be caused by hardware failure. > > Most any hardware bugs can be worked around in software... heh. ok, i'm willing to concede this point, but only because we're talking about symantics now. is not supporting a hardware bug considered a kernel bug? maybe. maybe not. there's nearly an infinite number of things bad hardware can do. should the kernel have a work around for all of them? all possible conceivable crazy things hardware can do? this isn't quite as simple as a switch that tests the value of an integer. should we call code buggy if it doesn't address all possible circumstances? i dunno! > The kernel is still alive and functioning, the driver knows > how much data is queued on the device, it knows what data rate is > being played and it could easily determine that the device has locked > up... and reset the device. Most drivers will reset their devices > when they detect a timeout or other "shouldn't happen" sort of > error condition... if the device doesn't respond to the reset > report that and return IO error messages to user space. > > A work around as drastic as blacklisting the buggy chipset is > acceptable if the authors can't figure out how to dance around > the problem. exactly. > > the chipset in question is known to have issues in both linux and > > windows. > > Hrmmm... I agree that I see reports of problems with the "via chipsets" > even in the kernel documentation directory... > /usr/src/linux/Documentation/sound/VIA-chipset > saying that there was no word back from VIA but that file is ancient > ... dated Jan 1999. > > I had heard via was much more active supporting linux, and > now that I look further they appear to have step by step directions
Re: [vox-tech] ac97 sound problems
Mark, thanks for the advice on ALSA. I got that set up and it does work. On Wednesday 24 April 2002 11:59 pm, you wrote: > I think I setup a Mandrake 8.2 on a system with ac97. Is your machine a > Sony VAIO, slight purplish-silver color with a fold-out cover for the > floppy? Is it a system with 2 USB connections on front as well as the > back, got IEEE 1394-like connector with a disclaimer that it may not work > with all 1394 devices? And it's got both DVD and CDRW? It also has a > blue-LED power button that's long-thin-width shape on the front low-middle > center? I've seen that system poping up everywhere these days; apparently > it hit the sweet spot in price and power. No, I dont have this system. I put a new motherboard/processor (FIC AN11) in my old system. thanks again! Kai ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: Tough nuts for "kill -9" (was Re: [vox-tech] ac97 sound problems)
On Thu, Apr 25, 2002 at 12:36:02PM -0700, Jeff Newmiller wrote: > On Thu, 25 Apr 2002, Peter Jay Salzman wrote: > > begin [EMAIL PROTECTED] <[EMAIL PROTECTED]> > > > 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. > > The process may also be a zombie... this has been discussed on this list > and is a Unix FAQ ... Heh, zombie "processes" are already dead, which is why they can not be killed. On Linux all of their resources are released and they only occupy a few pages of memory for process state and return code, until their parent calls wait on them (which "buries" them). It's true that you can send them -9 and they will still appear in ps. Later, Mike ... in another bold statement all processes become zombies just after they exit. unless _maybe_ you are on a SMP machine... except maybe init, and all those those pesky kernel threads... ;) (I'm actually not certain of implementation, it could be that the kernel may suspend the process that exits, before cleaning up after it and flaging it as a Z state, to signal the parent... but that seems messy.) ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] ac97 sound problems
On Thu, Apr 25, 2002 at 11:05:43AM -0700, Peter Jay Salzman wrote: > begin [EMAIL PROTECTED] <[EMAIL PROTECTED]> > > 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. > > as you point out, processes in "uninterruptable sleep" can't be killed > with SIGKILL. the process is put to sleep while the kernel waits for > some event to happen. this corresponds to process status "D". It is true that processes in state D don't die instantly, I had not considered them. Even processes in state D should die in a few seconds or _maybe_ a minute for a very slow device... but I can't think of any thing at the moment that is a _valid_ reason to lock a process in uninterruptable sleep forever. Realize that when the kernel exposes a method to become "stuck" forever in that state a malicious program can do great evil things to the machine by for example sucking up as much memory as possible and any other critical resources it can get, then calling the magic "lock me" method and the only way out would be a power cycle. Processes that get wedged in state D can also prevent the filesystems from unmounting... If you think of a few cases that locking the process is valid please let me know, I probably overlooked something... > as you point out, it can be kernel bug. often a race condition. > but it can also be caused by hardware failure. Most any hardware bugs can be worked around in software... The kernel is still alive and functioning, the driver knows how much data is queued on the device, it knows what data rate is being played and it could easily determine that the device has locked up... and reset the device. Most drivers will reset their devices when they detect a timeout or other "shouldn't happen" sort of error condition... if the device doesn't respond to the reset report that and return IO error messages to user space. A work around as drastic as blacklisting the buggy chipset is acceptable if the authors can't figure out how to dance around the problem. > the chipset in question is known to have issues in both linux and > windows. Hrmmm... I agree that I see reports of problems with the "via chipsets" even in the kernel documentation directory... /usr/src/linux/Documentation/sound/VIA-chipset saying that there was no word back from VIA but that file is ancient ... dated Jan 1999. I had heard via was much more active supporting linux, and now that I look further they appear to have step by step directions for enabling their chipsets in Linux... http://www.viaarena.com/?PageID=88 also public support forums available, possibly looking there would be another good place. Later, Mike ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Tough nuts for "kill -9" (was Re: [vox-tech] ac97 sound problems)
On Thu, 25 Apr 2002, Peter Jay Salzman wrote: > mike, > > as always, this was a very informative post! i think i may have > something to add. > > begin [EMAIL PROTECTED] <[EMAIL PROTECTED]> > > > > 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. > > > So you have a kernel bug. > > as you point out, processes in "uninterruptable sleep" can't be killed > with SIGKILL. the process is put to sleep while the kernel waits for > some event to happen. this corresponds to process status "D". > > as you point out, it can be kernel bug. often a race condition. > but it can also be caused by hardware failure. The process may also be a zombie... this has been discussed on this list and is a Unix FAQ ... http://www.erlenstar.demon.co.uk/unix/faq_2.html#SEC13 In such cases, you need to find and clean up the parent of the zombie and then wait a moment for the process table to get cleaned up. --- Jeff NewmillerThe . . Go Live... DCN:<[EMAIL PROTECTED]>Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] ac97 sound problems
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:
# #defineEAGAIN 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 Supp
Re: [vox-tech] ac97 sound problems
mike, as always, this was a very informative post! i think i may have something to add. begin [EMAIL PROTECTED] <[EMAIL PROTECTED]> > > 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. > So you have a kernel bug. as you point out, processes in "uninterruptable sleep" can't be killed with SIGKILL. the process is put to sleep while the kernel waits for some event to happen. this corresponds to process status "D". as you point out, it can be kernel bug. often a race condition. but it can also be caused by hardware failure. the chipset in question is known to have issues in both linux and windows. pete ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] ac97 sound problems
I think I setup a Mandrake 8.2 on a system with ac97. Is your machine a Sony VAIO, slight purplish-silver color with a fold-out cover for the floppy? Is it a system with 2 USB connections on front as well as the back, got IEEE 1394-like connector with a disclaimer that it may not work with all 1394 devices? And it's got both DVD and CDRW? It also has a blue-LED power button that's long-thin-width shape on the front low-middle center? I've seen that system poping up everywhere these days; apparently it hit the sweet spot in price and power. Mandrake 8.2 does support that system's sound card, but the autodetection doesn't work quite well with that sound board. You'll need to modify /etc/modules.conf to use one of the Alsa drivers instead of the kernel's sound driver. I don't have the exact info at the moment (and won't until next month, as I am nowhere near that machine right now), but you can get the information from Alsa's homepage: http://www.alsa-project.org/ Here's what you'll need to do: 1. Go to their sound card matrix and find your sound card. It should tell you which driver you should use. 2. Go to their manual section and find one of the examples that tells you what to add to your /etc/modules.conf (or /etc/conf.modules). The example for adding code to /etc/modules.conf should be about 10 lines. Do not look for the example for ISAPNP or PNP, but the normal one. 3. In your /etc/modules.conf or /etc/conf.modules, remove the reference to the current sound card driver. 4. Type in the example code you found in step #2, but replace the references to the example sound card driver with yours. Several of their examples are also for systems with more than one sound card, so remove any references to extra sound cards. 5. Reboot. Your sound card should now work. BTW, you don't need to download their drivers from the website; Mandrake already comes with them. But you do need the documentation from their website for steps #1 and #2. If you're not sure how to do the above, just let me know and I'll get back to you in about a week. -Mark On Wed, 24 Apr 2002, Kai Harris wrote: > I'm having problems getting sound out of my onboard soundcard. This appears > to be a fairly common problem for other Mandrake users (i recently upgraded > to 8.2, although the sound didn't work in 8.1 either) gauging from the > Mandrake Support website and various Google searches. However, I have been > unable to find a description/solution to my particular problem. > > I'm not getting any sound at all out of my VIA VT8233 AC97 integrated > soundcard. Here is a list of what I know about the device: > > 1. the ac97 device driver is being loaded on startup: > from dmesg: > 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 > via_audio: ignoring drain playback error -11 > via_audio: ignoring drain playback error -11 > > I'm not sure what the "ignoring drain playback error" message is, i'm hoping > someone might be able to shed some light on that. > > 2. the soundcard is setup as a module. > from /etc/modules.conf: > alias sound-slot-0 via82cxxx_audio > > 3. the file permissions for /dev/sound: > crw-rw1 kai audio 14, 4 Dec 31 1969 audio > crw-rw1 kai audio 14, 3 Dec 31 1969 dsp > crw-rw1 kai audio 14, 5 Dec 31 1969 dspW > crw-rw1 kai audio 14, 0 Dec 31 1969 mixer > crw-rw1 kai audio 14, 1 Dec 31 1969 sequencer > crw-rw1 kai audio 14, 8 Dec 31 1969 sequencer2 > and for /dev/dsp: > lr-xr-xr-x 1 root root 9 Apr 14 11:56 dsp -> sound/dsp > > 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? > > 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 > > 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
