From owner-freebsd-sparc64@FreeBSD.ORG Mon Dec 6 04:58:28 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 845C816A4CE; Mon, 6 Dec 2004 04:58:28 +0000 (GMT) Received: from ns.kt-is.co.kr (ns.kt-is.co.kr [211.218.149.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id E53D943D31; Mon, 6 Dec 2004 04:58:27 +0000 (GMT) (envelope-from yongari@kt-is.co.kr) Received: from michelle.kt-is.co.kr (ns2.kt-is.co.kr [220.76.118.193]) (authenticated bits=128) by ns.kt-is.co.kr (8.12.10/8.12.10) with ESMTP id iB64uTAh051770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Dec 2004 13:56:29 +0900 (KST) Received: from michelle.kt-is.co.kr (localhost.kt-is.co.kr [127.0.0.1]) by michelle.kt-is.co.kr (8.13.1/8.13.1) with ESMTP id iB64wLMu001241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Dec 2004 13:58:21 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Received: (from yongari@localhost) by michelle.kt-is.co.kr (8.13.1/8.13.1/Submit) id iB64wKZT001240; Mon, 6 Dec 2004 13:58:20 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Date: Mon, 6 Dec 2004 13:58:19 +0900 From: Pyun YongHyeon To: Scott Long Message-ID: <20041206045819.GB744@kt-is.co.kr> References: <60205.24.112.41.105.1102267644.squirrel@24.112.41.105> <41B3495C.3040805@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41B3495C.3040805@freebsd.org> User-Agent: Mutt/1.4.2.1i X-Filter-Version: 1.11a (ns.kt-is.co.kr) cc: sparc64@freebsd.org cc: jnaughto@ee.ryerson.ca cc: Pyun YongHyeon Subject: Re: issues... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: yongari@kt-is.co.kr List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2004 04:58:28 -0000 On Sun, Dec 05, 2004 at 10:46:04AM -0700, Scott Long wrote: > [Forwarding to the sparc64 list and one of the sparc64 developers for > input] > > jnaughto@ee.ryerson.ca wrote: > >Hi, > > > >I have a Ultra sparc R420 which has 2gigs of ram and 2 450Mhz processors. > >I > >thought it would be a great machine to provide DNS/mail/webmail services. > >I > >installed Freebsd 5.3 on the server and I'm fighting with the station now. > >What I mean by "fighting" is that the station likes to spontaneously > >reboot. I've cvsup'ed the latest in the RELENG5 source tree. Re-compiled > >using the > >32bit time_t (I've read the UPDATING file), and yet the station still > >likes to > >crash... > > > >The hardware was in use for some time running solaris, yet I didn't want to > >put a solaris workstation in my public side of my network. Can you tell > >me if > >the following errors could be responsible for the system crashing: > > > >Dec 5 02:21:13 eccles kernel: hme0: error signaled, status=0x3010501 > >Dec 5 02:21:13 eccles kernel: hme0: error signaled, status=0x3010501 > >Dec 5 02:21:29 eccles kernel: hme0: error signaled, status=0x400 > >Dec 5 02:36:41 eccles kernel: hme0: error signaled, status=0x3010501 > >Dec 5 02:43:07 eccles kernel: hme0: error signaled, status=0x3010501 > >Dec 5 02:43:07 eccles kernel: hme0: too may errors; not reporting any more > > > >I've have also installed 1 intel-express pro pci card which doesn't seem > >to be > >reporting any errors. Any suggestions? > > Unfortunatly, I have no idea why it spews the message. And hme(4), I admit, is not tolerant on errors and its statistics are not correct. For example, expire counter bits in global status registers are not error at all. So, in your error message there are two errors. 1. TX Master Err Ack 2. Max Packet Size Error The first error is "fatal" one and it should not happen in normal circumstances. Normally it indicates H/W error or serious programming error in our driver. The only action that can be done by driver is reseting the H/W. However, your message shows that it's not freqeunet enough in time line and it seems that DMA engine is still alive. So I don't think resetting the H/W would help in this case. If I were you, I would have checked duplex negotiation settings. I guess the second error is the side effect of the first error. If your happy meal ethernet H/W is sane I don't think the errors you encountered cause a spontaneous system reboot. > > > > Cheers > > Jason > > > >Jason Naughton, Lead Engineer, > >Department of Electrical Engineering, Ryerson University > >87 Gerrard St. E., Toronto, Ontario, M5B 2K3 > >Office: (416)-979-5000 x7168 Fax: (416)-979-5280 > > > > > -- Regards, Pyun YongHyeon http://www.kr.freebsd.org/~yongari | yongari@freebsd.org