Did you install the appropriate System.map in /usr/src/linux? If not,please use the -m option to specify the correct System.map file.

> > > > and boot messages. And booting with> > >> > > Difficult, I have no log in this case. I don't see unusual message> > > before the oops except :> > > > I need those boot messages.> > Here is a log of a successful boot with devfs-patch-v200 but without> starting devfsd.

Well, that doesn't help. I need to see the boot messages with when itfails. And I need the debugging output from passing "devfs=dall" tothe kernel as well.

> > > none already mounted on /dev> > > > 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 soexplicitely.

> > > /dev is only a mountpoint on my system. I have no other fallback without> > > devfs but a working kernel (thanksfully there are plenty).> > >> > > > "devfs=dall" is required as well.> > >> > > No option appended (no 'devfs='). grub.> > > > I know nothing about grub. Somehow, you need to pass "devfs=dall" to> > maybe I should pass an option but so far it was working without any,> as you can see it in the command line from the log above.

Argh! I want to see the boot messages when "devfs=dall" is passed,*for the failure case*! Otherwise I don't know exactly at which pointit fails, nor do I know what has happened prior to the failure point.These kinds of bugs are usually the result of a chain of events, so Ineed to see what's been going on, a step at a time. Hence"devfs=dall".

> > the kernel when booting. And I need to see the boot messages when this> > option is given to the kernel. If it's too verbose, you can try> > "devfs=dreg,dunreg,dfree" instead. Copy the messages down by hand if> > you need to, but I need to see them. Do yourself a favour and set up a> > serial console so you can capture boot messages easily.> > I'll try my best, I like devfs.

Great. That will help in getting full debugging information.

> > Also, make sure you are not using any proprietary drivers (like> > NVidia). If you have such drivers, move them to another directory to> > no chance

I'm not asking you to give up using NVidia drivers forever, but it'svery important that those drivers are not loaded until the Oops hashappened, you've captured the boot messages, run them through ksymoopsand either mailed them to me, or at the very least saved them to afile for later emailing. By moving the NVidia drivers, you ensure thatthey aren't autoloaded prior to Oops generation and debug capturing.

If you're unwilling to move those drivers elsewhere (I don't see whythis is a problem for you: you can live without them for a fewminutes), then neither I nor anyone else on this list can or will helpyou. Binary-only drivers like NVidia cause no end of problems, andkernels with them loaded (or even once loaded and then unloaded) arenot debuggable by the community. For all I know, the NVidia driverabuses devfs in some way, and there isn't a bug in devfs itself. Butnot having the source, *I can't be sure*. And since I don't know, Ican't help.

Just why are you unwilling to move those drivers?

> > 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 unlessthere is a kernel bug (i.e. a devfs bug, or maybe a driver bug). Ibelieve that devfsd-v1.3.20 should not make it more likely to get anOops than when using devfsd-1.3.18. If devfsd-v1.3.20 really doestrigger an Oops while 1.3.18 doesn't then please try 1.3.19 and reportthe results.

A separate issue is why rxvt doesn't work. Again, it's important totry devfsd-v1.3.19 to see if that also breaks rxvt. If so, report andalso send a strace output of rxvt so I can see what's going wrongthere.

Finally, please try kernel 2.4.17-pre1, which has the latest versionof devfs. The 2.5.1-pre kernels have a lot of new experimental codewhich could be causing some of the problems. By using 2.4.17, itlimits the changes to (mostly) devfs, so limits the variables. Whenyou use 2.5.1, I can't tell if there is a bug in devfs, or perhapssome driver which is doing something illegal with devfs.