Messages in this thread | | | Date | Sat, 1 Dec 2001 18:49:54 -0700 | From | Richard Gooch <> | Subject | Re: 2.4.17pre2: devfs: devfs_mk_dir(printers): could not append to dir: dffe45c0 "", err: -17 |
| |
Adam Schrotenboer writes: > On Saturday 01 December 2001 13:08, Richard Gooch wrote: > > linux-kernel@borntraeger.net writes: > <snip> > > The new devfs core is less forgiving about these kinds of > > bugs/misuses. > > > > > devfs: devfs_register(nvidiactl): could not append to parent, err: -17 > > > devfs: devfs_register(nvidia0): could not append to parent, err: -17 > > > > > > with 2.4.16 and before the message was: > > > > > > devfs: devfs_register(): device already registered: "nvidia0" > > > > Who knows what nvidia does? Talk to them. Could be a bug in their > > driver where they create duplicate entries (the old devfs code would > > often let you get away with this). Or again, perhaps something in > > user-space is creating these entries. > > > As of 1541 anyway (haven't tried anything newer, assuming newer > exists), the make install of the nvidia driver also runs > makedevices.sh (a vendor sp script that makes the devnodes. This may > also have been put in the initscripts (mine isn't, but i tend to use > the tar.gz fmt, not using the RPMs) Perhaps there is no check for > devfs (likely will be fixed in the next release, as this is a new > situation)
Well, it doesn't matter if the install script dumps things into /dev, since that will be lost on the next boot anyway. What matters is if the boot scripts (or something else) puts things in devfs.
> > > Why has this changed, and what is actually happen? My system runs > > > fine. > > > > You're lucky that the with way you use your system, it still works. > > > <snip> AFAIK, the nvidia scipt does not make the devnodes persistent > (if so, it's b0rken on my box)
You can easily check this: move the NVidia drivers elsewhere and reboot. If device nodes for nvidia appear in devfs, then something in user-space is creating those inodes.
Regards,
Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |