Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 3 Sep 2003 08:50:30 -0700 (PDT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: conf/56031: ipfw hangs on every invocation
Message-ID:  <200309031550.h83FoUej092140@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR conf/56031; it has been noted by GNATS.

From: Robert Watson <rwatson@FreeBSD.org>
To: "James F.  Hranicky" <jfh@cise.ufl.edu>
Cc: FreeBSD-gnats-submit@FreeBSD.org, admin@cise.ufl.edu,
	freebsd-bugs@FreeBSD.org
Subject: Re: conf/56031: ipfw hangs on every invocation
Date: Wed, 3 Sep 2003 11:45:41 -0400 (EDT)

 On Wed, 3 Sep 2003, James F.  Hranicky wrote:
 
 > On Tue, 2 Sep 2003 12:10:28 -0400 (EDT)
 > Robert Watson <rwatson@FreeBSD.org> wrote:
 > 
 > > 
 > > On Tue, 2 Sep 2003, James F.  Hranicky wrote:
 > > 
 > > > Let me know if I can provide any more info. 
 > > 
 > > This seems to suggest it's really just the userland application spinning,
 > > not a hang in the kernel.  Could you try using truss to see if, once it
 > > starts spinning, it's making system calls, or just stuck entirely in
 > > userspace?
 > 
 > As far as I can tell it's hanging in the last ioctl() .
 
 In, or after?  The "Running" state reported by Ctrl-T suggests it is in
 userspace spinning, perhaps as a result of an unexpected return from the
 ioctl()...
 
 > > Assuming it's purely a userspace problem (perhaps triggered by
 > > syntactically poor output from the kernel), the next thing to do is
 > > probably to instrument your ipfw binary with either printfs or debugging
 > > symbols and see where in its execution it is spinning.  
 > 
 > I can compile it with debugging symbols and trace through the execution, 
 > but it seems like the ioctl() is where it's hanging, again some kind of
 > odd terminal thing.
 > 
 > > Could you include a list of your IPFW rules also, please?  
 > 
 > I don't have any set at this time, just the default pass any any. 
 > 
 > I'll trace through it with gdb if you think it will help.
 
 I'd step up to the ioctl in question, and then see if it really hangs in
 the ioctl(), or if it gets past and starts spinning.  If it's the ioctl(),
 it would be very helpful to know which file descriptor it's on, and what
 the arguments are.  If it's not the ioctl() call, we need to figure out
 which loop isn't taking something important into account.
 
 Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
 robert@fledge.watson.org      Network Associates Laboratories
 
 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200309031550.h83FoUej092140>