Re: Patch to make mount follow a symlink at /etc/mtab
I wrote: > I attach a patch that modifies the mount program in the util-linux > package so that if /etc/mtab is a symbolic link (to a location outside > of /proc) then mount accesses mtab at the target of the symbolic link. I have discovered a problem with the patch I posted here. With the patch applied, umount aborts if it is called without "-n" and the mtab file is not writable. This is different from the current behavior of the umount program and, I have discovered, there are scripts out there that run umount without "-n" when the root filesystem is mounted read-only. So I have changed the patch to make umount not abort if mtab is not writable and "-n" is not specified. Get the updated patch at: http://panopticon.csustan.edu/thood/readonly-root.html -- Thomas Hood - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Patch to make mount follow a symlink at /etc/mtab
I attach a patch that modifies the mount program in the util-linux
package so that if /etc/mtab is a symbolic link (to a location outside
of /proc) then mount accesses mtab at the target of the symbolic link.
This feature is useful when the root filesystem is mounted read-only;
/etc/mtab can then be symlinked to a location on a writable filesystem.
In the long run mtab should be eliminated entirely but in the meantime
it is nice to be able to relocate the file.
The patch deals correctly with the fact that mount creates lock files
in the same directory as mtab.
This patch also fixes a bug in umount.c whereby umount will update mtab
in some circumstances even though the -n option has been given.
I wrote the patch in August 2003 and submitted it to the util-linux
maintainer at that time. He said that he would apply it if it proved
to be reliable after some testing. The patch has been on my web page
http://panopticon.csustan.edu/thood/readonly-root.html
for almost two years since then, updated from time to time as new
versions of util-linux were released. I have advertised the patch in
various forums and I have used the patch myself for a long time. No
problems have ever been reported.
The latest version of the patch applies to versions 2.12p and 2.12q.
util-linux-2.12q-symlinkmtab_jdth20050709.patch
I tested it by patching the latest Debian and Ubuntu packages. In
order for the latter to build I had to modify 10fstab.dpatch as well.
I attach the patch for that file too.
util-linux-2.12q-symlinkmtab-10fstab_jdth20050709.patch
--
Thomas Hood
diff -uNr util-linux-2.12p_ORIG/mount/fstab.c util-linux-2.12p/mount/fstab.c
--- util-linux-2.12p_ORIG/mount/fstab.c 2004-12-21 20:09:24.0 +0100
+++ util-linux-2.12p/mount/fstab.c 2005-07-09 11:53:19.0 +0200
@@ -1,7 +1,10 @@
-/* 1999-02-22 Arkadiusz Mi¶kiewicz <[EMAIL PROTECTED]>
+/*
+ * 1999-02-22 Arkadiusz Mi¶kiewicz <[EMAIL PROTECTED]>
* - added Native Language Support
- * Sun Mar 21 1999 - Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
+ * 1999-03-21 Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
* - fixed strerr(errno) in gettext calls
+ * 2003-08-08 Thomas Hood <[EMAIL PROTECTED]> with help from Patrick McLean
+ * - Write through a symlink at /etc/mtab if it doesn't point into /proc/
*/
#include
@@ -11,67 +14,129 @@
#include
#include "mntent.h"
#include "fstab.h"
+#include "realpath.h"
#include "sundries.h"
#include "xmalloc.h"
#include "mount_blkid.h"
#include "paths.h"
#include "nls.h"
-#define streq(s, t) (strcmp ((s), (t)) == 0)
-
-#define PROC_MOUNTS "/proc/mounts"
-
-
/* Information about mtab. */
-static int have_mtab_info = 0;
-static int var_mtab_does_not_exist = 0;
-static int var_mtab_is_a_symlink = 0;
+/* A 64 bit number can be displayed in 20 decimal digits */
+#define LEN_LARGEST_PID 20
+#define MTAB_PATH_MAX (PATH_MAX - (sizeof(MTAB_LOCK_SUFFIX) - 1) - LEN_LARGEST_PID)
+static char mtab_path[MTAB_PATH_MAX];
+static char mtab_lock_path[PATH_MAX];
+static char mtab_lock_targ[PATH_MAX];
+static char mtab_temp_path[PATH_MAX];
-static void
+/*
+ * Set mtab_path to the real path of the mtab file
+ * or to the null string if that path is inaccessible
+ *
+ * Run this early
+ */
+void
get_mtab_info(void) {
struct stat mtab_stat;
- if (!have_mtab_info) {
- if (lstat(MOUNTED, &mtab_stat))
- var_mtab_does_not_exist = 1;
- else if (S_ISLNK(mtab_stat.st_mode))
- var_mtab_is_a_symlink = 1;
- have_mtab_info = 1;
+ if (lstat(MOUNTED, &mtab_stat)) {
+ /* Assume that the lstat error means that the file does not exist */
+ /* (Maybe we should check errno here) */
+ strcpy(mtab_path, MOUNTED);
+ } else if (S_ISLNK(mtab_stat.st_mode)) {
+ /* Is a symlink */
+ int len;
+ char *r = myrealpath(MOUNTED, mtab_path, MTAB_PATH_MAX);
+ mtab_path[MTAB_PATH_MAX - 1] = 0; /* Just to be sure */
+ len = strlen(mtab_path);
+ if (
+ r == NULL
+ || len == 0
+ || len >= (MTAB_PATH_MAX - 1)
+ || streqn(mtab_path, PATH_PROC, sizeof(PATH_PROC) - 1)
+ ) {
+ /* Real path invalid or inaccessible */
+ mtab_path[0] = '\0';
+ return;
+ }
+ /* mtab_path now contains mtab's real path */
+ } else {
+ /* Exists and is not a symlink */
+ strcpy(mtab_path, MOUNTED);
}
+
+ sprintf(mtab_lock_path, "%s%s", mtab_path, MTAB_LOCK_SUFFIX);
+ sprintf(mtab_lock_targ, "%s%s%d", mtab_path, MTAB_LOCK_SUFFIX, getpid());
+ sprintf(mtab_temp_path, "%s%s", mtab_path, MTAB_TEMP_SUFFIX);
+
+ return;
}
-int
-mtab_does_not_exist(void) {
- get_mtab_info();
- return var_mtab_does_not_exist;
+/*
+ * Tell whether or not the mtab real path is accessible
+ *
+ * get_mtab_info() must have been run
+ */
+static int
+mtab_is_accessible(void) {
+ return (mtab_path[0] != '\0');
}
+/*
+ * Tell whe
[BUG] "unregister_netdevice: waiting for eth0 to become free. Usage count = 2"
>Groan< The "unregister_netdevice" bug is back. I haven't been able to do extensive testing, but I have just encountered the message unregister_netdevice: waiting for eth0 to become free. Usage count = 2 again. Once it starts, it repeats ad infinitum, once per second. The message starts spewing when I do a "cardctl eject" on a Xircom CEM56 modem/ethernet card (driven by xirc2ps_cs.o, serial.o) which was previously configured using DHCP with IPX enabled. The cardctl eject never completes and the OS will not shut down completely; it hangs at the point where it tries to de-configure network interfaces. Disabling IPX cured the problem for me the next time I tried. I am running 2.4.6-ac2, but the bug could have been reintroduced a while back. I haven't been using Ethernet for a couple of months. Well, I'm no expert on the networking code, so I'll just suggest some things that look odd to me. I'm looking in net/ipx/af_ipx.c, tracing through ipxitf_create(). This function exits with dev->refcnt incremented ... unless something goes wrong, in which case the function exits through via a goto to "out_dev" which decrements the refcnt again. Likewise, ipxitf_auto_create() increments the dev refcnt (by doing a dev_hold(dev)) if all goes well. However when I look at ipxitf_delete(), which I presume ought to undo what the *_create() functions do, I see nothing that decrements the refcnt. If this is where the bug lies then I would suggest that the functions be documented to say that "this function exits with the refcnt incremented if blah blah blah", etc. As an aside, I notice that __dev_get_by_name() is called from ipxitf_delete(). A comment preceding __dev_get_by_name() in net/core/dev.c says that this function should be called "under RTNL semaphore or @dev_base_lock", but it is actually called under the ipx_interfaces_lock. Is this okay? __dev_get_by_name() is also called from within ipxitf_ioctl(), seemingly under no locks at all. Also okay? Thomas Hood - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-ac16 PIIX4 ACPI getting wrong IRQ?
Alan Cox wrote: > > So the ACPI function of the PIIX4 is now being given > > IRQ 9. I don't want this. I was using IRQ 9 for a > > PCMCIA device. > > It was always being given IRQ 9, now we correctly handle this. Okay, but. IRQs are scarce. With previous kernels I was able to use IRQ 9 for other things without any obvious problems. Perhaps this is only because I don't have ACPI support enabled. Still, if I disable ACPI support then shouldn't I be able to use IRQ 9 for other things? If so, shouldn't the kernel to refrain from reserving this IRQ? Thomas Hood jdthood_AT_yahoo.co.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] to deal with bad dev->refcnt in unregister_netdevice()
This bug seems to be fixed in 2.4.2-ac16. Thanks again to Arnaldo Carvalho de Melo. Thomas On 21 Feb 2001 I wrote: > Update on the "unregister_netdevice" bug ... > > Arnaldo Carvalho de Melo found one bug but there > remains another one that makes the dev->refcnt too > high instead of too low. > > To be continued ... > > Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.2-ac16 PIIX4 ACPI getting wrong IRQ?
With 2.4.3-pre1, /proc/pci contained:
> Bus 0, device 7, function 3:
> Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 1).
With 2.4.2-ac16, /proc/pci contains:
> Bus 0, device 7, function 3:
>Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 1).
> IRQ 9.
So the ACPI function of the PIIX4 is now being given
IRQ 9. I don't want this. I was using IRQ 9 for a
PCMCIA device.
So I tried booting the kernel with "acpi=off" and
"pci=irqmask=0x0800", but the result was the same.
Documentation/kernel-parameters.txt says that
"pci=irqmask=0x ... sets a bit mask of IRQs allowed
to be assigned". This parameter is being ignored.
[... searches through kernel sources ...]
Well I see that this is the result of a change to
/usr/src/linux-2.4.2-ac16/arch/i386/kernel/pci_pc.c
which looks deliberate:
< static void __init pci_fixup_piix4_acpi(struct pci_dev *d)
< {
< /*
<* PIIX4 ACPI device: hardwired IRQ9
<*/
< d->irq = 9;
< }
What's going on?
Thomas Hood
jdthood_AT_yahoo.co.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 corruption: IDE + PCMCIA ?
I have seen the same sort of problem in the past. My conclusion was that there was a problem with dynamic registering and unregistering of ide interfaces. Thomas Hood jdthood_AT_yahoo.co.uk > I've experienced some disk corruption on my laptop. > > Scenario: > I'm cross-compiling tons of sources and I felt the need > to insert a CompactFlash card (via PCMCIA) in my laptop. > So I did, no problem: > mounted, touched a file, umounted, cardctl-ejected. > > Pretty soon my compilation stops: > bash: /usr/bin/sort: cannot execute binary file > > Okey. The date on /usr/bin/sort is unchanged. Must be root to write. > [...] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Forcible removal of modules
Hi. Here's my question, with a little introduction. Sometimes modules need to be reloaded in order to cause some sort of reinitialization (of the driver or of the hardware) to occur. Sometimes this has to be done every time a machine is suspended. E.g., some sound driver modules need to be reloaded after an APM suspend because the sound chip forgets its configuration during the suspend. Obviously, one would like to be able to automate the process of unloading and reloading the modules by putting some commands in the apmd_proxy script. Sometimes, though, "rmmod themodulename" fails because some process is holding open a device handled by the device driver module in question. The solution to this is to do a "fuser" on the device nodes associated with the device driver and kill all the processes reported to be using those nodes. However, this is easier said than done because of one problem: while you are killing a batch of processes that are using the device node, other processes may be opening that device node! What is needed is a way of preventing processes from opening a given device node. Now, one way of doing this is to change the device permissions on the node to 000. Unfortunately this does not work well with devfs under the circumstances we have in mind here: because once the permissions are changed the device driver is removed; then devfs stores "000" as the permissions that are to be used for that device node when it is created again. My question is: Is there some better way of blocking all open() calls to a particular device driver while processes using it are being killed off? Thomas Hood ___ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should isa-pnp utilize the PnP BIOS?
Okay, a couple of people have responded positively to this suggestion. The next question is, how should it be implemented? How 'bout: $ cd pcmcia-cs/modules $ cp pnp_bios.c pnp_proc.c pnp_rsrc.c /usr/src/linux/2.4.2a/drivers/pnp $ cd ../include/linux $ cp pnp_bios.h pnp_resource.h /usr/src/linux/2.4.2a/include/linux Edit makefiles Edit isapnp.c to include new global flag "isapnp_usepnpbios", a MODULE_PARM, which each isapnp function checks at entry. If the flag is set then: in the case of "low-level" functions, return immediately; in the case of "high-level" functions, call appropriate pnp_bios functions to perform the task; in the case of isapnp_init(), just check isapnp_disabled and exit. isapnp's /proc interface would not be supported. Presumably inter_module_get_request() would be used to call the isapnp-bios routines. Comments? (Go easy on me; I'm a newbie at kernel hacking.) Thomas > Hello, l-k. > > On my ThinkPad 600, The ThinkPad PnP BIOS configures > all PnP devices at boot time. > > If I load the isa-pnp.o driver it never detects any ISA PnP > devices: it says "isapnp: No Plug & Play device found". This > is unfortunate, because it means that device drivers can't > find out from isa-pnp where the devices are. > > David Hinds's pcmcia-cs package contains driver code that > interfaces with the PnP BIOS. With it, one can list the resource > usage of ISA PnP devices (serial and parallel ports, sound chip, > etc.) and set them, using the "lspnp" and "setpnp" commands. > > Would it not be useful if the isa-pnp driver would fall back > to utilizing the PnP BIOS (if possible) in order to read and > change ISA PnP device configurations when it can't do this > itself? If so, could this perhaps be done by bringing the Hinds > PnP BIOS driver into the kernel and interfacing isa-pnp to it? > > Thomas Hood > jdthood_AT_yahoo.co.uk <- Change '_AT_' to '@' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Should isa-pnp utilize the PnP BIOS?
Hello, l-k. On my ThinkPad 600, The ThinkPad PnP BIOS configures all PnP devices at boot time. If I load the isa-pnp.o driver it never detects any ISA PnP devices: it says "isapnp: No Plug & Play device found". This is unfortunate, because it means that device drivers can't find out from isa-pnp where the devices are. David Hinds's pcmcia-cs package contains driver code that interfaces with the PnP BIOS. With it, one can list the resource usage of ISA PnP devices (serial and parallel ports, sound chip, etc.) and set them, using the "lspnp" and "setpnp" commands. Would it not be useful if the isa-pnp driver would fall back to utilizing the PnP BIOS (if possible) in order to read and change ISA PnP device configurations when it can't do this itself? If so, could this perhaps be done by bringing the Hinds PnP BIOS driver into the kernel and interfacing isa-pnp to it? Thomas Hood jdthood_AT_yahoo.co.uk <- Change '_AT_' to '@' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] to deal with bad dev->refcnt in unregister_netdevice()
Update on the "unregister_netdevice" bug ... Arnaldo Carvalho de Melo found one bug but there remains another one that makes the dev->refcnt too high instead of too low. To be continued ... Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] to deal with bad dev->refcnt in unregister_netdevice()
Update on the "unregister_netdevice" bug ... Arnaldo Carvalho de Melo has been valiantly trying in his scarce free time to find the cause. I haven't been able to hunt effectively because I don't really understand the networking code; however I have been experimenting to see what are the exact conditions under which the failure occurs. I modified my kernel to print dev->refcnt in /proc/net/dev so that I could see what the refcnt of eth0 is at any given moment. One of the more interesting experiment logs is appended below. Experimentation seems to show 1) It happens when ipx is used, specifically when auto_interface=on and auto_primary=on 2) It happens only or especially when using DHCP 3) It happens only to PCMCIA ethernet cards Thomas Hood jdthood_AT_yahoo.co.uk Linux 2.4.1-ac10 /etc/pcmcia/network disabled with an 'exit 0' command refcnt message --- -- --- (boot) 0 (I inserted Xircom card) 1 ifconfig eth0 up 2 ipx_configure --auto_interface=on --auto_primary=on2 ifconfig eth0 down 0 "Freeing alive device c127ac8c, eth0" cardctl eject? "unregister_netdevice: waiting for eth0 to become free. Usage count = 0 Message from syslogd@thanatos at Wed Feb 14 12:51:26 2001 ... thanatos kernel: unregister_netdevice: waiting for eth0 to become free. Usage count = 0" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] to deal with bad dev->refcnt in unregister_netdevice()
Sorry, but it turns out that the bug is not completely
fixed by the change that acme made. With the change,
ifup-ing and if-downing eth0 with the ipx module loaded
no longer reduces eth0's refcnt to an indefinitely low
(larger and larger negative) number. However if the ipx
module is loaded first and ipx configured on eth0, and
then the network card inserted and "ifconfig eth0 up" done,
and then "ifconfig eth0 down" done, then once again the
refcnt is too low, so that when I try to "cardctl eject"
my ethernet card, "modprobe -r xirc2ps_cs" hangs up.
This whole business of refcnts needs to be thought
through more carefully.
> This bug was fixed by "acme" in 2.4.1-ac10. :)
> The ipx driver now increments refcnt on NETDEV_UP to
> match downing the interface on NETDEV_DOWN.
>
> Thanks all.
> Thomas
>
>
> > Okay, I now know the cause of this problem. It's a bug in
> > the ipx driver. (This also closes pcmcia-cs bug #126563.)
> >
> > Through copious use of printk()s I was able to track down
> > the point at which the dev->refcnt for my card was being
> > erroneously decremented. It was being erroneously decremented
> > by "notifier_call_chain(&netdev_chain, NETDEV_DOWN, dev);"
> > near the end of the "dev_close()" function in net/core/dev.c.
> > This indicated that one of the registered notifiers
> > was doing an improper "dev_put()". I rmmod-ed the ipx module
> > from my system and the problem magically disappeared. The
> > refcnt is no longer inappropriately decremented and there
> > are no more inappropriate calls to netdev_finish_unregister()
> > in the absence of a prior call to unregister_netdevice()
> > (which is what resulted in the "Freeing alive device" messages).
> >
> > Where is the bug? It is in the ipx driver. When I configure
> > eth0 for ipx, the device gets added to the ipx driver's linked
> > list of devices headed at "ipx_interfaces". The ipx driver
> > registers the following function to be notified of net events.
> > It's clear that the ipx driver will do a __ipxitf_put (which
> > decrements dev-refcnt and does a dev_put() on dev) every time
> > eth0 is taken down with "ifconfig eth0 down"! That would be
> > okay, I guess, if the opposite were done on an "ifconfig eth0 up"
> > but it isn't. This needs to be fixed somehow. I'll leave it
> > up to the maintainers and other gurus to figure out how. In
> > the meantime I'll just avoid using ipx.
> >
> > net/ipx/af_ipx.c ---
> > static int ipxitf_device_event(struct notifier_block *notifier,
> > unsigned long event, void *ptr)
> > {
> > struct net_device *dev = ptr;
> > ipx_interface *i, *tmp;
> >
> > if (event != NETDEV_DOWN)
> > return NOTIFY_DONE;
> >
> > spin_lock_bh(&ipx_interfaces_lock);
> > for (i = ipx_interfaces; i;) {
> > tmp = i->if_next;
> > if (i->if_dev == dev)
> > __ipxitf_put(i);
> > i = tmp;
> >
> > }
> > spin_unlock_bh(&ipx_interfaces_lock);
> > return NOTIFY_DONE;
> > }
> > --
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://vger.kernel.org/lkml/
Re: [PATCH] to deal with bad dev->refcnt in unregister_netdevice()
This bug was fixed by "acme" in 2.4.1-ac10. :)
The ipx driver now increments refcnt on NETDEV_UP to
match downing the interface on NETDEV_DOWN.
Thanks all.
Thomas
> Okay, I now know the cause of this problem. It's a bug in
> the ipx driver. (This also closes pcmcia-cs bug #126563.)
>
> Through copious use of printk()s I was able to track down
> the point at which the dev->refcnt for my card was being
> erroneously decremented. It was being erroneously decremented
> by "notifier_call_chain(&netdev_chain, NETDEV_DOWN, dev);"
> near the end of the "dev_close()" function in net/core/dev.c.
> This indicated that one of the registered notifiers
> was doing an improper "dev_put()". I rmmod-ed the ipx module
> from my system and the problem magically disappeared. The
> refcnt is no longer inappropriately decremented and there
> are no more inappropriate calls to netdev_finish_unregister()
> in the absence of a prior call to unregister_netdevice()
> (which is what resulted in the "Freeing alive device" messages).
>
> Where is the bug? It is in the ipx driver. When I configure
> eth0 for ipx, the device gets added to the ipx driver's linked
> list of devices headed at "ipx_interfaces". The ipx driver
> registers the following function to be notified of net events.
> It's clear that the ipx driver will do a __ipxitf_put (which
> decrements dev-refcnt and does a dev_put() on dev) every time
> eth0 is taken down with "ifconfig eth0 down"! That would be
> okay, I guess, if the opposite were done on an "ifconfig eth0 up"
> but it isn't. This needs to be fixed somehow. I'll leave it
> up to the maintainers and other gurus to figure out how. In
> the meantime I'll just avoid using ipx.
>
> net/ipx/af_ipx.c ---
> static int ipxitf_device_event(struct notifier_block *notifier,
> unsigned long event, void *ptr)
> {
> struct net_device *dev = ptr;
> ipx_interface *i, *tmp;
>
> if (event != NETDEV_DOWN)
> return NOTIFY_DONE;
>
> spin_lock_bh(&ipx_interfaces_lock);
> for (i = ipx_interfaces; i;) {
> tmp = i->if_next;
> if (i->if_dev == dev)
> __ipxitf_put(i);
> i = tmp;
>
> }
> spin_unlock_bh(&ipx_interfaces_lock);
> return NOTIFY_DONE;
> }
> --
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] to deal with bad dev->refcnt in unregister_netdevice()
> > Here is a patch which may not solve the underlying > > This does not. refcnt cannot be <1 at this point. The refcnt shouldn't be less than 1, but it is in fact less than 1. (As I'm sure you understand.) > > assuming that the latter messages aren't serious? > > They are fatal. Machine must be rebooted after them. True. I found that with testing---lots of ifups and ifdowns, etc.---the kernel becomes unstable. > > I hope the networking gurus can find the real bugs here. > > Well, someone forgets to grab refcnt or makes redundant dev_put. > Try to catch this, f.e. adding BUG() to the places where fatal > messages are generated to get backtraces. > Alexey I think that the ipx driver makes an inappropriate dev_put in its notifier callback. However that is for people better acquainted with the come than I to judge. Removing the ipx driver does work around the problem though. Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] to deal with bad dev->refcnt in unregister_netdevice()
Okay, I now know the cause of this problem. It's a bug in
the ipx driver. (This also closes pcmcia-cs bug #126563.)
Through copious use of printk()s I was able to track down
the point at which the dev->refcnt for my card was being
erroneously decremented. It was being erroneously decremented
by "notifier_call_chain(&netdev_chain, NETDEV_DOWN, dev);"
near the end of the "dev_close()" function in net/core/dev.c.
This indicated that one of the registered notifiers
was doing an improper "dev_put()". I rmmod-ed the ipx module
from my system and the problem magically disappeared. The
refcnt is no longer inappropriately decremented and there
are no more inappropriate calls to netdev_finish_unregister()
in the absence of a prior call to unregister_netdevice()
(which is what resulted in the "Freeing alive device" messages).
Where is the bug? It is in the ipx driver. When I configure
eth0 for ipx, the device gets added to the ipx driver's linked
list of devices headed at "ipx_interfaces". The ipx driver
registers the following function to be notified of net events.
It's clear that the ipx driver will do a __ipxitf_put (which
decrements dev-refcnt and does a dev_put() on dev) every time
eth0 is taken down with "ifconfig eth0 down"! That would be
okay, I guess, if the opposite were done on an "ifconfig eth0 up"
but it isn't. This needs to be fixed somehow. I'll leave it
up to the maintainers and other gurus to figure out how. In
the meantime I'll just avoid using ipx.
net/ipx/af_ipx.c ---
static int ipxitf_device_event(struct notifier_block *notifier,
unsigned long event, void *ptr)
{
struct net_device *dev = ptr;
ipx_interface *i, *tmp;
if (event != NETDEV_DOWN)
return NOTIFY_DONE;
spin_lock_bh(&ipx_interfaces_lock);
for (i = ipx_interfaces; i;) {
tmp = i->if_next;
if (i->if_dev == dev)
__ipxitf_put(i);
i = tmp;
}
spin_unlock_bh(&ipx_interfaces_lock);
return NOTIFY_DONE;
}
--
--
Thomas Hood
Please reply to me at: jdthood_AT_yahoo.co.uk
I wrote:
> Earlier I reported error messages when I tried to eject
> a Xircom CEM56 network card under Linux 2.4.x. (See below.
> I also submitted this patch as a followup to that thread.)
>
> Here is a patch which may not solve the underlying
> problem but which does prevent the kernel from generating
> an infinite number of
> "unregister_netdevice: waiting for eth0 to become free.
> Usage count = -1"
> messages on "cardctl eject" and from hanging up at shutdown.
>
> -
> root@thanatos:/usr/src/kernel-source-2.4.1-ac3/net/core# diff -Naur dev.c_ORIG dev.c
> --- dev.c_ORIG Mon Feb 5 17:39:31 2001
> +++ dev.c Wed Feb 7 18:35:45 2001
> @@ -2555,7 +2555,7 @@
> */
>
> now = warning_time = jiffies;
> - while (atomic_read(&dev->refcnt) != 1) {
> + while (atomic_read(&dev->refcnt) > 1) {
> if ((jiffies - now) > 1*HZ) {
> /* Rebroadcast unregister notification */
> notifier_call_chain(&netdev_chain, NETDEV_UNREGISTER, dev);
> ---
>
> The underlying problem seem so be that refcnt is zero or
> less at this point. This is erroneous. The error in
> maintaining the refcnt appears to occur only when
> I configure the eth0 interface (using pump or dhclient).
> The more times I "ifup eth0" and "ifdown eth0" before
> ejecting the card, the lower the "usage count" is
> reported to be (i.e., the larger the negative number!).
>
> Be that as it may, because of the erroneous refcnt,
> the above while loop within unregister_netdevice()
> loops forever in the original code. As modified it
> falls through; and this makes the kernel usable for me.
>
> In order to avoid the
>"KERNEL: assertion(dev->ip_ptr==NULL)failed at
> dev.c(2422):netdev_finish_unregister"
> message and the occasional
>"Freeing alive device"
> message it seems to suffice that I kill the dhclient
> process before running "ifdown eth0". Am I right in
> assuming that the latter messages aren't serious?
>
> I hope the networking gurus can find the real bugs here.
>
> Thomas Hood
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Bug: 2.4.0 w/ PCMCIA on ThinkPad: KERNEL: assertion(dev->ip_ptr==NULL)failed at dev.c(2422):netdev_finish_unregister
This problem has been resolved (sort of). See the follow up to
"[PATCH] to deal with bad dev->refcnt in unregister_netdevice()"
Thomas Hood
> Here is a patch which may not solve the underlying
> problem but which does prevent the kernel from
> generating an infinite number of error messages
> on "cardctl eject" and from hanging up on shutdown.
>
>
> jdthood@thanatos:/usr/src/kernel-source-2.4.1-ac3/net/core# diff dev.c_ORIG dev.c
> 2558c2558
> < while (atomic_read(&dev->refcnt) != 1) {
> ---
> > while (atomic_read(&dev->refcnt) > 1) {
> -
>
> The underlying problem is that refcnt is zero or less
> at this point. This is erroneous. The error in
> maintaining the refcnt appears to occur only when
> I configure the eth0 interface using pump or dhclient.
> Be that as it may, because of the erroneous refcnt,
> this while loop loops forever in the original. As
> modified it falls through; and this makes the kernel
> usable for me.
>
> I hope the networking gurus can find the real bug.
>
> Thomas Hood
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] xirc2ps_cs.c SET_MODULE_OWNER(dev)
I presume that this change needs to be made. (All of the drivers/net/pcmcia/*.c need the change.) // Thomas jdthood@thanatos:/usr/src/kernel-source-2.4.1-ac3/drivers/net/pcmcia# diff -Naur xirc2ps_cs.c_ORIG xirc2ps_cs.c --- xirc2ps_cs.c_ORIG Thu Feb 8 19:11:54 2001 +++ xirc2ps_cs.cThu Feb 8 19:12:01 2001 @@ -637,6 +637,7 @@ link->irq.Instance = dev; /* Fill in card specific entries */ +SET_MODULE_OWNER(dev); dev->hard_start_xmit = &do_start_xmit; dev->set_config = &do_config; dev->get_stats = &do_get_stats; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] to deal with bad dev->refcnt in unregister_netdevice()
Earlier I reported error messages when I tried to eject
a Xircom CEM56 network card under Linux 2.4.x. (See below.
I also submitted this patch as a followup to that thread.)
Here is a patch which may not solve the underlying
problem but which does prevent the kernel from generating
an infinite number of
"unregister_netdevice: waiting for eth0 to become free.
Usage count = -1"
messages on "cardctl eject" and from hanging up at shutdown.
-
root@thanatos:/usr/src/kernel-source-2.4.1-ac3/net/core# diff -Naur dev.c_ORIG dev.c
--- dev.c_ORIG Mon Feb 5 17:39:31 2001
+++ dev.c Wed Feb 7 18:35:45 2001
@@ -2555,7 +2555,7 @@
*/
now = warning_time = jiffies;
- while (atomic_read(&dev->refcnt) != 1) {
+ while (atomic_read(&dev->refcnt) > 1) {
if ((jiffies - now) > 1*HZ) {
/* Rebroadcast unregister notification */
notifier_call_chain(&netdev_chain, NETDEV_UNREGISTER, dev);
---
The underlying problem seem so be that refcnt is zero or
less at this point. This is erroneous. The error in
maintaining the refcnt appears to occur only when
I configure the eth0 interface (using pump or dhclient).
The more times I "ifup eth0" and "ifdown eth0" before
ejecting the card, the lower the "usage count" is
reported to be (i.e., the larger the negative number!).
Be that as it may, because of the erroneous refcnt,
the above while loop within unregister_netdevice()
loops forever in the original code. As modified it
falls through; and this makes the kernel usable for me.
In order to avoid the
"KERNEL: assertion(dev->ip_ptr==NULL)failed at
dev.c(2422):netdev_finish_unregister"
message and the occasional
"Freeing alive device"
message it seems to suffice that I kill the dhclient
process before running "ifdown eth0". Am I right in
assuming that the latter messages aren't serious?
I hope the networking gurus can find the real bugs here.
Thomas Hood
> I have a bit more information about this bug now.
> The message "assertion(yadda) failed ..." occurs only
> if the eth0 interface has been configured using pump
> or dhclient. If the card isn't connected to the network
> the message never occurs. If eth0 is merely brought up
> and down using ifconfig the message doesn't occur. Only
> if pump or dhclient has configured eth0 does the message
> occur. Sometimes it occurs on "ifdown eth0", sometimes
> on "cardctl eject" and sometimes during the shutdown
> sequence.
>
> Thomas
>
> >
> > Dear l-k.
> >
> > I'm still having this problem with kernel 2.4.0:
> >
> > Conditions:
> > Linux 2.4.0 compiled on an IBM ThinkPad 600 51U (Pentium II)
> > laptop with PCMCIA support. Same behavior with integral kernel
> > PCMCIA, modular kernel PCMCIA and modular Hinds PCMCIA. System
> > is Progeny Debian beta II.
> >
> > I have a Xircom modem/ethernet card which works correctly using
> > the serial_cs, xirc2ps_cs, ds, i82365 and pcmcia_core modules;
> > however when I try to "cardctl eject" or "reboot" I get first,
> >"KERNEL: assertion(dev->ip_ptr==NULL)failed at
> > dev.c(2422):netdev_finish_unregister"
> > (not exact since I had to copy it down on paper ... doesn't
> > show up in the logs) then a perpetual series of:
> >"unregister_netdevice: waiting for eth0 to become free.
> > Usage count = -1"
> > messages every five seconds or so. "ps -A" reveals that
> > modprobe is running; it can't be killed even with "kill -9".
> > The "ifconfig" command locks up. Shutdown won't complete
> > so I end up having to use SysRq-S-U-B to reboot.
> >
> > This problem only occurs if the Xircom card is connected to
> > the Ethernet (in which case it is configured using DHCP).
> > If the card is left unconnected to the network, the problem
> > does not occur---the card can be ejected.
> >
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Bug: 2.4.0 w/ PCMCIA on ThinkPad: KERNEL: assertion(dev->ip_ptr==NULL)failed at dev.c(2422):netdev_finish_unregister
Here is a patch which may not solve the underlying
problem but which does prevent the kernel from
generating an infinite number of error messages
on "cardctl eject" and from hanging up on shutdown.
jdthood@thanatos:/usr/src/kernel-source-2.4.1-ac3/net/core# diff dev.c_ORIG dev.c
2558c2558
< while (atomic_read(&dev->refcnt) != 1) {
---
> while (atomic_read(&dev->refcnt) > 1) {
-
The underlying problem is that refcnt is zero or less
at this point. This is erroneous. The error in
maintaining the refcnt appears to occur only when
I configure the eth0 interface using pump or dhclient.
Be that as it may, because of the erroneous refcnt,
this while loop loops forever in the original. As
modified it falls through; and this makes the kernel
usable for me.
I hope the networking gurus can find the real bug.
Thomas Hood
> I have a bit more information about this bug now.
> The message "assertion(yadda) failed ..." occurs only
> if the eth0 interface has been configured using pump
> or dhclient. If the card isn't connected to the network
> the message never occurs. If eth0 is merely brought up
> and down using ifconfig the message doesn't occur. Only
> if pump or dhclient has configured eth0 does the message
> occur. Sometimes it occurs on "ifdown eth0", sometimes
> on "cardctl eject" and sometimes during the shutdown
> sequence.
>
> Thomas
>
> > Dear l-k.
> >
> > I'm still having this problem with kernel 2.4.0:
> >
> > Conditions:
> > Linux 2.4.0 compiled on an IBM ThinkPad 600 51U (Pentium II)
> > laptop with PCMCIA support. Same behavior with integral kernel
> > PCMCIA, modular kernel PCMCIA and modular Hinds PCMCIA. System
> > is Progeny Debian beta II.
> >
> > I have a Xircom modem/ethernet card which works correctly using
> > the serial_cs, xirc2ps_cs, ds, i82365 and pcmcia_core modules;
> > however when I try to "cardctl eject" or "reboot" I get first,
> >"KERNEL: assertion(dev->ip_ptr==NULL)failed at
> > dev.c(2422):netdev_finish_unregister"
> > (not exact since I had to copy it down on paper ... doesn't
> > show up in the logs) then a perpetual series of:
> >"unregister_netdevice: waiting for eth0 to become free.
> > Usage count = -1"
> > messages every five seconds or so. "ps -A" reveals that
> > modprobe is running; it can't be killed even with "kill -9".
> > The "ifconfig" command locks up. Shutdown won't complete
> > so I end up having to use SysRq-S-U-B to reboot.
> >
> > This problem only occurs if the Xircom card is connected to
> > the Ethernet (in which case it is configured using DHCP).
> > If the card is left unconnected to the network, the problem
> > does not occur---the card can be ejected.
> >
> > Thomas Hood
> > Please cc: your replies to me at jdthood_AT_yahoo.co.uk
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Bug: 2.4.0 w/ PCMCIA on ThinkPad: KERNEL: assertion(dev->ip_ptr==NULL)failed at dev.c(2422):netdev_finish_unregister
I have a bit more information about this bug now. The message "assertion(yadda) failed ..." occurs only if the eth0 interface has been configured using pump or dhclient. If the card isn't connected to the network the message never occurs. If eth0 is merely brought up and down using ifconfig the message doesn't occur. Only if pump or dhclient has configured eth0 does the message occur. Sometimes it occurs on "ifdown eth0", sometimes on "cardctl eject" and sometimes during the shutdown sequence. Thomas > Dear l-k. > > I'm still having this problem with kernel 2.4.0: > > Conditions: > Linux 2.4.0 compiled on an IBM ThinkPad 600 51U (Pentium II) > laptop with PCMCIA support. Same behavior with integral kernel > PCMCIA, modular kernel PCMCIA and modular Hinds PCMCIA. System > is Progeny Debian beta II. > > I have a Xircom modem/ethernet card which works correctly using > the serial_cs, xirc2ps_cs, ds, i82365 and pcmcia_core modules; > however when I try to "cardctl eject" or "reboot" I get first, >"KERNEL: assertion(dev->ip_ptr==NULL)failed at > dev.c(2422):netdev_finish_unregister" > (not exact since I had to copy it down on paper ... doesn't > show up in the logs) then a perpetual series of: >"unregister_netdevice: waiting for eth0 to become free. > Usage count = -1" > messages every five seconds or so. "ps -A" reveals that > modprobe is running; it can't be killed even with "kill -9". > The "ifconfig" command locks up. Shutdown won't complete > so I end up having to use SysRq-S-U-B to reboot. > > This problem only occurs if the Xircom card is connected to > the Ethernet (in which case it is configured using DHCP). > If the card is left unconnected to the network, the problem > does not occur---the card can be ejected. > > Thomas Hood > Please cc: your replies to me at jdthood_AT_yahoo.co.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[BUG] Shutting down PCMCIA driver in Linux 2.4.1, "Trying to free nonexistent resource <000003e0-000003e1>"
I get this message when shutting down Linux with 2.4.1 kernel, kernel PCMCIA support compiled as a module. - $ cat /proc/ioports ... 03e0-03e1 : i82365 ... $ sudo reboot (reboot) $ grep 3e0 /var/log/messages Feb 4 18:13:44 thanatos kernel: Trying to free nonexistent resource <03e0-03e1> -- IIRC, during the shutdown sequences the "Trying ..." message appears just after the words "Shutting down PCMCIA card services: cardmgr modules". T. Hood jdthood_AT_mail.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Bug: 2.4.0 w/ PCMCIA on ThinkPad: KERNEL: assertion(dev->ip_ptr==NULL)failed at dev.c(2422):netdev_finish_unregister
Dear l-k. I'm still having this problem with kernel 2.4.0: Conditions: Linux 2.4.0 compiled on an IBM ThinkPad 600 51U (Pentium II) laptop with PCMCIA support. Same behavior with integral kernel PCMCIA, modular kernel PCMCIA and modular Hinds PCMCIA. System is Progeny Debian beta II. I have a Xircom modem/ethernet card which works correctly using the serial_cs, xirc2ps_cs, ds, i82365 and pcmcia_core modules; however when I try to "cardctl eject" or "reboot" I get first, "KERNEL: assertion(dev->ip_ptr==NULL)failed at dev.c(2422):netdev_finish_unregister" (not exact since I had to copy it down on paper ... doesn't show up in the logs) then a perpetual series of: "unregister_netdevice: waiting for eth0 to become free. Usage count = -1" messages every five seconds or so. "ps -A" reveals that modprobe is running; it can't be killed even with "kill -9". The "ifconfig" command locks up. Shutdown won't complete so I end up having to use SysRq-S-U-B to reboot. This problem only occurs if the Xircom card is connected to the Ethernet (in which case it is configured using DHCP). If the card is left unconnected to the network, the problem does not occur---the card can be ejected. Thomas Hood Please cc: your replies to me at jdthood_AT_yahoo.co.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
With recent kernels, ThinkPad 600 won't resume for two minutes after suspend
Hi. With recent kernels, my ThinkPad 600 won't resume for two minutes after it is suspended. When the Fn key is pressed the machine starts up, the CD-ROM scans, the screen backlight turns on, and the APM light flashes. But then it just stays like that instead of restarting the CPU; it is completely hung, although the APM light continues to flash. If I wait more than about two minutes with the machine suspended, however, then everything resumes normally. I have been running Linux for two years. This never happened before a couple weeks ago when I upgraded to kernels 2.2.18 and then 2.4.0 . I have since tested kernel 2.2.17 and see the same problem. Do I have a hardware problem, or might something have changed in the kernel that could lead to this behavior? Thomas Hood jdthood_AT_yahoo.co.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Bug: 2.4.0-test12 w/ PCMCIA on ThinkPad: KERNEL: assertion(dev->ip_ptr==NULL)failed at dev.c(2422):netdev_finish_unregister
2.4.0-test12 compiled on an IBM ThinkPad 600 51U (Pentium II) with PCMCIA support. Same behavior with Linus PCMCIA and Hinds PCMCIA. I have a Xircom modem/ethernet card which works correctly using the serial_cs, xirc2ps_cs, ds, i82365 and pcmcia_core modules; however when I try to "cardctl eject" or "reboot" I get first, "KERNEL: assertion(dev->ip_ptr==NULL)failed at dev.c(2422):netdev_finish_unregister" (not exact since I had to copy it down on paper ... doesn't show up in the logs) then a perpetual series of: "unregister_netdevice: waiting for eth0 to become free. Usage count = -1" messages every five seconds or so. "ps -A" reveals that modprobe is running; it can't be killed even with "kill -9". The "ifconfig" command locks up. Thomas Hood Please cc: your replies to me at jdthood_AT_mail.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Controlling subsystem power using APM
> Linux aesthetics disaproves of no-value-added definitions like
> +struct apm_get_power_state_inparms {
> + unsigned short dev_id;
> +};
This is included for reasons of symmetry---it is
one of the components of a union.
> and in the code you present, rtnval seems redundant,
> since user-level can look at errno to see whether the
> ioctl succeeded.
rtnval is the APM BIOS return code whereas errno
is the ioctl return code.
Thanks
Thomas Hood
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Controlling subsystem power using APM
Hello. For the purpose of minimizing power consumption on a ThinkPad 600 laptop I would like to be able to issue "set power state" and "get power state" commands to the APM BIOS so as to power down the serial port and other subsystems. However the apm code does not presently support this. I have submitted a patch request to the apm code maintainer; my message (#76) can be found at: http://linuxcare.com.au/local-cgi-bin/apm?findid=76 Is this the right way to go about things? If it is a badi idea to add this sort of functionality to the apm driver then an alternative would be to export the address of the APM BIOS so that I could call it myself from a kernel module. Thomas Hood [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
