[lkml]   [2001]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.5.1-pre5 not easy to boot with devfs
    Richard Gooch wrote:

    > I assume if you use kernel 2.4.16 with devfsd-1.3.20 that there is no
    > Oops?

    No there is no oops with 2.4.16, BUT I am sure CONFIG_DEBUG_KERNEL is
    not set in my kernel 2.4.16. I shall try to re-compile it with it.

    2.5.1-pre5 is fine as well, provided that you don't say yes to

    >ksymoops 2.4.3 on i686 2.5.1-pre5. Options used
    > -V (default)
    > -k /proc/ksyms (default)
    > -l /proc/modules (default)
    > -o /lib/modules/2.5.1-pre5/ (default)
    > -m /usr/src/linux/ (default)
    > Did you install the appropriate in /usr/src/linux? If not,

    I am building linux in /usr/gnu/linux. There is only one file in
    /usr/src/linux, the I put before running ksymoops.

    > > > Edit your /etc/fstab and remove the line for devfs. You don't
    > > > need/want that if you have CONFIG_DEVFS_MOUNT=y.
    > >
    > > no problem
    > I assume that didn't help. It would be helpful if you said so
    > explicitely.

    I have now removed this line in fstab. It was useful when /dev had
    permanent device files. With devfs only it's not needed but it doesn't

    > I'm not asking you to give up using NVidia drivers forever, but it's
    > very important that those drivers are not loaded until the Oops has
    > happened, you've captured the boot messages, run them through ksymoops
    > and either mailed them to me, or at the very least saved them to a
    > file for later emailing. By moving the NVidia drivers, you ensure that
    > they aren't autoloaded prior to Oops generation and debug capturing.
    > If you're unwilling to move those drivers elsewhere (I don't see why
    > this is a problem for you: you can live without them for a few
    > minutes), then neither I nor anyone else on this list can or will help
    > you. Binary-only drivers like NVidia cause no end of problems, and
    > kernels with them loaded (or even once loaded and then unloaded) are
    > not debuggable by the community. For all I know, the NVidia driver
    > abuses devfs in some way, and there isn't a bug in devfs itself. But
    > not having the source, *I can't be sure*. And since I don't know, I
    > can't help.
    > Just why are you unwilling to move those drivers?

    You misundertood me. I would never include in the kernel a binary driver
    which would break at each new release of linux.

    > > > prevent their being loaded. Even if you load but don't use such
    > > > drivers, they still make debugging information unreliable.
    > > >
    > > > I've had a look at the code, and I see no reason for devfs to fail in
    > > > this way, unless some driver is abusing it.
    > >
    > > I would suspect 1st devfsd. 2.4.16 is not happy at all with
    > > devfsd-1.3.20, even rxvt fails to find a terminal.
    > Devfsd is just a user-space process, and can't cause an Oops unless
    > there is a kernel bug (i.e. a devfs bug, or maybe a driver bug). I
    > believe that devfsd-v1.3.20 should not make it more likely to get an
    > Oops than when using devfsd-1.3.18. If devfsd-v1.3.20 really does
    > trigger an Oops while 1.3.18 doesn't then please try 1.3.19 and report
    > the results.
    > A separate issue is why rxvt doesn't work. Again, it's important to
    > try devfsd-v1.3.19 to see if that also breaks rxvt. If so, report and
    > also send a strace output of rxvt so I can see what's going wrong
    > there.
    > Finally, please try kernel 2.4.17-pre1, which has the latest version
    > of devfs. The 2.5.1-pre kernels have a lot of new experimental code
    > which could be causing some of the problems. By using 2.4.17, it
    > limits the changes to (mostly) devfs, so limits the variables. When
    > you use 2.5.1, I can't tell if there is a bug in devfs, or perhaps
    > some driver which is doing something illegal with devfs.

    Pierre Rousselet <>
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:13    [W:0.026 / U:3.512 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site