From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael Chan" Subject: Re: Mystery packet killing tg3 Date: Wed, 04 May 2005 15:30:22 -0700 Message-ID: <1115245822.15156.78.camel@rh4> References: <20050504155143.1a78cb7a@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com Return-path: To: "Stephen Hemminger" In-Reply-To: <20050504155143.1a78cb7a@dxpl.pdx.osdl.net> Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com List-Id: netdev.vger.kernel.org On Wed, 2005-05-04 at 15:51 -0700, Stephen Hemminger wrote: > On Tue, 3 May 2005 23:27:38 -0700 > "Michael Chan" wrote: > > > I think stop_block errors can only happen during dev_close, suspend, netdev > > watchdog, or ethtool "set" calls. > > It seems that dhclient was failing on bootup then taking the device down. > When the device down happened it got the tg3_stop_block from > Call Trace:{:tg3:tg3_stop_block+185} {:tg3:tg3_abort_hw+605} > {:tg3:tg3_halt+40} {:tg3:tg3_close+71} > {dev_close+100} {dev_change_flags+104} > {devinet_ioctl+773} {inet_ioctl+92} > {sock_ioctl+556} {do_ioctl+58} > {vfs_ioctl+715} {sys_ioctl+77} > {system_call+126} > This makes sense. Before the dhclient closes the device, was the device functioning properly? If not, was it not sending or not receiving? If the device was functioning properly prior to the close, meaning that the dhclient was closing because there was no response from the dhcp server, then the stop_block error was inconsequential.