Hi Jeff,
> (We've got a bunch of SGI Linux boxen running SGI's version of RedHat)
This particular one looks like a 330 with ProPack 1.3-VW. :-)
I think the temporary workaround is to remove rmmod -as from
/etc/cron.d/kmod. I think you have done this.
> looks to me like dmdaemon is using those kernel modules but doesn't have
> the appropriate things open so rmmod sees those modules as not being in
I don't think there is an issue with dmdaemon. What happens is that
when dmdaemon starts up on linux, the loading of the ossaudio dmmodule
causes dmdaemon to open the appropriate /dev/ entry to allow queries
on the ossaudio device. Once it's done with the queries, it closes
these opened file handles since it dosen't need them anymore (and it
should be able to do this without worry). Nor is it a bug in rmmod.
The problem (afaict) lies in the ALSA modules. One note is that I
don't see this problem on my sgi 550 running 1.3-VW + 1.4 (it has a
different version of the ALSA modules and kernel).
dmdaemon causes the loading of the same modules that a basic audio app
would. Could you try repeating the experiment with mpg123 (run mpg123,
exit, rmmod, rmmod)? Also, there's been a couple of revisions of ALSA
since the 0.59 version that shipped with 1.3-VW. I am told that there
will be a sw update for 230/330/550 soon with a new kernel, new ALSA
drivers, new gfx drivers so I'll get the appropriate people to help us
check that this issue dosen't happen on a 330 with said
configuration.
Thanks,
jaya
>
> Hi... I've got a problem with the dmdaemon and rmmod.
>
> My Linux system:
>
> Linux elanor.wetafx.co.nz 2.2.15-3SGI_39smp #1 SMP Mon Jul 24 08:45:16
> EDT 2000 i686 unknown
>
> (We've got a bunch of SGI Linux boxen running SGI's version of RedHat)
> has a bit of a problem when running dmdaemon.
>
> Before I start dmdaemon, on a clean boot after logging in, lsmod looks
> like this (only lines of interest are shown):
>
> Module Size Used by
> snd-mixer-oss 4148 0 (autoclean)
> snd-pcm 31352 0 [snd-card-via686a]
> snd 36108 1 [snd-seq-midi snd-seq-oss
> snd-seq-midi-event snd-seq snd-mixer-oss snd-card-via686a
> snd-mpu401-uart snd-rawmidi snd-seq-device snd-pcm snd-timer
> snd-ac97-codec snd-mixer]
> soundcore 137560 6 [snd]
>
> After I run dmdaemon it changes to this:
>
> Module Size Used by
> snd-pcm-oss 16660 0 (autoclean)
> snd-pcm-plugin 13256 0 (autoclean) [snd-pcm-oss]
> snd-mixer-oss 4148 0 (autoclean) [snd-pcm-oss]
> snd-pcm 31352 0 [snd-pcm-oss snd-pcm-plugin
> snd-card-via686a]
> snd 36108 1 [snd-pcm-oss snd-pcm-plugin
> snd-seq-midi snd-seq-oss snd-seq-midi-event snd-seq snd-mixer-oss
> snd-card-via686a snd-mpu401-uart snd-rawmidi snd-seq-device snd-pcm
> snd-timer snd-ac97-codec snd-mixer]
> soundcore 137560 7 [snd]
>
> but the problem is rmmod -a (well, rmmod -as, which is configured, by
> default, to run every ten minutes via cron). If dmdaemon sits idle,
> that is nothing has opened a device, rmmod -a can run once which
> basically changes the list back to the first and then when rmmod runs
> again, it basically hangs things up, sucking up all the cpu and the
> machine eventually doesn't respond and has to be rebooted.
>
> So, without knowing squat about what causes these loadable kernel
> modules to load and what makes them think they are or are not in use, it
> looks to me like dmdaemon is using those kernel modules but doesn't have
> the appropriate things open so rmmod sees those modules as not being in
> use, unloads them but dmdaemon is in fact still using them so the next
> time rmmod runs it chokes... or something like that.
>
> Anyone else seeing similar behaviour? Does it look like it's a kernel
> problem, an rmmod problem or a dmsdk problem?
>
> On my machine it's easy to make happen.
>
> boot
> run dmdaemon
> run rmmod -a
> run rmmod -a, it will hang
>
> My solution for the moment, is to disable the auto module cleaning ever
> ten minutes.
>
|