>>
>> I just booted into 2.4.19-pre10-ac2 for the first time, and noticed
>> something very odd: my disk activity light was flashing at about
>> half-second intervals, very regularly, and I could hear the disk
>> moving. I was only able to track it down to which disk controller, via
>> /proc/interrupts (are there any tools for monitoring VFS activity?
>> They'd be really useful). Eventually I hunted down the program causing
>> it: xmms.
>>
>> The reason turned out to be that I hadn't remembered to build my sound
>> driver for this kernel version. Every half-second xmms tried to open
>> /dev/mixer (and failed, ENOENT). Every time it did that there was
>> actual disk activity. Easily reproducible without xmms. Reproducible
>> on any non-existant device in devfs, but not for nonexisting files on
>> other filesystems. Is something bypassing the normal disk cache
>> mechanisms here? That doesn't seem right at all.
>>
>
>
>syslog activity from a printk, perhaps?
No. It is most probably devfsd trying to load sound modules.
This is exactly the reason Mandrake does not enable devfs in kernel-secure.
You can badly hit your system by doing in a loop ls /dev/foo for some device
foo that is configured for module autoloading.
It is very fascist decision; the slightly more forgiving way is to disable
devfsd module autoloading (or disable devfsd entirely, just run it once
after all drivers are loaded to execute actions) but then you lose support
for hot plugging and some people do use kernel-secure on desktops.
-andrej
On Mon, Jun 17, 2002 at 10:59:26AM +0400, Borsenkow Andrej wrote:
> >>
> >> I just booted into 2.4.19-pre10-ac2 for the first time, and noticed
> >> something very odd: my disk activity light was flashing at about
> >> half-second intervals, very regularly, and I could hear the disk
> >> moving. I was only able to track it down to which disk controller, via
> >> /proc/interrupts (are there any tools for monitoring VFS activity?
> >> They'd be really useful). Eventually I hunted down the program causing
> >> it: xmms.
> >>
> >> The reason turned out to be that I hadn't remembered to build my sound
> >> driver for this kernel version. Every half-second xmms tried to open
> >> /dev/mixer (and failed, ENOENT). Every time it did that there was
> >> actual disk activity. Easily reproducible without xmms. Reproducible
> >> on any non-existant device in devfs, but not for nonexisting files on
> >> other filesystems. Is something bypassing the normal disk cache
> >> mechanisms here? That doesn't seem right at all.
> >>
> >
> >
> >syslog activity from a printk, perhaps?
>
> No. It is most probably devfsd trying to load sound modules.
>
> This is exactly the reason Mandrake does not enable devfs in kernel-secure.
> You can badly hit your system by doing in a loop ls /dev/foo for some device
> foo that is configured for module autoloading.
>
> It is very fascist decision; the slightly more forgiving way is to disable
> devfsd module autoloading (or disable devfsd entirely, just run it once
> after all drivers are loaded to execute actions) but then you lose support
> for hot plugging and some people do use kernel-secure on desktops.
For the curious, the reason is that modprobe writes even failed attempts
to a log in /var/log/ksymoops, and calls fdatasync() on that file
afterwards. There is no way to disable this without removing that
directory, as a design decision. I don't personally see the point in
logging attempts which fail because there is no driver...
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
Daniel Jacobowitz writes:
> On Mon, Jun 17, 2002 at 10:59:26AM +0400, Borsenkow Andrej wrote:
> > >>
> > >> I just booted into 2.4.19-pre10-ac2 for the first time, and noticed
> > >> something very odd: my disk activity light was flashing at about
> > >> half-second intervals, very regularly, and I could hear the disk
> > >> moving. I was only able to track it down to which disk controller, via
> > >> /proc/interrupts (are there any tools for monitoring VFS activity?
> > >> They'd be really useful). Eventually I hunted down the program causing
> > >> it: xmms.
> > >>
> > >> The reason turned out to be that I hadn't remembered to build my sound
> > >> driver for this kernel version. Every half-second xmms tried to open
> > >> /dev/mixer (and failed, ENOENT). Every time it did that there was
> > >> actual disk activity. Easily reproducible without xmms. Reproducible
> > >> on any non-existant device in devfs, but not for nonexisting files on
> > >> other filesystems. Is something bypassing the normal disk cache
> > >> mechanisms here? That doesn't seem right at all.
> > >>
> > >
> > >
> > >syslog activity from a printk, perhaps?
> >
> > No. It is most probably devfsd trying to load sound modules.
> >
> > This is exactly the reason Mandrake does not enable devfs in kernel-secure.
> > You can badly hit your system by doing in a loop ls /dev/foo for some device
> > foo that is configured for module autoloading.
> >
> > It is very fascist decision; the slightly more forgiving way is to disable
> > devfsd module autoloading (or disable devfsd entirely, just run it once
> > after all drivers are loaded to execute actions) but then you lose support
> > for hot plugging and some people do use kernel-secure on desktops.
>
> For the curious, the reason is that modprobe writes even failed
> attempts to a log in /var/log/ksymoops, and calls fdatasync() on
> that file afterwards. There is no way to disable this without
> removing that directory, as a design decision. I don't personally
> see the point in logging attempts which fail because there is no
> driver...
Sounds like the behaviour of modprobe needs to be fixed.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
Borsenkow Andrej writes:
> >>
> >> I just booted into 2.4.19-pre10-ac2 for the first time, and noticed
> >> something very odd: my disk activity light was flashing at about
> >> half-second intervals, very regularly, and I could hear the disk
> >> moving. I was only able to track it down to which disk controller, via
> >> /proc/interrupts (are there any tools for monitoring VFS activity?
> >> They'd be really useful). Eventually I hunted down the program causing
> >> it: xmms.
> >>
> >> The reason turned out to be that I hadn't remembered to build my sound
> >> driver for this kernel version. Every half-second xmms tried to open
> >> /dev/mixer (and failed, ENOENT). Every time it did that there was
> >> actual disk activity. Easily reproducible without xmms. Reproducible
> >> on any non-existant device in devfs, but not for nonexisting files on
> >> other filesystems. Is something bypassing the normal disk cache
> >> mechanisms here? That doesn't seem right at all.
> >>
> >
> >
> >syslog activity from a printk, perhaps?
>
> No. It is most probably devfsd trying to load sound modules.
>
> This is exactly the reason Mandrake does not enable devfs in
> kernel-secure. You can badly hit your system by doing in a loop ls
> /dev/foo for some device foo that is configured for module
> autoloading.
>
> It is very fascist decision; the slightly more forgiving way is to
> disable devfsd module autoloading (or disable devfsd entirely, just
> run it once after all drivers are loaded to execute actions) but
> then you lose support for hot plugging and some people do use
> kernel-secure on desktops.
Or you can use the IGNORE action to selectively disable loading of
some modules (whether or not they exist).
Another option is to write a shared object extension to devfsd which
has rate-limiting. All the mechanisms you need are there or can be
built on top of the existing infrastructure.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
On Tue, 25 Jun 2002 23:38:48 -0400,
Richard Gooch <[email protected]> wrote:
>Daniel Jacobowitz writes:
>> For the curious, the reason is that modprobe writes even failed
>> attempts to a log in /var/log/ksymoops, and calls fdatasync() on
>> that file afterwards. There is no way to disable this without
>> removing that directory, as a design decision. I don't personally
>> see the point in logging attempts which fail because there is no
>> driver...
>
>Sounds like the behaviour of modprobe needs to be fixed.
People wanted to know what was invoking modprobe and with what
parameters, especially for failed attempts. The call to fdatasync() is
to "ensure" that the log data hits the disk _before_ the module is
loaded, otherwise debugging data is lost if the module init routine
oopses.
Keith Owens writes:
> On Tue, 25 Jun 2002 23:38:48 -0400,
> Richard Gooch <[email protected]> wrote:
> >Daniel Jacobowitz writes:
> >> For the curious, the reason is that modprobe writes even failed
> >> attempts to a log in /var/log/ksymoops, and calls fdatasync() on
> >> that file afterwards. There is no way to disable this without
> >> removing that directory, as a design decision. I don't personally
> >> see the point in logging attempts which fail because there is no
> >> driver...
> >
> >Sounds like the behaviour of modprobe needs to be fixed.
>
> People wanted to know what was invoking modprobe and with what
> parameters, especially for failed attempts. The call to fdatasync()
> is to "ensure" that the log data hits the disk _before_ the module
> is loaded, otherwise debugging data is lost if the module init
> routine oopses.
Then there needs to be a way of enabling/disabling this. Maybe a
run-time config option?
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]