Re: [new PATCH] Re: 8139too: defunct threads
On Sun, 15 Apr 2001, Manfred Spraul wrote: > Alan, which fix would you prefer: > * init could use wait3 and set __WALL. > * all kernel thread users could set SIGCHLD. Some already do that > (__call_usermodehelper). > * the kernel_thread implementations could force the exit signal to > SIGCHLD. > > I'd prefer the last version. > The attached patch is tested with i386. The alpha, parisc and ppc > assember changes are guessed. This patch fixed my problem. Thanks, -Rms - 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: [new PATCH] Re: 8139too: defunct threads
On Sun, 15 Apr 2001, Manfred Spraul wrote: Alan, which fix would you prefer: * init could use wait3 and set __WALL. * all kernel thread users could set SIGCHLD. Some already do that (__call_usermodehelper). * the kernel_thread implementations could force the exit signal to SIGCHLD. I'd prefer the last version. The attached patch is tested with i386. The alpha, parisc and ppc assember changes are guessed. This patch fixed my problem. Thanks, -Rms - 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] Re: 8139too: defunct threads
On Sat, 14 Apr 2001, Manfred Spraul wrote: > From: "Alan Cox" <[EMAIL PROTECTED]> > > > > That has an implicit race, a zombie can always appear as we are > execing init. > > I think init wants fixing > > > Rod, could you boot again with the unpatched kernel and send a sigchild > to init? > > #kill -CHLD 1 > > If I understand the init code correctly the sigchild handler reaps all > zombies, but probably the signal got lost because the children died > before the parent was created ;-) That doesn't 'fix' it. The thing I find funny is that it only appears when IP_PNP is compiled in. It is as if the driver ends up in some weird state when IP_PNP is used. According to ps, from my limited understanding, the thread is stuck in do_exit [root@stewart-nw34 /root]# ps elaxww|grep eth F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 044 0 7 1 9 0 00 do_exi Z? 0:00 [eth0 ] 044 0 8 1 9 0 00 do_exi Z? 0:00 [eth1 ] 044 0 9 1 9 0 00 do_exi Z? 0:00 [eth2 ] 040 0 229 1 9 0 00 rtl813 SW ? 0:00 [eth1] Thanks for helping with this, -Rms - 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: 8139too: defunct threads
On Sat, 14 Apr 2001, Manfred Spraul wrote:
> >> Ah. Of course. All (or most) kernel initialisation is
> >> done by PID 1. Search for "kernel_thread" in init/main.c
> >>
> >> So it seems that in your setup, process 1 is not reaping
> >> children, which is why this hasn't been reported before.
> >> Is there something unusual about your setup?
>
> > I found the difference which causes this. If I build my kernel with
> > IP_PNP (IP: kernel level autoconfiguration) support I get a defunt
> > thread for each 8139too device. If I don't build with IP_PNP
> > support I don't get any, defunct ethernet threads.
>
> Does init(8) reap children that died before it was spawned? I assume
> that the defunct tasks were there _before_ init was spawned.
>
> Perhaps init() [in linux/init/main.c] should reap all defunct tasks
> before the execve("/sbin/init").
>
> I've attached an untested patch, could you try it?
Yes, that fixes my problem. No more defunct eth? processes when IP_PNP is
compiled in. With the fix you said to the patch; replacing curtask with
current.
Thanks,
-Rms
-
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: 8139too: defunct threads
On Sat, 14 Apr 2001, Manfred Spraul wrote:
Ah. Of course. All (or most) kernel initialisation is
done by PID 1. Search for "kernel_thread" in init/main.c
So it seems that in your setup, process 1 is not reaping
children, which is why this hasn't been reported before.
Is there something unusual about your setup?
I found the difference which causes this. If I build my kernel with
IP_PNP (IP: kernel level autoconfiguration) support I get a defunt
thread for each 8139too device. If I don't build with IP_PNP
support I don't get any, defunct ethernet threads.
Does init(8) reap children that died before it was spawned? I assume
that the defunct tasks were there _before_ init was spawned.
Perhaps init() [in linux/init/main.c] should reap all defunct tasks
before the execve("/sbin/init").
I've attached an untested patch, could you try it?
Yes, that fixes my problem. No more defunct eth? processes when IP_PNP is
compiled in. With the fix you said to the patch; replacing curtask with
current.
Thanks,
-Rms
-
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] Re: 8139too: defunct threads
On Sat, 14 Apr 2001, Manfred Spraul wrote: From: "Alan Cox" [EMAIL PROTECTED] That has an implicit race, a zombie can always appear as we are execing init. I think init wants fixing Rod, could you boot again with the unpatched kernel and send a sigchild to init? #kill -CHLD 1 If I understand the init code correctly the sigchild handler reaps all zombies, but probably the signal got lost because the children died before the parent was created ;-) That doesn't 'fix' it. The thing I find funny is that it only appears when IP_PNP is compiled in. It is as if the driver ends up in some weird state when IP_PNP is used. According to ps, from my limited understanding, the thread is stuck in do_exit [root@stewart-nw34 /root]# ps elaxww|grep eth F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 044 0 7 1 9 0 00 do_exi Z? 0:00 [eth0 defunct] 044 0 8 1 9 0 00 do_exi Z? 0:00 [eth1 defunct] 044 0 9 1 9 0 00 do_exi Z? 0:00 [eth2 defunct] 040 0 229 1 9 0 00 rtl813 SW ? 0:00 [eth1] Thanks for helping with this, -Rms - 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: 8139too: defunct threads
On Thu, 12 Apr 2001, Andrew Morton wrote: > Rod Stewart wrote: > > > > On Thu, 12 Apr 2001, Andrew Morton wrote: > > > Rod Stewart wrote: > > > > > > > > Hello, > > > > > > > > Using the 8139too driver, 0.9.15c, we have noticed that we get a defunct > > > > thread for each device we have; if the driver is built into the kernel. > > > > If the driver is built as a module, no defunct threads appear. > > > > > > What is the parent PID for the defunct tasks? zero? > > > > According to ps, 1 > > Ah. Of course. All (or most) kernel initialisation is > done by PID 1. Search for "kernel_thread" in init/main.c > > So it seems that in your setup, process 1 is not reaping > children, which is why this hasn't been reported before. > Is there something unusual about your setup? I found the difference which causes this. If I build my kernel with IP_PNP (IP: kernel level autoconfiguration) support I get a defunt thread for each 8139too device. If I don't build with IP_PNP support I don't get any, defunct ethernet threads. This make any sense? Here is the relevant diff from a working config to a bad one: [root@stewart-nw34 conf]# diff -u config-p5-good config-p6-bad --- config-p5-good Fri Apr 13 16:07:10 2001 +++ config-p6-bad Fri Apr 13 16:12:21 2001 @@ -173,7 +173,9 @@ # CONFIG_IP_ROUTE_TOS is not set # CONFIG_IP_ROUTE_VERBOSE is not set # CONFIG_IP_ROUTE_LARGE_TABLES is not set -# CONFIG_IP_PNP is not set +CONFIG_IP_PNP=y +# CONFIG_IP_PNP_BOOTP is not set +# CONFIG_IP_PNP_RARP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m # CONFIG_NET_IPGRE_BROADCAST is not set Thanks, -Rms - 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: 8139too: defunct threads
On Thu, 12 Apr 2001, Andrew Morton wrote: Rod Stewart wrote: On Thu, 12 Apr 2001, Andrew Morton wrote: Rod Stewart wrote: Hello, Using the 8139too driver, 0.9.15c, we have noticed that we get a defunct thread for each device we have; if the driver is built into the kernel. If the driver is built as a module, no defunct threads appear. What is the parent PID for the defunct tasks? zero? According to ps, 1 Ah. Of course. All (or most) kernel initialisation is done by PID 1. Search for "kernel_thread" in init/main.c So it seems that in your setup, process 1 is not reaping children, which is why this hasn't been reported before. Is there something unusual about your setup? I found the difference which causes this. If I build my kernel with IP_PNP (IP: kernel level autoconfiguration) support I get a defunt thread for each 8139too device. If I don't build with IP_PNP support I don't get any, defunct ethernet threads. This make any sense? Here is the relevant diff from a working config to a bad one: [root@stewart-nw34 conf]# diff -u config-p5-good config-p6-bad --- config-p5-good Fri Apr 13 16:07:10 2001 +++ config-p6-bad Fri Apr 13 16:12:21 2001 @@ -173,7 +173,9 @@ # CONFIG_IP_ROUTE_TOS is not set # CONFIG_IP_ROUTE_VERBOSE is not set # CONFIG_IP_ROUTE_LARGE_TABLES is not set -# CONFIG_IP_PNP is not set +CONFIG_IP_PNP=y +# CONFIG_IP_PNP_BOOTP is not set +# CONFIG_IP_PNP_RARP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m # CONFIG_NET_IPGRE_BROADCAST is not set Thanks, -Rms - 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: 8139too: defunct threads
On Thu, 12 Apr 2001, Andrew Morton wrote: > Rod Stewart wrote: > > > > On Thu, 12 Apr 2001, Andrew Morton wrote: > > > Is there something unusual about your setup? > > > > One box is standard PIII with RH 7.0, the other is a custom Crusoe TM5400 > > board. But from further investigation it appears to be a kernel config > > option. As I've got a 2.4.0 kernel which has very little compiled in and > > not showing the problem and another kernel which has many more networking > > options built in and showing the problem. I've seen this problem > > since 2.4.0.test11. > > > > Sorry. I meant: what is process 1 on this machine? Is it not > the normal init? If not, then according to Alan, the fault > lies with your userspace. Kernel requires that PID 1 reap > children. Yes, it is the normal init on both boxes. -Rms - 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: 8139too: defunct threads
On Thu, 12 Apr 2001, Andrew Morton wrote: > Rod Stewart wrote: > > > > On Thu, 12 Apr 2001, Andrew Morton wrote: > > > Rod Stewart wrote: > > > > > > > > Hello, > > > > > > > > Using the 8139too driver, 0.9.15c, we have noticed that we get a defunct > > > > thread for each device we have; if the driver is built into the kernel. > > > > If the driver is built as a module, no defunct threads appear. > > > > > > What is the parent PID for the defunct tasks? zero? > > > > According to ps, 1 > > Ah. Of course. All (or most) kernel initialisation is > done by PID 1. Search for "kernel_thread" in init/main.c > > So it seems that in your setup, process 1 is not reaping > children, which is why this hasn't been reported before. > Is there something unusual about your setup? One box is standard PIII with RH 7.0, the other is a custom Crusoe TM5400 board. But from further investigation it appears to be a kernel config option. As I've got a 2.4.0 kernel which has very little compiled in and not showing the problem and another kernel which has many more networking options built in and showing the problem. I've seen this problem since 2.4.0.test11. I'll send a note once I find the config option which is causing this, probably tomorrow. Thanks, -Rms - 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: 8139too: defunct threads
On Thu, 12 Apr 2001, Andrew Morton wrote: > Rod Stewart wrote: > > > > Hello, > > > > Using the 8139too driver, 0.9.15c, we have noticed that we get a defunct > > thread for each device we have; if the driver is built into the kernel. > > If the driver is built as a module, no defunct threads appear. > > What is the parent PID for the defunct tasks? zero? According to ps, 1 [root@stewart-nw34 networking]# ps alexw F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 044 0 14 1 9 0 00 do_exi Z? 0:00 [eth0 ] 044 0 15 1 9 0 00 do_exi Z? 0:00 [eth1 ] 044 0 16 1 9 0 00 do_exi Z? 0:00 [eth2 ] 040 0 240 1 9 0 00 rtl813 SW ? 0:00 [eth0] -Rms - 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/
8139too: defunct threads
Hello, Using the 8139too driver, 0.9.15c, we have noticed that we get a defunct thread for each device we have; if the driver is built into the kernel. If the driver is built as a module, no defunct threads appear. This has happened with any 2.4 kernel we've used, up to and including 2.4.3. Below is the output from a custom board (but the problem also shows up with a standard PCI card with RTL-8139B) with three RealTek RTL8139 chipsets on it. [root@stewart-nw34 /root]# ps uax|grep eth root14 0.0 0.0 00 ? Z13:39 0:00 [eth0 ] root15 0.0 0.0 00 ? Z13:39 0:00 [eth1 ] root16 0.0 0.0 00 ? Z13:39 0:00 [eth2 ] root 240 0.0 0.0 00 ?SW 13:39 0:00 [eth0] root 572 0.0 0.0 00 pts/1SW 13:49 0:00 [eth1] root 538 0.0 0.4 1216 460 pts/0S13:41 0:00 grep eth 8139too Fast Ethernet driver 0.9.15c loaded PCI: Enabling device 00:05.0 ( -> 0003) PCI: Assigned IRQ 6 for device 00:05.0 PCI: Setting latency timer of device 00:05.0 to 64 eth0: RealTek RTL8139 Fast Ethernet at 0xc780, 00:10:57:01:00:19, IRQ 6 eth0: Identified 8139 chip type 'RTL-8139C' PCI: Enabling device 00:09.0 ( -> 0003) PCI: Assigned IRQ 6 for device 00:09.0 PCI: Setting latency timer of device 00:09.0 to 64 eth1: RealTek RTL8139 Fast Ethernet at 0xc7802100, 00:10:57:02:00:19, IRQ 6 eth1: Identified 8139 chip type 'RTL-8139C' PCI: Enabling device 00:0a.0 ( -> 0003) PCI: Assigned IRQ 6 for device 00:0a.0 PCI: Setting latency timer of device 00:0a.0 to 64 eth2: RealTek RTL8139 Fast Ethernet at 0xc7804200, 00:10:57:03:00:19, IRQ 6 eth2: Identified 8139 chip type 'RTL-8139C' I'm not certain if this is supposed to be expected behaviour or not, if it is we'll tell QA to ignore it. Thanks, -Rms - 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/
8139too: defunct threads
Hello, Using the 8139too driver, 0.9.15c, we have noticed that we get a defunct thread for each device we have; if the driver is built into the kernel. If the driver is built as a module, no defunct threads appear. This has happened with any 2.4 kernel we've used, up to and including 2.4.3. Below is the output from a custom board (but the problem also shows up with a standard PCI card with RTL-8139B) with three RealTek RTL8139 chipsets on it. [root@stewart-nw34 /root]# ps uax|grep eth root14 0.0 0.0 00 ? Z13:39 0:00 [eth0 defunct] root15 0.0 0.0 00 ? Z13:39 0:00 [eth1 defunct] root16 0.0 0.0 00 ? Z13:39 0:00 [eth2 defunct] root 240 0.0 0.0 00 ?SW 13:39 0:00 [eth0] root 572 0.0 0.0 00 pts/1SW 13:49 0:00 [eth1] root 538 0.0 0.4 1216 460 pts/0S13:41 0:00 grep eth 8139too Fast Ethernet driver 0.9.15c loaded PCI: Enabling device 00:05.0 ( - 0003) PCI: Assigned IRQ 6 for device 00:05.0 PCI: Setting latency timer of device 00:05.0 to 64 eth0: RealTek RTL8139 Fast Ethernet at 0xc780, 00:10:57:01:00:19, IRQ 6 eth0: Identified 8139 chip type 'RTL-8139C' PCI: Enabling device 00:09.0 ( - 0003) PCI: Assigned IRQ 6 for device 00:09.0 PCI: Setting latency timer of device 00:09.0 to 64 eth1: RealTek RTL8139 Fast Ethernet at 0xc7802100, 00:10:57:02:00:19, IRQ 6 eth1: Identified 8139 chip type 'RTL-8139C' PCI: Enabling device 00:0a.0 ( - 0003) PCI: Assigned IRQ 6 for device 00:0a.0 PCI: Setting latency timer of device 00:0a.0 to 64 eth2: RealTek RTL8139 Fast Ethernet at 0xc7804200, 00:10:57:03:00:19, IRQ 6 eth2: Identified 8139 chip type 'RTL-8139C' I'm not certain if this is supposed to be expected behaviour or not, if it is we'll tell QA to ignore it. Thanks, -Rms - 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: 8139too: defunct threads
On Thu, 12 Apr 2001, Andrew Morton wrote: Rod Stewart wrote: Hello, Using the 8139too driver, 0.9.15c, we have noticed that we get a defunct thread for each device we have; if the driver is built into the kernel. If the driver is built as a module, no defunct threads appear. What is the parent PID for the defunct tasks? zero? According to ps, 1 [root@stewart-nw34 networking]# ps alexw F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 044 0 14 1 9 0 00 do_exi Z? 0:00 [eth0 defunct] 044 0 15 1 9 0 00 do_exi Z? 0:00 [eth1 defunct] 044 0 16 1 9 0 00 do_exi Z? 0:00 [eth2 defunct] 040 0 240 1 9 0 00 rtl813 SW ? 0:00 [eth0] -Rms - 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: 8139too: defunct threads
On Thu, 12 Apr 2001, Andrew Morton wrote: Rod Stewart wrote: On Thu, 12 Apr 2001, Andrew Morton wrote: Is there something unusual about your setup? One box is standard PIII with RH 7.0, the other is a custom Crusoe TM5400 board. But from further investigation it appears to be a kernel config option. As I've got a 2.4.0 kernel which has very little compiled in and not showing the problem and another kernel which has many more networking options built in and showing the problem. I've seen this problem since 2.4.0.test11. Sorry. I meant: what is process 1 on this machine? Is it not the normal init? If not, then according to Alan, the fault lies with your userspace. Kernel requires that PID 1 reap children. Yes, it is the normal init on both boxes. -Rms - 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: modutils-2.3.21: modprobe looping
On Wed, 29 Nov 2000, Keith Owens wrote: > On Tue, 28 Nov 2000 20:22:59 +0100, > Kurt Garloff <[EMAIL PROTECTED]> wrote: > >Find attached the modules.dep that caused this: There is a circular > >dependency of pppoe on pppox on pppoe on > > The kernel code is broken. Circular dependencies make no sense, the > pppoe maintainer agrees and I thought that bug was fixed. It is fixed in test10/11. -Rms - 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: modutils-2.3.21: modprobe looping
On Wed, 29 Nov 2000, Keith Owens wrote: On Tue, 28 Nov 2000 20:22:59 +0100, Kurt Garloff [EMAIL PROTECTED] wrote: Find attached the modules.dep that caused this: There is a circular dependency of pppoe on pppox on pppoe on The kernel code is broken. Circular dependencies make no sense, the pppoe maintainer agrees and I thought that bug was fixed. It is fixed in test10/11. -Rms - 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/
