After upgrading from 2.4.16 to 2.4.17pre2 I got the following message in
dmesg:
.
parport0: assign_addrs: aa5500ff(80)
parport_pc: Via 686A parallel port: io=0x378
devfs: devfs_mk_dir(printers): could not append to dir: dffe45c0 "", err: -17
lp0: using parport0 (polling).
.
or
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"
Why has this changed, and what is actually happen? My system runs fine.
greetings
Christian Borntr?ger
[email protected] writes:
> After upgrading from 2.4.16 to 2.4.17pre2 I got the following message in
> dmesg:
>
> .
> parport0: assign_addrs: aa5500ff(80)
> parport_pc: Via 686A parallel port: io=0x378
> devfs: devfs_mk_dir(printers): could not append to dir: dffe45c0 "", err: -17
> lp0: using parport0 (polling).
Something other than drivers/char/lp.c is creating (implicitly or
explicitly) the "printers" directory in the devfs root dir. A
find+grep on the kernel sources does not reveal anything which would
do this. Either you are loading some other kernel module to which I
don't have the sources, or you have created /dev/printers from
user-space.
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.
> 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.
BTW: if it is something in user-space creating these entries (say some
vendor-provided boot script which populates devfs with "persistent"
entries), then I suggest you rip out whatever is doing it. Instead, if
you want permissions management, use devfsd-v1.3.20, which provides a
complete solution to this. The new sample devfsd.conf file shows you
how to configure devfsd to do this.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
On Saturday 01 December 2001 13:08, Richard Gooch wrote:
> [email protected] 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)
> > 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)
--
tabris
Adam Schrotenboer writes:
> On Saturday 01 December 2001 13:08, Richard Gooch wrote:
> > [email protected] 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: [email protected]
Current: [email protected]
On Sat, Dec 01, 2001 at 08:37:24PM -0500, Adam Schrotenboer wrote:
> On Saturday 01 December 2001 13:08, Richard Gooch wrote:
> > [email protected] 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)
There is now a 2313 version of the driver. It has put in devfs calls, but it
seems they still call the makedefs script in the make install.
I don't know if the devfs code is correct but here it is.
from nv.c modules_init();
#ifdef CONFIG_DEVFS_FS
rc = devfs_register_chrdev(nv_major, "nvidia", &nv_fops);
#else
rc = register_chrdev(nv_major, "nvidia", &nv_fops);
#endif
if (rc < 0) {
NV_EMSG((nv_state_t *) 0, "init_module: register failed");
return rc;
}
osMemSet(nv_linux_devices, 0, sizeof(nv_linux_state_t) * NV_MAX_DEVICES);
num_devices = nvos_probe_devices();
#ifdef CONFIG_DEVFS_FS
osMemSet(nv_dev_handle, 0, sizeof(devfs_handle_t) * NV_MAX_DEVICES);
do {
char name[16];
int i;
nv_ctl_handle = devfs_register(NULL, "nvidiactl",
DEVFS_FL_DEFAULT, nv_major, 255,
S_IFCHR | S_IRUGO | S_IWUGO,
&nv_fops, NULL);
for (i = 0; i < num_devices; i++) {
snprintf(name, 16, "nvidia%d", i);
nv_dev_handle[i] = devfs_register(NULL, name,
DEVFS_FL_DEFAULT, nv_major, i,
S_IFCHR | S_IRUGO | S_IWUGO,
&nv_fops, NULL);
}
} while(0);
#endif
andrew may writes:
> On Sat, Dec 01, 2001 at 08:37:24PM -0500, Adam Schrotenboer wrote:
> > On Saturday 01 December 2001 13:08, Richard Gooch wrote:
> > > [email protected] 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)
>
> There is now a 2313 version of the driver. It has put in devfs
> calls, but it seems they still call the makedefs script in the make
> install.
What's important is whether something has been added to the boot
scripts which create these device nodes in /dev.
> I don't know if the devfs code is correct but here it is.
>
> from nv.c modules_init();
>
> #ifdef CONFIG_DEVFS_FS
> rc = devfs_register_chrdev(nv_major, "nvidia", &nv_fops);
> #else
> rc = register_chrdev(nv_major, "nvidia", &nv_fops);
> #endif
>
> if (rc < 0) {
> NV_EMSG((nv_state_t *) 0, "init_module: register failed");
> return rc;
> }
>
> osMemSet(nv_linux_devices, 0, sizeof(nv_linux_state_t) * NV_MAX_DEVICES);
> num_devices = nvos_probe_devices();
>
> #ifdef CONFIG_DEVFS_FS
> osMemSet(nv_dev_handle, 0, sizeof(devfs_handle_t) * NV_MAX_DEVICES);
> do {
> char name[16];
> int i;
>
> nv_ctl_handle = devfs_register(NULL, "nvidiactl",
> DEVFS_FL_DEFAULT, nv_major, 255,
> S_IFCHR | S_IRUGO | S_IWUGO,
> &nv_fops, NULL);
>
> for (i = 0; i < num_devices; i++) {
> snprintf(name, 16, "nvidia%d", i);
> nv_dev_handle[i] = devfs_register(NULL, name,
> DEVFS_FL_DEFAULT, nv_major, i,
> S_IFCHR | S_IRUGO | S_IWUGO,
> &nv_fops, NULL);
> }
> } while(0);
> #endif
This appears reasonable. However, if they call this initialisation
code twice, it's a bug.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
<-snip->
> This appears reasonable. However, if they call this initialisation
> code twice, it's a bug.
I found the reason for these messages. It has a boot-script source.
Mandrake stores the attributes of device nodes in /lib/dev-state.
This directory is copied into /dev directly before devfsd is started.
If there is a device file in /lib/dev-state it is created in /dev even before
the driver is loaded.
When the driver is loaded it tries again to create the node and the message
appears.
Thanks for your suggestions and remarks.
greetings
Christian
[email protected] writes:
> I found the reason for these messages. It has a boot-script source.
> Mandrake stores the attributes of device nodes in /lib/dev-state.
> This directory is copied into /dev directly before devfsd is started.
OK, clean out stuff you don't need in /lib/dev-state. Check your
devfsd configuation to see if /lib/dev-state is being repopulated
automatically. If so, grab devfsd-v1.3.20 and use the new RESTORE
directive. This is the correct way to handle persistence. Remove the
boot-script code which populates from /lib/dev-state.
> If there is a device file in /lib/dev-state it is created in /dev
> even before the driver is loaded. When the driver is loaded it
> tries again to create the node and the message appears.
OK, I suspected as much. Good. Thanks for tracking this down.
Attempting to create the same entry twice *should* yield EEXIST on the
second try. The new devfs is strict about this, the old one wasn't.
I consider this issue closed. I'd suggest you contact Mandrake and get
them to upgrade to devfsd-v1.3.20, remove the boot script code and use
the RESTORE directive instead. This requires v1.2 of the devfs core
(found in 2.4.17-pre1).
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
> I consider this issue closed. I'd suggest you contact Mandrake and get
> them to upgrade to devfsd-v1.3.20, remove the boot script code and use
> the RESTORE directive instead. This requires v1.2 of the devfs core
> (found in 2.4.17-pre1).
So the devfs in 2.4.17pre isnt back compatible - definitely 2.5 material
then. This is the same sort of reason the 32bit uid quota code can't go into
2.4 proper. Its a pain but its not reasonable to expect every random devfs
user to handle this in a stable tree update
Alan Cox writes:
> > I consider this issue closed. I'd suggest you contact Mandrake and get
> > them to upgrade to devfsd-v1.3.20, remove the boot script code and use
> > the RESTORE directive instead. This requires v1.2 of the devfs core
> > (found in 2.4.17-pre1).
>
> So the devfs in 2.4.17pre isnt back compatible - definitely 2.5
> material then. This is the same sort of reason the 32bit uid quota
> code can't go into 2.4 proper. Its a pain but its not reasonable to
> expect every random devfs user to handle this in a stable tree
> update
I wouldn't say it's not back compatible. If you want to use a new
devfsd feature, then you need the new devfs. The key difference
between the old and new devfs core (aside from fixing those races) is
that the new devfs core will spit out an EEXIST warning message
whereas before it didn't. But his system still worked. It didn't
break.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
> I wouldn't say it's not back compatible. If you want to use a new
> devfsd feature, then you need the new devfs. The key difference
> between the old and new devfs core (aside from fixing those races) is
> that the new devfs core will spit out an EEXIST warning message
> whereas before it didn't. But his system still worked. It didn't
> break.
Ok so the old devfsd works but spews a few errors. Right - then I agree
with you.
Alan
Alan Cox writes:
> > I wouldn't say it's not back compatible. If you want to use a new
> > devfsd feature, then you need the new devfs. The key difference
> > between the old and new devfs core (aside from fixing those races) is
> > that the new devfs core will spit out an EEXIST warning message
> > whereas before it didn't. But his system still worked. It didn't
> > break.
>
> Ok so the old devfsd works but spews a few errors. Right - then I
> agree with you.
It's not simply the version of devfsd that matters. Upgrading to a new
devfsd won't cause the errors. It's the new devfs core that's issuing
the warnings. These warnings happen because Mandrake populates devfs
with a bunch of inodes early in the boot scripts, then later the
drivers are loaded. When the drivers try to register entries, devfs
spits out the EEXIST warnings.
The point of the new devfsd is that you can use the new RESTORE
directive instead of some kludged-up boot scripts to restore
inodes. The RESTORE directive will only re-create *manually created*
inodes (i.e. when the admin goes "ln -s misc/psaux mouse"), and not
ones created by drivers or devfsd (it does however restore permissions
for any changed inodes). This avoids the duplicates that you otherwise
get with Mandrake's boot scripts.
However, for the new RESTORE directive to do what you want, you need
the new devfs core. Otherwise RESTORE will end up re-creating inodes
created by devfsd (i.e. from MKOLDCOMPAT), which is undesirable.
I hope that explains it clearly.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]