From owner-freebsd-sparc64@FreeBSD.ORG Sun Jun 13 23:58:43 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 22EF916A4D0; Sun, 13 Jun 2004 23:58:43 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9748343D1D; Sun, 13 Jun 2004 23:58:42 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smtp3.sentex.ca (8.12.11/8.12.11) with ESMTP id i5DNwEhc040933; Sun, 13 Jun 2004 19:58:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i5DNwKfP011425; Sun, 13 Jun 2004 19:58:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4A9BE7303F; Sun, 13 Jun 2004 19:58:20 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040613235820.4A9BE7303F@freebsd-current.sentex.ca> Date: Sun, 13 Jun 2004 19:58:20 -0400 (EDT) Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2004 23:58:43 -0000 TB --- 2004-06-13 22:53:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-06-13 22:53:00 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-06-13 22:53:00 - checking out the source tree TB --- 2004-06-13 22:53:00 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64 TB --- 2004-06-13 22:53:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-06-13 22:57:44 - building world (CFLAGS=-O2 -pipe) TB --- 2004-06-13 22:57:44 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src TB --- 2004-06-13 22:57:44 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-06-13 23:54:33 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-06-13 23:54:33 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src TB --- 2004-06-13 23:54:33 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Jun 13 23:54:33 GMT 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /tinderbox/sandbox/CURRENT/sparc64/sparc64/src/sys/net/if_fwsubr.c:281: error: structure has no member named `datagram_size' /tinderbox/sandbox/CURRENT/sparc64/sparc64/src/sys/net/if_fwsubr.c:282: error: structure has no member named `ether_type' /tinderbox/sandbox/CURRENT/sparc64/sparc64/src/sys/net/if_fwsubr.c:289: error: structure has no member named `datagram_size' /tinderbox/sandbox/CURRENT/sparc64/sparc64/src/sys/net/if_fwsubr.c: In function `firewire_input_fragment': /tinderbox/sandbox/CURRENT/sparc64/sparc64/src/sys/net/if_fwsubr.c:359: error: structure has no member named `datagram_size' /tinderbox/sandbox/CURRENT/sparc64/sparc64/src/sys/net/if_fwsubr.c:364: error: structure has no member named `datagram_size' /tinderbox/sandbox/CURRENT/sparc64/sparc64/src/sys/net/if_fwsubr.c: In function `firewire_input': /tinderbox/sandbox/CURRENT/sparc64/sparc64/src/sys/net/if_fwsubr.c:525: error: structure has no member named `ether_type' *** Error code 1 Stop in /tinderbox/sandbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/sandbox/CURRENT/sparc64/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sandbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/sandbox/CURRENT/sparc64/sparc64/src. TB --- 2004-06-13 23:58:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-06-13 23:58:20 - ERROR: failed to build generic kernel TB --- 2004-06-13 23:58:20 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Mon Jun 14 11:01:58 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 828B116A4CE for ; Mon, 14 Jun 2004 11:01:58 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B22D43D2F for ; Mon, 14 Jun 2004 11:01:58 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i5EB1gIj072636 for ; Mon, 14 Jun 2004 11:01:42 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i5EB1fcF072630 for freebsd-sparc64@freebsd.org; Mon, 14 Jun 2004 11:01:41 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 14 Jun 2004 11:01:41 GMT Message-Id: <200406141101.i5EB1fcF072630@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2004 11:01:58 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/12/16] sparc64/60300sparc64 Constant kernel messages: calcru: negativ o [2004/02/21] sparc64/63161sparc64 system panics when writing to an NFS moun 2 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/06/24] sparc64/53670sparc64 pthreads implementation on 5.1-Release sp o [2004/01/29] sparc64/62053sparc64 Using bridging on 5.2 Sparc64 causes imme 2 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2003/10/11] sparc64/57856sparc64 sparc64: IDE Raid controller no detect di o [2004/05/06] sparc64/66314sparc64 SMP kernel panic: ipi_send: couldn't send 2 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Mon Jun 14 15:28:31 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 504AB16A4CE for ; Mon, 14 Jun 2004 15:28:31 +0000 (GMT) Received: from electra.cse.Buffalo.EDU (electra.cse.Buffalo.EDU [128.205.32.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB9CE43D5D for ; Mon, 14 Jun 2004 15:28:30 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from electra.cse.Buffalo.EDU (kensmith@localhost [127.0.0.1]) i5EFSU2n026655 for ; Mon, 14 Jun 2004 11:28:30 -0400 (EDT) Received: (from kensmith@localhost) by electra.cse.Buffalo.EDU (8.12.10/8.12.9/Submit) id i5EFSUMH026654 for freebsd-sparc64@freebsd.org; Mon, 14 Jun 2004 11:28:30 -0400 (EDT) Date: Mon, 14 Jun 2004 11:28:30 -0400 From: Ken Smith To: freebsd-sparc64@freebsd.org Message-ID: <20040614152830.GB26436@electra.cse.Buffalo.EDU> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XF85m9dhOBO43t/C" Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Sparc64 snapshot June 12th, 2004 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2004 15:28:31 -0000 --XF85m9dhOBO43t/C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable There is an ISO built from -current on June 12th, 2004 loaded on ftp-master now. It should propagate to the major mirror sites through the next twelve hours or so. It's in snapshots/sparc64. The MD5 sum is: MD5 (SNAP-20040612-sparc64-miniinst.iso) =3D ca969deed4c3b2a7f7a2f1f30be81e= 08 This includes the first esp(4) driver that doesn't have problems with the CD-ROM, but as I expected Scott fixed tagged transfers half way through the snapshot build... ;-) I'll wait another week to see if there is any more 'fallout' for the driver and build another snapshot next weekend that includes the tagged transfers. Most people interested in this sort of stuff should be able to handle cvsup updates anyway... --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --XF85m9dhOBO43t/C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (SunOS) iD8DBQFAzcQd/G14VSmup/YRAkOwAJ48+v3d9B48LrOJMWjMosbV1OGuxgCgi0SL D2siB8puVCTWLrrN9Qun3o0= =XOLo -----END PGP SIGNATURE----- --XF85m9dhOBO43t/C-- From owner-freebsd-sparc64@FreeBSD.ORG Mon Jun 14 21:44:55 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 9CD8616A4D7; Mon, 14 Jun 2004 21:44:55 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C57743D55; Mon, 14 Jun 2004 21:44:54 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i5ELirte047344; Mon, 14 Jun 2004 17:44:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i5ELirff025987; Mon, 14 Jun 2004 17:44:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 78F487303F; Mon, 14 Jun 2004 17:44:53 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040614214453.78F487303F@freebsd-current.sentex.ca> Date: Mon, 14 Jun 2004 17:44:53 -0400 (EDT) Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2004 21:44:56 -0000 TB --- 2004-06-14 20:50:25 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-06-14 20:50:25 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-06-14 20:50:25 - checking out the source tree TB --- 2004-06-14 20:50:25 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64 TB --- 2004-06-14 20:50:25 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-06-14 20:55:12 - building world (CFLAGS=-O2 -pipe) TB --- 2004-06-14 20:55:12 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src TB --- 2004-06-14 20:55:12 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.bin/fstat cc -O2 -pipe -c /tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/fstat/cd9660.c cc -O2 -pipe -c /tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/fstat/fstat.c /tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/fstat/fstat.c: In function `socktrans': /tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/fstat/fstat.c:855: error: `SS_CANTRCVMORE' undeclared (first use in this function) /tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/fstat/fstat.c:855: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/fstat/fstat.c:855: error: for each function it appears in.) /tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/fstat/fstat.c:858: error: `SS_CANTSENDMORE' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/fstat. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/usr.bin. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-06-14 21:44:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-06-14 21:44:53 - ERROR: failed to build world TB --- 2004-06-14 21:44:53 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 15 15:00:39 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 BD1D416A4CE for ; Tue, 15 Jun 2004 15:00:39 +0000 (GMT) Received: from radix.mware.ca (H6.C18.B96.tor.eicat.ca [66.96.18.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1368643D1F for ; Tue, 15 Jun 2004 15:00:39 +0000 (GMT) (envelope-from Mykel@mWare.ca) Received: from mWare.ca (immutable.condor.lan [10.100.104.31]) by radix.mware.ca (8.12.4/8.12.4) with ESMTP id i5FF00kH007251; Tue, 15 Jun 2004 11:00:00 -0400 Message-ID: <40CF0EE8.6040305@mWare.ca> Date: Tue, 15 Jun 2004 10:59:52 -0400 From: Mykel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040123 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Smith References: <20040614152830.GB26436@electra.cse.Buffalo.EDU> In-Reply-To: <20040614152830.GB26436@electra.cse.Buffalo.EDU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-sparc64@freebsd.org Subject: Re: Sparc64 snapshot June 12th, 2004 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2004 15:00:39 -0000 [10:55:11] myke@immutable:~$ md5sum /vol/local/space/distro-iso/SNAP-20040612-sparc64-miniinst.iso ca969deed4c3b2a7f7a2f1f30be81e08 /vol/local/space/distro-iso/SNAP-20040612-sparc64-miniinst.iso boot cdrom [splash screen] Rebooting with command: boot cdrom Boot device: /sbus/SUNW,fas@e,8800000/sd@6,0:F File and args: and now it's just sitting there... been like that 10 minutes. :( Myke Ken Smith wrote: >There is an ISO built from -current on June 12th, 2004 loaded on ftp-master >now. It should propagate to the major mirror sites through the next twelve >hours or so. It's in snapshots/sparc64. The MD5 sum is: > >MD5 (SNAP-20040612-sparc64-miniinst.iso) = ca969deed4c3b2a7f7a2f1f30be81e08 > >This includes the first esp(4) driver that doesn't have problems with >the CD-ROM, but as I expected Scott fixed tagged transfers half way >through the snapshot build... ;-) > >I'll wait another week to see if there is any more 'fallout' for the >driver and build another snapshot next weekend that includes the tagged >transfers. Most people interested in this sort of stuff should be >able to handle cvsup updates anyway... > > > From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 15 15:03:21 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 BE61A16A4CE for ; Tue, 15 Jun 2004 15:03:21 +0000 (GMT) Received: from radix.mware.ca (H6.C18.B96.tor.eicat.ca [66.96.18.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1828E43D2D for ; Tue, 15 Jun 2004 15:03:21 +0000 (GMT) (envelope-from Mykel@mWare.ca) Received: from mWare.ca (immutable.condor.lan [10.100.104.31]) by radix.mware.ca (8.12.4/8.12.4) with ESMTP id i5FF2akH007264; Tue, 15 Jun 2004 11:02:36 -0400 Message-ID: <40CF0F84.4080000@mWare.ca> Date: Tue, 15 Jun 2004 11:02:28 -0400 From: Mykel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040123 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mykel References: <20040614152830.GB26436@electra.cse.Buffalo.EDU> <40CF0EE8.6040305@mWare.ca> In-Reply-To: <40CF0EE8.6040305@mWare.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Ken Smith cc: freebsd-sparc64@freebsd.org Subject: Re: Sparc64 snapshot June 12th, 2004 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2004 15:03:21 -0000 Holy karp... talk about PEBKAC... I had the CD in upside down. *boggles* - I've never done that before. Now it's booting, and I'm at the sysinstall main menu! this is further that I used to get... will report more later! Myke Mykel wrote: > [10:55:11] myke@immutable:~$ md5sum > /vol/local/space/distro-iso/SNAP-20040612-sparc64-miniinst.iso > ca969deed4c3b2a7f7a2f1f30be81e08 > /vol/local/space/distro-iso/SNAP-20040612-sparc64-miniinst.iso > > boot cdrom > [splash screen] > > Rebooting with command: boot cdrom > Boot device: /sbus/SUNW,fas@e,8800000/sd@6,0:F File and args: > > > and now it's just sitting there... been like that 10 minutes. :( > > Myke > > > Ken Smith wrote: > >> There is an ISO built from -current on June 12th, 2004 loaded on >> ftp-master >> now. It should propagate to the major mirror sites through the next >> twelve >> hours or so. It's in snapshots/sparc64. The MD5 sum is: >> >> MD5 (SNAP-20040612-sparc64-miniinst.iso) = >> ca969deed4c3b2a7f7a2f1f30be81e08 >> >> This includes the first esp(4) driver that doesn't have problems with >> the CD-ROM, but as I expected Scott fixed tagged transfers half way >> through the snapshot build... ;-) >> >> I'll wait another week to see if there is any more 'fallout' for the >> driver and build another snapshot next weekend that includes the tagged >> transfers. Most people interested in this sort of stuff should be >> able to handle cvsup updates anyway... >> >> >> > _______________________________________________ > freebsd-sparc64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > To unsubscribe, send any mail to > "freebsd-sparc64-unsubscribe@freebsd.org" From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 16 03:38:15 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 487EB16A4CE for ; Wed, 16 Jun 2004 03:38:15 +0000 (GMT) Received: from radix.mware.ca (H6.C18.B96.tor.eicat.ca [66.96.18.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 793D643D31 for ; Wed, 16 Jun 2004 03:38:12 +0000 (GMT) (envelope-from Mykel@mWare.ca) Received: from mWare.ca (immutable.condor.lan [10.100.104.31]) by radix.mware.ca (8.12.4/8.12.4) with ESMTP id i5G3bnkH010503 for ; Tue, 15 Jun 2004 23:37:49 -0400 Message-ID: <40CFC0A0.1000604@mWare.ca> Date: Tue, 15 Jun 2004 23:38:08 -0400 From: Mykel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040123 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-sparc64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: IT! WORKS! X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2004 03:38:15 -0000 w00t! I have the June 14th snapshot installed and running on my Ultra2! Aside from HORRIBLE terminal issues (ncurses is allergic to the console, also, you can only type at about 1CPS, everything else gets dropped) but IT WORKS! $ uname -a FreeBSD phoebus.condor.lan SNAP-20040612 FreeBSD SNAP-20040612 #0: Mon Jun 14 07:25:37 UTC 2004 root@bobbi.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC sparc64 From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 16 03:41:23 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 35D1716A4CE for ; Wed, 16 Jun 2004 03:41:23 +0000 (GMT) Received: from electra.cse.Buffalo.EDU (electra.cse.Buffalo.EDU [128.205.32.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8E5043D2D for ; Wed, 16 Jun 2004 03:41:22 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from electra.cse.Buffalo.EDU (kensmith@localhost [127.0.0.1]) i5G3et2n028215; Tue, 15 Jun 2004 23:40:55 -0400 (EDT) Received: (from kensmith@localhost) by electra.cse.Buffalo.EDU (8.12.10/8.12.9/Submit) id i5G3etYw028214; Tue, 15 Jun 2004 23:40:55 -0400 (EDT) Date: Tue, 15 Jun 2004 23:40:55 -0400 From: Ken Smith To: Mykel Message-ID: <20040616034055.GE26532@electra.cse.Buffalo.EDU> References: <40CFC0A0.1000604@mWare.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40CFC0A0.1000604@mWare.ca> User-Agent: Mutt/1.4.1i cc: freebsd-sparc64@freebsd.org Subject: Re: IT! WORKS! X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2004 03:41:23 -0000 On Tue, Jun 15, 2004 at 11:38:08PM -0400, Mykel wrote: > w00t! > > I have the June 14th snapshot installed and running on my Ultra2! > > Aside from HORRIBLE terminal issues (ncurses is allergic to the console, > also, you can only type at about 1CPS, everything else gets dropped) > > but > > IT WORKS! > > $ uname -a > FreeBSD phoebus.condor.lan SNAP-20040612 FreeBSD SNAP-20040612 #0: Mon > Jun 14 07:25:37 UTC 2004 > root@bobbi.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC sparc64 Yay! :-) FYI - I'm going to do another snapshot. Scott reported there was more fixed recently than just tagged transfers. Serial port is still the best way to do an install, that's on the todo list... :-) -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 16 03:47:18 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 620EF16A4CE for ; Wed, 16 Jun 2004 03:47:18 +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 9705D43D1F for ; Wed, 16 Jun 2004 03:47:17 +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 i5G3i3Ah068139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 16 Jun 2004 12:44:04 +0900 (KST) Received: from michelle.kt-is.co.kr (localhost.kt-is.co.kr [127.0.0.1]) i5G3jK1r008349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Jun 2004 12:45:21 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Received: (from yongari@localhost) by michelle.kt-is.co.kr (8.12.10/8.12.10/Submit) id i5G3jKNn008348 for freebsd-sparc64@freebsd.org; Wed, 16 Jun 2004 12:45:20 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Date: Wed, 16 Jun 2004 12:45:20 +0900 From: Pyun YongHyeon To: freebsd-sparc64@freebsd.org Message-ID: <20040616034520.GB7887@kt-is.co.kr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Filter-Version: 1.11a (ns.kt-is.co.kr) Subject: TCP/UDP cksum offload on hme(4) 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: Wed, 16 Jun 2004 03:47:18 -0000 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello All, I made a patch that enables cksum offloads on hme(4). Originally the patch was made for OpenBSD due to FreeBSD's lack of FAS366 support. Now, we had esp(4) ported by Scott, I could port the patch from my OpenBSD patch. During simple test phase, I didn't notice problems. 1. UDP TX cksum offload has an issue. The hardware doesn't flip the cksum bits when the computed cksum is 0x0000. I have no idea this is the reason why STP2002QFP says it supports only TCP RX/TX cksum. (pp. 29, pp. 40, pp. 42) 2. The patch was tested on Ultra2(2x300MHz, FAS366). I'd like to hear ok/nok results from PCI based sparc64 users. The dmesg of the Ultra2 is available at: http:///www.kr.freebsd.org/~yognari/dmesg.u2.txt 3. I couldn't feel performance boost from the cksum offloads but enabling it reduced system loads considerably. The attached patch is for -CURRENT(2004.06.07), and is also available at: http://www.kr.freebsd.org/~yognari/hme.freebsd.diff Corrections, suggestions welcome. Thanks. Regards, Pyun YongHyeon -- Pyun YongHyeon --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="hme.freebsd.diff" --- if_hme.c.orig Wed Jun 16 12:16:56 2004 +++ if_hme.c Wed Jun 16 12:16:56 2004 @@ -54,9 +54,15 @@ * maximum packet size (this is not verified). Buffers starting on odd * boundaries must be mapped so that the burst can start on a natural boundary. * - * Checksumming is not yet supported. + * STP2002QFP-UG says that Ethernet hardware supports TCP checksum offload. + * In reality, we can do the same technique for UDP datagram too. However, + * the hardware doesn't compensate the cksum for UDP datagram which can yield + * to 0x0. + * When the UDP datagram with cksum 0 sent to a system, it would think it + * received a datagram with 'no cksum'. I don't know this is compulsory reason + * to disable UDP cksum offload capability. */ - +#define HME_CSUM_FEATURES (CSUM_TCP | CSUM_UDP) #define HMEDEBUG #define KTR_HME KTR_CT2 /* XXX */ @@ -80,6 +86,12 @@ #include #include +#include +#include +#include +#include +#include + #include #include @@ -106,10 +118,12 @@ static void hme_mediastatus(struct ifnet *, struct ifmediareq *); static int hme_load_txmbuf(struct hme_softc *, struct mbuf *); -static void hme_read(struct hme_softc *, int, int); +static void hme_read(struct hme_softc *, int, int, u_int32_t); static void hme_eint(struct hme_softc *, u_int); static void hme_rint(struct hme_softc *); static void hme_tint(struct hme_softc *); +static void hme_txcksum(struct mbuf *, u_int32_t *); +static void hme_rxcksum(struct mbuf *, u_int32_t); static void hme_cdma_callback(void *, bus_dma_segment_t *, int, int); static void hme_rxdma_callback(void *, bus_dma_segment_t *, int, @@ -316,11 +330,12 @@ ether_ifattach(ifp, sc->sc_arpcom.ac_enaddr); /* - * Tell the upper layer(s) we support long frames. + * Tell the upper layer(s) we support long frames and cksum offloads. */ ifp->if_data.ifi_hdrlen = sizeof(struct ether_vlan_header); - ifp->if_capabilities |= IFCAP_VLAN_MTU; - ifp->if_capenable |= IFCAP_VLAN_MTU; + ifp->if_capabilities |= IFCAP_VLAN_MTU | IFCAP_HWCSUM; + ifp->if_hwassist |= HME_CSUM_FEATURES; + ifp->if_capenable |= IFCAP_VLAN_MTU | IFCAP_HWCSUM; callout_init(&sc->sc_tick_ch, 0); return (0); @@ -656,7 +671,7 @@ struct hme_softc *sc = (struct hme_softc *)xsc; struct ifnet *ifp = &sc->sc_arpcom.ac_if; u_int8_t *ea; - u_int32_t v; + u_int32_t n, v; /* * Initialization sequence. The numbered steps below correspond @@ -740,6 +755,15 @@ v = HME_SEB_CFG_BURST64; break; } + /* + * Blindly setting 64bit transfers may hang PCI cards(Cheerio?). + * Allowing 64bit transfers breaks TX checksum offload as well. + * Don't know this comes from hardware bug or driver's DMAing + * scheme. + * + * if (sc->sc_pci == 0) + * v |= HME_SEB_CFG_64BIT; + */ HME_SEB_WRITE_4(sc, HME_SEBI_CFG, v); /* step 9. ETX Configuration: use mostly default values */ @@ -775,6 +799,12 @@ /* Enable DMA, fix RX first byte offset. */ v &= ~HME_ERX_CFG_FBO_MASK; v |= HME_ERX_CFG_DMAENABLE | (HME_RXOFFS << HME_ERX_CFG_FBO_SHIFT); + /* RX TCP/UDP cksum offset */ + if (ifp->if_capenable & IFCAP_TXCSUM) { + n = (ETHER_HDR_LEN + sizeof(struct ip)) / 2; + n = (n << HME_ERX_CFG_CSUM_SHIFT) & HME_ERX_CFG_CSUMSTART; + v |= n; + } CTR1(KTR_HME, "hme_init: programming ERX_CFG to %x", (u_int)v); HME_ERX_WRITE_4(sc, HME_ERXI_CFG, v); @@ -893,6 +923,55 @@ ("hme_txdma_callback: missed end of packet!")); } +/* TX TCP/UDP cksum */ +static void +hme_txcksum(struct mbuf *m, u_int32_t *cflags) +{ + struct ip *ip; + u_int32_t offset, offset2, csumflag; + caddr_t p; + + if ((m->m_pkthdr.csum_flags & CSUM_TCP)) { + offset2 = offsetof(struct tcphdr, th_sum); + csumflag = HME_XD_TCPCKSUM; + } else if((m->m_pkthdr.csum_flags & CSUM_UDP)) { + offset2 = offsetof(struct udphdr, uh_sum); + csumflag = HME_XD_UDPCKSUM; + } else + return; + + for(; m && m->m_len == 0; m = m->m_next) + ; + if (m == NULL || m->m_len < ETHER_HDR_LEN) { + printf("hme_txcksum: m_len < ETHER_HDR_LEN\n"); + return; /* cksum will be corrupted */ + } + if (m->m_len < ETHER_HDR_LEN + sizeof(u_int32_t)) { + if (m->m_len != ETHER_HDR_LEN) { + printf("hme_txcksum: m_len != ETHER_HDR_LEN\n"); + return; /* cksum will be corrupted */ + } + /* XXX */ + for(m = m->m_next; m && m->m_len == 0; m = m->m_next) + ; + if (m == NULL) + return; /* cksum will be corrupted */ + ip = mtod(m, struct ip *); + } else { + p = mtod(m, caddr_t); + p += ETHER_HDR_LEN; + ip = (struct ip *)p; + } + if ((ip->ip_hl << 2) == sizeof(*ip)) + *cflags = csumflag; + else { + offset = (ip->ip_hl << 2) + ETHER_HDR_LEN; + *cflags = offset << HME_XD_TXCKSUM_SSHIFT; + *cflags |= ((offset + offset2) << HME_XD_TXCKSUM_OSHIFT); + *cflags |= HME_XD_TXCKSUM; + } +} + /* * Routine to dma map an mbuf chain, set up the descriptor rings accordingly and * start the transmission. @@ -905,11 +984,12 @@ struct hme_txdma_arg cba; struct hme_txdesc *td; int error, si, ri; - u_int32_t flags; + u_int32_t flags, cflags = 0; si = sc->sc_rb.rb_tdhead; if ((td = STAILQ_FIRST(&sc->sc_rb.rb_txfreeq)) == NULL) return (-1); + hme_txcksum(m0, &cflags); td->htx_m = m0; cba.hta_sc = sc; cba.hta_htx = td; @@ -933,7 +1013,7 @@ do { ri = (ri + HME_NTXDESC - 1) % HME_NTXDESC; flags = HME_XD_GETFLAGS(sc->sc_pci, sc->sc_rb.rb_txd, ri) | - HME_XD_OWN; + HME_XD_OWN | cflags; CTR3(KTR_HME, "hme_load_mbuf: activating ri %d, si %d (%#x)", ri, si, flags); HME_XD_SETFLAGS(sc->sc_pci, sc->sc_rb.rb_txd, ri, flags); @@ -951,7 +1031,7 @@ * Pass a packet to the higher levels. */ static void -hme_read(struct hme_softc *sc, int ix, int len) +hme_read(struct hme_softc *sc, int ix, int len, u_int32_t flags) { struct ifnet *ifp = &sc->sc_arpcom.ac_if; struct mbuf *m; @@ -986,6 +1066,9 @@ m->m_pkthdr.rcvif = ifp; m->m_pkthdr.len = m->m_len = len + HME_RXOFFS; m_adj(m, HME_RXOFFS); + /* RX TCP/UDP cksum */ + if (ifp->if_capenable & IFCAP_RXCSUM) + hme_rxcksum(m, flags); /* Pass the packet up. */ (*ifp->if_input)(ifp, m); } @@ -1108,6 +1191,71 @@ } /* + * RX TCP/UDP cksumming + */ +static void +hme_rxcksum(struct mbuf *m, u_int32_t flags) +{ + struct ether_header *eh; + struct ip *ip; + struct udphdr *uh; + int32_t hlen, len, pktlen; + u_int16_t cksum, *opts; + u_int32_t temp32; + + pktlen = m->m_pkthdr.len; + if (pktlen < sizeof(struct ether_header)) + return; + eh = mtod(m, struct ether_header *); + if (eh->ether_type != htons(ETHERTYPE_IP)) + return; + ip = (struct ip *)(eh + 1); + if (ip->ip_v != IPVERSION) + return; + + hlen = ip->ip_hl << 2; + pktlen -= sizeof(struct ether_header); + if (hlen < sizeof(struct ip)) + return; + if (ntohs(ip->ip_len) < hlen) + return; + if (ntohs(ip->ip_len) != pktlen) + return; + if (ip->ip_off & htons(IP_MF | IP_OFFMASK)) + return; /* can't handle fragmented packet */ + + switch (ip->ip_p) { + case IPPROTO_TCP: + if (pktlen < (hlen + sizeof(struct tcphdr))) + return; + break; + case IPPROTO_UDP: + if (pktlen < (hlen + sizeof(struct udphdr))) + return; + uh = (struct udphdr *)((caddr_t)ip + hlen); + if (uh->uh_sum == 0) + return; /* no checksum */ + break; + default: + return; + } + + cksum = ~(flags & HME_XD_RXCKSUM); + /* cksum fixup for IP options */ + len = hlen - sizeof(struct ip); + if (len > 0) { + opts = (u_int16_t *)(ip + 1); + for (; len > 0; len -= sizeof(u_int16_t), opts++) { + temp32 = cksum - *opts; + temp32 = (temp32 >> 16) + (temp32 & 65535); + cksum = temp32 & 65535; + } + } + m->m_pkthdr.csum_flags |= CSUM_DATA_VALID; + m->m_pkthdr.csum_data = cksum; +} + +/* * Receive interrupt. */ static void @@ -1137,7 +1285,7 @@ hme_discard_rxbuf(sc, ri); } else { len = HME_XD_DECODE_RSIZE(flags); - hme_read(sc, ri, len); + hme_read(sc, ri, len, flags); } } if (progress) { @@ -1386,6 +1534,15 @@ case SIOCGIFMEDIA: case SIOCSIFMEDIA: error = ifmedia_ioctl(ifp, ifr, &sc->sc_mii->mii_media, cmd); + break; + case SIOCSIFCAP: + ifp->if_capenable = ifr->ifr_reqcap; + if (ifp->if_capenable & IFCAP_HWCSUM) + ifp->if_hwassist = HME_CSUM_FEATURES; + else + ifp->if_hwassist = 0; + if (ifp->if_flags & IFF_RUNNING) + hme_init(sc); break; default: error = ether_ioctl(ifp, cmd, data); --- if_hme_sbus.c.orig Wed Jun 16 12:16:56 2004 +++ if_hme_sbus.c Wed Jun 16 12:16:56 2004 @@ -244,8 +244,14 @@ burst = sbus_get_burstsz(dev); /* Translate into plain numerical format */ - sc->sc_burst = (burst & SBUS_BURST_32) ? 32 : - (burst & SBUS_BURST_16) ? 16 : 0; + if ((burst & SBUS_BURST_64)) + sc->sc_burst = 64; + else if ((burst & SBUS_BURST_32)) + sc->sc_burst = 32; + else if ((burst & SBUS_BURST_16)) + sc->sc_burst = 16; + else + sc->sc_burst = 0; sc->sc_pci = 0; /* XXX: should all be done in bus_dma. */ sc->sc_dev = dev; --- if_hmereg.h.orig Wed Jun 16 12:16:56 2004 +++ if_hmereg.h Wed Jun 16 12:16:56 2004 @@ -54,8 +54,8 @@ #define HME_SEB_CFG_BURST16 0x00000000 /* 16 byte bursts */ #define HME_SEB_CFG_BURST32 0x00000001 /* 32 byte bursts */ #define HME_SEB_CFG_BURST64 0x00000002 /* 64 byte bursts */ -#define HME_SEB_CFG_64BIT 0x00000004 /* ? */ -#define HME_SEB_CFG_PARITY 0x00000008 /* ? */ +#define HME_SEB_CFG_64BIT 0x00000004 /* extended transfer mode */ +#define HME_SEB_CFG_PARITY 0x00000008 /* parity check for DVMA/PIO */ #define HME_SEB_STAT_GOTFRAME 0x00000001 /* frame received */ #define HME_SEB_STAT_RCNTEXP 0x00000002 /* rx frame count expired */ @@ -154,7 +154,7 @@ #define HME_ERXI_FIFO_WPTR (3*4) /* FIFO write pointer */ #define HME_ERXI_FIFO_SWPTR (4*4) /* FIFO shadow write pointer */ #define HME_ERXI_FIFO_RPTR (5*4) /* FIFO read pointer */ -#define HME_ERXI_FIFO_SRPTR (6*4) /* FIFO shadow read pointer */ +#define HME_ERXI_FIFO_PKTCNT (6*4) /* FIFO packet counter */ #define HME_ERXI_STATEMACHINE (7*4) /* State machine */ /* RXI_CFG bits */ @@ -167,6 +167,7 @@ #define HME_ERX_CFG_RINGSIZE256 0x00000600 /* Descriptor ring size: 256 */ #define HME_ERX_CFG_RINGSIZEMSK 0x00000600 /* Descriptor ring size: 256 */ #define HME_ERX_CFG_CSUMSTART 0x007f0000 /* cksum offset */ +#define HME_ERX_CFG_CSUM_SHIFT 16 /* * HME MAC-core register offsets @@ -289,7 +290,11 @@ #define HME_XD_RXLENMSK 0x3fff0000 /* packet length mask (rx) */ #define HME_XD_RXLENSHIFT 16 #define HME_XD_TXLENMSK 0x00003fff /* packet length mask (tx) */ +#define HME_XD_TXCKSUM_SSHIFT 14 +#define HME_XD_TXCKSUM_OSHIFT 20 #define HME_XD_RXCKSUM 0x0000ffff /* packet checksum (rx) */ +#define HME_XD_TCPCKSUM 0x13288000 /* precomputed tcp cksum */ +#define HME_XD_UDPCKSUM 0x12888000 /* precomputed udp cksum */ /* Macros to encode/decode the receive buffer size from the flags field */ #define HME_XD_ENCODE_RSIZE(sz) \ --NzB8fVQJ5HfG6fxh-- From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 16 03:49:12 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 C65A016A4CE for ; Wed, 16 Jun 2004 03:49:12 +0000 (GMT) Received: from radix.mware.ca (H6.C18.B96.tor.eicat.ca [66.96.18.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF2B843D1F for ; Wed, 16 Jun 2004 03:49:11 +0000 (GMT) (envelope-from Mykel@mWare.ca) Received: from mWare.ca (immutable.condor.lan [10.100.104.31]) by radix.mware.ca (8.12.4/8.12.4) with ESMTP id i5G3l8kH010611; Tue, 15 Jun 2004 23:47:09 -0400 Message-ID: <40CFC2CF.8080509@mWare.ca> Date: Tue, 15 Jun 2004 23:47:27 -0400 From: Mykel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040123 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Smith , freebsd-sparc64@freebsd.org References: <40CFC0A0.1000604@mWare.ca> <20040616034055.GE26532@electra.cse.Buffalo.EDU> In-Reply-To: <20040616034055.GE26532@electra.cse.Buffalo.EDU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Re: IT! WORKS! X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2004 03:49:13 -0000 Ken Smith wrote: >On Tue, Jun 15, 2004 at 11:38:08PM -0400, Mykel wrote: > > >>w00t! >> >>I have the June 14th snapshot installed and running on my Ultra2! >> >>Aside from HORRIBLE terminal issues (ncurses is allergic to the console, >>also, you can only type at about 1CPS, everything else gets dropped) >> >>but >> >>IT WORKS! >> >>$ uname -a >>FreeBSD phoebus.condor.lan SNAP-20040612 FreeBSD SNAP-20040612 #0: Mon >>Jun 14 07:25:37 UTC 2004 >>root@bobbi.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC sparc64 >> >> > >Yay! :-) > >FYI - I'm going to do another snapshot. Scott reported there was >more fixed recently than just tagged transfers. > >Serial port is still the best way to do an install, that's on the >todo list... :-) > > Well, you see - I /had/ thought of that, but you must understand... what I have on my desk: -> Centrino laptop (Slackware) with no RS232 ports -> $CLIENT's PC/router/server/paperweight -> Toshiba T1200 laptop Yes... T1200 - an XT, (it's only 5 or 6 years younger than me) running MSDOs 6.22 and ProCOMM+, the only problem is - the screen is too small for any reasonable terminal, so it's just a mess. So I just bit the bullet, reboot serveral times before deciding VT100 mode would be the best on the console. Now how about the console? how can I make typing at least practical on here? I was hoping to use this as a desktop machine. Also - can I just CVSup from my local mirror or is that different on Sparc64? And X - how do I get that going? Just follow the handbook? If anyone wants to ssh into this box, I can create some accounts and punch some NAT holes Myke From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 16 03:49:27 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 9A6FE16A4CE for ; Wed, 16 Jun 2004 03:49:27 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4ECE643D1D for ; Wed, 16 Jun 2004 03:49:27 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i5G3oQZ9013482; Tue, 15 Jun 2004 21:50:26 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40CFC2B5.6090500@freebsd.org> Date: Tue, 15 Jun 2004 21:47:01 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mykel References: <40CFC0A0.1000604@mWare.ca> In-Reply-To: <40CFC0A0.1000604@mWare.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.4 required=3.8 tests=MANY_EXCLAMATIONS autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-sparc64@freebsd.org Subject: Re: IT! WORKS! X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2004 03:49:27 -0000 Mykel wrote: > w00t! > > I have the June 14th snapshot installed and running on my Ultra2! > > Aside from HORRIBLE terminal issues (ncurses is allergic to the console, > also, you can only type at about 1CPS, everything else gets dropped) > > but > > IT WORKS! > > $ uname -a > FreeBSD phoebus.condor.lan SNAP-20040612 FreeBSD SNAP-20040612 #0: Mon > Jun 14 07:25:37 UTC 2004 > root@bobbi.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC sparc64 > I run my Ultra2 serial console at 38400 and it works fine. I gave up on using the keyboard as ofwcons is pretty lossy and uart(4) locks up the system once interrupts are enabled. I've been told that the serial hardware is unreliable above 9600 bps, so cranking it down might help ofwcons, dunno. Once I finish getting the Ultra1 to work I might try to figure out the uart(4) problems. Scott From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 16 03:59:44 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 16C2916A4CE for ; Wed, 16 Jun 2004 03:59:44 +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 733AE43D1F for ; Wed, 16 Jun 2004 03:59:43 +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 i5G3vDAh068814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 16 Jun 2004 12:57:13 +0900 (KST) Received: from michelle.kt-is.co.kr (localhost.kt-is.co.kr [127.0.0.1]) i5G3wU1r008380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Jun 2004 12:58:30 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Received: (from yongari@localhost) by michelle.kt-is.co.kr (8.12.10/8.12.10/Submit) id i5G3wUZq008379 for freebsd-sparc64@freebsd.org; Wed, 16 Jun 2004 12:58:30 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Date: Wed, 16 Jun 2004 12:58:30 +0900 From: Pyun YongHyeon To: freebsd-sparc64@freebsd.org Message-ID: <20040616035830.GC7887@kt-is.co.kr> References: <20040616034520.GB7887@kt-is.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040616034520.GB7887@kt-is.co.kr> User-Agent: Mutt/1.4.1i X-Filter-Version: 1.11a (ns.kt-is.co.kr) Subject: Re: TCP/UDP cksum offload on hme(4) 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: Wed, 16 Jun 2004 03:59:44 -0000 On Wed, Jun 16, 2004 at 12:45:20PM +0900, To freebsd-sparc64@freebsd.org wrote: > Hello All, > > I made a patch that enables cksum offloads on hme(4). Originally > the patch was made for OpenBSD due to FreeBSD's lack of FAS366 > support. Now, we had esp(4) ported by Scott, I could port the patch > from my OpenBSD patch. During simple test phase, I didn't notice > problems. > > 1. UDP TX cksum offload has an issue. The hardware doesn't flip the > cksum bits when the computed cksum is 0x0000. I have no idea this > is the reason why STP2002QFP says it supports only TCP RX/TX cksum. > (pp. 29, pp. 40, pp. 42) > > 2. The patch was tested on Ultra2(2x300MHz, FAS366). I'd like to > hear ok/nok results from PCI based sparc64 users. > The dmesg of the Ultra2 is available at: > http:///www.kr.freebsd.org/~yognari/dmesg.u2.txt > > 3. I couldn't feel performance boost from the cksum offloads but > enabling it reduced system loads considerably. > > The attached patch is for -CURRENT(2004.06.07), and is also available at: ^^^^^^^^^^^ 2004.06.14 The corrected URL is: http://www.kr.freebsd.org/~yongari/dmesg.u2.txt http://www.kr.freebsd.org/~yongari/hme.freebsd.diff -- Pyun YongHyeon From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 16 04:02:52 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 7193316A4CE for ; Wed, 16 Jun 2004 04:02:52 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 099D543D2D for ; Wed, 16 Jun 2004 04:02:52 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i5G45PlL013532; Tue, 15 Jun 2004 22:05:25 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40CFC638.7040308@freebsd.org> Date: Tue, 15 Jun 2004 22:02:00 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mykel References: <40CFC0A0.1000604@mWare.ca> <20040616034055.GE26532@electra.cse.Buffalo.EDU> <40CFC2CF.8080509@mWare.ca> In-Reply-To: <40CFC2CF.8080509@mWare.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.4 required=3.8 tests=MANY_EXCLAMATIONS autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Ken Smith cc: freebsd-sparc64@freebsd.org Subject: Re: IT! WORKS! X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2004 04:02:52 -0000 Mykel wrote: > Ken Smith wrote: > >> On Tue, Jun 15, 2004 at 11:38:08PM -0400, Mykel wrote: >> >> >>> w00t! >>> >>> I have the June 14th snapshot installed and running on my Ultra2! >>> >>> Aside from HORRIBLE terminal issues (ncurses is allergic to the >>> console, also, you can only type at about 1CPS, everything else gets >>> dropped) >>> >>> but >>> >>> IT WORKS! >>> >>> $ uname -a >>> FreeBSD phoebus.condor.lan SNAP-20040612 FreeBSD SNAP-20040612 #0: >>> Mon Jun 14 07:25:37 UTC 2004 >>> root@bobbi.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC sparc64 >>> >> >> >> Yay! :-) >> >> FYI - I'm going to do another snapshot. Scott reported there was >> more fixed recently than just tagged transfers. >> >> Serial port is still the best way to do an install, that's on the >> todo list... :-) >> >> > Well, you see - I /had/ thought of that, but you must understand... what > I have on my desk: > -> Centrino laptop (Slackware) with no RS232 ports > -> $CLIENT's PC/router/server/paperweight > -> Toshiba T1200 laptop > > Yes... T1200 - an XT, (it's only 5 or 6 years younger than me) running > MSDOs 6.22 and ProCOMM+, the only problem is - the screen is too small > for any reasonable terminal, so it's just a mess. Man, flash back to 1986! My first pc experience was a T1000. I would have killed for a T1200 back then ;-) > > So I just bit the bullet, reboot serveral times before deciding VT100 > mode would be the best on the console. > > Now how about the console? how can I make typing at least practical on > here? I was hoping to use this as a desktop machine. As I mentioned in my other email, you might try adjusting the serial port speed. Just a guess though. I bootstrapped my machine by netbooting it and then manually paritioning the disk and doing an installworld into it. > > Also - can I just CVSup from my local mirror or is that different on > Sparc64? And X - how do I get that going? Just follow the handbook? cvsup works just as it does on x86. X requires syscons (or pvct, but that doesn't work on sparc64). syscons + creator appears to somewhat work for me, but it requires uart(4) for the keyboard. Again, uart(4) locks up my U2 as soon as interrupts are enabled, so it's not really an option. Scott From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 16 04:33:44 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 65BA816A4CE for ; Wed, 16 Jun 2004 04:33:44 +0000 (GMT) Received: from gw.redstone-is.net (gw.redstone-is.net [209.12.17.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A6EE43D46 for ; Wed, 16 Jun 2004 04:33:44 +0000 (GMT) (envelope-from freebsd-lists@teuton.org) Received: from amuzgo.teuton.org (amuzgo.teuton.org [12.98.36.131]) by gw.redstone-is.net (8.12.9/8.12.9) with ESMTP id i5G4HjiR018543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Jun 2004 22:17:49 -0600 (MDT) Received: from aztec ([12.98.36.130] helo=[192.168.2.2]) by amuzgo.teuton.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.24; FreeBSD 4.8) id 1BaS7T-000G9z-66 for freebsd-sparc64@freebsd.org; Tue, 15 Jun 2004 22:33:51 -0600 Date: Tue, 15 Jun 2004 22:33:33 -0600 From: Erik Mugele To: freebsd-sparc64@freebsd.org Message-ID: <078BE89FAA4E81BA3E1698A2@[192.168.2.2]> In-Reply-To: <40CFC2CF.8080509@mWare.ca> References: <40CFC0A0.1000604@mWare.ca> <20040616034055.GE26532@electra.cse.Buffalo.EDU> <40CFC2CF.8080509@mWare.ca> X-Mailer: Mulberry/3.1.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: IT! WORKS! X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2004 04:33:44 -0000 --On Tuesday, June 15, 2004 11:47 PM -0400 Mykel wrote: > Yes... T1200 - an XT, (it's only 5 or 6 years younger than me) running > MSDOs 6.22 and ProCOMM+, the only problem is - the screen is too small > for any reasonable terminal, so it's just a mess. A T1200! Great line of "little" computers. I use one as my main terminal connected to an annex for serial access to all my consoles. Runs DOS 3.3 and Kermit. Erik From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 16 04:37:35 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 4A4E016A4CE for ; Wed, 16 Jun 2004 04:37:35 +0000 (GMT) Received: from mail.dragondata.com (server3-a.your.org [64.202.112.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FFEB43D4C for ; Wed, 16 Jun 2004 04:37:35 +0000 (GMT) (envelope-from toasty@dragondata.com) Received: from localhost (localhost.your.org [127.0.0.1]) by mail.dragondata.com (Postfix) with ESMTP id 939D33D18CC; Tue, 15 Jun 2004 23:37:34 -0500 (CDT) Received: from mail.dragondata.com ([127.0.0.1]) by localhost (server3.dragondata.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07069-03-14; Tue, 15 Jun 2004 23:37:34 -0500 (CDT) Received: by mail.dragondata.com (Postfix, from userid 1000) id 067CD3D189B; Tue, 15 Jun 2004 23:37:34 -0500 (CDT) Received: from [199.165.179.45] (ppp045.dhcp.your.org [199.165.179.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.dragondata.com (Postfix) with ESMTP id B05853D1943; Tue, 15 Jun 2004 23:37:32 -0500 (CDT) In-Reply-To: <20040616034520.GB7887@kt-is.co.kr> References: <20040616034520.GB7887@kt-is.co.kr> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <264D82AE-BF4F-11D8-A89B-000A95A8A1F2@dragondata.com> Content-Transfer-Encoding: 7bit From: Kevin Day Date: Tue, 15 Jun 2004 23:39:27 -0500 To: yongari@kt-is.co.kr X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server3.dragondata.com X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63 languages=en, sco bayes=0.5 X-Virus-Scanned: by amavisd-new at dragondata.com cc: freebsd-sparc64@freebsd.org Subject: Re: TCP/UDP cksum offload on hme(4) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2004 04:37:35 -0000 On Jun 15, 2004, at 10:45 PM, Pyun YongHyeon wrote: > > 1. UDP TX cksum offload has an issue. The hardware doesn't flip the > cksum bits when the computed cksum is 0x0000. I have no idea this > is the reason why STP2002QFP says it supports only TCP RX/TX cksum. > (pp. 29, pp. 40, pp. 42) > > I'm not sure if you're aware of this or not, but: > If the computed checksum is zero, it is transmitted as all ones > (the > equivalent in one's complement arithmetic). An all zero > transmitted > checksum value means that the transmitter generated no checksum > (for > debugging or for higher level protocols that don't care) So, if a UDP packet has an all zero checksum, it's supposed to mean there was no checksum performed. If you legitimately came up with 0x0000 for a checksum, you're supposed to set the header field to 0xffff. From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 16 04:53:01 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 EC96916A4CE; Wed, 16 Jun 2004 04:53:01 +0000 (GMT) Received: from radix.mware.ca (H6.C18.B96.tor.eicat.ca [66.96.18.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAAE443D1D; Wed, 16 Jun 2004 04:53:00 +0000 (GMT) (envelope-from Mykel@mWare.ca) Received: from mWare.ca (immutable.condor.lan [10.100.104.31]) by radix.mware.ca (8.12.4/8.12.4) with ESMTP id i5G4qVkH010902; Wed, 16 Jun 2004 00:52:31 -0400 Message-ID: <40CFD221.5030709@mWare.ca> Date: Wed, 16 Jun 2004 00:52:49 -0400 From: Mykel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040123 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long , freebsd-sparc64@freebsd.org References: <40CFC0A0.1000604@mWare.ca> <20040616034055.GE26532@electra.cse.Buffalo.EDU> <40CFC2CF.8080509@mWare.ca> <40CFC638.7040308@freebsd.org> In-Reply-To: <40CFC638.7040308@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: IT! WORKS! X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2004 04:53:02 -0000 Scott Long wrote: > Mykel wrote: > >> Ken Smith wrote: >> >>> On Tue, Jun 15, 2004 at 11:38:08PM -0400, Mykel wrote: >>> >>> >>>> w00t! >>>> >>>> I have the June 14th snapshot installed and running on my Ultra2! >>>> >>>> Aside from HORRIBLE terminal issues (ncurses is allergic to the >>>> console, also, you can only type at about 1CPS, everything else >>>> gets dropped) >>>> >>>> but >>>> >>>> IT WORKS! >>>> >>>> $ uname -a >>>> FreeBSD phoebus.condor.lan SNAP-20040612 FreeBSD SNAP-20040612 #0: >>>> Mon Jun 14 07:25:37 UTC 2004 >>>> root@bobbi.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC sparc64 >>>> >>> >>> >>> >>> Yay! :-) >>> >>> FYI - I'm going to do another snapshot. Scott reported there was >>> more fixed recently than just tagged transfers. >>> >>> Serial port is still the best way to do an install, that's on the >>> todo list... :-) >>> >>> >> Well, you see - I /had/ thought of that, but you must understand... >> what I have on my desk: >> -> Centrino laptop (Slackware) with no RS232 ports >> -> $CLIENT's PC/router/server/paperweight >> -> Toshiba T1200 laptop >> >> Yes... T1200 - an XT, (it's only 5 or 6 years younger than me) >> running MSDOs 6.22 and ProCOMM+, the only problem is - the screen is >> too small for any reasonable terminal, so it's just a mess. > > > Man, flash back to 1986! My first pc experience was a T1000. I would > have killed for a T1200 back then ;-) My first was on a Zenith (QueensU.ca branded) XT @ 8Mhz with a *MEG* of RAM... whoa... Then I saw a scanner and a colour screen... well that nearly knocked me out of my diapers! ;) >> So I just bit the bullet, reboot serveral times before deciding VT100 >> mode would be the best on the console. >> >> Now how about the console? how can I make typing at least practical >> on here? I was hoping to use this as a desktop machine. > > As I mentioned in my other email, you might try adjusting the serial > port speed. Remember... you're talking to the guy who put his CD in upside down earlier today... how do I do that? > Just a guess though. I bootstrapped my machine by > netbooting it and then manually paritioning the disk and doing an > installworld into it. Heh - kinda defeats the whole point of what I did today :\ > >> >> Also - can I just CVSup from my local mirror or is that different on >> Sparc64? And X - how do I get that going? Just follow the handbook? > > > cvsup works just as it does on x86. X requires syscons (or pvct, but > that doesn't work on sparc64). syscons + creator appears to somewhat > work for me, but it requires uart(4) for the keyboard. Again, uart(4) > locks up my U2 as soon as interrupts are enabled, so it's not really an > option. there really is no way around this at the time? (I just read "$stuff it doesn't work $more_stuff") From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 16 04:53:43 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 D290416A4CF for ; Wed, 16 Jun 2004 04:53:43 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E9F443D1D for ; Wed, 16 Jun 2004 04:53:43 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i5G4uBZe013731; Tue, 15 Jun 2004 22:56:11 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40CFD21E.9090309@freebsd.org> Date: Tue, 15 Jun 2004 22:52:46 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: yongari@kt-is.co.kr References: <20040616034520.GB7887@kt-is.co.kr> In-Reply-To: <20040616034520.GB7887@kt-is.co.kr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-sparc64@freebsd.org Subject: Re: TCP/UDP cksum offload on hme(4) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2004 04:53:43 -0000 Excellent work, thanks a lot! Have you sent this to Bill Paul for review? Scott Pyun YongHyeon wrote: > Hello All, > > I made a patch that enables cksum offloads on hme(4). Originally > the patch was made for OpenBSD due to FreeBSD's lack of FAS366 > support. Now, we had esp(4) ported by Scott, I could port the patch > from my OpenBSD patch. During simple test phase, I didn't notice > problems. > > 1. UDP TX cksum offload has an issue. The hardware doesn't flip the > cksum bits when the computed cksum is 0x0000. I have no idea this > is the reason why STP2002QFP says it supports only TCP RX/TX cksum. > (pp. 29, pp. 40, pp. 42) > > 2. The patch was tested on Ultra2(2x300MHz, FAS366). I'd like to > hear ok/nok results from PCI based sparc64 users. > The dmesg of the Ultra2 is available at: > http:///www.kr.freebsd.org/~yognari/dmesg.u2.txt > > 3. I couldn't feel performance boost from the cksum offloads but > enabling it reduced system loads considerably. > > The attached patch is for -CURRENT(2004.06.07), and is also available at: > http://www.kr.freebsd.org/~yognari/hme.freebsd.diff > > Corrections, suggestions welcome. > > Thanks. > > Regards, > Pyun YongHyeon > > > ------------------------------------------------------------------------ > > --- if_hme.c.orig Wed Jun 16 12:16:56 2004 > +++ if_hme.c Wed Jun 16 12:16:56 2004 > @@ -54,9 +54,15 @@ > * maximum packet size (this is not verified). Buffers starting on odd > * boundaries must be mapped so that the burst can start on a natural boundary. > * > - * Checksumming is not yet supported. > + * STP2002QFP-UG says that Ethernet hardware supports TCP checksum offload. > + * In reality, we can do the same technique for UDP datagram too. However, > + * the hardware doesn't compensate the cksum for UDP datagram which can yield > + * to 0x0. > + * When the UDP datagram with cksum 0 sent to a system, it would think it > + * received a datagram with 'no cksum'. I don't know this is compulsory reason > + * to disable UDP cksum offload capability. > */ > - > +#define HME_CSUM_FEATURES (CSUM_TCP | CSUM_UDP) > #define HMEDEBUG > #define KTR_HME KTR_CT2 /* XXX */ > > @@ -80,6 +86,12 @@ > #include > #include > > +#include > +#include > +#include > +#include > +#include > + > #include > #include > > @@ -106,10 +118,12 @@ > static void hme_mediastatus(struct ifnet *, struct ifmediareq *); > > static int hme_load_txmbuf(struct hme_softc *, struct mbuf *); > -static void hme_read(struct hme_softc *, int, int); > +static void hme_read(struct hme_softc *, int, int, u_int32_t); > static void hme_eint(struct hme_softc *, u_int); > static void hme_rint(struct hme_softc *); > static void hme_tint(struct hme_softc *); > +static void hme_txcksum(struct mbuf *, u_int32_t *); > +static void hme_rxcksum(struct mbuf *, u_int32_t); > > static void hme_cdma_callback(void *, bus_dma_segment_t *, int, int); > static void hme_rxdma_callback(void *, bus_dma_segment_t *, int, > @@ -316,11 +330,12 @@ > ether_ifattach(ifp, sc->sc_arpcom.ac_enaddr); > > /* > - * Tell the upper layer(s) we support long frames. > + * Tell the upper layer(s) we support long frames and cksum offloads. > */ > ifp->if_data.ifi_hdrlen = sizeof(struct ether_vlan_header); > - ifp->if_capabilities |= IFCAP_VLAN_MTU; > - ifp->if_capenable |= IFCAP_VLAN_MTU; > + ifp->if_capabilities |= IFCAP_VLAN_MTU | IFCAP_HWCSUM; > + ifp->if_hwassist |= HME_CSUM_FEATURES; > + ifp->if_capenable |= IFCAP_VLAN_MTU | IFCAP_HWCSUM; > > callout_init(&sc->sc_tick_ch, 0); > return (0); > @@ -656,7 +671,7 @@ > struct hme_softc *sc = (struct hme_softc *)xsc; > struct ifnet *ifp = &sc->sc_arpcom.ac_if; > u_int8_t *ea; > - u_int32_t v; > + u_int32_t n, v; > > /* > * Initialization sequence. The numbered steps below correspond > @@ -740,6 +755,15 @@ > v = HME_SEB_CFG_BURST64; > break; > } > + /* > + * Blindly setting 64bit transfers may hang PCI cards(Cheerio?). > + * Allowing 64bit transfers breaks TX checksum offload as well. > + * Don't know this comes from hardware bug or driver's DMAing > + * scheme. > + * > + * if (sc->sc_pci == 0) > + * v |= HME_SEB_CFG_64BIT; > + */ > HME_SEB_WRITE_4(sc, HME_SEBI_CFG, v); > > /* step 9. ETX Configuration: use mostly default values */ > @@ -775,6 +799,12 @@ > /* Enable DMA, fix RX first byte offset. */ > v &= ~HME_ERX_CFG_FBO_MASK; > v |= HME_ERX_CFG_DMAENABLE | (HME_RXOFFS << HME_ERX_CFG_FBO_SHIFT); > + /* RX TCP/UDP cksum offset */ > + if (ifp->if_capenable & IFCAP_TXCSUM) { > + n = (ETHER_HDR_LEN + sizeof(struct ip)) / 2; > + n = (n << HME_ERX_CFG_CSUM_SHIFT) & HME_ERX_CFG_CSUMSTART; > + v |= n; > + } > CTR1(KTR_HME, "hme_init: programming ERX_CFG to %x", (u_int)v); > HME_ERX_WRITE_4(sc, HME_ERXI_CFG, v); > > @@ -893,6 +923,55 @@ > ("hme_txdma_callback: missed end of packet!")); > } > > +/* TX TCP/UDP cksum */ > +static void > +hme_txcksum(struct mbuf *m, u_int32_t *cflags) > +{ > + struct ip *ip; > + u_int32_t offset, offset2, csumflag; > + caddr_t p; > + > + if ((m->m_pkthdr.csum_flags & CSUM_TCP)) { > + offset2 = offsetof(struct tcphdr, th_sum); > + csumflag = HME_XD_TCPCKSUM; > + } else if((m->m_pkthdr.csum_flags & CSUM_UDP)) { > + offset2 = offsetof(struct udphdr, uh_sum); > + csumflag = HME_XD_UDPCKSUM; > + } else > + return; > + > + for(; m && m->m_len == 0; m = m->m_next) > + ; > + if (m == NULL || m->m_len < ETHER_HDR_LEN) { > + printf("hme_txcksum: m_len < ETHER_HDR_LEN\n"); > + return; /* cksum will be corrupted */ > + } > + if (m->m_len < ETHER_HDR_LEN + sizeof(u_int32_t)) { > + if (m->m_len != ETHER_HDR_LEN) { > + printf("hme_txcksum: m_len != ETHER_HDR_LEN\n"); > + return; /* cksum will be corrupted */ > + } > + /* XXX */ > + for(m = m->m_next; m && m->m_len == 0; m = m->m_next) > + ; > + if (m == NULL) > + return; /* cksum will be corrupted */ > + ip = mtod(m, struct ip *); > + } else { > + p = mtod(m, caddr_t); > + p += ETHER_HDR_LEN; > + ip = (struct ip *)p; > + } > + if ((ip->ip_hl << 2) == sizeof(*ip)) > + *cflags = csumflag; > + else { > + offset = (ip->ip_hl << 2) + ETHER_HDR_LEN; > + *cflags = offset << HME_XD_TXCKSUM_SSHIFT; > + *cflags |= ((offset + offset2) << HME_XD_TXCKSUM_OSHIFT); > + *cflags |= HME_XD_TXCKSUM; > + } > +} > + > /* > * Routine to dma map an mbuf chain, set up the descriptor rings accordingly and > * start the transmission. > @@ -905,11 +984,12 @@ > struct hme_txdma_arg cba; > struct hme_txdesc *td; > int error, si, ri; > - u_int32_t flags; > + u_int32_t flags, cflags = 0; > > si = sc->sc_rb.rb_tdhead; > if ((td = STAILQ_FIRST(&sc->sc_rb.rb_txfreeq)) == NULL) > return (-1); > + hme_txcksum(m0, &cflags); > td->htx_m = m0; > cba.hta_sc = sc; > cba.hta_htx = td; > @@ -933,7 +1013,7 @@ > do { > ri = (ri + HME_NTXDESC - 1) % HME_NTXDESC; > flags = HME_XD_GETFLAGS(sc->sc_pci, sc->sc_rb.rb_txd, ri) | > - HME_XD_OWN; > + HME_XD_OWN | cflags; > CTR3(KTR_HME, "hme_load_mbuf: activating ri %d, si %d (%#x)", > ri, si, flags); > HME_XD_SETFLAGS(sc->sc_pci, sc->sc_rb.rb_txd, ri, flags); > @@ -951,7 +1031,7 @@ > * Pass a packet to the higher levels. > */ > static void > -hme_read(struct hme_softc *sc, int ix, int len) > +hme_read(struct hme_softc *sc, int ix, int len, u_int32_t flags) > { > struct ifnet *ifp = &sc->sc_arpcom.ac_if; > struct mbuf *m; > @@ -986,6 +1066,9 @@ > m->m_pkthdr.rcvif = ifp; > m->m_pkthdr.len = m->m_len = len + HME_RXOFFS; > m_adj(m, HME_RXOFFS); > + /* RX TCP/UDP cksum */ > + if (ifp->if_capenable & IFCAP_RXCSUM) > + hme_rxcksum(m, flags); > /* Pass the packet up. */ > (*ifp->if_input)(ifp, m); > } > @@ -1108,6 +1191,71 @@ > } > > /* > + * RX TCP/UDP cksumming > + */ > +static void > +hme_rxcksum(struct mbuf *m, u_int32_t flags) > +{ > + struct ether_header *eh; > + struct ip *ip; > + struct udphdr *uh; > + int32_t hlen, len, pktlen; > + u_int16_t cksum, *opts; > + u_int32_t temp32; > + > + pktlen = m->m_pkthdr.len; > + if (pktlen < sizeof(struct ether_header)) > + return; > + eh = mtod(m, struct ether_header *); > + if (eh->ether_type != htons(ETHERTYPE_IP)) > + return; > + ip = (struct ip *)(eh + 1); > + if (ip->ip_v != IPVERSION) > + return; > + > + hlen = ip->ip_hl << 2; > + pktlen -= sizeof(struct ether_header); > + if (hlen < sizeof(struct ip)) > + return; > + if (ntohs(ip->ip_len) < hlen) > + return; > + if (ntohs(ip->ip_len) != pktlen) > + return; > + if (ip->ip_off & htons(IP_MF | IP_OFFMASK)) > + return; /* can't handle fragmented packet */ > + > + switch (ip->ip_p) { > + case IPPROTO_TCP: > + if (pktlen < (hlen + sizeof(struct tcphdr))) > + return; > + break; > + case IPPROTO_UDP: > + if (pktlen < (hlen + sizeof(struct udphdr))) > + return; > + uh = (struct udphdr *)((caddr_t)ip + hlen); > + if (uh->uh_sum == 0) > + return; /* no checksum */ > + break; > + default: > + return; > + } > + > + cksum = ~(flags & HME_XD_RXCKSUM); > + /* cksum fixup for IP options */ > + len = hlen - sizeof(struct ip); > + if (len > 0) { > + opts = (u_int16_t *)(ip + 1); > + for (; len > 0; len -= sizeof(u_int16_t), opts++) { > + temp32 = cksum - *opts; > + temp32 = (temp32 >> 16) + (temp32 & 65535); > + cksum = temp32 & 65535; > + } > + } > + m->m_pkthdr.csum_flags |= CSUM_DATA_VALID; > + m->m_pkthdr.csum_data = cksum; > +} > + > +/* > * Receive interrupt. > */ > static void > @@ -1137,7 +1285,7 @@ > hme_discard_rxbuf(sc, ri); > } else { > len = HME_XD_DECODE_RSIZE(flags); > - hme_read(sc, ri, len); > + hme_read(sc, ri, len, flags); > } > } > if (progress) { > @@ -1386,6 +1534,15 @@ > case SIOCGIFMEDIA: > case SIOCSIFMEDIA: > error = ifmedia_ioctl(ifp, ifr, &sc->sc_mii->mii_media, cmd); > + break; > + case SIOCSIFCAP: > + ifp->if_capenable = ifr->ifr_reqcap; > + if (ifp->if_capenable & IFCAP_HWCSUM) > + ifp->if_hwassist = HME_CSUM_FEATURES; > + else > + ifp->if_hwassist = 0; > + if (ifp->if_flags & IFF_RUNNING) > + hme_init(sc); > break; > default: > error = ether_ioctl(ifp, cmd, data); > --- if_hme_sbus.c.orig Wed Jun 16 12:16:56 2004 > +++ if_hme_sbus.c Wed Jun 16 12:16:56 2004 > @@ -244,8 +244,14 @@ > > burst = sbus_get_burstsz(dev); > /* Translate into plain numerical format */ > - sc->sc_burst = (burst & SBUS_BURST_32) ? 32 : > - (burst & SBUS_BURST_16) ? 16 : 0; > + if ((burst & SBUS_BURST_64)) > + sc->sc_burst = 64; > + else if ((burst & SBUS_BURST_32)) > + sc->sc_burst = 32; > + else if ((burst & SBUS_BURST_16)) > + sc->sc_burst = 16; > + else > + sc->sc_burst = 0; > > sc->sc_pci = 0; /* XXX: should all be done in bus_dma. */ > sc->sc_dev = dev; > --- if_hmereg.h.orig Wed Jun 16 12:16:56 2004 > +++ if_hmereg.h Wed Jun 16 12:16:56 2004 > @@ -54,8 +54,8 @@ > #define HME_SEB_CFG_BURST16 0x00000000 /* 16 byte bursts */ > #define HME_SEB_CFG_BURST32 0x00000001 /* 32 byte bursts */ > #define HME_SEB_CFG_BURST64 0x00000002 /* 64 byte bursts */ > -#define HME_SEB_CFG_64BIT 0x00000004 /* ? */ > -#define HME_SEB_CFG_PARITY 0x00000008 /* ? */ > +#define HME_SEB_CFG_64BIT 0x00000004 /* extended transfer mode */ > +#define HME_SEB_CFG_PARITY 0x00000008 /* parity check for DVMA/PIO */ > > #define HME_SEB_STAT_GOTFRAME 0x00000001 /* frame received */ > #define HME_SEB_STAT_RCNTEXP 0x00000002 /* rx frame count expired */ > @@ -154,7 +154,7 @@ > #define HME_ERXI_FIFO_WPTR (3*4) /* FIFO write pointer */ > #define HME_ERXI_FIFO_SWPTR (4*4) /* FIFO shadow write pointer */ > #define HME_ERXI_FIFO_RPTR (5*4) /* FIFO read pointer */ > -#define HME_ERXI_FIFO_SRPTR (6*4) /* FIFO shadow read pointer */ > +#define HME_ERXI_FIFO_PKTCNT (6*4) /* FIFO packet counter */ > #define HME_ERXI_STATEMACHINE (7*4) /* State machine */ > > /* RXI_CFG bits */ > @@ -167,6 +167,7 @@ > #define HME_ERX_CFG_RINGSIZE256 0x00000600 /* Descriptor ring size: 256 */ > #define HME_ERX_CFG_RINGSIZEMSK 0x00000600 /* Descriptor ring size: 256 */ > #define HME_ERX_CFG_CSUMSTART 0x007f0000 /* cksum offset */ > +#define HME_ERX_CFG_CSUM_SHIFT 16 > > /* > * HME MAC-core register offsets > @@ -289,7 +290,11 @@ > #define HME_XD_RXLENMSK 0x3fff0000 /* packet length mask (rx) */ > #define HME_XD_RXLENSHIFT 16 > #define HME_XD_TXLENMSK 0x00003fff /* packet length mask (tx) */ > +#define HME_XD_TXCKSUM_SSHIFT 14 > +#define HME_XD_TXCKSUM_OSHIFT 20 > #define HME_XD_RXCKSUM 0x0000ffff /* packet checksum (rx) */ > +#define HME_XD_TCPCKSUM 0x13288000 /* precomputed tcp cksum */ > +#define HME_XD_UDPCKSUM 0x12888000 /* precomputed udp cksum */ > > /* Macros to encode/decode the receive buffer size from the flags field */ > #define HME_XD_ENCODE_RSIZE(sz) \ > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-sparc64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org" From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 16 05:07:16 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 5233916A4CF for ; Wed, 16 Jun 2004 05:07:16 +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 76C4443D46 for ; Wed, 16 Jun 2004 05:07:15 +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 i5G53wAh071964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Jun 2004 14:03:58 +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.12.10/8.12.10) with ESMTP id i5G55G1r008591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jun 2004 14:05:16 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Received: (from yongari@localhost) by michelle.kt-is.co.kr (8.12.10/8.12.10/Submit) id i5G55FiI008590; Wed, 16 Jun 2004 14:05:15 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Date: Wed, 16 Jun 2004 14:05:15 +0900 From: Pyun YongHyeon To: Kevin Day Message-ID: <20040616050515.GA8540@kt-is.co.kr> References: <20040616034520.GB7887@kt-is.co.kr> <264D82AE-BF4F-11D8-A89B-000A95A8A1F2@dragondata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <264D82AE-BF4F-11D8-A89B-000A95A8A1F2@dragondata.com> User-Agent: Mutt/1.4.1i X-Filter-Version: 1.11a (ns.kt-is.co.kr) cc: freebsd-sparc64@freebsd.org Subject: Re: TCP/UDP cksum offload on hme(4) 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: Wed, 16 Jun 2004 05:07:16 -0000 On Tue, Jun 15, 2004 at 11:39:27PM -0500, Kevin Day wrote: > > On Jun 15, 2004, at 10:45 PM, Pyun YongHyeon wrote: > > > > 1. UDP TX cksum offload has an issue. The hardware doesn't flip the > > cksum bits when the computed cksum is 0x0000. I have no idea this > > is the reason why STP2002QFP says it supports only TCP RX/TX cksum. > > (pp. 29, pp. 40, pp. 42) > > > > > > I'm not sure if you're aware of this or not, but: > > >If the computed checksum is zero, it is transmitted as all ones > >(the > >equivalent in one's complement arithmetic). An all zero > >transmitted > >checksum value means that the transmitter generated no checksum > >(for > >debugging or for higher level protocols that don't care) > > > So, if a UDP packet has an all zero checksum, it's supposed to mean > there was no checksum performed. If you legitimately came up with > 0x0000 for a checksum, you're supposed to set the header field to > 0xffff. > The TX cksumming is performed during DMA by the hardware. So when the hardware computes the cksum I have no chance to reset to 0xffff. (i.e. The mbuf was already passed to TX FIFO.) I verified the deficiency with manually created UDP payload. Regards, Pyun YongHyeon -- Pyun YongHyeon From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 16 05:12:24 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 C7E0A16A4CE; Wed, 16 Jun 2004 05:12:24 +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 2F54C43D39; Wed, 16 Jun 2004 05:12:24 +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 i5G58lAh072322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Jun 2004 14:08:47 +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.12.10/8.12.10) with ESMTP id i5G5A51r008615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jun 2004 14:10:05 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Received: (from yongari@localhost) by michelle.kt-is.co.kr (8.12.10/8.12.10/Submit) id i5G5A5ro008614; Wed, 16 Jun 2004 14:10:05 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Date: Wed, 16 Jun 2004 14:10:04 +0900 From: Pyun YongHyeon To: Scott Long Message-ID: <20040616051004.GB8540@kt-is.co.kr> References: <20040616034520.GB7887@kt-is.co.kr> <40CFD21E.9090309@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40CFD21E.9090309@freebsd.org> User-Agent: Mutt/1.4.1i X-Filter-Version: 1.11a (ns.kt-is.co.kr) cc: freebsd-sparc64@freebsd.org Subject: Re: TCP/UDP cksum offload on hme(4) 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: Wed, 16 Jun 2004 05:12:24 -0000 On Tue, Jun 15, 2004 at 10:52:46PM -0600, Scott Long wrote: > Excellent work, thanks a lot! Have you sent this to Bill Paul > for review? > > Scott > Not yet. Because the patch was not tested on PCI based sparc64 systems at all, I wanted to hear success/failure reply first. After that I can send the patch for review. Regards, Pyun YongHyeon -- Pyun YongHyeon From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 16 08:56:49 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 127F916A4CE for ; Wed, 16 Jun 2004 08:56:49 +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 04E9643D5C for ; Wed, 16 Jun 2004 08:56:48 +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 i5G8s1Ah083089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Jun 2004 17:54:01 +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.12.10/8.12.10) with ESMTP id i5G8tJ1r009243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jun 2004 17:55:19 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Received: (from yongari@localhost) by michelle.kt-is.co.kr (8.12.10/8.12.10/Submit) id i5G8tIed009242; Wed, 16 Jun 2004 17:55:18 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Date: Wed, 16 Jun 2004 17:55:18 +0900 From: Pyun YongHyeon To: Mykel Message-ID: <20040616085518.GA8881@kt-is.co.kr> References: <40CFC0A0.1000604@mWare.ca> <20040616034055.GE26532@electra.cse.Buffalo.EDU> <40CFC2CF.8080509@mWare.ca> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: <40CFC2CF.8080509@mWare.ca> User-Agent: Mutt/1.4.1i X-Filter-Version: 1.11a (ns.kt-is.co.kr) cc: freebsd-sparc64@freebsd.org Subject: Re: IT! WORKS! 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: Wed, 16 Jun 2004 08:56:49 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jun 15, 2004 at 11:47:27PM -0400, Mykel wrote: > Ken Smith wrote: ... > > Now how about the console? how can I make typing at least practical on > here? I was hoping to use this as a desktop machine. > Because I got big trouble while testing TCP/UDP cksum offload fix for hme(4) on console, I touched ofw_console code. I stole the code from OpenBSD. It seems that now the console works as expected. No more 1 sec. pause needed to see correct typing on keyboard. Here is patch. I'm not familiar with tty code, so it may be just dirty hack or it may not work except my Ultra2. Regards, Pyun YongHyeon -- Pyun YongHyeon --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ofw_console.diff" --- sys/dev/ofw/ofw_console.c.orig Fri Jun 11 07:15:51 2004 +++ sys/dev/ofw/ofw_console.c Wed Jun 16 17:38:48 2004 @@ -42,7 +42,8 @@ #include -#define OFW_POLL_HZ 4 +#define OFW_POLL_HZ 100 +#define OFBURSTLEN 128 /* max number of bytes to write in one chunk */ static d_open_t ofw_dev_open; static d_close_t ofw_dev_close; @@ -125,7 +126,7 @@ ttychars(tp); tp->t_iflag = TTYDEF_IFLAG; tp->t_oflag = TTYDEF_OFLAG; - tp->t_cflag = TTYDEF_CFLAG|CLOCAL; + tp->t_cflag = TTYDEF_CFLAG; tp->t_lflag = TTYDEF_LFLAG; tp->t_ispeed = tp->t_ospeed = TTYDEF_SPEED; ttsetwater(tp); @@ -162,6 +163,8 @@ return (ENXIO); } + /* XXX Should be replaced with callout_stop(9) */ + untimeout(ofw_timeout, tp, ofw_timeouthandle); ttyld_close(tp, flag); ttyclose(tp); @@ -179,16 +182,18 @@ static void ofw_tty_start(struct tty *tp) { + struct clist *cl; + int len; + u_char buf[OFBURSTLEN]; - if (tp->t_state & (TS_TIMEOUT | TS_TTSTOP)) { - ttwwakeup(tp); + + if (tp->t_state & (TS_TIMEOUT | TS_BUSY | TS_TTSTOP)) return; - } tp->t_state |= TS_BUSY; - while (tp->t_outq.c_cc != 0) { - ofw_cons_putc(NULL, getc(&tp->t_outq)); - } + cl = &tp->t_outq; + len = q_to_b(cl, buf, OFBURSTLEN); + OF_write(stdout, buf, len); tp->t_state &= ~TS_BUSY; ttwwakeup(tp); --FL5UXtIhxfXey3p5-- From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 16 09:25:29 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 9B43C16A4CE for ; Wed, 16 Jun 2004 09:25:29 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 487B143D58 for ; Wed, 16 Jun 2004 09:25:29 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i5G9RIsL014935; Wed, 16 Jun 2004 03:27:18 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40D011A8.1030404@freebsd.org> Date: Wed, 16 Jun 2004 03:23:52 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: yongari@kt-is.co.kr References: <40CFC0A0.1000604@mWare.ca> <20040616034055.GE26532@electra.cse.Buffalo.EDU> <40CFC2CF.8080509@mWare.ca> <20040616085518.GA8881@kt-is.co.kr> In-Reply-To: <20040616085518.GA8881@kt-is.co.kr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.4 required=3.8 tests=MANY_EXCLAMATIONS autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Mykel cc: freebsd-sparc64@freebsd.org Subject: Re: IT! WORKS! X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2004 09:25:29 -0000 Pyun YongHyeon wrote: > On Tue, Jun 15, 2004 at 11:47:27PM -0400, Mykel wrote: > > Ken Smith wrote: > ... > > > > Now how about the console? how can I make typing at least practical on > > here? I was hoping to use this as a desktop machine. > > > > Because I got big trouble while testing TCP/UDP cksum offload > fix for hme(4) on console, I touched ofw_console code. I stole > the code from OpenBSD. It seems that now the console works as > expected. No more 1 sec. pause needed to see correct typing on > keyboard. Here is patch. I'm not familiar with tty code, so > it may be just dirty hack or it may not work except my Ultra2. > > Regards, > Pyun YongHyeon > Another nice patch =-) The only question that I have is, is it possible to have more than OFBURSTLEN characters in the outq, and if so, what happens to the extra charaters? Do they just stay in the outq until the next poll cycle? I guess that it's hard to get 12,800 keypresses in a second, though. The only other problem that I see is that I remember ofwcons taking up a lot of CPU when the polling cycle is increased. This was several years ago, though, so it might be different now. Have you compared CPU usage with your patch? Scott From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 16 10:25:30 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 54EF416A4CE; Wed, 16 Jun 2004 10:25:30 +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 9745443D41; Wed, 16 Jun 2004 10:25:29 +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 i5GANkAh086810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Jun 2004 19:23:46 +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.12.10/8.12.10) with ESMTP id i5GAP51r009461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jun 2004 19:25:05 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Received: (from yongari@localhost) by michelle.kt-is.co.kr (8.12.10/8.12.10/Submit) id i5GAP4w6009460; Wed, 16 Jun 2004 19:25:05 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Date: Wed, 16 Jun 2004 19:25:04 +0900 From: Pyun YongHyeon To: Scott Long Message-ID: <20040616102504.GB8881@kt-is.co.kr> References: <40CFC0A0.1000604@mWare.ca> <20040616034055.GE26532@electra.cse.Buffalo.EDU> <40CFC2CF.8080509@mWare.ca> <20040616085518.GA8881@kt-is.co.kr> <40D011A8.1030404@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D011A8.1030404@freebsd.org> User-Agent: Mutt/1.4.1i X-Filter-Version: 1.11a (ns.kt-is.co.kr) cc: freebsd-sparc64@freebsd.org Subject: Re: IT! WORKS! 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: Wed, 16 Jun 2004 10:25:30 -0000 On Wed, Jun 16, 2004 at 03:23:52AM -0600, Scott Long wrote: > Pyun YongHyeon wrote: > >On Tue, Jun 15, 2004 at 11:47:27PM -0400, Mykel wrote: > > > Ken Smith wrote: > >... > > > > > > Now how about the console? how can I make typing at least practical on > > > here? I was hoping to use this as a desktop machine. > > > > > > >Because I got big trouble while testing TCP/UDP cksum offload > >fix for hme(4) on console, I touched ofw_console code. I stole > >the code from OpenBSD. It seems that now the console works as > >expected. No more 1 sec. pause needed to see correct typing on > >keyboard. Here is patch. I'm not familiar with tty code, so > >it may be just dirty hack or it may not work except my Ultra2. > > > >Regards, > >Pyun YongHyeon > > > > Another nice patch =-) The only question that I have is, is it > possible to have more than OFBURSTLEN characters in the outq, and > if so, what happens to the extra charaters? Do they just stay in > the outq until the next poll cycle? I guess that it's hard to I'm sorry I don't know. I just thought OF_write() is too slow, it would be more efficient to write at once. So I stole the code from OpenBSD. > get 12,800 keypresses in a second, though. The only other > problem that I see is that I remember ofwcons taking up a lot of > CPU when the polling cycle is increased. This was several years > ago, though, so it might be different now. Have you compared > CPU usage with your patch? > top says "0.5% sys" when I use OFW_POLL_HZ with 100. But when I change the value to 20, top said "0.0% sys". With the value 20, I had no lost characters on console. So in practice, the OFW_POLL_HZ could be set to 20 or less than the value. Thank you for pointing out. > Scott Regards, Pyun YongHyeon -- Pyun YongHyeon From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 16 10:42:49 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 79A0F16A4CE for ; Wed, 16 Jun 2004 10:42:49 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 128CF43D1D for ; Wed, 16 Jun 2004 10:42:49 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i5GAjGFC015195; Wed, 16 Jun 2004 04:45:17 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40D023EE.7020302@freebsd.org> Date: Wed, 16 Jun 2004 04:41:50 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: yongari@kt-is.co.kr References: <40CFC0A0.1000604@mWare.ca> <20040616034055.GE26532@electra.cse.Buffalo.EDU> <40CFC2CF.8080509@mWare.ca> <20040616085518.GA8881@kt-is.co.kr> <40D011A8.1030404@freebsd.org> <20040616102504.GB8881@kt-is.co.kr> In-Reply-To: <20040616102504.GB8881@kt-is.co.kr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.4 required=3.8 tests=MANY_EXCLAMATIONS autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-sparc64@freebsd.org Subject: Re: IT! WORKS! X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2004 10:42:49 -0000 Pyun YongHyeon wrote: > On Wed, Jun 16, 2004 at 03:23:52AM -0600, Scott Long wrote: > > Pyun YongHyeon wrote: > > >On Tue, Jun 15, 2004 at 11:47:27PM -0400, Mykel wrote: > > > > Ken Smith wrote: > > >... > > > > > > > > Now how about the console? how can I make typing at least practical on > > > > here? I was hoping to use this as a desktop machine. > > > > > > > > > >Because I got big trouble while testing TCP/UDP cksum offload > > >fix for hme(4) on console, I touched ofw_console code. I stole > > >the code from OpenBSD. It seems that now the console works as > > >expected. No more 1 sec. pause needed to see correct typing on > > >keyboard. Here is patch. I'm not familiar with tty code, so > > >it may be just dirty hack or it may not work except my Ultra2. > > > > > >Regards, > > >Pyun YongHyeon > > > > > > > Another nice patch =-) The only question that I have is, is it > > possible to have more than OFBURSTLEN characters in the outq, and > > if so, what happens to the extra charaters? Do they just stay in > > the outq until the next poll cycle? I guess that it's hard to > I'm sorry I don't know. I just thought OF_write() is too slow, > it would be more efficient to write at once. So I stole the code > from OpenBSD. > > > get 12,800 keypresses in a second, though. The only other > > problem that I see is that I remember ofwcons taking up a lot of > > CPU when the polling cycle is increased. This was several years > > ago, though, so it might be different now. Have you compared > > CPU usage with your patch? > > > top says "0.5% sys" when I use OFW_POLL_HZ with 100. But when I > change the value to 20, top said "0.0% sys". With the value 20, > I had no lost characters on console. So in practice, the OFW_POLL_HZ > could be set to 20 or less than the value. > Thank you for pointing out. > Look at rev 1.4 of ofw_console.c. It looks like the polling interval was changed from 50 to 4 in response to poor performance and a certain lockup potential. Your change to batch the console writes will undoubtably help this, though. It would be very intereting to get some testing results from a blade100 and an Ultra5/10 on this. If people with this hardware can test and report back both whether it helps/hurts and if it had any impact on CPU load, I'll commit it. Scott From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 16 10:58:43 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 72FB816A4CE; Wed, 16 Jun 2004 10:58:43 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0839943D4C; Wed, 16 Jun 2004 10:58:43 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smtp3.sentex.ca (8.12.11/8.12.11) with ESMTP id i5G9EOKH063650; Wed, 16 Jun 2004 05:14:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i5G9EPmX087712; Wed, 16 Jun 2004 05:14:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C524A7306D; Wed, 16 Jun 2004 05:14:24 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040616091424.C524A7306D@freebsd-current.sentex.ca> Date: Wed, 16 Jun 2004 05:14:24 -0400 (EDT) Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2004 10:58:43 -0000 TB --- 2004-06-16 08:32:56 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-06-16 08:32:56 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-06-16 08:32:56 - checking out the source tree TB --- 2004-06-16 08:32:56 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64 TB --- 2004-06-16 08:32:56 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-06-16 08:35:36 - building world (CFLAGS=-O2 -pipe) TB --- 2004-06-16 08:35:36 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src TB --- 2004-06-16 08:35:36 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/exclude.c cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/full-write.c cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/getdate.c cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/getline.c cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/getstr.c cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/hash.c {standard input}: Assembler messages: {standard input}:1283: Error: Illegal operands *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/gnu. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-06-16 09:14:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-06-16 09:14:24 - ERROR: failed to build world TB --- 2004-06-16 09:14:24 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 16 16:12:54 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 4161B16A4CE for ; Wed, 16 Jun 2004 16:12:54 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0705943D39 for ; Wed, 16 Jun 2004 16:12:54 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.12.11/8.12.10) with ESMTP id i5GGCIxn057743 for ; Wed, 16 Jun 2004 09:12:18 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i5GGCHgx057742 for freebsd-sparc64@freebsd.org; Wed, 16 Jun 2004 09:12:17 -0700 (PDT) (envelope-from obrien) Date: Wed, 16 Jun 2004 09:12:17 -0700 From: "David O'Brien" To: freebsd-sparc64@freebsd.org Message-ID: <20040616161217.GA57659@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Subject: ** HEADS UP ** DO NOT UPDATE and 'make world' YOUR SPARCS X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-sparc64@freebsd.org List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2004 16:12:54 -0000 I've hit an issue that I suspect can render your machine useless if you install a new binutils. I suggest not installing a new userland world until you see the "ALL CLEAR". -- -- David (obrien@FreeBSD.org) From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 16 21:44:17 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 DE6C716A4D0 for ; Wed, 16 Jun 2004 21:44:17 +0000 (GMT) Received: from sockar.homeip.net (tourist.net1.nerim.net [62.212.109.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 038E043D45 for ; Wed, 16 Jun 2004 21:44:17 +0000 (GMT) (envelope-from amon@sockar.homeip.net) Received: from sockar.homeip.net (localhost [127.0.0.1]) by sockar.homeip.net (8.12.9p2/8.12.9) with ESMTP id i5GLgxJL002407; Wed, 16 Jun 2004 23:42:59 +0200 (CEST) (envelope-from amon@sockar.homeip.net) Received: (from amon@localhost) by sockar.homeip.net (8.12.9p2/8.12.9/Submit) id i5GLgwH5002402; Wed, 16 Jun 2004 23:42:58 +0200 (CEST) (envelope-from amon) Date: Wed, 16 Jun 2004 23:42:58 +0200 From: Herve Boulouis To: Pyun YongHyeon Message-ID: <20040616234258.A95312@ra.aabs> References: <20040616034520.GB7887@kt-is.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040616034520.GB7887@kt-is.co.kr>; from yongari@kt-is.co.kr on Wed, Jun 16, 2004 at 12:45:20PM +0900 cc: freebsd-sparc64@freebsd.org Subject: Re: TCP/UDP cksum offload on hme(4) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2004 21:44:18 -0000 Le 16/06/2004 à 12:45, Pyun YongHyeon a écrit: > Hello All, > > 2. The patch was tested on Ultra2(2x300MHz, FAS366). I'd like to > hear ok/nok results from PCI based sparc64 users. > The dmesg of the Ultra2 is available at: > http:///www.kr.freebsd.org/~yognari/dmesg.u2.txt > > 3. I couldn't feel performance boost from the cksum offloads but > enabling it reduced system loads considerably. After some very basic testing (mainly ftp transfers), your patch seems to work correctly on my netra t 1125 (2*300Mhz). My -current is from mid april. -- Herve Boulouis From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 17 02:48:38 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 1728516A4CE for ; Thu, 17 Jun 2004 02:48:38 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 0191A43D41 for ; Thu, 17 Jun 2004 02:48:37 +0000 (GMT) (envelope-from tmoestl@gmx.net) Received: (qmail 16946 invoked by uid 65534); 17 Jun 2004 02:47:53 -0000 Received: from p509075AC.dip.t-dialin.net (EHLO timesink.dyndns.org) (80.144.117.172) by mail.gmx.net (mp003) with SMTP; 17 Jun 2004 04:47:53 +0200 X-Authenticated: #5374206 Received: by abel (Postfix, from userid 1001) id 0D6CB6E0; Thu, 17 Jun 2004 04:48:00 +0200 (CEST) Date: Thu, 17 Jun 2004 04:48:00 +0200 From: Thomas Moestl To: Pyun YongHyeon Message-ID: <20040617024759.GA5610@timesink.dyndns.org> References: <20040616034520.GB7887@kt-is.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040616034520.GB7887@kt-is.co.kr> User-Agent: Mutt/1.5.6i cc: freebsd-sparc64@freebsd.org Subject: Re: TCP/UDP cksum offload on hme(4) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2004 02:48:38 -0000 Hello, On Wed, 2004/06/16 at 12:45:20 +0900, Pyun YongHyeon wrote: > 1. UDP TX cksum offload has an issue. The hardware doesn't flip the > cksum bits when the computed cksum is 0x0000. I have no idea this > is the reason why STP2002QFP says it supports only TCP RX/TX cksum. > (pp. 29, pp. 40, pp. 42) It would probably be better not to advertise CSUM_UDP by default then, so that the checksum will never be unset unless that is desired. One of the IFF_LINK* flags or a sysctl could be used to allow the user to enable it anyway. > Corrections, suggestions welcome. Great work! I had long been contemplating to implement this, but always was too lazy :) I have some comments regarding the patch, mostly about minor style issues and oversights: > --- if_hme.c.orig Wed Jun 16 12:16:56 2004 > +++ if_hme.c Wed Jun 16 12:16:56 2004 > @@ -54,9 +54,15 @@ > * maximum packet size (this is not verified). Buffers starting on odd > * boundaries must be mapped so that the burst can start on a natural boundary. > * > - * Checksumming is not yet supported. > + * STP2002QFP-UG says that Ethernet hardware supports TCP checksum offload. > + * In reality, we can do the same technique for UDP datagram too. However, > + * the hardware doesn't compensate the cksum for UDP datagram which can yield > + * to 0x0. > + * When the UDP datagram with cksum 0 sent to a system, it would think it > + * received a datagram with 'no cksum'. I don't know this is compulsory reason > + * to disable UDP cksum offload capability. > */ > - > +#define HME_CSUM_FEATURES (CSUM_TCP | CSUM_UDP) > #define HMEDEBUG > #define KTR_HME KTR_CT2 /* XXX */ > > @@ -80,6 +86,12 @@ > #include > #include > > +#include > +#include > +#include > +#include > +#include > + > #include > #include > > @@ -106,10 +118,12 @@ > static void hme_mediastatus(struct ifnet *, struct ifmediareq *); > > static int hme_load_txmbuf(struct hme_softc *, struct mbuf *); > -static void hme_read(struct hme_softc *, int, int); > +static void hme_read(struct hme_softc *, int, int, u_int32_t); > static void hme_eint(struct hme_softc *, u_int); > static void hme_rint(struct hme_softc *); > static void hme_tint(struct hme_softc *); > +static void hme_txcksum(struct mbuf *, u_int32_t *); > +static void hme_rxcksum(struct mbuf *, u_int32_t); > > static void hme_cdma_callback(void *, bus_dma_segment_t *, int, int); > static void hme_rxdma_callback(void *, bus_dma_segment_t *, int, > @@ -316,11 +330,12 @@ > ether_ifattach(ifp, sc->sc_arpcom.ac_enaddr); > > /* > - * Tell the upper layer(s) we support long frames. > + * Tell the upper layer(s) we support long frames and cksum offloads. > */ > ifp->if_data.ifi_hdrlen = sizeof(struct ether_vlan_header); > - ifp->if_capabilities |= IFCAP_VLAN_MTU; > - ifp->if_capenable |= IFCAP_VLAN_MTU; > + ifp->if_capabilities |= IFCAP_VLAN_MTU | IFCAP_HWCSUM; > + ifp->if_hwassist |= HME_CSUM_FEATURES; > + ifp->if_capenable |= IFCAP_VLAN_MTU | IFCAP_HWCSUM; > > callout_init(&sc->sc_tick_ch, 0); > return (0); > @@ -656,7 +671,7 @@ > struct hme_softc *sc = (struct hme_softc *)xsc; > struct ifnet *ifp = &sc->sc_arpcom.ac_if; > u_int8_t *ea; > - u_int32_t v; > + u_int32_t n, v; > > /* > * Initialization sequence. The numbered steps below correspond > @@ -740,6 +755,15 @@ > v = HME_SEB_CFG_BURST64; > break; > } > + /* > + * Blindly setting 64bit transfers may hang PCI cards(Cheerio?). > + * Allowing 64bit transfers breaks TX checksum offload as well. > + * Don't know this comes from hardware bug or driver's DMAing > + * scheme. > + * > + * if (sc->sc_pci == 0) > + * v |= HME_SEB_CFG_64BIT; > + */ > HME_SEB_WRITE_4(sc, HME_SEBI_CFG, v); > > /* step 9. ETX Configuration: use mostly default values */ > @@ -775,6 +799,12 @@ > /* Enable DMA, fix RX first byte offset. */ > v &= ~HME_ERX_CFG_FBO_MASK; > v |= HME_ERX_CFG_DMAENABLE | (HME_RXOFFS << HME_ERX_CFG_FBO_SHIFT); > + /* RX TCP/UDP cksum offset */ > + if (ifp->if_capenable & IFCAP_TXCSUM) { > + n = (ETHER_HDR_LEN + sizeof(struct ip)) / 2; > + n = (n << HME_ERX_CFG_CSUM_SHIFT) & HME_ERX_CFG_CSUMSTART; > + v |= n; > + } Should this test not be for the IFCAP_RXCSUM bit? Also, a minor style nit: please add a comparison against 0 to such bit tests, e.g.: if ((ifp->if_capenable & IFCAP_RXCSUM) != 0) { > CTR1(KTR_HME, "hme_init: programming ERX_CFG to %x", (u_int)v); > HME_ERX_WRITE_4(sc, HME_ERXI_CFG, v); > > @@ -893,6 +923,55 @@ > ("hme_txdma_callback: missed end of packet!")); > } > > +/* TX TCP/UDP cksum */ > +static void > +hme_txcksum(struct mbuf *m, u_int32_t *cflags) > +{ > + struct ip *ip; > + u_int32_t offset, offset2, csumflag; > + caddr_t p; > + > + if ((m->m_pkthdr.csum_flags & CSUM_TCP)) { > + offset2 = offsetof(struct tcphdr, th_sum); > + csumflag = HME_XD_TCPCKSUM; > + } else if((m->m_pkthdr.csum_flags & CSUM_UDP)) { > + offset2 = offsetof(struct udphdr, uh_sum); > + csumflag = HME_XD_UDPCKSUM; > + } else > + return; (It seems that csum_data contains the offset of the field that the checksum should be written into, relative to the start of the IP payload, for outgoing packets; this might save some code here, but that is of course not that important.) > + > + for(; m && m->m_len == 0; m = m->m_next) > + ; > + if (m == NULL || m->m_len < ETHER_HDR_LEN) { > + printf("hme_txcksum: m_len < ETHER_HDR_LEN\n"); > + return; /* cksum will be corrupted */ > + } It would probably be best to try as hard as possible to not fail here. Since the conditions in which we would fail because of mbuf sizes should rarely be true, maybe a good option would be to just sacrifice some CPU time and do an m_pullup() then to rectify the mbuf chain according to our needs (hme_txcksum would need to return a struct mbuf * for that)? > + if (m->m_len < ETHER_HDR_LEN + sizeof(u_int32_t)) { > + if (m->m_len != ETHER_HDR_LEN) { > + printf("hme_txcksum: m_len != ETHER_HDR_LEN\n"); > + return; /* cksum will be corrupted */ > + } > + /* XXX */ > + for(m = m->m_next; m && m->m_len == 0; m = m->m_next) > + ; > + if (m == NULL) > + return; /* cksum will be corrupted */ > + ip = mtod(m, struct ip *); > + } else { > + p = mtod(m, caddr_t); > + p += ETHER_HDR_LEN; > + ip = (struct ip *)p; > + } > + if ((ip->ip_hl << 2) == sizeof(*ip)) > + *cflags = csumflag; > + else { > + offset = (ip->ip_hl << 2) + ETHER_HDR_LEN; > + *cflags = offset << HME_XD_TXCKSUM_SSHIFT; > + *cflags |= ((offset + offset2) << HME_XD_TXCKSUM_OSHIFT); > + *cflags |= HME_XD_TXCKSUM; > + } I would suggest to always use the code in the else branch of the if. The time needed to compute the flags is negligible, and it would make the code a bit clearer. > +} > + > /* > * Routine to dma map an mbuf chain, set up the descriptor rings accordingly and > * start the transmission. > @@ -905,11 +984,12 @@ > struct hme_txdma_arg cba; > struct hme_txdesc *td; > int error, si, ri; > - u_int32_t flags; > + u_int32_t flags, cflags = 0; > > si = sc->sc_rb.rb_tdhead; > if ((td = STAILQ_FIRST(&sc->sc_rb.rb_txfreeq)) == NULL) > return (-1); > + hme_txcksum(m0, &cflags); > td->htx_m = m0; > cba.hta_sc = sc; > cba.hta_htx = td; > @@ -933,7 +1013,7 @@ > do { > ri = (ri + HME_NTXDESC - 1) % HME_NTXDESC; > flags = HME_XD_GETFLAGS(sc->sc_pci, sc->sc_rb.rb_txd, ri) | > - HME_XD_OWN; > + HME_XD_OWN | cflags; > CTR3(KTR_HME, "hme_load_mbuf: activating ri %d, si %d (%#x)", > ri, si, flags); > HME_XD_SETFLAGS(sc->sc_pci, sc->sc_rb.rb_txd, ri, flags); > @@ -951,7 +1031,7 @@ > * Pass a packet to the higher levels. > */ > static void > -hme_read(struct hme_softc *sc, int ix, int len) > +hme_read(struct hme_softc *sc, int ix, int len, u_int32_t flags) > { > struct ifnet *ifp = &sc->sc_arpcom.ac_if; > struct mbuf *m; > @@ -986,6 +1066,9 @@ > m->m_pkthdr.rcvif = ifp; > m->m_pkthdr.len = m->m_len = len + HME_RXOFFS; > m_adj(m, HME_RXOFFS); > + /* RX TCP/UDP cksum */ > + if (ifp->if_capenable & IFCAP_RXCSUM) > + hme_rxcksum(m, flags); > /* Pass the packet up. */ > (*ifp->if_input)(ifp, m); > } > @@ -1108,6 +1191,71 @@ > } > > /* > + * RX TCP/UDP cksumming > + */ > +static void > +hme_rxcksum(struct mbuf *m, u_int32_t flags) > +{ > + struct ether_header *eh; > + struct ip *ip; > + struct udphdr *uh; > + int32_t hlen, len, pktlen; > + u_int16_t cksum, *opts; > + u_int32_t temp32; > + > + pktlen = m->m_pkthdr.len; > + if (pktlen < sizeof(struct ether_header)) > + return; > + eh = mtod(m, struct ether_header *); > + if (eh->ether_type != htons(ETHERTYPE_IP)) > + return; > + ip = (struct ip *)(eh + 1); > + if (ip->ip_v != IPVERSION) > + return; For paranoia reasons, it would be nice to check whether the packet is large enough to contain an ip header before we access its fields, too; I guess that could be conveniently combined with the sizeof(struct ether_header) check above. > + > + hlen = ip->ip_hl << 2; > + pktlen -= sizeof(struct ether_header); > + if (hlen < sizeof(struct ip)) > + return; > + if (ntohs(ip->ip_len) < hlen) > + return; This test is a bit redundant with the TCP/UDP ones below. > + if (ntohs(ip->ip_len) != pktlen) > + return; > + if (ip->ip_off & htons(IP_MF | IP_OFFMASK)) > + return; /* can't handle fragmented packet */ > + > + switch (ip->ip_p) { > + case IPPROTO_TCP: > + if (pktlen < (hlen + sizeof(struct tcphdr))) > + return; > + break; > + case IPPROTO_UDP: > + if (pktlen < (hlen + sizeof(struct udphdr))) > + return; > + uh = (struct udphdr *)((caddr_t)ip + hlen); > + if (uh->uh_sum == 0) > + return; /* no checksum */ > + break; > + default: > + return; > + } > + > + cksum = ~(flags & HME_XD_RXCKSUM); > + /* cksum fixup for IP options */ > + len = hlen - sizeof(struct ip); > + if (len > 0) { > + opts = (u_int16_t *)(ip + 1); > + for (; len > 0; len -= sizeof(u_int16_t), opts++) { > + temp32 = cksum - *opts; > + temp32 = (temp32 >> 16) + (temp32 & 65535); > + cksum = temp32 & 65535; > + } > + } > + m->m_pkthdr.csum_flags |= CSUM_DATA_VALID; > + m->m_pkthdr.csum_data = cksum; > +} > + > +/* > * Receive interrupt. > */ > static void > @@ -1137,7 +1285,7 @@ > hme_discard_rxbuf(sc, ri); > } else { > len = HME_XD_DECODE_RSIZE(flags); > - hme_read(sc, ri, len); > + hme_read(sc, ri, len, flags); > } > } > if (progress) { > @@ -1386,6 +1534,15 @@ > case SIOCGIFMEDIA: > case SIOCSIFMEDIA: > error = ifmedia_ioctl(ifp, ifr, &sc->sc_mii->mii_media, cmd); > + break; > + case SIOCSIFCAP: > + ifp->if_capenable = ifr->ifr_reqcap; > + if (ifp->if_capenable & IFCAP_HWCSUM) > + ifp->if_hwassist = HME_CSUM_FEATURES; > + else > + ifp->if_hwassist = 0; > + if (ifp->if_flags & IFF_RUNNING) > + hme_init(sc); As I understand it, if_hwassist reflects only the types of checksums for outgoing packets that we are able to do, so it should only be set if IFCAP_TXCSUM is enabled, not either TXCSUM or RXCSUM. The network stack will check only if_hwassist, not if_capenable, to determine which TX checksums it may offload. > break; > default: > error = ether_ioctl(ifp, cmd, data); > --- if_hme_sbus.c.orig Wed Jun 16 12:16:56 2004 > +++ if_hme_sbus.c Wed Jun 16 12:16:56 2004 > @@ -244,8 +244,14 @@ > > burst = sbus_get_burstsz(dev); > /* Translate into plain numerical format */ > - sc->sc_burst = (burst & SBUS_BURST_32) ? 32 : > - (burst & SBUS_BURST_16) ? 16 : 0; > + if ((burst & SBUS_BURST_64)) > + sc->sc_burst = 64; > + else if ((burst & SBUS_BURST_32)) > + sc->sc_burst = 32; > + else if ((burst & SBUS_BURST_16)) > + sc->sc_burst = 16; > + else > + sc->sc_burst = 0; > > sc->sc_pci = 0; /* XXX: should all be done in bus_dma. */ > sc->sc_dev = dev; > --- if_hmereg.h.orig Wed Jun 16 12:16:56 2004 > +++ if_hmereg.h Wed Jun 16 12:16:56 2004 > @@ -54,8 +54,8 @@ > #define HME_SEB_CFG_BURST16 0x00000000 /* 16 byte bursts */ > #define HME_SEB_CFG_BURST32 0x00000001 /* 32 byte bursts */ > #define HME_SEB_CFG_BURST64 0x00000002 /* 64 byte bursts */ > -#define HME_SEB_CFG_64BIT 0x00000004 /* ? */ > -#define HME_SEB_CFG_PARITY 0x00000008 /* ? */ > +#define HME_SEB_CFG_64BIT 0x00000004 /* extended transfer mode */ > +#define HME_SEB_CFG_PARITY 0x00000008 /* parity check for DVMA/PIO */ > > #define HME_SEB_STAT_GOTFRAME 0x00000001 /* frame received */ > #define HME_SEB_STAT_RCNTEXP 0x00000002 /* rx frame count expired */ > @@ -154,7 +154,7 @@ > #define HME_ERXI_FIFO_WPTR (3*4) /* FIFO write pointer */ > #define HME_ERXI_FIFO_SWPTR (4*4) /* FIFO shadow write pointer */ > #define HME_ERXI_FIFO_RPTR (5*4) /* FIFO read pointer */ > -#define HME_ERXI_FIFO_SRPTR (6*4) /* FIFO shadow read pointer */ > +#define HME_ERXI_FIFO_PKTCNT (6*4) /* FIFO packet counter */ > #define HME_ERXI_STATEMACHINE (7*4) /* State machine */ > > /* RXI_CFG bits */ > @@ -167,6 +167,7 @@ > #define HME_ERX_CFG_RINGSIZE256 0x00000600 /* Descriptor ring size: 256 */ > #define HME_ERX_CFG_RINGSIZEMSK 0x00000600 /* Descriptor ring size: 256 */ > #define HME_ERX_CFG_CSUMSTART 0x007f0000 /* cksum offset */ > +#define HME_ERX_CFG_CSUM_SHIFT 16 Please name the constants consistently in the way similar ones are (..._CSUMSTART was alread in error), e.g. ..._CSUMSTART_MASK and ..._CSUMSTART_SHIFT, or an abbreviation thereof if that is too long. > > /* > * HME MAC-core register offsets > @@ -289,7 +290,11 @@ > #define HME_XD_RXLENMSK 0x3fff0000 /* packet length mask (rx) */ > #define HME_XD_RXLENSHIFT 16 > #define HME_XD_TXLENMSK 0x00003fff /* packet length mask (tx) */ > +#define HME_XD_TXCKSUM_SSHIFT 14 > +#define HME_XD_TXCKSUM_OSHIFT 20 > #define HME_XD_RXCKSUM 0x0000ffff /* packet checksum (rx) */ > +#define HME_XD_TCPCKSUM 0x13288000 /* precomputed tcp cksum */ > +#define HME_XD_UDPCKSUM 0x12888000 /* precomputed udp cksum */ If these two constants are still needed (one of my suggestion above would eliminate them), please use the shift and bit constants defined above, together with the actual offset values, to assemble them in order to make them more readable and seem less like "magic values". > /* Macros to encode/decode the receive buffer size from the flags field */ > #define HME_XD_ENCODE_RSIZE(sz) \ Thanks, - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ "Reality continues to ruin my life." -- Calvin and Hobbes From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 17 02:50:04 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 5CF6A16A4CF for ; Thu, 17 Jun 2004 02:50:04 +0000 (GMT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 68CE143D45 for ; Thu, 17 Jun 2004 02:50:03 +0000 (GMT) (envelope-from tmoestl@gmx.net) Received: (qmail 4304 invoked by uid 65534); 17 Jun 2004 02:49:38 -0000 Received: from p509075AC.dip.t-dialin.net (EHLO timesink.dyndns.org) (80.144.117.172) by mail.gmx.net (mp026) with SMTP; 17 Jun 2004 04:49:38 +0200 X-Authenticated: #5374206 Received: by abel (Postfix, from userid 1001) id AE2FC6E0; Thu, 17 Jun 2004 04:49:46 +0200 (CEST) Date: Thu, 17 Jun 2004 04:49:46 +0200 From: Thomas Moestl To: Scott Long Message-ID: <20040617024946.GB5610@timesink.dyndns.org> References: <20040616034520.GB7887@kt-is.co.kr> <40CFD21E.9090309@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40CFD21E.9090309@freebsd.org> User-Agent: Mutt/1.5.6i cc: freebsd-sparc64@freebsd.org Subject: Re: TCP/UDP cksum offload on hme(4) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2004 02:50:04 -0000 On Tue, 2004/06/15 at 22:52:46 -0600, Scott Long wrote: > Excellent work, thanks a lot! Have you sent this to Bill Paul > for review? I'm not sure that wpaul@ is interested in this driver. As far as I can tell, he as never touched it. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ "The secret to enjoying your job is to have a hobby that is even worse." -- Calvin and Hobbes From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 17 03:21:16 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 279C416A4CF for ; Thu, 17 Jun 2004 03:21:16 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B300C43D5D for ; Thu, 17 Jun 2004 03:21:15 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i5H3Nb25017867; Wed, 16 Jun 2004 21:23:37 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40D10DE5.3070206@freebsd.org> Date: Wed, 16 Jun 2004 21:20:05 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Moestl References: <20040616034520.GB7887@kt-is.co.kr> <40CFD21E.9090309@freebsd.org> <20040617024946.GB5610@timesink.dyndns.org> In-Reply-To: <20040617024946.GB5610@timesink.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-sparc64@freebsd.org Subject: Re: TCP/UDP cksum offload on hme(4) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2004 03:21:16 -0000 Thomas Moestl wrote: > On Tue, 2004/06/15 at 22:52:46 -0600, Scott Long wrote: > >>Excellent work, thanks a lot! Have you sent this to Bill Paul >> for review? > > > I'm not sure that wpaul@ is interested in this driver. As far as I can > tell, he as never touched it. > > - Thomas > I thought that he might be interested in reviewing the checksum offload code. Sorry if I stepped on toes. Scott From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 17 06:30:58 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 E393316A4CE for ; Thu, 17 Jun 2004 06:30:58 +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 B533943D39 for ; Thu, 17 Jun 2004 06:30:57 +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 i5H6SwAh027256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Jun 2004 15:29:00 +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.12.10/8.12.10) with ESMTP id i5H6UN1r012470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jun 2004 15:30:23 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Received: (from yongari@localhost) by michelle.kt-is.co.kr (8.12.10/8.12.10/Submit) id i5H6UM4R012469; Thu, 17 Jun 2004 15:30:22 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Date: Thu, 17 Jun 2004 15:30:22 +0900 From: Pyun YongHyeon To: Thomas Moestl Message-ID: <20040617063022.GA11797@kt-is.co.kr> References: <20040616034520.GB7887@kt-is.co.kr> <20040617024759.GA5610@timesink.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <20040617024759.GA5610@timesink.dyndns.org> User-Agent: Mutt/1.4.1i X-Filter-Version: 1.11a (ns.kt-is.co.kr) cc: freebsd-sparc64@freebsd.org Subject: Re: TCP/UDP cksum offload on hme(4) 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: Thu, 17 Jun 2004 06:30:59 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jun 17, 2004 at 04:48:00AM +0200, Thomas Moestl wrote: > Hello, > > On Wed, 2004/06/16 at 12:45:20 +0900, Pyun YongHyeon wrote: > > 1. UDP TX cksum offload has an issue. The hardware doesn't flip the > > cksum bits when the computed cksum is 0x0000. I have no idea this > > is the reason why STP2002QFP says it supports only TCP RX/TX cksum. > > (pp. 29, pp. 40, pp. 42) > > It would probably be better not to advertise CSUM_UDP by default then, > so that the checksum will never be unset unless that is desired. One > of the IFF_LINK* flags or a sysctl could be used to allow the user to > enable it anyway. > Ok. Patch was modified to use IFF_LINK0. Now UDP TX cksumming is disabled by default. > > + > > + for(; m && m->m_len == 0; m = m->m_next) > > + ; > > + if (m == NULL || m->m_len < ETHER_HDR_LEN) { > > + printf("hme_txcksum: m_len < ETHER_HDR_LEN\n"); > > + return; /* cksum will be corrupted */ > > + } > > It would probably be best to try as hard as possible to not fail > here. Since the conditions in which we would fail because of mbuf > sizes should rarely be true, maybe a good option would be to just > sacrifice some CPU time and do an m_pullup() then to rectify the mbuf > chain according to our needs (hme_txcksum would need to return a > struct mbuf * for that)? > Because we will have ALTQ feature in near future, the driver can't call IF_PREPEND anymore. So if m_pullup() failed it would be dropped. I thought, we may not encounter such mbuf fragmentation in real environments.(I didn't see any of these fragment condition on my setup.) If we use m_pullup() it will make ALTQ-enabled hme driver useless. > > + > > + hlen = ip->ip_hl << 2; > > + pktlen -= sizeof(struct ether_header); > > + if (hlen < sizeof(struct ip)) > > + return; > > + if (ntohs(ip->ip_len) < hlen) > > + return; > > This test is a bit redundant with the TCP/UDP ones below. > When we have a packet that contains IP header with options plus some corrupted TCP/UDP header(i.e. less than the size of the header), should the check be performed? > > + if (ntohs(ip->ip_len) != pktlen) > > + return; > > + if (ip->ip_off & htons(IP_MF | IP_OFFMASK)) > > + return; /* can't handle fragmented packet */ > > + > > + switch (ip->ip_p) { > > + case IPPROTO_TCP: > > + if (pktlen < (hlen + sizeof(struct tcphdr))) > > + return; > > + break; > > + case IPPROTO_UDP: > > + if (pktlen < (hlen + sizeof(struct udphdr))) > > + return; > > + uh = (struct udphdr *)((caddr_t)ip + hlen); > > + if (uh->uh_sum == 0) > > + return; /* no checksum */ > > + break; > > + default: > > + return; > > + } Thank you very much for your detailed explanation and suggestions. New patch is available at: http://www.kr.freebsd.org/~yongari/hme.freebsd.diff2 Thanks again. Rgeards, Pyun YongHyeon -- Pyun YongHyeon --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="hme.freebsd.diff2" --- if_hme.c.orig Tue Jun 15 17:05:24 2004 +++ if_hme.c Thu Jun 17 14:55:36 2004 @@ -54,9 +54,15 @@ * maximum packet size (this is not verified). Buffers starting on odd * boundaries must be mapped so that the burst can start on a natural boundary. * - * Checksumming is not yet supported. + * STP2002QFP-UG says that Ethernet hardware supports TCP checksum offload. + * In reality, we can do the same technique for UDP datagram too. However, + * the hardware doesn't compensate the cksum for UDP datagram which can yield + * to 0x0. + * When the UDP datagram with cksum 0 sent to a system, it would think it + * received a datagram with 'no cksum'. I don't know this is compulsory reason + * to disable UDP cksum offload capability. */ - +#define HME_CSUM_FEATURES (CSUM_TCP) #define HMEDEBUG #define KTR_HME KTR_CT2 /* XXX */ @@ -80,6 +86,12 @@ #include #include +#include +#include +#include +#include +#include + #include #include @@ -106,10 +118,12 @@ static void hme_mediastatus(struct ifnet *, struct ifmediareq *); static int hme_load_txmbuf(struct hme_softc *, struct mbuf *); -static void hme_read(struct hme_softc *, int, int); +static void hme_read(struct hme_softc *, int, int, u_int32_t); static void hme_eint(struct hme_softc *, u_int); static void hme_rint(struct hme_softc *); static void hme_tint(struct hme_softc *); +static void hme_txcksum(struct mbuf *, u_int32_t *); +static void hme_rxcksum(struct mbuf *, u_int32_t); static void hme_cdma_callback(void *, bus_dma_segment_t *, int, int); static void hme_rxdma_callback(void *, bus_dma_segment_t *, int, @@ -120,6 +134,7 @@ devclass_t hme_devclass; static int hme_nerr; +static int hme_csum_features = HME_CSUM_FEATURES; DRIVER_MODULE(miibus, hme, miibus_driver, miibus_devclass, 0, 0); MODULE_DEPEND(hme, miibus, 1, 1, 1); @@ -316,11 +331,12 @@ ether_ifattach(ifp, sc->sc_arpcom.ac_enaddr); /* - * Tell the upper layer(s) we support long frames. + * Tell the upper layer(s) we support long frames and cksum offloads. */ ifp->if_data.ifi_hdrlen = sizeof(struct ether_vlan_header); - ifp->if_capabilities |= IFCAP_VLAN_MTU; - ifp->if_capenable |= IFCAP_VLAN_MTU; + ifp->if_capabilities |= IFCAP_VLAN_MTU | IFCAP_HWCSUM; + ifp->if_hwassist |= hme_csum_features; + ifp->if_capenable |= IFCAP_VLAN_MTU | IFCAP_HWCSUM; callout_init(&sc->sc_tick_ch, 0); return (0); @@ -656,7 +672,7 @@ struct hme_softc *sc = (struct hme_softc *)xsc; struct ifnet *ifp = &sc->sc_arpcom.ac_if; u_int8_t *ea; - u_int32_t v; + u_int32_t n, v; /* * Initialization sequence. The numbered steps below correspond @@ -740,6 +756,15 @@ v = HME_SEB_CFG_BURST64; break; } + /* + * Blindly setting 64bit transfers may hang PCI cards(Cheerio?). + * Allowing 64bit transfers breaks TX checksum offload as well. + * Don't know this comes from hardware bug or driver's DMAing + * scheme. + * + * if (sc->sc_pci == 0) + * v |= HME_SEB_CFG_64BIT; + */ HME_SEB_WRITE_4(sc, HME_SEBI_CFG, v); /* step 9. ETX Configuration: use mostly default values */ @@ -775,6 +800,10 @@ /* Enable DMA, fix RX first byte offset. */ v &= ~HME_ERX_CFG_FBO_MASK; v |= HME_ERX_CFG_DMAENABLE | (HME_RXOFFS << HME_ERX_CFG_FBO_SHIFT); + /* RX TCP/UDP cksum offset */ + n = (ETHER_HDR_LEN + sizeof(struct ip)) / 2; + n = (n << HME_ERX_CFG_CSUMSTART_SHIFT) & HME_ERX_CFG_CSUMSTART_MASK; + v |= n; CTR1(KTR_HME, "hme_init: programming ERX_CFG to %x", (u_int)v); HME_ERX_WRITE_4(sc, HME_ERXI_CFG, v); @@ -893,6 +922,46 @@ ("hme_txdma_callback: missed end of packet!")); } +/* TX TCP/UDP cksum */ +static void +hme_txcksum(struct mbuf *m, u_int32_t *cflags) +{ + struct ip *ip; + u_int32_t offset, offset2; + caddr_t p; + + if ((m->m_pkthdr.csum_flags & hme_csum_features) == 0) + return; + + for(; m && m->m_len == 0; m = m->m_next) + ; + if (m == NULL || m->m_len < ETHER_HDR_LEN) { + printf("hme_txcksum: m_len < ETHER_HDR_LEN\n"); + return; /* cksum will be corrupted */ + } + if (m->m_len < ETHER_HDR_LEN + sizeof(u_int32_t)) { + if (m->m_len != ETHER_HDR_LEN) { + printf("hme_txcksum: m_len != ETHER_HDR_LEN\n"); + return; /* cksum will be corrupted */ + } + /* XXX */ + for(m = m->m_next; m && m->m_len == 0; m = m->m_next) + ; + if (m == NULL) + return; /* cksum will be corrupted */ + ip = mtod(m, struct ip *); + } else { + p = mtod(m, caddr_t); + p += ETHER_HDR_LEN; + ip = (struct ip *)p; + } + offset2 = m->m_pkthdr.csum_data; + offset = (ip->ip_hl << 2) + ETHER_HDR_LEN; + *cflags = offset << HME_XD_TXCKSUM_SSHIFT; + *cflags |= ((offset + offset2) << HME_XD_TXCKSUM_OSHIFT); + *cflags |= HME_XD_TXCKSUM; +} + /* * Routine to dma map an mbuf chain, set up the descriptor rings accordingly and * start the transmission. @@ -905,11 +974,12 @@ struct hme_txdma_arg cba; struct hme_txdesc *td; int error, si, ri; - u_int32_t flags; + u_int32_t flags, cflags = 0; si = sc->sc_rb.rb_tdhead; if ((td = STAILQ_FIRST(&sc->sc_rb.rb_txfreeq)) == NULL) return (-1); + hme_txcksum(m0, &cflags); td->htx_m = m0; cba.hta_sc = sc; cba.hta_htx = td; @@ -933,7 +1003,7 @@ do { ri = (ri + HME_NTXDESC - 1) % HME_NTXDESC; flags = HME_XD_GETFLAGS(sc->sc_pci, sc->sc_rb.rb_txd, ri) | - HME_XD_OWN; + HME_XD_OWN | cflags; CTR3(KTR_HME, "hme_load_mbuf: activating ri %d, si %d (%#x)", ri, si, flags); HME_XD_SETFLAGS(sc->sc_pci, sc->sc_rb.rb_txd, ri, flags); @@ -951,7 +1021,7 @@ * Pass a packet to the higher levels. */ static void -hme_read(struct hme_softc *sc, int ix, int len) +hme_read(struct hme_softc *sc, int ix, int len, u_int32_t flags) { struct ifnet *ifp = &sc->sc_arpcom.ac_if; struct mbuf *m; @@ -986,6 +1056,9 @@ m->m_pkthdr.rcvif = ifp; m->m_pkthdr.len = m->m_len = len + HME_RXOFFS; m_adj(m, HME_RXOFFS); + /* RX TCP/UDP cksum */ + if (ifp->if_capenable & IFCAP_RXCSUM) + hme_rxcksum(m, flags); /* Pass the packet up. */ (*ifp->if_input)(ifp, m); } @@ -1108,6 +1181,71 @@ } /* + * RX TCP/UDP cksumming + */ +static void +hme_rxcksum(struct mbuf *m, u_int32_t flags) +{ + struct ether_header *eh; + struct ip *ip; + struct udphdr *uh; + int32_t hlen, len, pktlen; + u_int16_t cksum, *opts; + u_int32_t temp32; + + pktlen = m->m_pkthdr.len; + if (pktlen < sizeof(struct ether_header) + sizeof(struct ip)) + return; + eh = mtod(m, struct ether_header *); + if (eh->ether_type != htons(ETHERTYPE_IP)) + return; + ip = (struct ip *)(eh + 1); + if (ip->ip_v != IPVERSION) + return; + + hlen = ip->ip_hl << 2; + pktlen -= sizeof(struct ether_header); + if (hlen < sizeof(struct ip)) + return; + if (ntohs(ip->ip_len) < hlen) + return; + if (ntohs(ip->ip_len) != pktlen) + return; + if (ip->ip_off & htons(IP_MF | IP_OFFMASK)) + return; /* can't handle fragmented packet */ + + switch (ip->ip_p) { + case IPPROTO_TCP: + if (pktlen < (hlen + sizeof(struct tcphdr))) + return; + break; + case IPPROTO_UDP: + if (pktlen < (hlen + sizeof(struct udphdr))) + return; + uh = (struct udphdr *)((caddr_t)ip + hlen); + if (uh->uh_sum == 0) + return; /* no checksum */ + break; + default: + return; + } + + cksum = ~(flags & HME_XD_RXCKSUM); + /* cksum fixup for IP options */ + len = hlen - sizeof(struct ip); + if (len > 0) { + opts = (u_int16_t *)(ip + 1); + for (; len > 0; len -= sizeof(u_int16_t), opts++) { + temp32 = cksum - *opts; + temp32 = (temp32 >> 16) + (temp32 & 65535); + cksum = temp32 & 65535; + } + } + m->m_pkthdr.csum_flags |= CSUM_DATA_VALID; + m->m_pkthdr.csum_data = cksum; +} + +/* * Receive interrupt. */ static void @@ -1137,7 +1275,7 @@ hme_discard_rxbuf(sc, ri); } else { len = HME_XD_DECODE_RSIZE(flags); - hme_read(sc, ri, len); + hme_read(sc, ri, len, flags); } } if (progress) { @@ -1373,6 +1511,10 @@ */ hme_init(sc); } + if ((ifp->if_flags & IFF_LINK0) != 0) + hme_csum_features |= CSUM_UDP; + else + hme_csum_features &= ~CSUM_UDP; #ifdef HMEDEBUG sc->sc_debug = (ifp->if_flags & IFF_DEBUG) != 0 ? 1 : 0; #endif @@ -1386,6 +1528,13 @@ case SIOCGIFMEDIA: case SIOCSIFMEDIA: error = ifmedia_ioctl(ifp, ifr, &sc->sc_mii->mii_media, cmd); + break; + case SIOCSIFCAP: + ifp->if_capenable = ifr->ifr_reqcap; + if (ifp->if_capenable & IFCAP_TXCSUM) + ifp->if_hwassist = hme_csum_features; + else + ifp->if_hwassist = 0; break; default: error = ether_ioctl(ifp, cmd, data); --- if_hme_sbus.c.orig Tue Jun 15 17:05:24 2004 +++ if_hme_sbus.c Tue Jun 15 17:05:24 2004 @@ -244,8 +244,14 @@ burst = sbus_get_burstsz(dev); /* Translate into plain numerical format */ - sc->sc_burst = (burst & SBUS_BURST_32) ? 32 : - (burst & SBUS_BURST_16) ? 16 : 0; + if ((burst & SBUS_BURST_64)) + sc->sc_burst = 64; + else if ((burst & SBUS_BURST_32)) + sc->sc_burst = 32; + else if ((burst & SBUS_BURST_16)) + sc->sc_burst = 16; + else + sc->sc_burst = 0; sc->sc_pci = 0; /* XXX: should all be done in bus_dma. */ sc->sc_dev = dev; --- if_hmereg.h.orig Tue Jun 15 17:05:24 2004 +++ if_hmereg.h Thu Jun 17 14:23:02 2004 @@ -54,8 +54,8 @@ #define HME_SEB_CFG_BURST16 0x00000000 /* 16 byte bursts */ #define HME_SEB_CFG_BURST32 0x00000001 /* 32 byte bursts */ #define HME_SEB_CFG_BURST64 0x00000002 /* 64 byte bursts */ -#define HME_SEB_CFG_64BIT 0x00000004 /* ? */ -#define HME_SEB_CFG_PARITY 0x00000008 /* ? */ +#define HME_SEB_CFG_64BIT 0x00000004 /* extended transfer mode */ +#define HME_SEB_CFG_PARITY 0x00000008 /* parity check for DVMA/PIO */ #define HME_SEB_STAT_GOTFRAME 0x00000001 /* frame received */ #define HME_SEB_STAT_RCNTEXP 0x00000002 /* rx frame count expired */ @@ -154,7 +154,7 @@ #define HME_ERXI_FIFO_WPTR (3*4) /* FIFO write pointer */ #define HME_ERXI_FIFO_SWPTR (4*4) /* FIFO shadow write pointer */ #define HME_ERXI_FIFO_RPTR (5*4) /* FIFO read pointer */ -#define HME_ERXI_FIFO_SRPTR (6*4) /* FIFO shadow read pointer */ +#define HME_ERXI_FIFO_PKTCNT (6*4) /* FIFO packet counter */ #define HME_ERXI_STATEMACHINE (7*4) /* State machine */ /* RXI_CFG bits */ @@ -166,7 +166,8 @@ #define HME_ERX_CFG_RINGSIZE128 0x00000400 /* Descriptor ring size: 128 */ #define HME_ERX_CFG_RINGSIZE256 0x00000600 /* Descriptor ring size: 256 */ #define HME_ERX_CFG_RINGSIZEMSK 0x00000600 /* Descriptor ring size: 256 */ -#define HME_ERX_CFG_CSUMSTART 0x007f0000 /* cksum offset */ +#define HME_ERX_CFG_CSUMSTART_MASK 0x007f0000 /* cksum offset mask */ +#define HME_ERX_CFG_CSUMSTART_SHIFT 16 /* * HME MAC-core register offsets @@ -289,6 +290,8 @@ #define HME_XD_RXLENMSK 0x3fff0000 /* packet length mask (rx) */ #define HME_XD_RXLENSHIFT 16 #define HME_XD_TXLENMSK 0x00003fff /* packet length mask (tx) */ +#define HME_XD_TXCKSUM_SSHIFT 14 +#define HME_XD_TXCKSUM_OSHIFT 20 #define HME_XD_RXCKSUM 0x0000ffff /* packet checksum (rx) */ /* Macros to encode/decode the receive buffer size from the flags field */ --9jxsPFA5p3P2qPhR-- From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 17 06:50:29 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 570AA16A4CE for ; Thu, 17 Jun 2004 06:50:29 +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 9939643D53 for ; Thu, 17 Jun 2004 06:50:28 +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 i5H6mBAh028401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Jun 2004 15:48:11 +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.12.10/8.12.10) with ESMTP id i5H6na1r012532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jun 2004 15:49:36 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Received: (from yongari@localhost) by michelle.kt-is.co.kr (8.12.10/8.12.10/Submit) id i5H6nZPs012531; Thu, 17 Jun 2004 15:49:35 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Date: Thu, 17 Jun 2004 15:49:35 +0900 From: Pyun YongHyeon To: Herve Boulouis Message-ID: <20040617064935.GB11797@kt-is.co.kr> References: <20040616034520.GB7887@kt-is.co.kr> <20040616234258.A95312@ra.aabs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040616234258.A95312@ra.aabs> User-Agent: Mutt/1.4.1i X-Filter-Version: 1.11a (ns.kt-is.co.kr) cc: freebsd-sparc64@freebsd.org Subject: Re: TCP/UDP cksum offload on hme(4) 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: Thu, 17 Jun 2004 06:50:29 -0000 On Wed, Jun 16, 2004 at 11:42:58PM +0200, Herve Boulouis wrote: > Le 16/06/2004 ? 12:45, Pyun YongHyeon a ?crit: > > Hello All, > > > > 2. The patch was tested on Ultra2(2x300MHz, FAS366). I'd like to > > hear ok/nok results from PCI based sparc64 users. > > The dmesg of the Ultra2 is available at: > > http:///www.kr.freebsd.org/~yognari/dmesg.u2.txt > > > > 3. I couldn't feel performance boost from the cksum offloads but > > enabling it reduced system loads considerably. > > After some very basic testing (mainly ftp transfers), your patch > seems to work correctly on my netra t 1125 (2*300Mhz). > > My -current is from mid april. > Thanks for your report. Did you get some speed up by cksum offload? Did you notice system loads changes under heavy traffic? How about NFS over UDP transport layer? I can't saturate the wire with/without my patch.(For TCP without witness it was about 67Mbps. On OpenBSD I got about 93Mbps.) I vaguely guess the reason was caused by hme's lack of auto-negotiation. > -- > Herve Boulouis Regards, Pyun YongHyeon -- Pyun YongHyeon From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 17 13:03:18 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 896E616A4D0; Thu, 17 Jun 2004 13:03:18 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 316AA43D2D; Thu, 17 Jun 2004 13:03:18 +0000 (GMT) (envelope-from ilmar@watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5HD1LIL029809; Thu, 17 Jun 2004 09:01:21 -0400 (EDT) (envelope-from ilmar@watson.org) Received: from localhost (ilmar@localhost)i5HD1Ldx029806; Thu, 17 Jun 2004 09:01:21 -0400 (EDT) (envelope-from ilmar@watson.org) X-Authentication-Warning: fledge.watson.org: ilmar owned process doing -bs Date: Thu, 17 Jun 2004 09:01:21 -0400 (EDT) From: "Ilmar S. Habibulin" To: Scott Long In-Reply-To: <40D023EE.7020302@freebsd.org> Message-ID: <20040617081225.H28897@fledge.watson.org> References: <40CFC0A0.1000604@mWare.ca> <20040616034055.GE26532@electra.cse.Buffalo.EDU> <40CFC2CF.8080509@mWare.ca> <20040616085518.GA8881@kt-is.co.kr> <40D011A8.1030404@freebsd.org> <20040616102504.GB8881@kt-is.co.kr> <40D023EE.7020302@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-sparc64@freebsd.org Subject: Re: IT! WORKS! X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2004 13:03:18 -0000 On Wed, 16 Jun 2004, Scott Long wrote: > It would be very intereting to get some testing results from a blade100 > and an Ultra5/10 on this. If people with this hardware can test and > report back both whether it helps/hurts and if it had any impact on CPU > load, I'll commit it. I want to confirm type speed up on blade100 with this patch applied. Can't tell top values now because of some bug, which causes kernel panic. So i have unbootable blade now. :( This bug is not related to the patch. I think i've reported it once. If you use screen as console and log in via ssh, kernel panics after some period of time. Don't know how to trace this panics, should i make the same steps like on i386 - set dumdev, use dump, kernel.debug and gdb -k? From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 17 13:09:12 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 A04A616A4CE; Thu, 17 Jun 2004 13:09:12 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 401E643D41; Thu, 17 Jun 2004 13:09:12 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i5HD8erd030050; Thu, 17 Jun 2004 09:08:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i5HD8fMG080593; Thu, 17 Jun 2004 09:08:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B97C87306D; Thu, 17 Jun 2004 09:08:40 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040617130840.B97C87306D@freebsd-current.sentex.ca> Date: Thu, 17 Jun 2004 09:08:40 -0400 (EDT) Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2004 13:09:12 -0000 TB --- 2004-06-17 12:27:31 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-06-17 12:27:31 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-06-17 12:27:31 - checking out the source tree TB --- 2004-06-17 12:27:31 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64 TB --- 2004-06-17 12:27:31 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-06-17 12:29:39 - building world (CFLAGS=-O2 -pipe) TB --- 2004-06-17 12:29:39 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src TB --- 2004-06-17 12:29:39 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/exclude.c cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/full-write.c cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/getdate.c cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/getline.c cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/getstr.c cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/hash.c {standard input}: Assembler messages: {standard input}:1283: Error: Illegal operands *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/gnu. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-06-17 13:08:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-06-17 13:08:40 - ERROR: failed to build world TB --- 2004-06-17 13:08:40 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 17 14:11:11 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 71DAE16A4CE for ; Thu, 17 Jun 2004 14:11:11 +0000 (GMT) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13E1043D45 for ; Thu, 17 Jun 2004 14:11:11 +0000 (GMT) (envelope-from tillman@seekingfire.com) Received: by mail.seekingfire.com (Postfix, from userid 500) id CBECD381; Thu, 17 Jun 2004 08:10:08 -0600 (CST) Date: Thu, 17 Jun 2004 08:10:08 -0600 From: Tillman Hodgson To: freebsd-sparc64@freebsd.org Message-ID: <20040617141008.GN76337@seekingfire.com> References: <20040616034520.GB7887@kt-is.co.kr> <20040616234258.A95312@ra.aabs> <20040617064935.GB11797@kt-is.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040617064935.GB11797@kt-is.co.kr> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-GPG-Key-ID: 828AFC7B X-GPG-Fingerprint: 5584 14BA C9EB 1524 0E68 F543 0F0A 7FBC 828A FC7B X-GPG-Key: http://www.seekingfire.com/gpg_key.asc X-Urban-Legend: There is lots of hidden information in headers User-Agent: Mutt/1.5.6i Subject: Re: TCP/UDP cksum offload on hme(4) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2004 14:11:11 -0000 On Thu, Jun 17, 2004 at 03:49:35PM +0900, Pyun YongHyeon wrote: > I can't saturate the wire with/without my patch.(For TCP without > witness it was about 67Mbps. On OpenBSD I got about 93Mbps.) > I vaguely guess the reason was caused by hme's lack of > auto-negotiation. That seems odd to me ... on my Ultra 5 (with 5 hme ports) running -current as of April 16, I recently ran some IPsec vs clear transmission tests: Ultra 5, clear transmission: [root@caliban /usr/local/netperf]# ./netperf -t UDP_STREAM -H athena UDP UNIDIRECTIONAL SEND TEST to athena : histogram Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 9216 9216 10.01 13004 13160 95.81 42080 10.01 12778 94.14 Ultra 5, with 3des: [root@caliban /usr/local/netperf]# ./netperf -t UDP_STREAM -H secathena UDP UNIDIRECTIONAL SEND TEST to secathena : histogram Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 9216 9216 10.01 715 0 5.27 42080 10.01 713 5.25 Ultra 5n, with blowfish: [root@caliban ~]# /usr/local/netperf/netperf -t UDP_STREAM -H secathena UDP UNIDIRECTIONAL SEND TEST to secathena : histogram Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 9216 9216 10.01 14744 0 108.63 42080 10.01 3681 27.12 (108, greater than 100mbit max, is due to using 'deflate' compression algorithm) (Oh, and the moral of the story is that blowfish rocks when usign IPsec in transport mode :-)) This was testing a UDP stream (simulating my UDP NFS exports) to an x86 NFS file server runing -STABLE with the a gigabit interface. They were connected through a D-link 1026G switch, and auto-negotiation was used. -T -- Zen is the unsymbolization of the world. R.H. Blyth From owner-freebsd-sparc64@FreeBSD.ORG Fri Jun 18 00:46:29 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 C8C6316A4CE for ; Fri, 18 Jun 2004 00:46:29 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64E2A43D53 for ; Fri, 18 Jun 2004 00:46:29 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (adsl-63-207-60-35.dsl.lsan03.pacbell.net [63.207.60.35])i5I0kA2M010916 for ; Thu, 17 Jun 2004 20:46:10 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 41AB652F71; Thu, 17 Jun 2004 17:46:08 -0700 (PDT) Date: Thu, 17 Jun 2004 17:46:07 -0700 From: Kris Kennaway To: sparc64@FreeBSD.org Message-ID: <20040618004607.GB6459@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xXmbgvnjoT4axfJE" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: panic: ipi_send: couldn't send ipi X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2004 00:46:29 -0000 --xXmbgvnjoT4axfJE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I got this on a dual ultra 60 running -CURRENT that I'm using for package builds: panic: ipi_send: couldn't send ipi cpuid =3D 0; Debugger("panic") Stopped at Debugger+0x1c: ta %xcc, 1 db> trace panic() at panic+0x170 cpu_ipi_send() at cpu_ipi_send+0xb8 cpu_ipi_selected() at cpu_ipi_selected+0x38 tlb_page_demap() at tlb_page_demap+0x158 vm_page_zero_idle() at vm_page_zero_idle+0x78 vm_pagezero() at vm_pagezero+0xc0 fork_exit() at fork_exit+0x9c fork_trampoline() at fork_trampoline+0x8 db> call dumpsys panic: trap: fast data access mmu miss cpuid =3D 0; Debugger("panic") Any ideas? =20 Kris --xXmbgvnjoT4axfJE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA0jtPWry0BWjoQKURAjvgAKDUai9Ftj+zctuvvF0EhjclLfPzFgCgji3M /hKZJgFTtAJueCb8qdb146U= =/rTe -----END PGP SIGNATURE----- --xXmbgvnjoT4axfJE-- From owner-freebsd-sparc64@FreeBSD.ORG Fri Jun 18 01:21:11 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 83B1E16A4CE for ; Fri, 18 Jun 2004 01:21:11 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id A6AA243D53 for ; Fri, 18 Jun 2004 01:21:10 +0000 (GMT) (envelope-from tmoestl@gmx.net) Received: (qmail 5806 invoked by uid 65534); 18 Jun 2004 01:20:38 -0000 Received: from p50907E21.dip.t-dialin.net (EHLO timesink.dyndns.org) (80.144.126.33) by mail.gmx.net (mp006) with SMTP; 18 Jun 2004 03:20:38 +0200 X-Authenticated: #5374206 Received: by abel (Postfix, from userid 1001) id CC93F6E8; Fri, 18 Jun 2004 03:20:45 +0200 (CEST) Date: Fri, 18 Jun 2004 03:20:45 +0200 From: Thomas Moestl To: Pyun YongHyeon Message-ID: <20040618012045.GF747@timesink.dyndns.org> References: <20040616034520.GB7887@kt-is.co.kr> <20040617024759.GA5610@timesink.dyndns.org> <20040617063022.GA11797@kt-is.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040617063022.GA11797@kt-is.co.kr> User-Agent: Mutt/1.5.6i cc: freebsd-sparc64@freebsd.org Subject: Re: TCP/UDP cksum offload on hme(4) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2004 01:21:11 -0000 On Thu, 2004/06/17 at 15:30:22 +0900, Pyun YongHyeon wrote: > On Thu, Jun 17, 2004 at 04:48:00AM +0200, Thomas Moestl wrote: > > On Wed, 2004/06/16 at 12:45:20 +0900, Pyun YongHyeon wrote: > > > + > > > + for(; m && m->m_len == 0; m = m->m_next) > > > + ; > > > + if (m == NULL || m->m_len < ETHER_HDR_LEN) { > > > + printf("hme_txcksum: m_len < ETHER_HDR_LEN\n"); > > > + return; /* cksum will be corrupted */ > > > + } > > > > It would probably be best to try as hard as possible to not fail > > here. Since the conditions in which we would fail because of mbuf > > sizes should rarely be true, maybe a good option would be to just > > sacrifice some CPU time and do an m_pullup() then to rectify the mbuf > > chain according to our needs (hme_txcksum would need to return a > > struct mbuf * for that)? > > > Because we will have ALTQ feature in near future, the driver > can't call IF_PREPEND anymore. So if m_pullup() failed it would > be dropped. I thought, we may not encounter such mbuf fragmentation > in real environments.(I didn't see any of these fragment condition > on my setup.) > If we use m_pullup() it will make ALTQ-enabled hme driver useless. As far as I know, the latest consensus was that there would be an equivalent function/macro even with ALTQ; otherwise, the driver would require some massive rework, as we depend on the prepend functionality right now (because we cannot know if we have a sufficient amount of free descriptors in advance). On second thought, though, I agree that adding more complexity to handle this case may be overkill, and that handling m_pullup() failures could get a bit yucky. > > > > + > > > + hlen = ip->ip_hl << 2; > > > + pktlen -= sizeof(struct ether_header); > > > + if (hlen < sizeof(struct ip)) > > > + return; > > > + if (ntohs(ip->ip_len) < hlen) > > > + return; > > > > This test is a bit redundant with the TCP/UDP ones below. > > > When we have a packet that contains IP header with options plus some > corrupted TCP/UDP header(i.e. less than the size of the header), > should the check be performed? Hmmm, in that case we could not use the checksumming anyway, so it would not be necessary. But that is, of course, nitpicking :) > New patch is available at: > http://www.kr.freebsd.org/~yongari/hme.freebsd.diff2 Just one further remark: > + if ((ifp->if_flags & IFF_LINK0) != 0) > + hme_csum_features |= CSUM_UDP; > + else > + hme_csum_features &= ~CSUM_UDP; Maybe if_hwassist should be changed accordingly in this case, too. It might be a bit counter-intuitive to need to do an extra SIOCSIFCAP before this takes effect. Thanks for your changes! Since people have reported that this patch works well on PCI hmes, I am planning to commit it soon. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ "I couldn't read it because my parents forgot to pay the gravity bill." -- Calvin and Hobbes From owner-freebsd-sparc64@FreeBSD.ORG Fri Jun 18 03:23:27 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 A705316A4CE for ; Fri, 18 Jun 2004 03:23:27 +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 E196343D48 for ; Fri, 18 Jun 2004 03:23:26 +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 i5I3KTAh069745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 Jun 2004 12:20: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.12.10/8.12.10) with ESMTP id i5I3M01r015572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jun 2004 12:22:00 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Received: (from yongari@localhost) by michelle.kt-is.co.kr (8.12.10/8.12.10/Submit) id i5I3LxhK015571; Fri, 18 Jun 2004 12:21:59 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Date: Fri, 18 Jun 2004 12:21:59 +0900 From: Pyun YongHyeon To: Thomas Moestl Message-ID: <20040618032159.GA15377@kt-is.co.kr> References: <20040616034520.GB7887@kt-is.co.kr> <20040617024759.GA5610@timesink.dyndns.org> <20040617063022.GA11797@kt-is.co.kr> <20040618012045.GF747@timesink.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040618012045.GF747@timesink.dyndns.org> User-Agent: Mutt/1.4.1i X-Filter-Version: 1.11a (ns.kt-is.co.kr) cc: freebsd-sparc64@freebsd.org Subject: Re: TCP/UDP cksum offload on hme(4) 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: Fri, 18 Jun 2004 03:23:27 -0000 On Fri, Jun 18, 2004 at 03:20:45AM +0200, Thomas Moestl wrote: ... > > Just one further remark: > > > + if ((ifp->if_flags & IFF_LINK0) != 0) > > + hme_csum_features |= CSUM_UDP; > > + else > > + hme_csum_features &= ~CSUM_UDP; > > Maybe if_hwassist should be changed accordingly in this case, too. It Yes, it needs if_hwassist modification too. > might be a bit counter-intuitive to need to do an extra SIOCSIFCAP > before this takes effect. > > > Thanks for your changes! Since people have reported that this patch > works well on PCI hmes, I am planning to commit it soon. > Great! Thank you very much. Regards, Pyun YongHyeon -- Pyun YongHyeon From owner-freebsd-sparc64@FreeBSD.ORG Fri Jun 18 14:20:06 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 3B6FE16A4CE; Fri, 18 Jun 2004 14:20:06 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE07B43D5C; Fri, 18 Jun 2004 14:20:03 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smtp3.sentex.ca (8.12.11/8.12.11) with ESMTP id i5IDCX39037443; Fri, 18 Jun 2004 09:12:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i5IDCY2p087702; Fri, 18 Jun 2004 09:12:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8D4B87306D; Fri, 18 Jun 2004 09:12:34 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040618131234.8D4B87306D@freebsd-current.sentex.ca> Date: Fri, 18 Jun 2004 09:12:34 -0400 (EDT) Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2004 14:20:06 -0000 TB --- 2004-06-18 12:30:35 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-06-18 12:30:35 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-06-18 12:30:35 - checking out the source tree TB --- 2004-06-18 12:30:35 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64 TB --- 2004-06-18 12:30:35 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-06-18 12:33:29 - building world (CFLAGS=-O2 -pipe) TB --- 2004-06-18 12:33:29 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src TB --- 2004-06-18 12:33:29 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/exclude.c cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/full-write.c cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/getdate.c cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/getline.c cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/getstr.c cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/hash.c {standard input}: Assembler messages: {standard input}:1283: Error: Illegal operands *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/gnu. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-06-18 13:12:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-06-18 13:12:34 - ERROR: failed to build world TB --- 2004-06-18 13:12:34 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Sat Jun 19 12:48:33 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 D59F916A4CE; Sat, 19 Jun 2004 12:48:33 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8215543D58; Sat, 19 Jun 2004 12:48:33 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i5JCmIXi067498; Sat, 19 Jun 2004 08:48:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i5JCmI88006961; Sat, 19 Jun 2004 08:48:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 42E957306D; Sat, 19 Jun 2004 08:48:18 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040619124818.42E957306D@freebsd-current.sentex.ca> Date: Sat, 19 Jun 2004 08:48:18 -0400 (EDT) Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2004 12:48:34 -0000 TB --- 2004-06-19 12:06:42 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-06-19 12:06:42 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-06-19 12:06:42 - checking out the source tree TB --- 2004-06-19 12:06:42 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64 TB --- 2004-06-19 12:06:42 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-06-19 12:09:06 - building world (CFLAGS=-O2 -pipe) TB --- 2004-06-19 12:09:06 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src TB --- 2004-06-19 12:09:06 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/exclude.c cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/full-write.c cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/getdate.c cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/getline.c cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/getstr.c cc -O2 -pipe -DHAVE_CONFIG_H -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/lib -I/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar/../../../contrib/tar/src -c /tinderbox/CURRENT/sparc64/sparc64/src/contrib/tar/lib/hash.c {standard input}: Assembler messages: {standard input}:1283: Error: Illegal operands *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/tar. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/gnu. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-06-19 12:48:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-06-19 12:48:18 - ERROR: failed to build world TB --- 2004-06-19 12:48:18 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Sat Jun 19 22:53:41 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 8E0AD16A4CE for ; Sat, 19 Jun 2004 22:53:41 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by mx1.FreeBSD.org (Postfix) with SMTP id 3146B43D48 for ; Sat, 19 Jun 2004 22:53:41 +0000 (GMT) (envelope-from drosihn@gmail.com) Received: by mproxy.gmail.com with SMTP id d78so175022rnf for ; Sat, 19 Jun 2004 15:53:21 -0700 (PDT) Received: by 10.38.9.50 with SMTP id 50mr84863rni; Sat, 19 Jun 2004 15:46:41 -0700 (PDT) Message-ID: <97880ae0406191546208772a8@mail.gmail.com> Date: Sat, 19 Jun 2004 18:46:41 -0400 From: Garance A Drosehn To: freebsd-sparc64@freebsd.org, Thomas Moestl In-Reply-To: <20040616161217.GA57659@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040616161217.GA57659@dragon.nuxi.com> Subject: Re: ** HEADS UP ** DO NOT UPDATE and 'make world' YOUR SPARCS X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2004 22:53:41 -0000 On Wed, 16 Jun 2004, David O'Brien wrote: > > I've hit an issue that I suspect can render your machine useless if you > install a new binutils. > > I suggest not installing a new userland world until you see the "ALL > CLEAR". So, is it safe to do a new buildworld/installworld after the fixes that were recently committed by Thomas? I "rushed" (*) a sparc64 buildworld together as soon as I saw that commit, but the new kernel panic'ed when I tried to boot into it. So, I didn't even get far enough to install the new userland. That panic might have been an error on my part, but I thought I would ask before making another attempt. (* - well, as much as I can "rush" a buildworld on an Ultra-10...)