From owner-freebsd-arm@FreeBSD.ORG Tue Feb 26 18:52:16 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BA982925 for ; Tue, 26 Feb 2013 18:52:16 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 7155218CF for ; Tue, 26 Feb 2013 18:52:16 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UAPdK-0006uW-5k; Tue, 26 Feb 2013 18:52:10 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1QIq7oX082417; Tue, 26 Feb 2013 11:52:07 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19Il/uXpzoc6hVEb+oMXSyj Subject: RE: Raspberry Pi Network Data From: Ian Lepore To: Sean Cavanaugh In-Reply-To: References: <20130226120335.6928b473@ivory.wynn.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Feb 2013 11:52:07 -0700 Message-ID: <1361904727.16937.133.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, 'Brett Wynkoop' X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 18:52:16 -0000 On Tue, 2013-02-26 at 13:17 -0500, Sean Cavanaugh wrote: > > > -----Original Message----- > > From: owner-freebsd-arm@freebsd.org [mailto:owner-freebsd- > > arm@freebsd.org] On Behalf Of Brett Wynkoop > > Sent: Tuesday, February 26, 2013 12:04 PM > > To: freebsd-arm@freebsd.org > > Subject: Raspberry Pi Network Data > > > > Greeting- > > > > For a couple of days I have been building software from ports. Mostly > these > > builds are for things I just want to try on the Pi, or Bone, but the > secondary > > reason is to put some pre-compiled packages up for those that do not have > > the patience to build them. > > > > While my Pi has been stable for a couple of weeks I have noted that > > sometimes it stops talking on the network. At those times if I get on the > > console and ifconfig down and back up the interface it starts talking on > the > > net just fine again. > > > > Last night I believe I found a link between disk i/o and network non- > > responsiveness. During a period of high disk i/o to the USB connected > flash > > drive I lost network. The console had messages about retrys to the disk > and > > the console was slow to respond. It took me for ever to get logged in > > because the console kept dropping characters while I typed. I am using > usb- > > keyboard and composite video for the console. > > > > When I got logged in I still had trouble typing ifconfig ue0 down ; > ifconfig ue0 > > up, but once I did everything went back to normal. > > Keyboard response was fine, disk i/o no longer seemed to be reporting > > errors and of course the network came back on line. > > > > I went to sleep with zoneminder building. Now 6 hours later I find the > > machine in the same state. Since the disk, keyboard, and ethernet are all > usb > > devices could we have a bug in the usb sub-system? > > > > As soon as the ifconfig ue0 down happens the console keyboard becomes > > properly responsive again. Could we have some sort of interrupt problem > > going on here? > > > > This is food for thought for you kernel hackers. If there is anything you > want > > me to specifically try or do the next time I have this problem, probably > in the > > next 24 hours, please let me know. > > > > Your fellow ARM hacker, > > > > -Brett > > > > Keep in mind that the network port, the SD card slot, and obviously the USB > ports themselves are all on the same USB bus. That may be part of the issue. > Definitely agree that it should be able to swap between them easier than > manually shunting it. Not the sd card, it has its own dedicated sdhci controller in the SoC. The only usb thing active on my rpi is the onboard hardware (hub and network interface) and it has a tendency to occasionally drop off the bus and return. Actually, it's not just the ethernet, the whole hub (onboard hub, not external) disappears and reappears. This happens intermittantly, sometimes several times a day. Twice it has failed to recover -- the hub never reattached until I rebooted. smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy ugen0.2: at usbus0 (disconnected) uhub1: at uhub0, port 1, addr 2 (disconnected) ugen0.3: at usbus0 (disconnected) smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: at uhub1, port 1, addr 3 (disconnected) smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy ukphy0: detached miibus0: detached Feb 26 03:13:05 rpi dhclient[246]: connection closed Feb 26 03:13:05 rpi dhclient[246]: exiting. Feb 26 03:13:05 rpi ntpd[519]: sendto(172.22.42.240) (fd=22): No route to host ugen0.2: at usbus0 uhub1: on usbus0 uhub1: MTT enabled uhub1: 3 ports with 2 removable, self powered Feb 26 03:13:06 rpi ntpd[519]: sendto(172.22.42.254) (fd=22): No route to host ugen0.3: at usbus0 smsc0: on usbus0 smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:33:7c:02 smsc0: chip 0xec00, rev. 0002 -- Ian