From owner-freebsd-sparc64@FreeBSD.ORG Sun Jan 3 01:28:28 2010 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A5BD1065670; Sun, 3 Jan 2010 01:28:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 39AB58FC0A; Sun, 3 Jan 2010 01:28:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o031SRss070689; Sat, 2 Jan 2010 20:28:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o031SRwr070677; Sun, 3 Jan 2010 01:28:27 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Jan 2010 01:28:27 GMT Message-Id: <201001030128.o031SRwr070677@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2010 01:28:28 -0000 TB --- 2010-01-03 00:18:35 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-03 00:18:35 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-01-03 00:18:35 - cleaning the object tree TB --- 2010-01-03 00:18:54 - cvsupping the source tree TB --- 2010-01-03 00:18:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-01-03 00:20:08 - building world TB --- 2010-01-03 00:20:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-03 00:20:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-03 00:20:08 - TARGET=sparc64 TB --- 2010-01-03 00:20:08 - TARGET_ARCH=sparc64 TB --- 2010-01-03 00:20:08 - TZ=UTC TB --- 2010-01-03 00:20:08 - __MAKE_CONF=/dev/null TB --- 2010-01-03 00:20:08 - cd /src TB --- 2010-01-03 00:20:08 - /usr/bin/make -B buildworld >>> World build started on Sun Jan 3 00:20:08 UTC 2010 >>> 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 >>> World build completed on Sun Jan 3 01:16:43 UTC 2010 TB --- 2010-01-03 01:16:43 - generating LINT kernel config TB --- 2010-01-03 01:16:43 - cd /src/sys/sparc64/conf TB --- 2010-01-03 01:16:43 - /usr/bin/make -B LINT TB --- 2010-01-03 01:16:43 - building LINT kernel TB --- 2010-01-03 01:16:43 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-03 01:16:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-03 01:16:43 - TARGET=sparc64 TB --- 2010-01-03 01:16:43 - TARGET_ARCH=sparc64 TB --- 2010-01-03 01:16:43 - TZ=UTC TB --- 2010-01-03 01:16:43 - __MAKE_CONF=/dev/null TB --- 2010-01-03 01:16:43 - cd /src TB --- 2010-01-03 01:16:43 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jan 3 01:16:43 UTC 2010 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror vnode_if.c :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror vers.c linking kernel init_sysent.o(.data+0x4088): undefined reference to `freebsd4_sigreturn' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-03 01:28:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-03 01:28:27 - ERROR: failed to build lint kernel TB --- 2010-01-03 01:28:27 - 3183.65 user 631.47 system 4191.59 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Mon Jan 4 11:07:06 2010 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36FFE1065697 for ; Mon, 4 Jan 2010 11:07:06 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 257788FC1E for ; Mon, 4 Jan 2010 11:07:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o04B76aq065021 for ; Mon, 4 Jan 2010 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o04B75nc065019 for freebsd-sparc64@FreeBSD.org; Mon, 4 Jan 2010 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Jan 2010 11:07:05 GMT Message-Id: <201001041107.o04B75nc065019@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2010 11:07:06 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/142102 sparc64 [nfs] [panic] FreeBSD 8.0 kernel panics on sparc64 whe s sparc/139134 sparc64 kernel output corruption f sparc/127051 sparc64 [hme] hme interfaces "pause" with the message "device o sparc/119244 sparc64 X11Forwarding to X11 server on sparc crashes Xorg o sparc/119240 sparc64 top has WCPU over 100% on UP system s sparc/119239 sparc64 gdb coredumps on sparc64 o sparc/113556 sparc64 [panic] trap: memory address not aligned; Rebooting... f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 s sparc/107087 sparc64 [hang] system is hung during boot from CD o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/80890 sparc64 [panic] kmem_malloc(73728): kmem_map too small running o sparc/80410 sparc64 [netgraph] netgraph is causing crash with mpd on sparc o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC 14 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Tue Jan 5 19:15:18 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50EC91065695 for ; Tue, 5 Jan 2010 19:15:18 +0000 (UTC) (envelope-from carton@Ivy.NET) Received: from sakima.Ivy.NET (sakima.Ivy.NET [69.31.131.60]) by mx1.freebsd.org (Postfix) with ESMTP id DA65A8FC1D for ; Tue, 5 Jan 2010 19:15:17 +0000 (UTC) Received: from castrovalva.Ivy.NET (castrovalva.Ivy.NET [69.31.131.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sakima.Ivy.NET (Postfix) with ESMTP id AACF5A8093 for ; Tue, 5 Jan 2010 14:15:16 -0500 (EST) Received: by castrovalva.Ivy.NET (Postfix, from userid 405) id 8E55812FD0D; Tue, 5 Jan 2010 14:15:16 -0500 (EST) To: freebsd-sparc64@freebsd.org References: <20091228135607.GA6907@mech-cluster241.men.bris.ac.uk> <20091228142338.GA7058@mech-cluster241.men.bris.ac.uk> <20091228185459.cbe38564.torfinn.ingolfsen@broadpark.no> <20091229104852.GA15327@mech-cluster241.men.bris.ac.uk> From: Miles Nordin MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Tue_Jan__5_14:15:06_2010-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 05 Jan 2010 14:15:15 -0500 In-Reply-To: Anton Shterenlikht's message of "Mon, 28 Dec 2009 14:23:38 +0000" Message-ID: User-Agent: T-gnus/6.17.2 (based on No Gnus v0.2) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.4 (alpha--netbsd) MULE/5.0 (SAKAKI) Subject: Re: usb mount error: g_vfs_done():da0s1[READ(offset=512, length=8192)]error = 5 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 19:15:18 -0000 --pgp-sign-Multipart_Tue_Jan__5_14:15:06_2010-1 Content-Type: text/plain; charset=US-ASCII >>>>> "as" == Anton Shterenlikht writes: as> worry that some config information could be on the card as as> well, the loss of which will make is unusable by the camera? what? no. If the card is removeable, then the camera can always format it. How else would you expect to buy a new storage card and use it? that said, if you don't care about the data, why fsck? fsck is not guaranteed to succeed. If you instead reformat the card (using the camera's format button) you've eliminated a variable---if FreeBSD can't read a freshly-formatted card, it's broken. and THAT said, if two different FreeBSD architectures behave differently w.r.t. reading the card, woudln't the problem be in FreeBSD rather than the filesystem? I have been using the a-data trio cards because they have SDHC on the front and USB on the back, so you get two chances for your crappy regression-filled operating system to work with it. however in other circumstances i've had problems with the wear leveling software running inside the card, and one of the cards with which i had problems had a-data stamped on it, so I'm not recommending them, just mentioning that the tool exists. as> I'll see if I can get hold of the manual, thank you. There's nothing in manuals anymore except congradulations-for-buying and a bunch of CYA disclaimers like ``please do not chew on the cord while sitting in the bath'' and ``contains mercury and cadmium and can never be thrown away, ever.'' The manual is basically an advertisment. The only way I've managed to learn more about my camera is to either find an extrememly smart 23-year-old girl (these ones are impossibly rare, but if you can find one they always find spookily weird features), or a professional photographer (who will have lots of friends who share tricks), who has the exact same camera and spy on them very closely while they're using it. so...welcome to the future, good luck trying to live here, take lots of photos!!!1! :( --pgp-sign-Multipart_Tue_Jan__5_14:15:06_2010-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (NetBSD) iQCVAwUAS0OPw4nCBbTaW/4dAQJbsQP5AfLCm7mLma6yNEhrj+Q27QRN0UBFh/US v7nVflHDeGmkmmIH8YojvhpFVeZK5skALfKogR73zv7jmbDXaDa/m3jd12dPHEZj tqhzivycqyKm3BYdnMCiS7Wi8xa5bkFvUpi0fj7elo3Is/feBQom9qlTRcj2Ojhm rrDSWK+5bpY= =bqYE -----END PGP SIGNATURE----- --pgp-sign-Multipart_Tue_Jan__5_14:15:06_2010-1-- From owner-freebsd-sparc64@FreeBSD.ORG Tue Jan 5 20:24:25 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 697E01065670 for ; Tue, 5 Jan 2010 20:24:25 +0000 (UTC) (envelope-from simon.griffiths@tenenbaum.co.uk) Received: from mail.tenenbaum.co.uk (87-194-142-21.bethere.co.uk [87.194.142.21]) by mx1.freebsd.org (Postfix) with ESMTP id 2114B8FC0C for ; Tue, 5 Jan 2010 20:24:25 +0000 (UTC) Received: from ion (unknown [192.168.1.16]) by mail.tenenbaum.co.uk (Postfix) with ESMTP id 8D05361C36; Tue, 5 Jan 2010 20:24:23 +0000 (GMT) From: "Simon Griffiths" To: "'Anton Shterenlikht'" , "'Andrew Belashov'" References: <20091215162601.GA22008@mech-cluster241.men.bris.ac.uk> <4B2B72E4.4060808@orel.ru> <20091218134058.GA89230@mech-cluster241.men.bris.ac.uk> In-Reply-To: <20091218134058.GA89230@mech-cluster241.men.bris.ac.uk> Date: Tue, 5 Jan 2010 20:24:26 -0000 Message-ID: <007701ca8e45$13b977d0$3b2c6770$@griffiths@tenenbaum.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqAqmm4JNsL07NUThCOr1Of6NJeXgNmoQYg Content-Language: en-gb Cc: gnome@freebsd.org, freebsd-sparc64@freebsd.org, freebsd-ports@freebsd.org Subject: RE: port devel/gobject-introspection fails to build on sparc X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 20:24:25 -0000 Hello, > -----Original Message----- > From: owner-freebsd-sparc64@freebsd.org [mailto:owner-freebsd- > sparc64@freebsd.org] On Behalf Of Anton Shterenlikht > Sent: 18 December 2009 13:41 > To: Andrew Belashov > Cc: gnome@freebsd.org; freebsd-sparc64@freebsd.org; freebsd- > ports@freebsd.org > Subject: Re: port devel/gobject-introspection fails to build on sparc > > On Fri, Dec 18, 2009 at 03:17:40PM +0300, Andrew Belashov wrote: > ** > ERROR:ginfo.c:337:g_base_info_get_name: code should not be reached > gmake[3]: *** [foo-1.0.tgir] Abort trap: 6 (core dumped) > gmake[3]: *** Deleting file `foo-1.0.tgir' > gmake[3]: Leaving directory `/usr/ports/devel/gobject- > introspection/work/gobject > -introspection-0.6.6/tests/scanner' > gmake[2]: *** [all-recursive] Error 1 > > > > -- > Anton Shterenlikht > Room 2.6, Queen's Building > Mech Eng Dept > Bristol University > University Walk, Bristol BS8 1TR, UK > Tel: +44 (0)117 331 5944 > Fax: +44 (0)117 929 4423 Did you find a way around this problem Anton? Many Thanks, Si. From owner-freebsd-sparc64@FreeBSD.ORG Tue Jan 5 22:00:37 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C836106568F; Tue, 5 Jan 2010 22:00:37 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id C6E638FC14; Tue, 5 Jan 2010 22:00:36 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-8-131.flashcable.ch [91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id o05M0SOh065148; Tue, 5 Jan 2010 23:00:29 +0100 (CET) (envelope-from andreast-list@fgznet.ch) Message-ID: <4B43B67C.60802@fgznet.ch> Date: Tue, 05 Jan 2010 23:00:28 +0100 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Simon Griffiths References: <20091215162601.GA22008@mech-cluster241.men.bris.ac.uk> <4B2B72E4.4060808@orel.ru> <20091218134058.GA89230@mech-cluster241.men.bris.ac.uk> <007701ca8e45$13b977d0$3b2c6770$@griffiths@tenenbaum.co.uk> In-Reply-To: <007701ca8e45$13b977d0$3b2c6770$@griffiths@tenenbaum.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: gnome@freebsd.org, freebsd-sparc64@freebsd.org, freebsd-ports@freebsd.org Subject: Re: port devel/gobject-introspection fails to build on sparc X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 22:00:37 -0000 On 05.01.10 21:24, Simon Griffiths wrote: > Hello, > >> -----Original Message----- >> From: owner-freebsd-sparc64@freebsd.org [mailto:owner-freebsd- >> sparc64@freebsd.org] On Behalf Of Anton Shterenlikht >> Sent: 18 December 2009 13:41 >> To: Andrew Belashov >> Cc: gnome@freebsd.org; freebsd-sparc64@freebsd.org; freebsd- >> ports@freebsd.org >> Subject: Re: port devel/gobject-introspection fails to build on sparc >> >> On Fri, Dec 18, 2009 at 03:17:40PM +0300, Andrew Belashov wrote: >> ** >> ERROR:ginfo.c:337:g_base_info_get_name: code should not be reached >> gmake[3]: *** [foo-1.0.tgir] Abort trap: 6 (core dumped) >> gmake[3]: *** Deleting file `foo-1.0.tgir' >> gmake[3]: Leaving directory `/usr/ports/devel/gobject- >> introspection/work/gobject >> -introspection-0.6.6/tests/scanner' >> gmake[2]: *** [all-recursive] Error 1 >> >> >> >> -- >> Anton Shterenlikht >> Room 2.6, Queen's Building >> Mech Eng Dept >> Bristol University >> University Walk, Bristol BS8 1TR, UK >> Tel: +44 (0)117 331 5944 >> Fax: +44 (0)117 929 4423 > > Did you find a way around this problem Anton? > I ran into the same issue and in my situation it was enough to satisfy the dependency issue. So I commented the assert in ginfo.c around line 337. This is not _the_ solution, but for me it was enough. Andreas From owner-freebsd-sparc64@FreeBSD.ORG Tue Jan 5 23:30:53 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B19A5106566C; Tue, 5 Jan 2010 23:30:53 +0000 (UTC) (envelope-from simon.griffiths@tenenbaum.co.uk) Received: from mail.tenenbaum.co.uk (87-194-142-21.bethere.co.uk [87.194.142.21]) by mx1.freebsd.org (Postfix) with ESMTP id 687DE8FC15; Tue, 5 Jan 2010 23:30:53 +0000 (UTC) Received: from ion (unknown [192.168.1.16]) by mail.tenenbaum.co.uk (Postfix) with ESMTP id E8FB061C36; Tue, 5 Jan 2010 23:30:51 +0000 (GMT) From: "Simon Griffiths" To: "'Andreas Tobler'" References: <20091215162601.GA22008@mech-cluster241.men.bris.ac.uk> <4B2B72E4.4060808@orel.ru> <20091218134058.GA89230@mech-cluster241.men.bris.ac.uk> <007701ca8e45$13b977d0$3b2c6770$@griffiths@tenenbaum.co.uk> <4B43B67C.60802@fgznet.ch> In-Reply-To: <4B43B67C.60802@fgznet.ch> Date: Tue, 5 Jan 2010 23:30:55 -0000 Message-ID: <009101ca8e5f$207ef930$617ceb90$@griffiths@tenenbaum.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqOUqICkg2czLE2TvmtGbrMvwT0zwADEuVQ Content-Language: en-gb Cc: gnome@freebsd.org, freebsd-sparc64@freebsd.org, freebsd-ports@freebsd.org Subject: RE: port devel/gobject-introspection fails to build on sparc X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 23:30:53 -0000 > -----Original Message----- > From: owner-freebsd-ports@freebsd.org [mailto:owner-freebsd- > ports@freebsd.org] On Behalf Of Andreas Tobler > Sent: 05 January 2010 22:00 > To: Simon Griffiths > Cc: gnome@freebsd.org; 'Anton Shterenlikht'; freebsd- > sparc64@freebsd.org; freebsd-ports@freebsd.org; 'Andrew Belashov' > Subject: Re: port devel/gobject-introspection fails to build on sparc > > > Did you find a way around this problem Anton? > > > > I ran into the same issue and in my situation it was enough to satisfy > the dependency issue. So I commented the assert in ginfo.c around line > 337. > This is not _the_ solution, but for me it was enough. > > Andreas Cool, that worked, thanks! Cheers, Si. From owner-freebsd-sparc64@FreeBSD.ORG Wed Jan 6 13:10:46 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A0B41065670; Wed, 6 Jan 2010 13:10:46 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 5198A8FC0C; Wed, 6 Jan 2010 13:10:45 +0000 (UTC) Received: from seis.bris.ac.uk ([137.222.10.93]) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1NSVer-0007IS-B3; Wed, 06 Jan 2010 13:10:44 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by seis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1NSVeq-00030X-8G; Wed, 06 Jan 2010 13:10:40 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id o06DAdq8022970; Wed, 6 Jan 2010 13:10:40 GMT (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.3/8.14.3/Submit) id o06DAdmk022969; Wed, 6 Jan 2010 13:10:39 GMT (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Wed, 6 Jan 2010 13:10:39 +0000 From: Anton Shterenlikht To: Simon Griffiths Message-ID: <20100106131039.GE15440@mech-cluster241.men.bris.ac.uk> References: <20091215162601.GA22008@mech-cluster241.men.bris.ac.uk> <4B2B72E4.4060808@orel.ru> <20091218134058.GA89230@mech-cluster241.men.bris.ac.uk> <007701ca8e45$13b977d0$3b2c6770$@griffiths@tenenbaum.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007701ca8e45$13b977d0$3b2c6770$@griffiths@tenenbaum.co.uk> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -4.5 X-Spam-Level: ---- Cc: gnome@freebsd.org, freebsd-sparc64@freebsd.org, freebsd-ports@freebsd.org Subject: Re: port devel/gobject-introspection fails to build on sparc X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 13:10:46 -0000 On Tue, Jan 05, 2010 at 08:24:26PM -0000, Simon Griffiths wrote: > Hello, > > > -----Original Message----- > > From: owner-freebsd-sparc64@freebsd.org [mailto:owner-freebsd- > > sparc64@freebsd.org] On Behalf Of Anton Shterenlikht > > Sent: 18 December 2009 13:41 > > To: Andrew Belashov > > Cc: gnome@freebsd.org; freebsd-sparc64@freebsd.org; freebsd- > > ports@freebsd.org > > Subject: Re: port devel/gobject-introspection fails to build on sparc > > > > On Fri, Dec 18, 2009 at 03:17:40PM +0300, Andrew Belashov wrote: > > ** > > ERROR:ginfo.c:337:g_base_info_get_name: code should not be reached > > gmake[3]: *** [foo-1.0.tgir] Abort trap: 6 (core dumped) > > gmake[3]: *** Deleting file `foo-1.0.tgir' > > gmake[3]: Leaving directory `/usr/ports/devel/gobject- > > introspection/work/gobject > > -introspection-0.6.6/tests/scanner' > > gmake[2]: *** [all-recursive] Error 1 > > > > > > > > -- > > Anton Shterenlikht > > Room 2.6, Queen's Building > > Mech Eng Dept > > Bristol University > > University Walk, Bristol BS8 1TR, UK > > Tel: +44 (0)117 331 5944 > > Fax: +44 (0)117 929 4423 > > Did you find a way around this problem Anton? no, but I haven't tried too hard. I'm trying again right now and will report back. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-sparc64@FreeBSD.ORG Thu Jan 7 14:45:59 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B750106566B for ; Thu, 7 Jan 2010 14:45:59 +0000 (UTC) (envelope-from zwendell@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 9346C8FC18 for ; Thu, 7 Jan 2010 14:45:58 +0000 (UTC) Received: by fxm27 with SMTP id 27so3749951fxm.3 for ; Thu, 07 Jan 2010 06:45:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=hq+xxsP0Hk6H27dwQKNwRyPDmQlGcmZsKirX1IsztVo=; b=XvALr4u0qqz6HleAfMDPhwAhqykgTp6uVGzjMoZBqhEhnpNMiR2Yu1UhR9S9DRwuso 1SL3RQIgyQhN9YLEPdAe6SYy+UGf7JExtnkHYhH3kLWXqPu3tkdl5h86CLY3h6NM6pDv uMbn9epsQH01284TRVgNuuesL7TPn4qRngeQ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=KxY73sTFksWJHUid0g96wp3D3u7zBskEzWR6DSvZ47+/O4qQdVB74XCeq2R9+Qw4gA iS3A7KHMJOU3UyfF0zbcAb1ipyv3iz10Id86LQyUki5RyBNlR0lb7R/+qFo/WhwP5/oO XTL0Nl+7qe4G5Q8C7VA8b8nOh+d1LR9ZHb60g= MIME-Version: 1.0 Received: by 10.239.167.66 with SMTP id f2mr972478hbe.143.1262874138169; Thu, 07 Jan 2010 06:22:18 -0800 (PST) From: Zach Wendell Date: Thu, 7 Jan 2010 09:21:58 -0500 Message-ID: To: freebsd-sparc64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Sun Netra X1 -- LOM: errors after clearing ram, etc. X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 14:45:59 -0000 Anyone have any ideas about the LOM output below? Just keeps spitting out the same thing over and over... Currently there are no drives installed (waiting for a coworker to bring in an extra HDD and CD-ROM drive so we can install BSD), but there is a stick of non-ECC PC133, 128MB ram installed. I have 3 sticks of non-ECC PC133, and one stick of non-ECC PC100 ram, all 128MB. 2 of them immediately throw a "no memory installed, will not proceed" error -- obviously those are bad (or most likely). The other 2 do what you'll see below... So far, I've only tried one stick at a time, to rule out bad combos, etc. Thanks in advance! ~zmw lom> LOM event: +0h31m28s host power on ` Processor Speed = [Speed Jumper = 7] 400 MHz Baud rate is 9600 8 Data bits, 1 stop bits, no parity (configured from lom) Firmware CORE Sun Microsystems, Inc. @(#) core 1.0.1 2001/02/19 09:55 Hardware Power ON Verifying NVRAM...Done Bootmode is 0 MCR0 = 36a0b004 MCR1 = c0804000 MCR2 = f110006 MCR3 = 6 Ecache Size = 256 KB NVRAM Test Icache Test Dcache Test MMU Test Ecache Tag Addr Test Ecache RAM Addr Test Clearing E$ Tags Done Clearing I/D TLBs Done Probing memory Done MEMBASE=0x0 MEMSIZE=0x8000000 Data Line Test Core Memory Test Processor Speed = 400 MHz Baud rate is 9600 8 Data bits, 1 stop bits, no parity (configured from lom) Firmware CORE Sun Microsystems, Inc. @(#) core 1.0.1 2001/02/19 09:55 Software Power ON Verifying NVRAM...Done Bootmode is 0 MCR0 = 36a0b004 MCR1 = c0804000 MCR2 = f110006 MCR3 = 6 Ecache Size = 256 KB Clearing E$ Tags Done Clearing I/D TLBs Done Probing memory Done MEMBASE=0x0 MEMSIZE=0x8000000 Clearing memory...Done Turing ON MMUs Done Copy ROM to RAM (148440 bytes) Done Orig PC=0x1fff0007efc New PC=0xf0f07f54 ****************************** **************** PSTATE=0000000000000015 TBA=00000000f0f00000 DCU Control=0000000000000000 AFSR=0000000000000000 AFAR=ffffffffffffffb8 PIL=000000000000000f I-SFSR=00000000000010a2 D-SFSR=000000000004002b D-SFAR=00000000000007ff TL=0005 TT=00c0 TPC=00000000f0f0b3f0 TNPC=00000000f0f0b3f4 TL=0004 TT=0034 TPC=00000000f0f05800 TNPC=00000000f0f05804 TL=0003 TT=00c0 TPC=00000000f0f0b3f0 TNPC=00000000f0f0b3f4 TL=0002 TT=0010 TPC=00000000f0f0b3f4 TNPC=00000000f0f0b3f8 TL=0001 TT=0010 TPC=00000000f0f0a42c TNPC=00000000f0f0a430 ********************************************** ********************************************** PSTATE=0000000000000015 TBA=00000000f0000000 DCU Control=0000000000000000 AFSR=0000000000000000 AFAR=ffffffffffffffb8 PIL=000000000000000f I-SFSR=00000000000010a2 D-SFSR=000000000004002b D-SFAR=00000000000007ff TL=0005 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 TL=0004 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 TL=0003 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 TL=0002 TT=0010 TPC=00000000f0000204 TNPC=0000000114800200 TL=0001 TT=0010 TPC=00000000f0003a04 TNPC=00000000f0003a08 ********************************************** ********************************************** PSTATE=0000000000000015 TBA=00000000f0000000 DCU Control=0000000000000000 AFSR=0000000000000000 AFAR=ffffffffffffffb8 PIL=000000000000000f I-SFSR=00000000000010a2 D-SFSR=000000000004002b D-SFAR=00000000000007ff TL=0005 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 TL=0004 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 TL=0003 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 TL=0002 TT=0010 TPC=00000000f0000204 TNPC=0000000114800200 TL=0001 TT=0010 TPC=00000000f0003a04 TNPC=00000000f0003a08 ********************************************** ********************************************** PSTATE=0000000000000015 TBA=00000000f0000000 DCU Control=0000000000000000 AFSR=0000000000000000 AFAR=ffffffffffffffb8 PIL=000000000000000f I-SFSR=00000000000010a2 D-SFSR=000000000004002b D-SFAR=00000000000007ff TL=0005 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 TL=0004 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 TL=0003 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 TL=0002 TT=0010 TPC=00000000f0000204 TNPC=0000000114800200 TL=0001 TT=0010 TPC=00000000f0003a04 TNPC=00000000f0003a08 ********************************************** ********************************************** PSTATE=0000000000000015 TBA=00000000f0000000 DCU Control=0000000000000000 AFSR=0000000000000000 AFAR=ffffffffffffffb8 PIL=000000000000000f I-SFSR=00000000000010a2 D-SFSR=000000000004002b D-SFAR=00000000000007ff TL=0005 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 TL=0004 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 TL=0003 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 TL=0002 TT=0010 TPC=00000000f0000204 TNPC=0000000114800200 TL=0001 TT=0010 TPC=00000000f0003a04 TNPC=00000000f0003a08 ********************************************** ********************************************** PSTATE=0000000000000015 TBA=00000000f0000000 DCU Control=0000000000000000 AFSR=0000000000000000 AFAR=ffffffffffffffb8 PIL=000000000000000f I-SFSR=00000000000010a2 D-SFSR=000000000004002b D-SFAR=00000000000007ff TL=0005 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 TL=0| lom> LOM event: +0h33m5s host power off lom> From owner-freebsd-sparc64@FreeBSD.ORG Fri Jan 8 13:49:44 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E7751065697 for ; Fri, 8 Jan 2010 13:49:44 +0000 (UTC) (envelope-from bradd@ameri.ca) Received: from compton.ameri.ca (compton.ameri.ca [IPv6:2001:418:8005::21]) by mx1.freebsd.org (Postfix) with ESMTP id AD6628FC1E for ; Fri, 8 Jan 2010 13:49:43 +0000 (UTC) Received: from mushroom.ameri.ca (mushroom.ameri.ca [IPv6:2001:418:8004::167]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: bradd) by compton.ameri.ca (Postfix) with ESMTPSA id 89BCF1FB9B8 for ; Fri, 8 Jan 2010 13:49:31 +0000 (UTC) From: brad dreisbach Content-Type: text/plain; charset=us-ascii Message-Id: <0334FB50-D299-4723-A36A-0228EC062D34@ameri.ca> Date: Fri, 8 Jan 2010 08:49:30 -0500 To: freebsd-sparc64@freebsd.org Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: smbfs X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 13:49:44 -0000 what is the status of smbfs support in the sparc64 port? From owner-freebsd-sparc64@FreeBSD.ORG Fri Jan 8 21:46:05 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6ABDE106566C for ; Fri, 8 Jan 2010 21:46:05 +0000 (UTC) (envelope-from craig001@lerwick.hopto.org) Received: from lerwick.hopto.org (81-178-20-70.dsl.pipex.com [81.178.20.70]) by mx1.freebsd.org (Postfix) with ESMTP id 695C58FC1C for ; Fri, 8 Jan 2010 21:46:03 +0000 (UTC) Received: (qmail 96762 invoked by uid 98); 8 Jan 2010 21:57:43 +0000 Received: from 192.168.0.100 by polaris.lerwick.hopto.org (envelope-from , uid 82) with qmail-scanner-2.01 (clamdscan: 0.95.1/9971. hbedv: 7.9.1.53/7.1.6.174. spamassassin: 3.2.5. Clear:RC:1(192.168.0.100):. Processed in 4.148983 secs); 08 Jan 2010 21:57:43 -0000 Received: from unknown (HELO x60.lerwick.hopto.org) (192.168.0.100) by lerwick.hopto.org with SMTP; 8 Jan 2010 21:57:39 +0000 Message-ID: <4B47A7A7.9060503@lerwick.hopto.org> Date: Fri, 08 Jan 2010 21:46:15 +0000 From: Craig Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20091221 Lightning/1.0b2pre Thunderbird/3.0 MIME-Version: 1.0 To: Zach Wendell References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-sparc64@freebsd.org Subject: Re: Sun Netra X1 -- LOM: errors after clearing ram, etc. X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 21:46:05 -0000 On 07/01/2010 14:21, Zach Wendell wrote: > Anyone have any ideas about the LOM output below? Just keeps spitting out > the same thing over and over... > > Currently there are no drives installed (waiting for a coworker to bring in > an extra HDD and CD-ROM drive so we can install BSD), but there is a stick > of non-ECC PC133, 128MB ram installed. > > I have 3 sticks of non-ECC PC133, and one stick of non-ECC PC100 ram, all > 128MB. 2 of them immediately throw a "no memory installed, will not proceed" > error -- obviously those are bad (or most likely). The other 2 do what > you'll see below... So far, I've only tried one stick at a time, to rule out > bad combos, etc. > > Thanks in advance! > ~zmw > > > > > > lom> > LOM event: +0h31m28s host power on > ` > Processor Speed = [Speed Jumper = 7] 400 MHz Baud rate is 9600 > 8 Data bits, 1 stop bits, no parity (configured from lom) > > Firmware CORE Sun Microsystems, Inc. > @(#) core 1.0.1 2001/02/19 09:55 > Hardware Power ON > Verifying NVRAM...Done > Bootmode is 0 > MCR0 = 36a0b004 > MCR1 = c0804000 > MCR2 = f110006 > MCR3 = 6 > Ecache Size = 256 KB > NVRAM Test > Icache Test > Dcache Test > MMU Test > Ecache Tag Addr Test > Ecache RAM Addr Test > Clearing E$ Tags Done > Clearing I/D TLBs Done > Probing memory > Done > MEMBASE=0x0 > MEMSIZE=0x8000000 > Data Line Test > Core Memory Test > > Processor Speed = 400 MHz > Baud rate is 9600 > 8 Data bits, 1 stop bits, no parity (configured from lom) > > Firmware CORE Sun Microsystems, Inc. > @(#) core 1.0.1 2001/02/19 09:55 > Software Power ON > Verifying NVRAM...Done > Bootmode is 0 > MCR0 = 36a0b004 > MCR1 = c0804000 > MCR2 = f110006 > MCR3 = 6 > Ecache Size = 256 KB > Clearing E$ Tags Done > Clearing I/D TLBs Done > Probing memory > Done > MEMBASE=0x0 > MEMSIZE=0x8000000 > Clearing memory...Done > Turing ON MMUs Done > Copy ROM to RAM (148440 bytes) Done > Orig PC=0x1fff0007efc New PC=0xf0f07f54 > > ****************************** > **************** > PSTATE=0000000000000015 TBA=00000000f0f00000 DCU > Control=0000000000000000 > AFSR=0000000000000000 AFAR=ffffffffffffffb8 PIL=000000000000000f > I-SFSR=00000000000010a2 D-SFSR=000000000004002b D-SFAR=00000000000007ff > TL=0005 TT=00c0 TPC=00000000f0f0b3f0 TNPC=00000000f0f0b3f4 > TL=0004 TT=0034 TPC=00000000f0f05800 TNPC=00000000f0f05804 > TL=0003 TT=00c0 TPC=00000000f0f0b3f0 TNPC=00000000f0f0b3f4 > TL=0002 TT=0010 TPC=00000000f0f0b3f4 TNPC=00000000f0f0b3f8 > TL=0001 TT=0010 TPC=00000000f0f0a42c TNPC=00000000f0f0a430 > ********************************************** > > ********************************************** > PSTATE=0000000000000015 TBA=00000000f0000000 DCU > Control=0000000000000000 > AFSR=0000000000000000 AFAR=ffffffffffffffb8 PIL=000000000000000f > I-SFSR=00000000000010a2 D-SFSR=000000000004002b D-SFAR=00000000000007ff > TL=0005 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 > TL=0004 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 > TL=0003 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 > TL=0002 TT=0010 TPC=00000000f0000204 TNPC=0000000114800200 > TL=0001 TT=0010 TPC=00000000f0003a04 TNPC=00000000f0003a08 > ********************************************** > > ********************************************** > PSTATE=0000000000000015 TBA=00000000f0000000 DCU > Control=0000000000000000 > AFSR=0000000000000000 AFAR=ffffffffffffffb8 PIL=000000000000000f > I-SFSR=00000000000010a2 D-SFSR=000000000004002b D-SFAR=00000000000007ff > TL=0005 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 > TL=0004 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 > TL=0003 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 > TL=0002 TT=0010 TPC=00000000f0000204 TNPC=0000000114800200 > TL=0001 TT=0010 TPC=00000000f0003a04 TNPC=00000000f0003a08 > ********************************************** > > ********************************************** > PSTATE=0000000000000015 TBA=00000000f0000000 DCU > Control=0000000000000000 > AFSR=0000000000000000 AFAR=ffffffffffffffb8 PIL=000000000000000f > I-SFSR=00000000000010a2 D-SFSR=000000000004002b D-SFAR=00000000000007ff > TL=0005 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 > TL=0004 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 > TL=0003 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 > TL=0002 TT=0010 TPC=00000000f0000204 TNPC=0000000114800200 > TL=0001 TT=0010 TPC=00000000f0003a04 TNPC=00000000f0003a08 > ********************************************** > > ********************************************** > PSTATE=0000000000000015 TBA=00000000f0000000 DCU > Control=0000000000000000 > AFSR=0000000000000000 AFAR=ffffffffffffffb8 PIL=000000000000000f > I-SFSR=00000000000010a2 D-SFSR=000000000004002b D-SFAR=00000000000007ff > TL=0005 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 > TL=0004 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 > TL=0003 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 > TL=0002 TT=0010 TPC=00000000f0000204 TNPC=0000000114800200 > TL=0001 TT=0010 TPC=00000000f0003a04 TNPC=00000000f0003a08 > ********************************************** > > ********************************************** > PSTATE=0000000000000015 TBA=00000000f0000000 DCU > Control=0000000000000000 > AFSR=0000000000000000 AFAR=ffffffffffffffb8 PIL=000000000000000f > I-SFSR=00000000000010a2 D-SFSR=000000000004002b D-SFAR=00000000000007ff > TL=0005 TT=0010 TPC=00000000f0004200 TNPC=00000000f0004204 > TL=0| > lom> > LOM event: +0h33m5s host power off > lom> > _______________________________________________ > 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" > I've seen the same on mine... turned out to be bad memory... It doesn't like mixed speeds and I think they got to be in matched pairs... I could be wrong tho ! Cheers Craig B From owner-freebsd-sparc64@FreeBSD.ORG Fri Jan 8 22:10:27 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2389110656CB for ; Fri, 8 Jan 2010 22:10:27 +0000 (UTC) (envelope-from kimble@spmpx220.com) Received: from T1.tash.net (t1.tash.net [192.160.132.52]) by mx1.freebsd.org (Postfix) with ESMTP id D868D8FC0C for ; Fri, 8 Jan 2010 22:10:26 +0000 (UTC) Received: from [127.0.0.1] (97-123-227-198.albq.qwest.net [97.123.227.198]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kcc@spmpx220.com) by T1.tash.net (Postfix) with ESMTPSA id BA2C92BD8029; Fri, 8 Jan 2010 14:54:39 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: kimble In-Reply-To: <4B47A7A7.9060503@lerwick.hopto.org> Date: Fri, 8 Jan 2010 14:54:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B47A7A7.9060503@lerwick.hopto.org> To: Craig Butler X-Mailer: Apple Mail (2.1077) Cc: freebsd-sparc64@freebsd.org Subject: Re: Sun Netra X1 -- LOM: errors after clearing ram, etc. X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 22:10:27 -0000 try putting some PC133 ECC/Registered memory in it... the X1 doesnt like = NON-ECC/non registered ram . On Jan 8, 2010, at 2:46 PM, Craig Butler wrote: > On 07/01/2010 14:21, Zach Wendell wrote: >> Anyone have any ideas about the LOM output below? Just keeps spitting = out >> the same thing over and over... >>=20 >> Currently there are no drives installed (waiting for a coworker to = bring in >> an extra HDD and CD-ROM drive so we can install BSD), but there is a = stick >> of non-ECC PC133, 128MB ram installed. >>=20 >> I have 3 sticks of non-ECC PC133, and one stick of non-ECC PC100 ram, = all >> 128MB. 2 of them immediately throw a "no memory installed, will not = proceed" >> error -- obviously those are bad (or most likely). The other 2 do = what >> you'll see below... So far, I've only tried one stick at a time, to = rule out >> bad combos, etc. >>=20 >> Thanks in advance! >> ~zmw >>=20 >>=20 >>=20 >>=20 >>=20 >> lom> >> LOM event: +0h31m28s host power on >> ` >> Processor Speed =3D [Speed Jumper =3D 7] 400 MHz Baud rate is 9600 >> 8 Data bits, 1 stop bits, no parity (configured from lom) >>=20 >> Firmware CORE Sun Microsystems, Inc. >> @(#) core 1.0.1 2001/02/19 09:55 >> Hardware Power ON >> Verifying NVRAM...Done >> Bootmode is 0 >> MCR0 =3D 36a0b004 >> MCR1 =3D c0804000 >> MCR2 =3D f110006 >> MCR3 =3D 6 >> Ecache Size =3D 256 KB >> NVRAM Test >> Icache Test >> Dcache Test >> MMU Test >> Ecache Tag Addr Test >> Ecache RAM Addr Test >> Clearing E$ Tags Done >> Clearing I/D TLBs Done >> Probing memory >> Done >> MEMBASE=3D0x0 >> MEMSIZE=3D0x8000000 >> Data Line Test >> Core Memory Test >>=20 >> Processor Speed =3D 400 MHz >> Baud rate is 9600 >> 8 Data bits, 1 stop bits, no parity (configured from lom) >>=20 >> Firmware CORE Sun Microsystems, Inc. >> @(#) core 1.0.1 2001/02/19 09:55 >> Software Power ON >> Verifying NVRAM...Done >> Bootmode is 0 >> MCR0 =3D 36a0b004 >> MCR1 =3D c0804000 >> MCR2 =3D f110006 >> MCR3 =3D 6 >> Ecache Size =3D 256 KB >> Clearing E$ Tags Done >> Clearing I/D TLBs Done >> Probing memory >> Done >> MEMBASE=3D0x0 >> MEMSIZE=3D0x8000000 >> Clearing memory...Done >> Turing ON MMUs Done >> Copy ROM to RAM (148440 bytes) Done >> Orig PC=3D0x1fff0007efc New PC=3D0xf0f07f54 >>=20 >> ****************************** >> **************** >> PSTATE=3D0000000000000015 TBA=3D00000000f0f00000 DCU >> Control=3D0000000000000000 >> AFSR=3D0000000000000000 AFAR=3Dffffffffffffffb8 = PIL=3D000000000000000f >> I-SFSR=3D00000000000010a2 D-SFSR=3D000000000004002b = D-SFAR=3D00000000000007ff >> TL=3D0005 TT=3D00c0 TPC=3D00000000f0f0b3f0 = TNPC=3D00000000f0f0b3f4 >> TL=3D0004 TT=3D0034 TPC=3D00000000f0f05800 = TNPC=3D00000000f0f05804 >> TL=3D0003 TT=3D00c0 TPC=3D00000000f0f0b3f0 = TNPC=3D00000000f0f0b3f4 >> TL=3D0002 TT=3D0010 TPC=3D00000000f0f0b3f4 = TNPC=3D00000000f0f0b3f8 >> TL=3D0001 TT=3D0010 TPC=3D00000000f0f0a42c = TNPC=3D00000000f0f0a430 >> ********************************************** >>=20 >> ********************************************** >> PSTATE=3D0000000000000015 TBA=3D00000000f0000000 DCU >> Control=3D0000000000000000 >> AFSR=3D0000000000000000 AFAR=3Dffffffffffffffb8 = PIL=3D000000000000000f >> I-SFSR=3D00000000000010a2 D-SFSR=3D000000000004002b = D-SFAR=3D00000000000007ff >> TL=3D0005 TT=3D0010 TPC=3D00000000f0004200 = TNPC=3D00000000f0004204 >> TL=3D0004 TT=3D0010 TPC=3D00000000f0004200 = TNPC=3D00000000f0004204 >> TL=3D0003 TT=3D0010 TPC=3D00000000f0004200 = TNPC=3D00000000f0004204 >> TL=3D0002 TT=3D0010 TPC=3D00000000f0000204 = TNPC=3D0000000114800200 >> TL=3D0001 TT=3D0010 TPC=3D00000000f0003a04 = TNPC=3D00000000f0003a08 >> ********************************************** >>=20 >> ********************************************** >> PSTATE=3D0000000000000015 TBA=3D00000000f0000000 DCU >> Control=3D0000000000000000 >> AFSR=3D0000000000000000 AFAR=3Dffffffffffffffb8 = PIL=3D000000000000000f >> I-SFSR=3D00000000000010a2 D-SFSR=3D000000000004002b = D-SFAR=3D00000000000007ff >> TL=3D0005 TT=3D0010 TPC=3D00000000f0004200 = TNPC=3D00000000f0004204 >> TL=3D0004 TT=3D0010 TPC=3D00000000f0004200 = TNPC=3D00000000f0004204 >> TL=3D0003 TT=3D0010 TPC=3D00000000f0004200 = TNPC=3D00000000f0004204 >> TL=3D0002 TT=3D0010 TPC=3D00000000f0000204 = TNPC=3D0000000114800200 >> TL=3D0001 TT=3D0010 TPC=3D00000000f0003a04 = TNPC=3D00000000f0003a08 >> ********************************************** >>=20 >> ********************************************** >> PSTATE=3D0000000000000015 TBA=3D00000000f0000000 DCU >> Control=3D0000000000000000 >> AFSR=3D0000000000000000 AFAR=3Dffffffffffffffb8 = PIL=3D000000000000000f >> I-SFSR=3D00000000000010a2 D-SFSR=3D000000000004002b = D-SFAR=3D00000000000007ff >> TL=3D0005 TT=3D0010 TPC=3D00000000f0004200 = TNPC=3D00000000f0004204 >> TL=3D0004 TT=3D0010 TPC=3D00000000f0004200 = TNPC=3D00000000f0004204 >> TL=3D0003 TT=3D0010 TPC=3D00000000f0004200 = TNPC=3D00000000f0004204 >> TL=3D0002 TT=3D0010 TPC=3D00000000f0000204 = TNPC=3D0000000114800200 >> TL=3D0001 TT=3D0010 TPC=3D00000000f0003a04 = TNPC=3D00000000f0003a08 >> ********************************************** >>=20 >> ********************************************** >> PSTATE=3D0000000000000015 TBA=3D00000000f0000000 DCU >> Control=3D0000000000000000 >> AFSR=3D0000000000000000 AFAR=3Dffffffffffffffb8 = PIL=3D000000000000000f >> I-SFSR=3D00000000000010a2 D-SFSR=3D000000000004002b = D-SFAR=3D00000000000007ff >> TL=3D0005 TT=3D0010 TPC=3D00000000f0004200 = TNPC=3D00000000f0004204 >> TL=3D0004 TT=3D0010 TPC=3D00000000f0004200 = TNPC=3D00000000f0004204 >> TL=3D0003 TT=3D0010 TPC=3D00000000f0004200 = TNPC=3D00000000f0004204 >> TL=3D0002 TT=3D0010 TPC=3D00000000f0000204 = TNPC=3D0000000114800200 >> TL=3D0001 TT=3D0010 TPC=3D00000000f0003a04 = TNPC=3D00000000f0003a08 >> ********************************************** >>=20 >> ********************************************** >> PSTATE=3D0000000000000015 TBA=3D00000000f0000000 DCU >> Control=3D0000000000000000 >> AFSR=3D0000000000000000 AFAR=3Dffffffffffffffb8 = PIL=3D000000000000000f >> I-SFSR=3D00000000000010a2 D-SFSR=3D000000000004002b = D-SFAR=3D00000000000007ff >> TL=3D0005 TT=3D0010 TPC=3D00000000f0004200 = TNPC=3D00000000f0004204 >> TL=3D0| >> lom> >> LOM event: +0h33m5s host power off >> lom> >> _______________________________________________ >> 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" >> =20 > I've seen the same on mine... turned out to be bad memory... It = doesn't like mixed speeds and I think they got to be in matched pairs... > I could be wrong tho ! >=20 > Cheers >=20 > Craig B >=20 >=20 > _______________________________________________ > 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 Fri Jan 8 22:23:39 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E37B106566C for ; Fri, 8 Jan 2010 22:23:39 +0000 (UTC) (envelope-from druid628@comcast.net) Received: from mail.arsecommerce.com (static-host-66-18-33-249.epbinternet.com [66.18.33.249]) by mx1.freebsd.org (Postfix) with ESMTP id 694548FC16 for ; Fri, 8 Jan 2010 22:23:38 +0000 (UTC) Received: from [192.168.166.76] (EatAtJoes.ars.chatt [192.168.166.76]) by mail.arsecommerce.com (Postfix) with ESMTPA id 427EF90676 for ; Fri, 8 Jan 2010 17:08:32 -0500 (EST) Message-ID: <4B47ACC6.6090701@comcast.net> Date: Fri, 08 Jan 2010 17:08:06 -0500 From: DruiD User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8pre) Gecko/20100108 Shredder/3.0.1pre MIME-Version: 1.0 To: freebsd-sparc64@freebsd.org References: <4B47A7A7.9060503@lerwick.hopto.org> In-Reply-To: <4B47A7A7.9060503@lerwick.hopto.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Sun Netra X1 -- LOM: errors after clearing ram, etc. X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 22:23:39 -0000 Ditto, I had issues with bad ram in my netra x1 and the messages I had resembled the ones you are seeing. Sort-of keeping with the topic at hand, but has anyone else who has FreeBSD installed on a netra x1 had any issues with the time accuracy . I've installed Freebsd 7.2 on my netra x1 and the time in the LOM seems to be off by a few hours and I can't seem to correct it. Anyone else run into this and/or resolved it? Thanks -mb /* Micah Breedlove * druid628@comcast.net */ CONFIDENTIALITY: This email (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you received this email in error, please notify the sender and delete this email from your system. Thank you. On 01/08/2010 04:46 PM, Craig Butler wrote: > On 07/01/2010 14:21, Zach Wendell wrote: >> Anyone have any ideas about the LOM output below? Just keeps spitting >> out >> the same thing over and over... >> >> Currently there are no drives installed (waiting for a coworker to >> bring in >> an extra HDD and CD-ROM drive so we can install BSD), but there is a >> stick >> of non-ECC PC133, 128MB ram installed. >> >> I have 3 sticks of non-ECC PC133, and one stick of non-ECC PC100 ram, >> all >> 128MB. 2 of them immediately throw a "no memory installed, will not >> proceed" >> error -- obviously those are bad (or most likely). The other 2 do what >> you'll see below... So far, I've only tried one stick at a time, to >> rule out >> bad combos, etc. >> >> Thanks in advance! >> ~zmw >> >> >> >> >> >> lom> >> LOM event: +0h31m28s host power on >> ` >> Processor Speed = [Speed Jumper = 7] 400 MHz Baud rate is 9600 >> 8 Data bits, 1 stop bits, no parity (configured from lom) >> >> Firmware CORE Sun Microsystems, Inc. >> @(#) core 1.0.1 2001/02/19 09:55 >> Hardware Power ON >> Verifying NVRAM...Done >> Bootmode is 0 >> MCR0 = 36a0b004 >> MCR1 = c0804000 >> MCR2 = f110006 >> MCR3 = 6 >> Ecache Size = 256 KB >> NVRAM Test >> Icache Test >> Dcache Test >> MMU Test >> Ecache Tag Addr Test >> Ecache RAM Addr Test >> Clearing E$ Tags Done >> Clearing I/D TLBs Done >> Probing memory >> Done >> MEMBASE=0x0 >> MEMSIZE=0x8000000 >> Data Line Test >> Core Memory Test >> >> Processor Speed = 400 MHz >> Baud rate is 9600 >> 8 Data bits, 1 stop bits, no parity (configured from lom) >> >> Firmware CORE Sun Microsystems, Inc. >> @(#) core 1.0.1 2001/02/19 09:55 >> Software Power ON >> Verifying NVRAM...Done >> Bootmode is 0 >> MCR0 = 36a0b004 >> MCR1 = c0804000 >> MCR2 = f110006 >> MCR3 = 6 >> Ecache Size = 256 KB >> Clearing E$ Tags Done >> Clearing I/D TLBs Done >> Probing memory >> Done >> MEMBASE=0x0 >> MEMSIZE=0x8000000 >> Clearing memory...Done >> Turing ON MMUs Done >> Copy ROM to RAM (148440 bytes) Done >> Orig PC=0x1fff0007efc New PC=0xf0f07f54 >> [[ Omitted to shorten reply email -mb ]] >> lom> >> LOM event: +0h33m5s host power off >> lom> >> _______________________________________________ >> 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" > I've seen the same on mine... turned out to be bad memory... It > doesn't like mixed speeds and I think they got to be in matched pairs... > I could be wrong tho ! > > Cheers > > Craig B > > > _______________________________________________ > 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 Fri Jan 8 22:37:55 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 757EE106566B for ; Fri, 8 Jan 2010 22:37:55 +0000 (UTC) (envelope-from zwendell@gmail.com) Received: from mail-qy0-f176.google.com (mail-qy0-f176.google.com [209.85.221.176]) by mx1.freebsd.org (Postfix) with ESMTP id 2A34B8FC16 for ; Fri, 8 Jan 2010 22:37:55 +0000 (UTC) Received: by qyk6 with SMTP id 6so8465648qyk.3 for ; Fri, 08 Jan 2010 14:37:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=tD4oX9re2psqrszI1D+Vkt1e2TQNw3JQh2D/ZXm9vXs=; b=Q4vKI1Eb76yLQLZdMcCkiFHN/RYXs6nGXRpcWTv/QS7STOWXkWY0PlhqPBKbQuj9Em sZbA26eMzZ9Wd1fOPmPal4SpHh4gU5yTDN+Eo87SfDQwAWVOV+j81+JUziI0Ep1Yfn0d t5PqRFL6/CFaurSx1ABDjYTvASImr4SbMJ4bI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=anTGo9CclBmPvpR+3w+H+2v3gW46EKTrNmj4DDsKsyf/gdqBdQXFbSd4lbb1Qw3hrL WRSNuVHyhNi9RbhlzYZ9U5k0uiGOG0v3KbN0Ku6k+F68GBH/LRY2tArpLZtdcSMDN+nS M365R9cxXfcvxMN8y0FUlcLafKHYw2aQyw9Vo= Received: by 10.224.114.9 with SMTP id c9mr14806830qaq.281.1262990269364; Fri, 08 Jan 2010 14:37:49 -0800 (PST) Received: from ?10.1.33.24? (cpe-74-74-204-143.rochester.res.rr.com [74.74.204.143]) by mx.google.com with ESMTPS id 7sm13562825qwf.4.2010.01.08.14.37.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 08 Jan 2010 14:37:46 -0800 (PST) References: <4B47A7A7.9060503@lerwick.hopto.org> <4B47ACC6.6090701@comcast.net> Message-Id: <91C2430A-E630-4B98-A395-5087DA8A4776@gmail.com> From: Zach Wendell To: DruiD In-Reply-To: <4B47ACC6.6090701@comcast.net> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Fri, 8 Jan 2010 17:37:41 -0500 Cc: "freebsd-sparc64@freebsd.org" Subject: Re: Sun Netra X1 -- LOM: errors after clearing ram, etc. X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 22:37:55 -0000 I think there's a known bug for that -- saw it on sun's website. On Jan 8, 2010, at 5:08 PM, DruiD wrote: > Ditto, I had issues with bad ram in my netra x1 and the messages I > had resembled the ones you are seeing. > > Sort-of keeping with the topic at hand, but has anyone else who has > FreeBSD installed on a netra x1 had any issues with the time > accuracy . > > I've installed Freebsd 7.2 on my netra x1 and the time in the LOM > seems to be off by a few hours and I can't seem to correct it. > Anyone else run into this and/or resolved it? > > Thanks > -mb > > /* Micah Breedlove > * druid628@comcast.net > */ > > CONFIDENTIALITY: This email (including any attachments) may contain > confidential, proprietary and privileged information, and > unauthorized disclosure or use is prohibited. If you received this > email in error, please notify the sender and delete this email from > your system. Thank you. > > > > On 01/08/2010 04:46 PM, Craig Butler wrote: >> On 07/01/2010 14:21, Zach Wendell wrote: >>> Anyone have any ideas about the LOM output below? Just keeps >>> spitting out >>> the same thing over and over... >>> >>> Currently there are no drives installed (waiting for a coworker to >>> bring in >>> an extra HDD and CD-ROM drive so we can install BSD), but there is >>> a stick >>> of non-ECC PC133, 128MB ram installed. >>> >>> I have 3 sticks of non-ECC PC133, and one stick of non-ECC PC100 >>> ram, all >>> 128MB. 2 of them immediately throw a "no memory installed, will >>> not proceed" >>> error -- obviously those are bad (or most likely). The other 2 do >>> what >>> you'll see below... So far, I've only tried one stick at a time, >>> to rule out >>> bad combos, etc. >>> >>> Thanks in advance! >>> ~zmw >>> >>> >>> >>> >>> >>> lom> >>> LOM event: +0h31m28s host power on >>> ` >>> Processor Speed = [Speed Jumper = 7] 400 MHz Baud rate is 9600 >>> 8 Data bits, 1 stop bits, no parity (configured from lom) >>> >>> Firmware CORE Sun Microsystems, Inc. >>> @(#) core 1.0.1 2001/02/19 09:55 >>> Hardware Power ON >>> Verifying NVRAM...Done >>> Bootmode is 0 >>> MCR0 = 36a0b004 >>> MCR1 = c0804000 >>> MCR2 = f110006 >>> MCR3 = 6 >>> Ecache Size = 256 KB >>> NVRAM Test >>> Icache Test >>> Dcache Test >>> MMU Test >>> Ecache Tag Addr Test >>> Ecache RAM Addr Test >>> Clearing E$ Tags Done >>> Clearing I/D TLBs Done >>> Probing memory >>> Done >>> MEMBASE=0x0 >>> MEMSIZE=0x8000000 >>> Data Line Test >>> Core Memory Test >>> >>> Processor Speed = 400 MHz >>> Baud rate is 9600 >>> 8 Data bits, 1 stop bits, no parity (configured from lom) >>> >>> Firmware CORE Sun Microsystems, Inc. >>> @(#) core 1.0.1 2001/02/19 09:55 >>> Software Power ON >>> Verifying NVRAM...Done >>> Bootmode is 0 >>> MCR0 = 36a0b004 >>> MCR1 = c0804000 >>> MCR2 = f110006 >>> MCR3 = 6 >>> Ecache Size = 256 KB >>> Clearing E$ Tags Done >>> Clearing I/D TLBs Done >>> Probing memory >>> Done >>> MEMBASE=0x0 >>> MEMSIZE=0x8000000 >>> Clearing memory...Done >>> Turing ON MMUs Done >>> Copy ROM to RAM (148440 bytes) Done >>> Orig PC=0x1fff0007efc New PC=0xf0f07f54 >>> [[ Omitted to shorten reply email -mb ]] >>> lom> >>> LOM event: +0h33m5s host power off >>> lom> >>> _______________________________________________ >>> 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 >>> " >> I've seen the same on mine... turned out to be bad memory... It >> doesn't like mixed speeds and I think they got to be in matched >> pairs... >> I could be wrong tho ! >> >> Cheers >> >> Craig B >> >> >> _______________________________________________ >> 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 >> " >> > _______________________________________________ > 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 Sat Jan 9 15:40:07 2010 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 998051065679 for ; Sat, 9 Jan 2010 15:40:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6F1538FC2B for ; Sat, 9 Jan 2010 15:40:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o09Fe7FT057276 for ; Sat, 9 Jan 2010 15:40:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o09Fe7ER057275; Sat, 9 Jan 2010 15:40:07 GMT (envelope-from gnats) Date: Sat, 9 Jan 2010 15:40:07 GMT Message-Id: <201001091540.o09Fe7ER057275@freefall.freebsd.org> To: freebsd-sparc64@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: sparc64/142102: commit references a PR X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 15:40:07 -0000 The following reply was made to PR sparc64/142102; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: sparc64/142102: commit references a PR Date: Sat, 9 Jan 2010 15:31:43 +0000 (UTC) Author: marius Date: Sat Jan 9 15:31:27 2010 New Revision: 201896 URL: http://svn.freebsd.org/changeset/base/201896 Log: Exclude options COMPAT_FREEBSD4 now that the MD freebsd4_sigreturn() is gone since r201396 and which is also in line with the fact that FreeBSD 4 didn't supported sparc64. PR: 142102 (second part) MFC after: 1 week Modified: head/sys/nfsserver/nfs.h head/sys/nfsserver/nfs_fha.c head/sys/nfsserver/nfs_srvkrpc.c Modified: head/sys/nfsserver/nfs.h ============================================================================== --- head/sys/nfsserver/nfs.h Sat Jan 9 14:56:38 2010 (r201895) +++ head/sys/nfsserver/nfs.h Sat Jan 9 15:31:27 2010 (r201896) @@ -240,6 +240,7 @@ extern int nfs_debug; #endif +void nfs_realign(struct mbuf **); struct mbuf *nfs_rephead(int, struct nfsrv_descript *, int, struct mbuf **, caddr_t *); void nfsm_srvfattr(struct nfsrv_descript *, struct vattr *, Modified: head/sys/nfsserver/nfs_fha.c ============================================================================== --- head/sys/nfsserver/nfs_fha.c Sat Jan 9 14:56:38 2010 (r201895) +++ head/sys/nfsserver/nfs_fha.c Sat Jan 9 15:31:27 2010 (r201896) @@ -158,9 +158,9 @@ SYSUNINIT(nfs_fha, SI_SUB_ROOT_CONF, SI_ static void fha_extract_info(struct svc_req *req, struct fha_info *i) { - struct mbuf *md = req->rq_args; + struct mbuf *md; nfsfh_t fh; - caddr_t dpos = mtod(md, caddr_t); + caddr_t dpos; static u_int64_t random_fh = 0; int error; int v3 = (req->rq_vers == 3); @@ -201,6 +201,10 @@ fha_extract_info(struct svc_req *req, st procnum == NFSPROC_NULL) goto out; + nfs_realign(&req->rq_args); + md = req->rq_args; + dpos = mtod(md, caddr_t); + /* Grab the filehandle. */ error = nfsm_srvmtofh_xx(&fh.fh_generic, v3, &md, &dpos); if (error) Modified: head/sys/nfsserver/nfs_srvkrpc.c ============================================================================== --- head/sys/nfsserver/nfs_srvkrpc.c Sat Jan 9 14:56:38 2010 (r201895) +++ head/sys/nfsserver/nfs_srvkrpc.c Sat Jan 9 15:31:27 2010 (r201896) @@ -266,7 +266,7 @@ nfs_rephead(int siz, struct nfsrv_descri * not occur with NFS/UDP and is supposed to only occassionally occur * with TCP. Use vfs.nfs.realign_count and realign_test to check this. */ -static void +void nfs_realign(struct mbuf **pm) /* XXX COMMON */ { struct mbuf *m; _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-sparc64@FreeBSD.ORG Sat Jan 9 16:00:15 2010 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 118351065670 for ; Sat, 9 Jan 2010 16:00:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F31368FC0A for ; Sat, 9 Jan 2010 16:00:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o09G0EKo073606 for ; Sat, 9 Jan 2010 16:00:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o09G0Ea8073600; Sat, 9 Jan 2010 16:00:14 GMT (envelope-from gnats) Date: Sat, 9 Jan 2010 16:00:14 GMT Message-Id: <201001091600.o09G0Ea8073600@freefall.freebsd.org> To: freebsd-sparc64@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: sparc64/142102: commit references a PR X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 16:00:15 -0000 The following reply was made to PR sparc64/142102; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: sparc64/142102: commit references a PR Date: Sat, 9 Jan 2010 15:59:24 +0000 (UTC) Author: marius Date: Sat Jan 9 15:59:15 2010 New Revision: 201899 URL: http://svn.freebsd.org/changeset/base/201899 Log: Some style(9) fixes in order to fabricate a commit to denote that the commit message for r201896 actually should have read: As nfsm_srvmtofh_xx() assumes the 4-byte alignment required by XDR ensure the mbuf data is aligned accordingly by calling nfs_realign() in fha_extract_info(). This fix is orthogonal to the problem solved by r199274/r199284. PR: 142102 (second part) MFC after: 1 week Modified: head/sys/nfsserver/nfs.h head/sys/nfsserver/nfs_fha.c head/sys/nfsserver/nfs_srvkrpc.c Modified: head/sys/nfsserver/nfs.h ============================================================================== --- head/sys/nfsserver/nfs.h Sat Jan 9 15:43:47 2010 (r201898) +++ head/sys/nfsserver/nfs.h Sat Jan 9 15:59:15 2010 (r201899) @@ -82,14 +82,13 @@ #define IO_METASYNC 0 #endif - /* NFS state flags XXX -Wunused */ #define NFSRV_SNDLOCK 0x01000000 /* Send socket lock */ #define NFSRV_WANTSND 0x02000000 /* Want above */ /* - * Structures for the nfssvc(2) syscall. Not that anyone but nfsd and mount_nfs - * should ever try and use it. + * Structures for the nfssvc(2) syscall. Not that anyone but nfsd and + * mount_nfs should ever try and use it. */ /* Modified: head/sys/nfsserver/nfs_fha.c ============================================================================== --- head/sys/nfsserver/nfs_fha.c Sat Jan 9 15:43:47 2010 (r201898) +++ head/sys/nfsserver/nfs_fha.c Sat Jan 9 15:59:15 2010 (r201899) @@ -71,16 +71,17 @@ static struct fha_global { u_long hashmask; } g_fha; -/* - * These are the entries in the filehandle hash. They talk about a specific - * file, requests against which are being handled by one or more nfsds. We keep - * a chain of nfsds against the file. We only have more than one if reads are - * ongoing, and then only if the reads affect disparate regions of the file. +/* + * These are the entries in the filehandle hash. They talk about a specific + * file, requests against which are being handled by one or more nfsds. We + * keep a chain of nfsds against the file. We only have more than one if reads + * are ongoing, and then only if the reads affect disparate regions of the + * file. * - * In general, we want to assign a new request to an existing nfsd if it is - * going to contend with work happening already on that nfsd, or if the - * operation is a read and the nfsd is already handling a proximate read. We - * do this to avoid jumping around in the read stream unnecessarily, and to + * In general, we want to assign a new request to an existing nfsd if it is + * going to contend with work happening already on that nfsd, or if the + * operation is a read and the nfsd is already handling a proximate read. We + * do this to avoid jumping around in the read stream unnecessarily, and to * avoid contention between threads over single files. */ struct fha_hash_entry { @@ -101,7 +102,7 @@ struct fha_info { }; static int fhe_stats_sysctl(SYSCTL_HANDLER_ARGS); - + static void nfs_fha_init(void *foo) { @@ -136,7 +137,7 @@ nfs_fha_init(void *foo) &fha_ctls.max_reqs_per_nfsd, 0, "Maximum requests that " "single nfsd thread should be working on at any time"); - SYSCTL_ADD_OID(&fha_clist, SYSCTL_STATIC_CHILDREN(_vfs_nfsrv_fha), + SYSCTL_ADD_OID(&fha_clist, SYSCTL_STATIC_CHILDREN(_vfs_nfsrv_fha), OID_AUTO, "fhe_stats", CTLTYPE_STRING | CTLFLAG_RD, 0, 0, fhe_stats_sysctl, "A", ""); } @@ -151,7 +152,7 @@ nfs_fha_uninit(void *foo) SYSINIT(nfs_fha, SI_SUB_ROOT_CONF, SI_ORDER_ANY, nfs_fha_init, NULL); SYSUNINIT(nfs_fha, SI_SUB_ROOT_CONF, SI_ORDER_ANY, nfs_fha_uninit, NULL); -/* +/* * This just specifies that offsets should obey affinity when within * the same 1Mbyte (1<<20) chunk for the file (reads only for now). */ @@ -167,18 +168,18 @@ fha_extract_info(struct svc_req *req, st u_int32_t *tl; rpcproc_t procnum; - /* - * We start off with a random fh. If we get a reasonable - * procnum, we set the fh. If there's a concept of offset + /* + * We start off with a random fh. If we get a reasonable + * procnum, we set the fh. If there's a concept of offset * that we're interested in, we set that. */ i->fh = ++random_fh; i->offset = 0; i->locktype = LK_EXCLUSIVE; - + /* * Extract the procnum and convert to v3 form if necessary, - * taking care to deal with out-of-range procnums. Caller will + * taking care to deal with out-of-range procnums. Caller will * ensure that rq_vers is either 2 or 3. */ procnum = req->rq_proc; @@ -188,19 +189,19 @@ fha_extract_info(struct svc_req *req, st procnum = nfsrv_nfsv3_procid[procnum]; } - /* - * We do affinity for most. However, we divide a realm of affinity - * by file offset so as to allow for concurrent random access. We - * only do this for reads today, but this may change when IFS supports + /* + * We do affinity for most. However, we divide a realm of affinity + * by file offset so as to allow for concurrent random access. We + * only do this for reads today, but this may change when IFS supports * efficient concurrent writes. */ if (procnum == NFSPROC_FSSTAT || procnum == NFSPROC_FSINFO || procnum == NFSPROC_PATHCONF || - procnum == NFSPROC_NOOP || + procnum == NFSPROC_NOOP || procnum == NFSPROC_NULL) goto out; - + nfs_realign(&req->rq_args); md = req->rq_args; dpos = mtod(md, caddr_t); @@ -270,8 +271,8 @@ fha_hash_entry_new(u_int64_t fh) e->num_writes = 0; e->num_threads = 0; LIST_INIT(&e->threads); - - return e; + + return (e); } static void @@ -296,10 +297,9 @@ fha_hash_entry_lookup(SVCPOOL *pool, u_i { struct fha_hash_entry *fhe, *new_fhe; - LIST_FOREACH(fhe, &g_fha.hashtable[fh % g_fha.hashmask], link) { + LIST_FOREACH(fhe, &g_fha.hashtable[fh % g_fha.hashmask], link) if (fhe->fh == fh) break; - } if (!fhe) { /* Allocate a new entry. */ @@ -308,25 +308,24 @@ fha_hash_entry_lookup(SVCPOOL *pool, u_i mtx_lock(&pool->sp_lock); /* Double-check to make sure we still need the new entry. */ - LIST_FOREACH(fhe, &g_fha.hashtable[fh % g_fha.hashmask], link) { + LIST_FOREACH(fhe, &g_fha.hashtable[fh % g_fha.hashmask], link) if (fhe->fh == fh) break; - } if (!fhe) { fhe = new_fhe; LIST_INSERT_HEAD(&g_fha.hashtable[fh % g_fha.hashmask], fhe, link); - } else { + } else fha_hash_entry_destroy(new_fhe); - } } - return fhe; + return (fhe); } static void fha_hash_entry_add_thread(struct fha_hash_entry *fhe, SVCTHREAD *thread) { + LIST_INSERT_HEAD(&fhe->threads, thread, st_alink); fhe->num_threads++; } @@ -339,7 +338,7 @@ fha_hash_entry_remove_thread(struct fha_ fhe->num_threads--; } -/* +/* * Account for an ongoing operation associated with this file. */ static void @@ -365,7 +364,7 @@ get_idle_thread(SVCPOOL *pool) } -/* +/* * Get the service thread currently associated with the fhe that is * appropriate to handle this operation. */ @@ -387,15 +386,15 @@ fha_hash_entry_choose_thread(SVCPOOL *po /* If there are any writes in progress, use the first thread. */ if (fhe->num_writes) { #if 0 - ITRACE_CURPROC(ITRACE_NFS, ITRACE_INFO, + ITRACE_CURPROC(ITRACE_NFS, ITRACE_INFO, "fha: %p(%d)w", thread, req_count); #endif return (thread); } - /* - * Check for read locality, making sure that we won't - * exceed our per-thread load limit in the process. + /* + * Check for read locality, making sure that we won't + * exceed our per-thread load limit in the process. */ offset1 = i->offset >> fha_ctls.bin_shift; offset2 = STAILQ_FIRST(&thread->st_reqs)->rq_p3 @@ -404,21 +403,21 @@ fha_hash_entry_choose_thread(SVCPOOL *po if ((fha_ctls.max_reqs_per_nfsd == 0) || (req_count < fha_ctls.max_reqs_per_nfsd)) { #if 0 - ITRACE_CURPROC(ITRACE_NFS, ITRACE_INFO, + ITRACE_CURPROC(ITRACE_NFS, ITRACE_INFO, "fha: %p(%d)r", thread, req_count); #endif return (thread); } } - /* + /* * We don't have a locality match, so skip this thread, - * but keep track of the most attractive thread in case + * but keep track of the most attractive thread in case * we need to come back to it later. */ #if 0 - ITRACE_CURPROC(ITRACE_NFS, ITRACE_INFO, - "fha: %p(%d)s off1 %llu off2 %llu", thread, + ITRACE_CURPROC(ITRACE_NFS, ITRACE_INFO, + "fha: %p(%d)s off1 %llu off2 %llu", thread, req_count, offset1, offset2); #endif if ((min_thread == NULL) || (req_count < min_count)) { @@ -427,38 +426,38 @@ fha_hash_entry_choose_thread(SVCPOOL *po } } - /* - * We didn't find a good match yet. See if we can add + /* + * We didn't find a good match yet. See if we can add * a new thread to this file handle entry's thread list. */ - if ((fha_ctls.max_nfsds_per_fh == 0) || + if ((fha_ctls.max_nfsds_per_fh == 0) || (fhe->num_threads < fha_ctls.max_nfsds_per_fh)) { - /* - * We can add a new thread, so try for an idle thread - * first, and fall back to this_thread if none are idle. + /* + * We can add a new thread, so try for an idle thread + * first, and fall back to this_thread if none are idle. */ if (STAILQ_EMPTY(&this_thread->st_reqs)) { thread = this_thread; #if 0 - ITRACE_CURPROC(ITRACE_NFS, ITRACE_INFO, + ITRACE_CURPROC(ITRACE_NFS, ITRACE_INFO, "fha: %p(%d)t", thread, thread->st_reqcount); #endif } else if ((thread = get_idle_thread(pool))) { #if 0 - ITRACE_CURPROC(ITRACE_NFS, ITRACE_INFO, + ITRACE_CURPROC(ITRACE_NFS, ITRACE_INFO, "fha: %p(%d)i", thread, thread->st_reqcount); #endif - } else { + } else { thread = this_thread; #if 0 - ITRACE_CURPROC(ITRACE_NFS, ITRACE_INFO, + ITRACE_CURPROC(ITRACE_NFS, ITRACE_INFO, "fha: %p(%d)b", thread, thread->st_reqcount); #endif } fha_hash_entry_add_thread(fhe, thread); } else { - /* - * We don't want to use any more threads for this file, so + /* + * We don't want to use any more threads for this file, so * go back to the most attractive nfsd we're already using. */ thread = min_thread; @@ -467,8 +466,8 @@ fha_hash_entry_choose_thread(SVCPOOL *po return (thread); } -/* - * After getting a request, try to assign it to some thread. Usually we +/* + * After getting a request, try to assign it to some thread. Usually we * handle it ourselves. */ SVCTHREAD * @@ -491,16 +490,16 @@ fha_assign(SVCTHREAD *this_thread, struc pool = req->rq_xprt->xp_pool; fha_extract_info(req, &i); - /* - * We save the offset associated with this request for later + /* + * We save the offset associated with this request for later * nfsd matching. */ fhe = fha_hash_entry_lookup(pool, i.fh); req->rq_p1 = fhe; req->rq_p2 = i.locktype; req->rq_p3 = i.offset; - - /* + + /* * Choose a thread, taking into consideration locality, thread load, * and the number of threads already working on this file. */ @@ -511,8 +510,8 @@ fha_assign(SVCTHREAD *this_thread, struc return (thread); } -/* - * Called when we're done with an operation. The request has already +/* + * Called when we're done with an operation. The request has already * been de-queued. */ void Modified: head/sys/nfsserver/nfs_srvkrpc.c ============================================================================== --- head/sys/nfsserver/nfs_srvkrpc.c Sat Jan 9 15:43:47 2010 (r201898) +++ head/sys/nfsserver/nfs_srvkrpc.c Sat Jan 9 15:59:15 2010 (r201899) @@ -187,19 +187,18 @@ nfssvc_nfsserver(struct thread *td, stru } error = nfssvc_addsock(fp, td); fdrop(fp, td); - } else if (uap->flag & NFSSVC_OLDNFSD) { + } else if (uap->flag & NFSSVC_OLDNFSD) error = nfssvc_nfsd(td, NULL); - } else if (uap->flag & NFSSVC_NFSD) { - if (!uap->argp) + else if (uap->flag & NFSSVC_NFSD) { + if (!uap->argp) return (EINVAL); error = copyin(uap->argp, (caddr_t)&nfsdarg, sizeof(nfsdarg)); if (error) return (error); error = nfssvc_nfsd(td, &nfsdarg); - } else { + } else error = ENXIO; - } return (error); } @@ -447,9 +446,8 @@ nfssvc_addsock(struct file *fp, struct t siz = sb_max_adj; error = soreserve(so, siz, siz); - if (error) { + if (error) return (error); - } /* * Steal the socket from userland so that it doesn't close @@ -471,7 +469,7 @@ nfssvc_addsock(struct file *fp, struct t } /* - * Called by nfssvc() for nfsds. Just loops around servicing rpc requests + * Called by nfssvc() for nfsds. Just loops around servicing rpc requests * until it is killed by a signal. */ static int @@ -496,9 +494,9 @@ nfssvc_nfsd(struct thread *td, struct nf #endif /* - * Only the first nfsd actually does any work. The RPC code - * adds threads to it as needed. Any extra processes offered - * by nfsd just exit. If nfsd is new enough, it will call us + * Only the first nfsd actually does any work. The RPC code + * adds threads to it as needed. Any extra processes offered + * by nfsd just exit. If nfsd is new enough, it will call us * once with a structure that specifies how many threads to * use. */ @@ -522,7 +520,7 @@ nfssvc_nfsd(struct thread *td, struct nf nfsrv_pool->sp_minthreads = 4; nfsrv_pool->sp_maxthreads = 4; } - + svc_run(nfsrv_pool); #ifdef KGSSAPI @@ -541,7 +539,7 @@ nfssvc_nfsd(struct thread *td, struct nf /* * Size the NFS server's duplicate request cache at 1/2 the - * nmbclusters, floating within a (64, 2048) range. This is to + * nmbclusters, floating within a (64, 2048) range. This is to * prevent all mbuf clusters being tied up in the NFS dupreq * cache for small values of nmbclusters. */ _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"