lkml.org 
[lkml]   [2001]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/
\
 
 \ /
  Last update: 2005-03-22 13:13    [from the cache]
©2003-2011 Jasper Spaans