From owner-freebsd-sparc64@FreeBSD.ORG Sun Apr 18 01:53:09 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 4003716A4CE for ; Sun, 18 Apr 2004 01:53:09 -0700 (PDT) Received: from slacknet.slacknet.com (slacknet.slacknet.com [204.228.135.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C21C43D3F for ; Sun, 18 Apr 2004 01:53:09 -0700 (PDT) (envelope-from rj45@slacknet.com) Received: from rj45 (helo=localhost) by slacknet.slacknet.com with local-esmtp (Exim 4.30 #1 (Debian)) id 1BF832-00049u-Kb for ; Sun, 18 Apr 2004 02:53:08 -0600 Date: Sun, 18 Apr 2004 02:53:08 -0600 (MDT) From: RJ45 To: freebsd-sparc64@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Subject: watchdog reset 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: Sun, 18 Apr 2004 08:53:09 -0000 Hello, I wrote some time ago about this problem. I have sporadic watchdog reset errors and machine goes to PROM. I have ultra 60 dual 450MHz. Someone told me that it could be faulty hardware (RAM for example). Anyway this kind of error never occourred me with solaris 9 installed. So I ask here if someone else has this kind of sporadic problem with other ultra type of workstations. I added debug options to the kernel but I could not trace anything useful once the machine is in PROM I have to reset it and no kernel crash dump is written to the disk at boot time. sorry aagin for boring the list thanks Rick From owner-freebsd-sparc64@FreeBSD.ORG Mon Apr 19 01:13:50 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 966F116A4CE for ; Mon, 19 Apr 2004 01:13:50 -0700 (PDT) Received: from tts.orel.ru (tts.orel.ru [213.59.64.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F1E943D1D for ; Mon, 19 Apr 2004 01:13:48 -0700 (PDT) (envelope-from bel@orel.ru) Received: from orel.ru (lg.orel.ru [62.33.11.59]) by tts.orel.ru (8.12.10/8.12.10/bel) with ESMTP id i3J8DijP014073 for ; Mon, 19 Apr 2004 12:13:45 +0400 Message-ID: <40838A37.2050800@orel.ru> Date: Mon, 19 Apr 2004 12:13:43 +0400 From: Andrew Belashov Organization: ORIS User-Agent: Mozilla/5.0 (X11; U; FreeBSD sparc64; en-US; rv:1.6) Gecko/20040407 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: freebsd-sparc64@freebsd.org X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Zombi-Check: on netra2.orel.ru Subject: Re: watchdog reset 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, 19 Apr 2004 08:13:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! RJ45 wrote: | I wrote some time ago about this problem. | I have sporadic watchdog reset errors and machine goes to PROM. | I have ultra 60 dual 450MHz. | | Someone told me that it could be faulty hardware (RAM for example). | Anyway this kind of error never occourred me with solaris 9 installed. | | So I ask here if someone else has this kind of sporadic problem | with other ultra type of workstations. | | I added debug options to the kernel but I could not trace anything useful | once the machine is in PROM I have to reset it and no kernel crash dump | is written to the disk at boot time. Rebuild kernel without SMP option and try it. I have statistics for five phisical machines for period more of one year. Versions of FreeBSD from 5.0-RELEASE to CURRENT. | N |Machine | CPUs | SMP option | Stability +---+--------------+------+------------+----------------------- | 1 |Netra T1 105 | 1 | YES | Excellent | 2 |Netra T1 105 | 1 | YES | Excellent | 3 |Ultra 10 | 1 | YES | Excellent | 4a|Ultra 60 | 2 | YES | Bad | 4b|-//- | 2 | NO | Excellent | 5a|Ultra 60 | 2 | YES | Bad | 5b|-//- | 2 | NO | Excellent Ultra 60 periodical hard lookup when kernel build with SMP option :( Also, with option DDB (kernel debugger) kernel may by generate strange panic: =================================================================== panic: ipi_send: couldn't send ipi cpuid = 1; Debugger("panic") Stopped at Debugger+0x1c: ta %xcc, 1 db> trace panic() at panic+0x134 cpu_ipi_send() at cpu_ipi_send+0xb0 cpu_ipi_selected() at cpu_ipi_selected+0x38 tlb_page_demap() at tlb_page_demap+0x74 pmap_zero_page_idle() at pmap_zero_page_idle+0xe4 vm_page_zero_idle() at vm_page_zero_idle+0x74 vm_pagezero() at vm_pagezero+0xb4 fork_exit() at fork_exit+0x90 fork_trampoline() at fork_trampoline+0x8 =================================================================== With best regards, Andrew Belashov. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAg4o1wF8YpH80o/IRAuPHAJ9GA9X82kYl6HOzmg04cocuePzA+QCdH3oI dVX8wnq1QcLS4Ffj4/oALHU= =ojw1 -----END PGP SIGNATURE----- From owner-freebsd-sparc64@FreeBSD.ORG Mon Apr 19 09:17: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 1D6F016A4CE; Mon, 19 Apr 2004 09:17:31 -0700 (PDT) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7621A43D2F; Mon, 19 Apr 2004 09:17:30 -0700 (PDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CA9477303A; Mon, 19 Apr 2004 12:17:29 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040419161729.CA9477303A@freebsd-current.sentex.ca> Date: Mon, 19 Apr 2004 12:17:29 -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, 19 Apr 2004 16:17:31 -0000 TB --- 2004-04-19 11:08:55 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-04-19 11:08:55 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-04-19 11:08:55 - checking out the source tree TB --- 2004-04-19 11:08:55 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64 TB --- 2004-04-19 11:08:55 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-04-19 11:18:09 - building world (CFLAGS=-O2 -pipe) TB --- 2004-04-19 11:18:09 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src TB --- 2004-04-19 11:18:09 - /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-04-19 16:11:34 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-04-19 16:11:34 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src TB --- 2004-04-19 16:11:34 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Apr 19 16:11:36 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 [...] awk -f /other/tinderbox/CURRENT/sparc64/sparc64/src/sys/tools/makeobjops.awk /other/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/pci/pcib_if.m -h awk -f /other/tinderbox/CURRENT/sparc64/sparc64/src/sys/tools/makeobjops.awk /other/tinderbox/CURRENT/sparc64/sparc64/src/sys/isa/isa_if.m -h awk -f /other/tinderbox/CURRENT/sparc64/sparc64/src/sys/tools/makeobjops.awk /other/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/pci/ofw_pci_if.m -h if [ -f .olddep ]; then mv .olddep .depend; fi rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES -V GEN_M_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/other/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/other/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/other/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/other/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/other/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/other/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/other/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -mcmodel=medlow -msoft-float -ffreestanding /other/tinderbox/CURRENT/sparc64/sparc64/src/sys/cam/scsi/scsi_da.c:33:20: opt_da.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /other/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/other/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /other/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/other/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /other/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /other/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-04-19 16:17:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-04-19 16:17:29 - ERROR: failed to build generic kernel TB --- 2004-04-19 16:17:29 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Mon Apr 19 10:36:14 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 5B99C16A4CE for ; Mon, 19 Apr 2004 10:36:14 -0700 (PDT) Received: from ida.interface-business.de (ida.interface-business.de [193.101.57.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id D58A843D5A for ; Mon, 19 Apr 2004 10:36:11 -0700 (PDT) (envelope-from j@ida.interface-business.de) Received: by ida.interface-business.de (Postfix, from userid 107) id 1FE147A48; Mon, 19 Apr 2004 19:36:10 +0200 (MET DST) Date: Mon, 19 Apr 2004 19:36:10 +0200 From: Joerg Wunsch To: freebsd-sparc@freebsd.org Message-ID: <20040419193610.A40602@ida.interface-business.de> References: <20040415120849.B4638@ida.interface-business.de> <20040415101408.GB41902@beastie.b0rken.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040415101408.GB41902@beastie.b0rken.org>; from jason-freebsdlists@freebsd.org on Thu, Apr 15, 2004 at 11:14:08AM +0100 X-Phone: +49-351-31809-14 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Organization: interface systems GmbH, Dresden Subject: Re: 5.2.1 mini-ISO fails to boot on U450 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joerg Wunsch List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 17:36:14 -0000 [Sorry for the silence, but I haven't been subscribed to sparc64 until right now, so I didn't notice that reply.] As Jason Mann wrote: > > Fatal SCSI error at script address 8 Illegal instruction > > Drive not ready > > Sounds like you have a dead disk. Hmm, I doubt that. The machine has been running Solaris until it got retired. The only change since is that a few out of its dozen of drives have been removed. > Open the door on the front of the server and check the status LEDs > next to each disk. They were all lit as expected. Just out of curiosity, I've pulled all but one drive, but the same. I found a FreeBSD 5.1 boot CD-ROM, and it gets me a few more messages on the serial console but will eventually fail similarly: Boot device: /pci@1f,4000/scsi@2/disk@6,0:f File and args: >> FreeBSD/sparc64 boot block Boot path: /pci@1f,4000/scsi@2/disk@6,0:f Boot loader: /boot/loader Console: OpenFirmware console Boot path set to /pci@1f,4000/scsi@2/disk@6,0:a FreeBSD/sparc64 bootstrap loader, Revision 1.0 (fenner@sparkle.attlabs.net, Tue May 6 15:11:35 PDT 2003) bootpath="/pci@1f,4000/scsi@2/disk@6,0:a" [here the `twiddle' is spinning] Loading /boot/defaults/loader.conf Fatal SCSI error at script address 8 Illegal instruction Drive not ready How's the sparc64 CD-ROM organized, would it be possible to dd the entire image onto a hard disk (using a Solaris boot), and try booting off that hard drive, just to avoid the CD-ROM as the possible source of error? The drives itself are 4 GB Seagate Barracudas. The SCSI controllers are the standard Sym 53C876 (I believe) dual-channel controllers that used to be in the E450. Are there any requirements wrt. the OBP version? It probably hasn't been upgraded for a while... (it announces itself as 3.14). Here's the output of probe-scsi-all (with a single hard drive) for reference. {0} ok probe-scsi-all /pci@6,4000/scsi@4,1 /pci@6,4000/scsi@4 /pci@1f,4000/scsi@2 Target 5 Unit 0 Removable Tape EXABYTE EXB-8505SMBANSH20090 Target 6 Unit 0 Removable Read Only device TOSHIBA XM5701TASUN12XCD0997 /pci@1f,4000/scsi@3 Target 0 Unit 0 Disk SEAGATE ST34371W SUN4.2G7462 Just to make sure I've also dug up an old 8 mm tape medium and loaded it into the Exb drive, but still the same. :( -- J"org Wunsch Unix support engineer joerg_wunsch@interface-systems.de http://www.interface-systems.de/~j/ From owner-freebsd-sparc64@FreeBSD.ORG Mon Apr 19 11:01: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 47C8F16A4D3 for ; Mon, 19 Apr 2004 11:01:38 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 424E943D54 for ; Mon, 19 Apr 2004 11:01:38 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) i3JI1cbv042885 for ; Mon, 19 Apr 2004 11:01:38 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i3JI1blN042879 for freebsd-sparc64@freebsd.org; Mon, 19 Apr 2004 11:01:37 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 19 Apr 2004 11:01:37 -0700 (PDT) Message-Id: <200404191801.i3JI1blN042879@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, 19 Apr 2004 18:01:38 -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/20] 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/28] sparc64/62053sparc64 Using bridging on 5.2 Sparc64 causes imme 2 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2003/10/10] sparc64/57856sparc64 sparc64: IDE Raid controller no detect di 1 problem total. From owner-freebsd-sparc64@FreeBSD.ORG Mon Apr 19 11:10:19 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 5E3F716A4CE for ; Mon, 19 Apr 2004 11:10:19 -0700 (PDT) Received: from altsoftware.com (mx1.altsoftware.com [216.191.138.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11E5443D49 for ; Mon, 19 Apr 2004 11:10:19 -0700 (PDT) (envelope-from cflecknell@altsoftware.com) Received: from localhost (localhost [127.0.0.1]) by altsoftware.com (Postfix) with ESMTP id 72BCD3A1FB for ; Mon, 19 Apr 2004 14:10:17 -0400 (EDT) Received: from altsoftware.com ([127.0.0.1])port 10024) with ESMTP id 14808-11 for ; Mon, 19 Apr 2004 14:10:13 -0400 (EDT) Received: from to4cfleck (CPE0040052ee836-CM014290014636.cpe.net.cable.rogers.com [65.49.89.249]) by altsoftware.com (Postfix) with ESMTP id D9A7E3A1F5 for ; Mon, 19 Apr 2004 14:10:07 -0400 (EDT) From: "Chris Flecknell" To: Date: Mon, 19 Apr 2004 14:10:02 -0400 Message-ID: <002301c42639$89aa3080$c702a8c0@altsoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040419193610.A40602@ida.interface-business.de> X-Virus-Scanned: by amavisd-new at altsoftware.com Subject: Ultra 10 Panic - lockup 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, 19 Apr 2004 18:10:19 -0000 Can anyone give any insight to this? The system is an Ultra 10 - 440MHz, 512 Ram. The system will lockup completely and have this left displayed on the console. The system can sometimes stay up for as long as a number of days, or as short as a few minutes. I *think* it's most likely hardware related, but am not sure how I can find out. I have gone through the Boot tests and it's never found a problem. panic: trap: instruction access error at line 364 in file /usr/src/sys/sparc64/sparc64/trap.c cpuid = 0; syncing disks, buffers remaining... 3866 3866 RED State Exception TL=0000.0000.0000.0005 TT=0000.0000.0000.0080 TPC=0000.0000.c003.c208 TnPC=0000.0000.c003.c20c TSTATE=0000.0044.5800.1503 TL=0000.0000.0000.0004 TT=0000.0000.0000.0010 TPC=0000.0000.c004.0f20 TnPC=0000.0000.c004.0f24 TSTATE=0000.0044.5800.1503 TL=0000.0000.0000.0003 TT=0000.0000.0000.0010 TPC=0000.0000.c004.0f20 TnPC=0000.0000.c004.0f24 TSTATE=0000.0044.5800.1502 TL=0000.0000.0000.0002 TT=0000.0000.0000.0032 TPC=0000.0000.c004.0f8c TnPC=0000.0000.c004.0f90 TSTATE=0000.0044.5800.1601 TL=0000.0000.0000.0001 TT=0000.0000.0000.0141 TPC=0000.0000.4023.2884 TnPC=0000.0000.4023.2888 TSTATE=0000.0044.0000.1200 Any help with this would be greatly appreciated. Chris Flecknell System Administrator Alt Software Inc. cflecknell@altsoftware.com From owner-freebsd-sparc64@FreeBSD.ORG Mon Apr 19 11:13:28 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E10D16A4CE for ; Mon, 19 Apr 2004 11:13:28 -0700 (PDT) Received: from ida.interface-business.de (ida.interface-business.de [193.101.57.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D46B43D49 for ; Mon, 19 Apr 2004 11:13:28 -0700 (PDT) (envelope-from j@ida.interface-business.de) Received: by ida.interface-business.de (Postfix, from userid 107) id D71157A48; Mon, 19 Apr 2004 20:13:26 +0200 (MET DST) Date: Mon, 19 Apr 2004 20:13:26 +0200 From: Joerg Wunsch To: freebsd-sparc@freebsd.org Message-ID: <20040419201326.H37759@ida.interface-business.de> References: <20040419193610.A40602@ida.interface-business.de> <002301c42639$89aa3080$c702a8c0@altsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002301c42639$89aa3080$c702a8c0@altsoftware.com>; from cflecknell@altsoftware.com on Mon, Apr 19, 2004 at 02:10:02PM -0400 X-Phone: +49-351-31809-14 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Organization: interface systems GmbH, Dresden cc: Chris Flecknell Subject: Re: Ultra 10 Panic - lockup X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joerg Wunsch List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 18:13:28 -0000 As Chris Flecknell wrote: > syncing disks, buffers remaining... 3866 3866 > RED State Exception Based on my (Solaris-based, not FreeBSD) knowledge of U10 issues, RED state exceptions are an indication of a broken CPU. -- J"org Wunsch Unix support engineer joerg_wunsch@interface-systems.de http://www.interface-systems.de/~j/ From owner-freebsd-sparc64@FreeBSD.ORG Mon Apr 19 11:36: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 B2BDF16A4CE for ; Mon, 19 Apr 2004 11:36:41 -0700 (PDT) Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 294C143D60 for ; Mon, 19 Apr 2004 11:36:41 -0700 (PDT) (envelope-from james.gill@mci.com) Received: from imr3.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQqlck09524; Mon, 19 Apr 2004 18:36:26 GMT Received: from haiti.corp.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: haiti.corp.us.uu.net [153.39.146.95]) id QQqlck14278; Mon, 19 Apr 2004 18:36:26 GMT Received: from localhost by haiti.corp.us.uu.net with ESMTP (peer crosschecked as: jamgill@localhost) id i3JIaLf28088; Mon, 19 Apr 2004 14:36:21 -0400 (EDT) Date: Mon, 19 Apr 2004 14:36:21 -0400 (EDT) From: "Gill, James" X-X-Sender: jamgill@haiti.corp.us.uu.net To: Joerg Wunsch In-Reply-To: <20040419201326.H37759@ida.interface-business.de> Message-ID: References: <20040419193610.A40602@ida.interface-business.de> <20040419201326.H37759@ida.interface-business.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-sparc@freebsd.org cc: Chris Flecknell Subject: Re: Ultra 10 Panic - lockup X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: James.Gill@MCI.com List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 18:36:41 -0000 I've got a box that is doing this. It very well may have a bad CPU. I have been advised to update the OBP and i'm going to try that. I had switched *to* this processor because of mysterious crashes, I may need better duct tape or McGuyvering on these frankenstein boxes. --gill On Mon, 19 Apr 2004, Joerg Wunsch wrote: > As Chris Flecknell wrote: > > > syncing disks, buffers remaining... 3866 3866 > > RED State Exception > > Based on my (Solaris-based, not FreeBSD) knowledge of U10 issues, > RED state exceptions are an indication of a broken CPU. > > ----------------------------------------------------- MCI/UUNET Network Security & Abuse * 1-800-900-0241,4 ----------------------------------------------------- v-net: desk = 806-3834 ; group = 806-8805 From owner-freebsd-sparc64@FreeBSD.ORG Mon Apr 19 11:53: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 0936016A4CE for ; Mon, 19 Apr 2004 11:53:30 -0700 (PDT) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9E6B43D39 for ; Mon, 19 Apr 2004 11:53:29 -0700 (PDT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 1001) id 4AC8F24; Mon, 19 Apr 2004 14:53:29 -0400 (EDT) Date: Mon, 19 Apr 2004 14:53:29 -0400 From: Adam McDougall To: freebsd-sparc@freebsd.org Message-ID: <20040419185328.GV45634@egr.msu.edu> References: <20040419193610.A40602@ida.interface-business.de> <002301c42639$89aa3080$c702a8c0@altsoftware.com> <20040419201326.H37759@ida.interface-business.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040419201326.H37759@ida.interface-business.de> User-Agent: Mutt/1.5.6i Subject: Re: Ultra 10 Panic - lockup 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, 19 Apr 2004 18:53:30 -0000 On Mon, Apr 19, 2004 at 08:13:26PM +0200, Joerg Wunsch wrote: As Chris Flecknell wrote: > syncing disks, buffers remaining... 3866 3866 > RED State Exception Based on my (Solaris-based, not FreeBSD) knowledge of U10 issues, RED state exceptions are an indication of a broken CPU. -- J"org Wunsch Unix support engineer I have also witnessed RED State Exceptions on boot of a Ultra 60 with loose ram (as shipped). I would suggest ensuring that all ram modules are the same height as they sit in the slot unless they are obviously different as viewed when off the motherboard. Also, remove sets of components not in use if possible. Install DIMMs in pairs. This may be helpful: http://sunsolve.sun.com/handbook_pub/Systems/U10/U10.html Google searches on the subject a year ago pointed mostly to bad motherboards when I looked, although hits were vague and could point to one of several hardware problems. From owner-freebsd-sparc64@FreeBSD.ORG Mon Apr 19 12:06: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 6162516A4CE for ; Mon, 19 Apr 2004 12:06:06 -0700 (PDT) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFFD043D5A for ; Mon, 19 Apr 2004 12:06:05 -0700 (PDT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) i3JJ5lOY094430; Mon, 19 Apr 2004 21:05:47 +0200 (CEST) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.10/8.12.10/Submit) id i3JJ5gip094429; Mon, 19 Apr 2004 21:05:42 +0200 (CEST) (envelope-from marius) Date: Mon, 19 Apr 2004 21:05:42 +0200 From: Marius Strobl To: Joerg Wunsch Message-ID: <20040419210542.B92463@newtrinity.zeist.de> References: <20040419193610.A40602@ida.interface-business.de> <002301c42639$89aa3080$c702a8c0@altsoftware.com> <20040419201326.H37759@ida.interface-business.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040419201326.H37759@ida.interface-business.de>; from j@ida.interface-business.de on Mon, Apr 19, 2004 at 08:13:26PM +0200 X-AntiVirus: checked by AntiVir Milter 1.1-beta; AVE 6.25.0.2; VDF 6.25.0.17 (host: newtrinity.zeist.de) cc: freebsd-sparc@freebsd.org cc: Chris Flecknell Subject: Re: Ultra 10 Panic - lockup 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, 19 Apr 2004 19:06:06 -0000 On Mon, Apr 19, 2004 at 08:13:26PM +0200, Joerg Wunsch wrote: > As Chris Flecknell wrote: > > > syncing disks, buffers remaining... 3866 3866 > > RED State Exception > > Based on my (Solaris-based, not FreeBSD) knowledge of U10 issues, > RED state exceptions are an indication of a broken CPU. > Might also be caused by the mainboard; at least I have a Sun AXi board that threw RED state exceptions but the CPU I took from that broken board ever since runs flawless with another AXi board. From owner-freebsd-sparc64@FreeBSD.ORG Mon Apr 19 14:09:48 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 94A2716A4CE; Mon, 19 Apr 2004 14:09:48 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74A5843D1D; Mon, 19 Apr 2004 14:09:48 -0700 (PDT) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 508E22A7EA; Mon, 19 Apr 2004 14:09:48 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 09946E259; Mon, 19 Apr 2004 14:09:50 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.11) with ESMTP id i3JL8v68073281; Mon, 19 Apr 2004 14:08:57 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.11/Submit) id i3JL8v2M073280; Mon, 19 Apr 2004 14:08:57 -0700 (PDT) (envelope-from peter) From: Peter Wemm To: freebsd-sparc64@freebsd.org Date: Mon, 19 Apr 2004 14:08:56 -0700 User-Agent: KMail/1.6.1 References: <20040301145508.GA27240@seekingfire.com> <20040301150312.GQ35475@elvis.mu.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200404191408.56929.peter@wemm.org> cc: Garance A Drosihn cc: sparc64@freebsd.org Subject: Re: Minor problem with 64bTT: monthly accounting figures 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, 19 Apr 2004 21:09:48 -0000 On Monday 01 March 2004 11:03 am, Garance A Drosihn wrote: > At 4:03 PM +0100 3/1/04, Maxime Henrion wrote: > >Tillman Hodgson wrote: > >> Look a little odd this month: > >> > >> Subject: caliban.rospa.ca monthly run output > >> > >> Doing login accounting: > >> root 0.84 > >> total -298848.27 > >> toor -298849.12 > >> > > > -- End of monthly output -- > > This would be from the output of the 'ac' command. I tried > this on my 64-bTT machine, and it seemed to be working OK. > > >This is probably because the time is stored as a 32-bits integer > >in /var/run/utmp and /var/log/wtmp. > > If the time-value is defined as a fixed 32-bit integer (instead > of being time_t), then the records themselves should be fine. The > records (as written) won't be changing in size due to this change. > > So, if there is a bug here then it'll probably be in the 'ac' > program. That's my guess, at least. We can look into that some > more, but don't need to address it right away. Just fyi, ac does things like this: time_t ut_timecopy; ut_timecopy = _time32_to_time(event_up->ut_time); strlcpy(str_result, ctime(&ut_timecopy), sizeof(str_result)); However, there is also a big scary comment that says: * With sparc64 using 64-bit time_t's, there is some system * routine which sets ut_time==0 (the high-order word of a * 64-bit time) instead of a 32-bit time value. It sounds like something clobbers ut_time.. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-sparc64@FreeBSD.ORG Mon Apr 19 14:09:48 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 94A2716A4CE; Mon, 19 Apr 2004 14:09:48 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74A5843D1D; Mon, 19 Apr 2004 14:09:48 -0700 (PDT) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 508E22A7EA; Mon, 19 Apr 2004 14:09:48 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 09946E259; Mon, 19 Apr 2004 14:09:50 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.11) with ESMTP id i3JL8v68073281; Mon, 19 Apr 2004 14:08:57 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.11/Submit) id i3JL8v2M073280; Mon, 19 Apr 2004 14:08:57 -0700 (PDT) (envelope-from peter) From: Peter Wemm To: freebsd-sparc64@freebsd.org Date: Mon, 19 Apr 2004 14:08:56 -0700 User-Agent: KMail/1.6.1 References: <20040301145508.GA27240@seekingfire.com> <20040301150312.GQ35475@elvis.mu.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200404191408.56929.peter@wemm.org> cc: Garance A Drosihn cc: sparc64@freebsd.org Subject: Re: Minor problem with 64bTT: monthly accounting figures 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, 19 Apr 2004 21:09:48 -0000 On Monday 01 March 2004 11:03 am, Garance A Drosihn wrote: > At 4:03 PM +0100 3/1/04, Maxime Henrion wrote: > >Tillman Hodgson wrote: > >> Look a little odd this month: > >> > >> Subject: caliban.rospa.ca monthly run output > >> > >> Doing login accounting: > >> root 0.84 > >> total -298848.27 > >> toor -298849.12 > >> > > > -- End of monthly output -- > > This would be from the output of the 'ac' command. I tried > this on my 64-bTT machine, and it seemed to be working OK. > > >This is probably because the time is stored as a 32-bits integer > >in /var/run/utmp and /var/log/wtmp. > > If the time-value is defined as a fixed 32-bit integer (instead > of being time_t), then the records themselves should be fine. The > records (as written) won't be changing in size due to this change. > > So, if there is a bug here then it'll probably be in the 'ac' > program. That's my guess, at least. We can look into that some > more, but don't need to address it right away. Just fyi, ac does things like this: time_t ut_timecopy; ut_timecopy = _time32_to_time(event_up->ut_time); strlcpy(str_result, ctime(&ut_timecopy), sizeof(str_result)); However, there is also a big scary comment that says: * With sparc64 using 64-bit time_t's, there is some system * routine which sets ut_time==0 (the high-order word of a * 64-bit time) instead of a 32-bit time value. It sounds like something clobbers ut_time.. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-sparc64@FreeBSD.ORG Mon Apr 19 14:11:03 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 E219416A4CE; Mon, 19 Apr 2004 14:11:03 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id D185C43D49; Mon, 19 Apr 2004 14:11:03 -0700 (PDT) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 94A9B2A8E0; Mon, 19 Apr 2004 14:11:03 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 2241EE259; Mon, 19 Apr 2004 14:11:06 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.11) with ESMTP id i3JLACOL073306; Mon, 19 Apr 2004 14:10:12 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.11/Submit) id i3JLACq7073305; Mon, 19 Apr 2004 14:10:12 -0700 (PDT) (envelope-from peter) From: Peter Wemm To: freebsd-sparc64@freebsd.org Date: Mon, 19 Apr 2004 14:10:12 -0700 User-Agent: KMail/1.6.1 References: <20040301145508.GA27240@seekingfire.com> <200404191408.56929.peter@wemm.org> In-Reply-To: <200404191408.56929.peter@wemm.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200404191410.12636.peter@wemm.org> cc: Garance A Drosihn cc: sparc64@freebsd.org Subject: Re: Minor problem with 64bTT: monthly accounting figures 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, 19 Apr 2004 21:11:04 -0000 On Monday 19 April 2004 02:08 pm, Peter Wemm wrote: > On Monday 01 March 2004 11:03 am, Garance A Drosihn wrote: Whoops. Time warp. Sorry. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-sparc64@FreeBSD.ORG Mon Apr 19 14:11:03 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 E219416A4CE; Mon, 19 Apr 2004 14:11:03 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id D185C43D49; Mon, 19 Apr 2004 14:11:03 -0700 (PDT) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 94A9B2A8E0; Mon, 19 Apr 2004 14:11:03 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 2241EE259; Mon, 19 Apr 2004 14:11:06 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.11) with ESMTP id i3JLACOL073306; Mon, 19 Apr 2004 14:10:12 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.11/Submit) id i3JLACq7073305; Mon, 19 Apr 2004 14:10:12 -0700 (PDT) (envelope-from peter) From: Peter Wemm To: freebsd-sparc64@freebsd.org Date: Mon, 19 Apr 2004 14:10:12 -0700 User-Agent: KMail/1.6.1 References: <20040301145508.GA27240@seekingfire.com> <200404191408.56929.peter@wemm.org> In-Reply-To: <200404191408.56929.peter@wemm.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200404191410.12636.peter@wemm.org> cc: Garance A Drosihn cc: sparc64@freebsd.org Subject: Re: Minor problem with 64bTT: monthly accounting figures 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, 19 Apr 2004 21:11:04 -0000 On Monday 19 April 2004 02:08 pm, Peter Wemm wrote: > On Monday 01 March 2004 11:03 am, Garance A Drosihn wrote: Whoops. Time warp. Sorry. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-sparc64@FreeBSD.ORG Mon Apr 19 14:50:45 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 088D916A4CE for ; Mon, 19 Apr 2004 14:50:45 -0700 (PDT) Received: from smtp0.server.rpi.edu (smtp0.server.rpi.edu [128.113.53.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8079143D54 for ; Mon, 19 Apr 2004 14:50:44 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp0.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i3JLohEd008373; Mon, 19 Apr 2004 17:50:43 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200404191408.56929.peter@wemm.org> References: <20040301145508.GA27240@seekingfire.com> <20040301150312.GQ35475@elvis.mu.org> <200404191408.56929.peter@wemm.org> Date: Mon, 19 Apr 2004 17:50:42 -0400 To: Peter Wemm From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: sparc64@freebsd.org Subject: Re: Minor problem with 64bTT: monthly accounting figures 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, 19 Apr 2004 21:50:45 -0000 At 2:08 PM -0700 4/19/04, Peter Wemm wrote: > >Just fyi, ac does things like this: > > time_t ut_timecopy; > ut_timecopy = _time32_to_time(event_up->ut_time); > strlcpy(str_result, ctime(&ut_timecopy), sizeof(str_result)); > >However, there is also a big scary comment that says: > * With sparc64 using 64-bit time_t's, there is some system > * routine which sets ut_time==0 (the high-order word of a > * 64-bit time) instead of a 32-bit time value. > >It sounds like something clobbers ut_time.. Big scary comment added by me, when fixing 'ac' to do more reasonable things with such records... Afaik, we have still not figured out what it is that writes records with zero for the timestamp. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-sparc64@FreeBSD.ORG Mon Apr 19 15:57: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 F22BB16A4CF for ; Mon, 19 Apr 2004 15:57:15 -0700 (PDT) Received: from mtaw4.prodigy.net (mtaw4.prodigy.net [64.164.98.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id B694643D41 for ; Mon, 19 Apr 2004 15:57:15 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (6c4f396470e95860473dc49354a06072@adsl-67-115-73-128.dsl.lsan03.pacbell.net [67.115.73.128]) by mtaw4.prodigy.net (8.12.10/8.12.10) with ESMTP id i3JMvE5k014941; Mon, 19 Apr 2004 15:57:14 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 574AA511D0; Mon, 19 Apr 2004 15:57:14 -0700 (PDT) Date: Mon, 19 Apr 2004 15:57:14 -0700 From: Kris Kennaway To: Garance A Drosihn Message-ID: <20040419225714.GC47217@xor.obsecurity.org> References: <20040301145508.GA27240@seekingfire.com> <20040301150312.GQ35475@elvis.mu.org> <200404191408.56929.peter@wemm.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oJ71EGRlYNjSvfq7" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: sparc64@freebsd.org Subject: Re: Minor problem with 64bTT: monthly accounting figures 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, 19 Apr 2004 22:57:16 -0000 --oJ71EGRlYNjSvfq7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 19, 2004 at 05:50:42PM -0400, Garance A Drosihn wrote: > At 2:08 PM -0700 4/19/04, Peter Wemm wrote: > > > >Just fyi, ac does things like this: > > > > time_t ut_timecopy; > > ut_timecopy =3D _time32_to_time(event_up->ut_time); > > strlcpy(str_result, ctime(&ut_timecopy), sizeof(str_result)); > > > >However, there is also a big scary comment that says: > > * With sparc64 using 64-bit time_t's, there is some system > > * routine which sets ut_time=3D=3D0 (the high-order word of a > > * 64-bit time) instead of a 32-bit time value. > > > >It sounds like something clobbers ut_time.. >=20 > Big scary comment added by me, when fixing 'ac' to do more > reasonable things with such records... Afaik, we have still > not figured out what it is that writes records with zero for > the timestamp. Should an erratum be added in case this is unresolved by 5.3, or is this too minor an issue? Kris --oJ71EGRlYNjSvfq7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAhFlJWry0BWjoQKURAvMGAJ9eoDIva+x9jXRzEcKsKlhnCjzX3ACeLiZv nxPTSfJF/Rvt1Q+Nj8N4p/A= =bA7u -----END PGP SIGNATURE----- --oJ71EGRlYNjSvfq7-- From owner-freebsd-sparc64@FreeBSD.ORG Mon Apr 19 17:11:09 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 BFF7516A4CE for ; Mon, 19 Apr 2004 17:11:09 -0700 (PDT) Received: from smtp0.server.rpi.edu (smtp0.server.rpi.edu [128.113.53.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54E8F43D5F for ; Mon, 19 Apr 2004 17:11:09 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp0.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i3K0B8Ed008904; Mon, 19 Apr 2004 20:11:08 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040419225714.GC47217@xor.obsecurity.org> References: <20040301145508.GA27240@seekingfire.com> <20040301150312.GQ35475@elvis.mu.org> <200404191408.56929.peter@wemm.org> <20040419225714.GC47217@xor.obsecurity.org> Date: Mon, 19 Apr 2004 20:11:06 -0400 To: Kris Kennaway From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: sparc64@freebsd.org Subject: Re: Minor problem with 64bTT: monthly accounting figures 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, 20 Apr 2004 00:11:09 -0000 At 3:57 PM -0700 4/19/04, Kris Kennaway wrote: >On Mon, Apr 19, 2004, Garance A Drosihn wrote: > > At 2:08 PM -0700 4/19/04, Peter Wemm wrote: > > > >> >However, there is also a big scary comment that says: > > > > > > * With sparc64 using 64-bit time_t's, there is some system > > > * routine which sets ut_time==0 (the high-order word of a > > > * 64-bit time) instead of a 32-bit time value. > > > >> >It sounds like something clobbers ut_time.. >> >> Big scary comment added by me, when fixing 'ac' to do more >> reasonable things with such records... Afaik, we have still >> not figured out what it is that writes records with zero for >> the timestamp. > >Should an erratum be added in case this is unresolved by 5.3, >or is this too minor an issue? I have been considering it a minor issue. But then, I also hoped that someone would notice the new warning message from `ac', rerun it in debug-mode, and be able to match up the bad-records with whatever they were doing at the time. And then we'd have a good clue as to which program is sometimes writing these bad records. But I guess that in normal operation, people won't see that message until the monthly-run, so maybe it won't come up often. In the cases I saw, it was just a few bad records over the course of a month, so I assume that whatever-it-is, it is something that doesn't happen often. I haven't seen it happen on my systems at all, but then almost all my sessions are made via ssh, so in my case it would either happen all the time, or it would probably never come up. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-sparc64@FreeBSD.ORG Tue Apr 20 07:10:08 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 DBE9A16A4D1 for ; Tue, 20 Apr 2004 07:10:08 -0700 (PDT) Received: from ida.interface-business.de (ida.interface-business.de [193.101.57.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 236C743D41 for ; Tue, 20 Apr 2004 07:10:08 -0700 (PDT) (envelope-from j@ida.interface-business.de) Received: by ida.interface-business.de (Postfix, from userid 107) id 8C0EB7A48; Tue, 20 Apr 2004 16:10:04 +0200 (MET DST) Date: Tue, 20 Apr 2004 16:10:04 +0200 From: Joerg Wunsch To: freebsd-sparc@freebsd.org Message-ID: <20040420161004.A47127@ida.interface-business.de> References: <20040415120849.B4638@ida.interface-business.de> <20040415101408.GB41902@beastie.b0rken.org> <20040419193610.A40602@ida.interface-business.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040419193610.A40602@ida.interface-business.de>; from j@ida.interface-business.de on Mon, Apr 19, 2004 at 07:36:10PM +0200 X-Phone: +49-351-31809-14 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Organization: interface systems GmbH, Dresden Subject: Re: 5.2.1 mini-ISO fails to boot on U450 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joerg Wunsch List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 14:10:09 -0000 As Joerg Wunsch wrote: > I found a FreeBSD 5.1 boot CD-ROM, and it gets me a few more messages > on the serial console but will eventually fail similarly: > > Boot device: /pci@1f,4000/scsi@2/disk@6,0:f File and args: > > >> FreeBSD/sparc64 boot block > Boot path: /pci@1f,4000/scsi@2/disk@6,0:f > Boot loader: /boot/loader > Console: OpenFirmware console > Boot path set to /pci@1f,4000/scsi@2/disk@6,0:a > > FreeBSD/sparc64 bootstrap loader, Revision 1.0 > (fenner@sparkle.attlabs.net, Tue May 6 15:11:35 PDT 2003) > bootpath="/pci@1f,4000/scsi@2/disk@6,0:a" > > [here the `twiddle' is spinning] > > Loading /boot/defaults/loader.conf > Fatal SCSI error at script address 8 Illegal instruction > Drive not ready No idea what this might have been. Thanks to Marius Strobl's documentation pointer, I've been able to set up a netboot server for the machine, and installed it that way. Unlike booting off the CD-ROM, booting off a normal disk works, and I can also access the CD-ROM. Would be interesting why booting off the CD-ROM does not work for FreeBSD. Booting the miniroot system didn't work either (``The file just loaded does not appear to be executable.''). I notice that the bootstrap process while netbooting is abysmally slow. Ethereal only records NFS requests (like for loader.conf etc.) every 30 or so seconds, between these calls the machine seems to be idle. Why's that? It's as dog slow as booting Solaris over the net... Btw., I had to fix rarpd(8) in order to work on interfaces with multiple IP addresses assigned. I guess the sparc64 community would be the #1 candidate consumer of rarpd, so I thought I let you know. ;-) -- J"org Wunsch Unix support engineer joerg_wunsch@interface-systems.de http://www.interface-systems.de/~j/ From owner-freebsd-sparc64@FreeBSD.ORG Tue Apr 20 10:19: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 2A02F16A4CE for ; Tue, 20 Apr 2004 10:19:16 -0700 (PDT) Received: from lydian.elandem.org (host217-37-7-147.in-addr.btopenworld.com [217.37.7.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D64143D5A for ; Tue, 20 Apr 2004 10:19:14 -0700 (PDT) (envelope-from mat@elandem.org) Received: from phrygian.elandem.org ([217.37.7.148] helo=bigboxii) by lydian.elandem.org with esmtp (Exim 4.24; FreeBSD) id 1BFysg-000DUQ-Q3 for freebsd-sparc64@freebsd.org; Tue, 20 Apr 2004 18:17:58 +0100 From: "Mat Ford" To: Date: Tue, 20 Apr 2004 18:16:26 +0100 Organization: elandem.org MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcQm+zZLOJEwwOsvQ/CXgLSLz2WiNA== Message-Id: Subject: installing world on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mat@elandem.org List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 17:19:16 -0000 I've just got 5.2.1-RELEASE running on my Ultra10 without problems. I'm wondering if it's safe to cvsup and do: cd /usr/src make -j4 buildworld make buildkernel KERNCONF=GENERIC make installkernel KERNCONF=GENERIC make installworld mergemaster fastboot portupgrade -arP Is this sane on the Sparc64 platform? I'm familiar with this process on i386. TIA, Mat --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.656 / Virus Database: 421 - Release Date: 09/04/2004 From owner-freebsd-sparc64@FreeBSD.ORG Tue Apr 20 10:29: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 0887116A4CE for ; Tue, 20 Apr 2004 10:29:12 -0700 (PDT) Received: from electra.cse.Buffalo.EDU (electra.cse.Buffalo.EDU [128.205.32.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A91CB43D49 for ; Tue, 20 Apr 2004 10:29:11 -0700 (PDT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from electra.cse.Buffalo.EDU (kensmith@localhost [127.0.0.1]) i3KHST8o008242; Tue, 20 Apr 2004 13:28:29 -0400 (EDT) Received: (from kensmith@localhost) by electra.cse.Buffalo.EDU (8.12.10/8.12.9/Submit) id i3KHST0D008241; Tue, 20 Apr 2004 13:28:29 -0400 (EDT) Date: Tue, 20 Apr 2004 13:28:28 -0400 From: Ken Smith To: Mat Ford Message-ID: <20040420172828.GA7721@electra.cse.Buffalo.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-sparc64@freebsd.org Subject: Re: installing world on sparc64 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, 20 Apr 2004 17:29:12 -0000 On Tue, Apr 20, 2004 at 06:16:26PM +0100, Mat Ford wrote: > I've just got 5.2.1-RELEASE running on my Ultra10 without problems. I'm > wondering if it's safe to cvsup and do: > > cd /usr/src > make -j4 buildworld > make buildkernel KERNCONF=GENERIC > make installkernel KERNCONF=GENERIC > make installworld > mergemaster > fastboot > portupgrade -arP > > Is this sane on the Sparc64 platform? I'm familiar with this process on > i386. If you were planning to do a cvsup to -current before doing that you shouldn't do it that way the first time. The time_t type was changed after the 5.2.1-RELEASE came out. For the first pass at doing an upgrade read and follow /usr/src/UPDATING.64BTT. After you are past the 64-bit time_t transition the above procedure works fine. I do it all the time, except that you don't need to include KERNCONF=GENERIC (that's the default). -- 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 Tue Apr 20 15:48:13 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 CC3BB16A4CE for ; Tue, 20 Apr 2004 15:48:13 -0700 (PDT) Received: from mtaw4.prodigy.net (mtaw4.prodigy.net [64.164.98.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id A772D43D5A for ; Tue, 20 Apr 2004 15:48:13 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (aea62048c947232b2deaee60c6b405f1@adsl-67-115-73-128.dsl.lsan03.pacbell.net [67.115.73.128]) by mtaw4.prodigy.net (8.12.10/8.12.10) with ESMTP id i3KMm15k023865; Tue, 20 Apr 2004 15:48:02 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id EBE0252237; Tue, 20 Apr 2004 15:48:01 -0700 (PDT) Date: Tue, 20 Apr 2004 15:48:01 -0700 From: Kris Kennaway To: Mat Ford Message-ID: <20040420224801.GA68706@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: freebsd-sparc64@freebsd.org Subject: Re: installing world on sparc64 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, 20 Apr 2004 22:48:13 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 20, 2004 at 06:16:26PM +0100, Mat Ford wrote: > I've just got 5.2.1-RELEASE running on my Ultra10 without problems. I'm > wondering if it's safe to cvsup and do: >=20 > cd /usr/src > make -j4 buildworld > make buildkernel KERNCONF=3DGENERIC > make installkernel KERNCONF=3DGENERIC > make installworld > mergemaster > fastboot > portupgrade -arP >=20 > Is this sane on the Sparc64 platform? I'm familiar with this process on > i386. That's not quite the documented upgrade procedure even on i386 (see the handbook). On sparc64 you'll need to do more to update to 5.2-CURRENT; see the UPDATING instructions (part of that documented upgrade procedure I mentioned :-). Kris --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAhaihWry0BWjoQKURAmEAAKCaoGR3TP2pCEGBg3ihOavQRYrz3wCgvgGu 3q3PYgVPECU8Dgi+gSctqW8= =Wrcd -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-sparc64@FreeBSD.ORG Wed Apr 21 00:18: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 D7FB016A4CE; Wed, 21 Apr 2004 00:18:16 -0700 (PDT) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id D748B43D5F; Wed, 21 Apr 2004 00:18:14 -0700 (PDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 655A37306D; Wed, 21 Apr 2004 03:18:14 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040421071814.655A37306D@freebsd-current.sentex.ca> Date: Wed, 21 Apr 2004 03:18:14 -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, 21 Apr 2004 07:18:17 -0000 From owner-freebsd-sparc64@FreeBSD.ORG Wed Apr 21 01:19:46 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 C001316A4CE; Wed, 21 Apr 2004 01:19:46 -0700 (PDT) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BF5543D45; Wed, 21 Apr 2004 01:19:46 -0700 (PDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 080717303A; Wed, 21 Apr 2004 04:19:45 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040421081945.080717303A@freebsd-current.sentex.ca> Date: Wed, 21 Apr 2004 04:19:45 -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, 21 Apr 2004 08:19:46 -0000 TB --- 2004-04-21 06:51:20 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-04-21 06:51:20 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-04-21 06:51:20 - checking out the source tree TB --- 2004-04-21 06:51:20 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64 TB --- 2004-04-21 06:51:20 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-04-21 07:01:27 - building world (CFLAGS=-O2 -pipe) TB --- 2004-04-21 07:01:27 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src TB --- 2004-04-21 07:01:27 - /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 [...] cc -O2 -pipe -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/other/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/res_data.c cc -O2 -pipe -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/other/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/res_debug.c cc -O2 -pipe -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/other/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/res_init.c cc -O2 -pipe -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/other/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/res_mkquery.c cc -O2 -pipe -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/other/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/res_mkupdate.c cc -O2 -pipe -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/other/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/res_query.c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/res_query.c: In function `__res_search': /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/res_query.c:196: warning: unused variable `hp' *** Error code 1 Stop in /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc. *** Error code 1 Stop in /other/tinderbox/CURRENT/sparc64/sparc64/src/lib. *** Error code 1 Stop in /other/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /other/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /other/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /other/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-04-21 08:19:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-04-21 08:19:45 - ERROR: failed to build world TB --- 2004-04-21 08:19:45 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Wed Apr 21 04:36:22 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 67C9B16A4CF; Wed, 21 Apr 2004 04:36:22 -0700 (PDT) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAF7A43D5A; Wed, 21 Apr 2004 04:36:21 -0700 (PDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 543EA7303A; Wed, 21 Apr 2004 07:36:21 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040421113621.543EA7303A@freebsd-current.sentex.ca> Date: Wed, 21 Apr 2004 07:36:21 -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, 21 Apr 2004 11:36:22 -0000 TB --- 2004-04-21 10:31:02 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-04-21 10:31:02 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-04-21 10:31:02 - checking out the source tree TB --- 2004-04-21 10:31:02 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64 TB --- 2004-04-21 10:31:02 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-04-21 10:40:10 - building world (CFLAGS=-O2 -pipe) TB --- 2004-04-21 10:40:10 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src TB --- 2004-04-21 10:40:10 - /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 [...] cc -O2 -pipe -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/other/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/res_data.c cc -O2 -pipe -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/other/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/res_debug.c cc -O2 -pipe -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/other/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/res_init.c cc -O2 -pipe -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/other/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/res_mkquery.c cc -O2 -pipe -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/other/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/res_mkupdate.c cc -O2 -pipe -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/other/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/res_query.c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/res_query.c: In function `__res_search': /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/res_query.c:196: warning: unused variable `hp' *** Error code 1 Stop in /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc. *** Error code 1 Stop in /other/tinderbox/CURRENT/sparc64/sparc64/src/lib. *** Error code 1 Stop in /other/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /other/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /other/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /other/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-04-21 11:36:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-04-21 11:36:20 - ERROR: failed to build world TB --- 2004-04-21 11:36:20 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Wed Apr 21 14:38: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 7478F16A4CE for ; Wed, 21 Apr 2004 14:38:18 -0700 (PDT) Received: from silver.teardrop.org (silver.teardrop.org [66.150.202.126]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0992743D53 for ; Wed, 21 Apr 2004 14:38:18 -0700 (PDT) (envelope-from snow@teardrop.org) Received: by silver.teardrop.org (Postfix, from userid 100) id 2CE1B26C0F; Wed, 21 Apr 2004 17:39:18 -0400 (EDT) Date: Wed, 21 Apr 2004 17:39:18 -0400 From: James Snow To: freebsd-sparc64@freebsd.org Message-ID: <20040421213917.GA693@teardrop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: 'make installworld' can't find /usr/bin/touch? 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, 21 Apr 2004 21:38:18 -0000 I see that this has been seen by at least one other person (http://lists.freebsd.org/mailman/htdig/freebsd-sparc64/2004-February/001340.html) but without a solution being found, that I can see. The error I see: -------------------------------------------------------------- >>> Installing everything.. -------------------------------------------------------------- cd /usr/src; make -f Makefile.inc1 install ===> share/info ===> include creating osreldate.h from newvers.sh touch: not found *** Error code 127 The system is an Ultra 10 running 5.2.1-R, and I'm trying to upgrade it to 5.2.1-R-p5. The first time this happened I did an 'rm -rf /usr/src /usr/obj' and cvsup'd again from scratch, but I see the same error. 'which touch' reports the existance of /usr/bin/touch and it works just fine. I'm kind of stumped. I figure I'm doing something stupid since this is my first FreeBSD-sparc64 box. Is the process for upgrading under 5.x on the sparc still: make buildworld make buildkernel make installkernel make installworld mergemaster or am I missing a step? -Snow From owner-freebsd-sparc64@FreeBSD.ORG Wed Apr 21 14:45:37 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 744A116A4CE for ; Wed, 21 Apr 2004 14:45:37 -0700 (PDT) Received: from electra.cse.Buffalo.EDU (electra.cse.Buffalo.EDU [128.205.32.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2555A43D4C for ; Wed, 21 Apr 2004 14:45:37 -0700 (PDT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from electra.cse.Buffalo.EDU (kensmith@localhost [127.0.0.1]) i3LLja8o010358; Wed, 21 Apr 2004 17:45:36 -0400 (EDT) Received: (from kensmith@localhost) by electra.cse.Buffalo.EDU (8.12.10/8.12.9/Submit) id i3LLjaZn010357; Wed, 21 Apr 2004 17:45:36 -0400 (EDT) Date: Wed, 21 Apr 2004 17:45:36 -0400 From: Ken Smith To: James Snow Message-ID: <20040421214536.GA10046@electra.cse.Buffalo.EDU> References: <20040421213917.GA693@teardrop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040421213917.GA693@teardrop.org> User-Agent: Mutt/1.4.1i cc: freebsd-sparc64@freebsd.org Subject: Re: 'make installworld' can't find /usr/bin/touch? 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, 21 Apr 2004 21:45:37 -0000 On Wed, Apr 21, 2004 at 05:39:18PM -0400, James Snow wrote: > The error I see: > > -------------------------------------------------------------- > >>> Installing everything.. > -------------------------------------------------------------- > cd /usr/src; make -f Makefile.inc1 install > ===> share/info > ===> include > creating osreldate.h from newvers.sh > touch: not found > *** Error code 127 > > The system is an Ultra 10 running 5.2.1-R, and I'm trying to > upgrade it to 5.2.1-R-p5. The first time this happened I did > an 'rm -rf /usr/src /usr/obj' and cvsup'd again from > scratch, but I see the same error. > > 'which touch' reports the existance of /usr/bin/touch and it > works just fine. > > I'm kind of stumped. I figure I'm doing something stupid > since this is my first FreeBSD-sparc64 box. Is the process > for upgrading under 5.x on the sparc still: > > make buildworld > make buildkernel > make installkernel > make installworld > mergemaster > > or am I missing a step? Try checking the current date/time your computer thinks it has. I've had these errors and it turned out the computer thought the date was *really* outrageous. -- 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 Apr 21 14:53:46 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 763A016A4CE for ; Wed, 21 Apr 2004 14:53:46 -0700 (PDT) Received: from silver.teardrop.org (silver.teardrop.org [66.150.202.126]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5045043D4C for ; Wed, 21 Apr 2004 14:53:44 -0700 (PDT) (envelope-from snow@teardrop.org) Received: by silver.teardrop.org (Postfix, from userid 100) id C63FC26C0F; Wed, 21 Apr 2004 17:54:44 -0400 (EDT) Date: Wed, 21 Apr 2004 17:54:44 -0400 From: James Snow To: Ken Smith Message-ID: <20040421215444.GB693@teardrop.org> References: <20040421213917.GA693@teardrop.org> <20040421214536.GA10046@electra.cse.Buffalo.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040421214536.GA10046@electra.cse.Buffalo.EDU> User-Agent: Mutt/1.4.1i cc: freebsd-sparc64@freebsd.org Subject: Re: 'make installworld' can't find /usr/bin/touch? 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, 21 Apr 2004 21:53:46 -0000 On Wed, Apr 21, 2004 at 05:45:36PM -0400, Ken Smith wrote: > > Try checking the current date/time your computer thinks it has. > I've had these errors and it turned out the computer thought > the date was *really* outrageous. It was indeed living somewhat in the past: Sun Mar 7 20:58:25 EST 2004 Synchronized it with my local timeserver and an immediate 'make installworld' fails the same way. Starting over with a make clean, buildkernel, buildworld, etc. We'll see how that fares. (It'll be a while.) Thanks for the tip. -Snow From owner-freebsd-sparc64@FreeBSD.ORG Thu Apr 22 07:33: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 D4BA316A4CE for ; Thu, 22 Apr 2004 07:33:39 -0700 (PDT) Received: from silver.teardrop.org (silver.teardrop.org [66.150.202.126]) by mx1.FreeBSD.org (Postfix) with ESMTP id B60E943D58 for ; Thu, 22 Apr 2004 07:33:39 -0700 (PDT) (envelope-from snow@teardrop.org) Received: by silver.teardrop.org (Postfix, from userid 100) id 5A00F26C16; Thu, 22 Apr 2004 10:34:39 -0400 (EDT) Date: Thu, 22 Apr 2004 10:34:39 -0400 From: James Snow To: freebsd-sparc64@freebsd.org Message-ID: <20040422143439.GA3886@teardrop.org> References: <20040421213917.GA693@teardrop.org> <20040421214536.GA10046@electra.cse.Buffalo.EDU> <20040421215444.GB693@teardrop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040421215444.GB693@teardrop.org> User-Agent: Mutt/1.4.1i Subject: Re: 'make installworld' can't find /usr/bin/touch? 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, 22 Apr 2004 14:33:39 -0000 This was indeed the cause of the problem. Thanks again. Summary for those searching the lists: 'make installworld' was failing like so: -------------------------------------------------------------- >>> Installing everything.. -------------------------------------------------------------- cd /usr/src; make -f Makefile.inc1 install ===> share/info ===> include creating osreldate.h from newvers.sh touch: not found *** Error code 127 The time on the machine was a little over a month in the past. (Brand new install, still setting it up.) Synchronizing the clock and doing a 'make clean && make buildworld && ...' fixed the problem. -Snow On Wed, Apr 21, 2004 at 05:54:44PM -0400, James Snow wrote: > On Wed, Apr 21, 2004 at 05:45:36PM -0400, Ken Smith wrote: > > > > Try checking the current date/time your computer thinks it has. > > I've had these errors and it turned out the computer thought > > the date was *really* outrageous. > > It was indeed living somewhat in the past: > > Sun Mar 7 20:58:25 EST 2004 > > Synchronized it with my local timeserver and an immediate > 'make installworld' fails the same way. Starting over with a > make clean, buildkernel, buildworld, etc. We'll see how that > fares. (It'll be a while.) > > Thanks for the tip. > > > -Snow > > _______________________________________________ > 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 Thu Apr 22 09:59:28 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6F2516A4CE for ; Thu, 22 Apr 2004 09:59:28 -0700 (PDT) Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id E639943D53 for ; Thu, 22 Apr 2004 09:59:27 -0700 (PDT) (envelope-from novo@cs.tu-berlin.de) Received: from 130-149-145-43.dialup.cs.tu-berlin.de (130-149-145-43.dialup.cs.tu-berlin.de [130.149.145.43]) by mail.cs.tu-berlin.de (8.9.3p2/8.9.3) with ESMTP id SAA25822 for ; Thu, 22 Apr 2004 18:58:56 +0200 (MET DST) Date: Thu, 22 Apr 2004 18:59:33 +0200 (CEST) From: Harti Brandt X-X-Sender: novo@130-149-145-43.dialup.cs.tu-berlin.de To: sparc64@freebsd.org Message-ID: <20040422185744.J62077@130-149-145-43.dialup.cs.tu-berlin.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-101533963-1082653173=:62077" Subject: RTC on ultra-10 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@freebsd.org List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 16:59:28 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-101533963-1082653173=:62077 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi all, has anybody an idea why the eeprom does not attach on my ultra-10? The result is that I have no RTC. Attached is the verbose boot and the config. harti --0-101533963-1082653173=:62077 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=ss Content-Transfer-Encoding: BASE64 Content-ID: <20040422185933.B62077@130-149-145-43.dialup.cs.tu-berlin.de> Content-Description: Content-Disposition: attachment; filename=ss Q29weXJpZ2h0IChjKSAxOTkyLTIwMDQgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwg MTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KCVRoZSBSZWdlbnRzIG9m IHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuDQpGcmVlQlNEIDUuMi1DVVJSRU5UICMxOiBUaHUgQXByIDIyIDE4 OjA1OjI4IENFU1QgMjAwNA0KICAgIG5vdm9AMTMwLTE0OS0xNDUtMTMyLmRp YWx1cC5jcy50dS1iZXJsaW4uZGU6L3Vzci9vYmovc3BhcmMvc3BhcmM2NC91 c3Ivc3JjL3N5cy9TT05KQQ0KUHJlbG9hZGVkIGVsZiBrZXJuZWwgIi9ib290 L2tlcm5lbC9rZXJuZWwiIGF0IDB4YzAyYmMwMDAuDQpUaW1lY291bnRlciAi dGljayIgZnJlcXVlbmN5IDQ0MDAwMDAwMCBIeiBxdWFsaXR5IDANCnJlYWwg bWVtb3J5ICA9IDI2ODQzNTQ1NiAoMjU2IE1CKQ0KYXZhaWwgbWVtb3J5ID0g MjUyMDkyNDE2ICgyNDAgTUIpDQptYWNoaW5lOiBTVU5XLFVsdHJhLTVfMTAN CmNwdTA6IFN1biBNaWNyb3N5c3RlbXMgVWx0cmFTcGFyYy1JSWkgUHJvY2Vz c29yICg0NDAuMDAgTUh6IENQVSkNCiAgbWFzaz0weDkxIG1heHRsPTUgbWF4 d2luPTcNCm51bGw6IDxudWxsIGRldmljZSwgemVybyBkZXZpY2U+DQpvcGVu ZmlybTogPE9wZW5GaXJtd2FyZSBjb250cm9sIGRldmljZT4NCm1lbTogPG1l bW9yeSAmIEkvTz4NCm5leHVzMDogPE9wZW5GaXJtd2FyZSBOZXh1cyBkZXZp Y2U+DQpwY2liMDogPFUyUCBVUEEtUENJIGJyaWRnZT4gb24gbmV4dXMwDQpw Y2liMDogU2FicmUsIGltcGwgMCwgdmVyc2lvbiAwLCBpZ24gMHg3YzAsIGJ1 cyBBDQppbml0YWxpemluZyBpbnRyX2NvdW50cA0KcGNpYjA6IFtGQVNUXQ0K cGNpYjA6IFtHSUFOVC1MT0NLRURdDQpwY2liMDogW0ZBU1RdDQpwY2liMDog W0dJQU5ULUxPQ0tFRF0NCkRWTUEgbWFwOiAweGMwMDAwMDAwIHRvIDB4YzNm ZmZmZmYNCnBjaTA6IDxPRlcgUENJIGJ1cz4gb24gcGNpYjANCnBjaTA6IHBo eXNpY2FsIGJ1cz0wDQpmb3VuZC0+CXZlbmRvcj0weDEwOGUsIGRldj0weDUw MDAsIHJldmlkPTB4MTMNCglidXM9MCwgc2xvdD0xLCBmdW5jPTENCgljbGFz cz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0xDQoJY21kcmVnPTB4 MDE0Nywgc3RhdHJlZz0weDAyYTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQ0K CWxhdHRpbWVyPTB4MTAgKDQ4MCBucyksIG1pbmdudD0weDAyICg1MDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykNCmZvdW5kLT4JdmVuZG9yPTB4MTA4ZSwg ZGV2PTB4NTAwMCwgcmV2aWQ9MHgxMw0KCWJ1cz0wLCBzbG90PTEsIGZ1bmM9 MA0KCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTENCglj bWRyZWc9MHgwMTQ3LCBzdGF0cmVnPTB4MDJhMCwgY2FjaGVsbnN6PTE2IChk d29yZHMpDQoJbGF0dGltZXI9MHgxMCAoNDgwIG5zKSwgbWluZ250PTB4MDIg KDUwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KcGNpYjE6IDxBUEIgUENJ LVBDSSBicmlkZ2U+IGF0IGRldmljZSAxLjEgb24gcGNpMA0KcGNpYjE6ICAg c2Vjb25kYXJ5IGJ1cyAgICAgMQ0KcGNpYjE6ICAgc3Vib3JkaW5hdGUgYnVz ICAgMQ0KcGNpYjE6ICAgSS9PIGRlY29kZSAgICAgICAgMHhjMDAwMDAtMHhk ZmZmZmYsIDB4ZTAwMDAwLTB4ZmZmZmZmDQpwY2liMTogICBtZW1vcnkgZGVj b2RlICAgICAweGUwMDAwMDAwLTB4ZmZmZmZmZmYNCnBjaTE6IDxPRlcgUENJ IGJ1cz4gb24gcGNpYjENCnBjaTE6IHBoeXNpY2FsIGJ1cz0xDQoJbWFwWzEw XTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBmMDAwMDAwMCwgc2l6ZSAyNCwg ZW5hYmxlZA0KcGNpYjE6IGRldmljZSAobnVsbCktMSByZXF1ZXN0ZWQgZGVj b2RlZCBtZW1vcnkgcmFuZ2UgMHhmMDAwMDAwMC0weGYwZmZmZmZmDQoJbWFw WzE0XTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBmMTAwMDAwMCwgc2l6ZSAy MywgZW5hYmxlZA0KcGNpYjE6IGRldmljZSAobnVsbCktMSByZXF1ZXN0ZWQg ZGVjb2RlZCBtZW1vcnkgcmFuZ2UgMHhmMTAwMDAwMC0weGYxN2ZmZmZmDQpm b3VuZC0+CXZlbmRvcj0weDEwOGUsIGRldj0weDEwMDAsIHJldmlkPTB4MDEN CglidXM9MSwgc2xvdD0xLCBmdW5jPTANCgljbGFzcz0wNi04MC0wMCwgaGRy dHlwZT0weDAwLCBtZmRldj0xDQoJY21kcmVnPTB4MDE0Niwgc3RhdHJlZz0w eDAyODAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4NTIg KDI0NjAgbnMpLCBtaW5nbnQ9MHgwYSAoMjUwMCBucyksIG1heGxhdD0weDE5 ICg2MjUwIG5zKQ0KCW1hcFsxMF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2Ug ZTAwMDAwMDAsIHNpemUgMTUsIGVuYWJsZWQNCnBjaWIxOiBkZXZpY2UgKG51 bGwpLTEgcmVxdWVzdGVkIGRlY29kZWQgbWVtb3J5IHJhbmdlIDB4ZTAwMDAw MDAtMHhlMDAwN2ZmZg0KZm91bmQtPgl2ZW5kb3I9MHgxMDhlLCBkZXY9MHgx MDAxLCByZXZpZD0weDAxDQoJYnVzPTEsIHNsb3Q9MSwgZnVuYz0xDQoJY2xh c3M9MDItMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQ0KCWNtZHJlZz0w eDAxNDYsIHN0YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykN CglsYXR0aW1lcj0weDUyICgyNDYwIG5zKSwgbWluZ250PTB4MGEgKDI1MDAg bnMpLCBtYXhsYXQ9MHgwNSAoMTI1MCBucykNCgltYXBbMTBdOiB0eXBlIDEs IHJhbmdlIDMyLCBiYXNlIGUxMDAwMDAwLCBzaXplIDI0LCBtZW1vcnkgZGlz YWJsZWQNCnBjaWIxOiBkZXZpY2UgKG51bGwpLTEgcmVxdWVzdGVkIGRlY29k ZWQgbWVtb3J5IHJhbmdlIDB4ZTEwMDAwMDAtMHhlMWZmZmZmZg0KCW1hcFsx NF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDAwMDAsIHNpemUgIDgs IHBvcnQgZGlzYWJsZWQNCgltYXBbMThdOiB0eXBlIDEsIHJhbmdlIDMyLCBi YXNlIGUyMDAwMDAwLCBzaXplIDEyLCBlbmFibGVkDQpwY2liMTogZGV2aWNl IChudWxsKS0xIHJlcXVlc3RlZCBkZWNvZGVkIG1lbW9yeSByYW5nZSAweGUy MDAwMDAwLTB4ZTIwMDBmZmYNCmZvdW5kLT4JdmVuZG9yPTB4MTAwMiwgZGV2 PTB4NDc1MCwgcmV2aWQ9MHg1Yw0KCWJ1cz0xLCBzbG90PTIsIGZ1bmM9MA0K CWNsYXNzPTAzLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTANCgljbWRy ZWc9MHgwMDgwLCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTE2IChkd29y ZHMpDQoJbGF0dGltZXI9MHg0MiAoMTk4MCBucyksIG1pbmdudD0weDA4ICgy MDAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpDQoJaW50cGluPWEsIGlycT0y NTUNCgltYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwYzAwMDAw LCBzaXplICAzLCBlbmFibGVkDQpwY2liMTogZGV2aWNlIChudWxsKS0xIHJl cXVlc3RlZCBkZWNvZGVkIEkvTyByYW5nZSAweGMwMDAwMC0weGMwMDAwNw0K CW1hcFsxNF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDBjMDAwMDgsIHNp emUgIDIsIGVuYWJsZWQNCnBjaWIxOiBkZXZpY2UgKG51bGwpLTEgcmVxdWVz dGVkIGRlY29kZWQgSS9PIHJhbmdlIDB4YzAwMDA4LTB4YzAwMDBiDQoJbWFw WzE4XTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMGMwMDAxMCwgc2l6ZSAg MywgZW5hYmxlZA0KcGNpYjE6IGRldmljZSAobnVsbCktMSByZXF1ZXN0ZWQg ZGVjb2RlZCBJL08gcmFuZ2UgMHhjMDAwMTAtMHhjMDAwMTcNCgltYXBbMWNd OiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwYzAwMDE4LCBzaXplICAyLCBl bmFibGVkDQpwY2liMTogZGV2aWNlIChudWxsKS0xIHJlcXVlc3RlZCBkZWNv ZGVkIEkvTyByYW5nZSAweGMwMDAxOC0weGMwMDAxYg0KCW1hcFsyMF06IHR5 cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDBjMDAwMjAsIHNpemUgIDQsIGVuYWJs ZWQNCnBjaWIxOiBkZXZpY2UgKG51bGwpLTEgcmVxdWVzdGVkIGRlY29kZWQg SS9PIHJhbmdlIDB4YzAwMDIwLTB4YzAwMDJmDQpmb3VuZC0+CXZlbmRvcj0w eDEwOTUsIGRldj0weDA2NDYsIHJldmlkPTB4MDMNCglidXM9MSwgc2xvdD0z LCBmdW5jPTANCgljbGFzcz0wMS0wMS04ZiwgaGRydHlwZT0weDAwLCBtZmRl dj0wDQoJY21kcmVnPTB4MDAwMSwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5z ej0wIChkd29yZHMpDQoJbGF0dGltZXI9MHgxMCAoNDgwIG5zKSwgbWluZ250 PTB4MDIgKDUwMCBucyksIG1heGxhdD0weDA0ICgxMDAwIG5zKQ0KCWludHBp bj1hLCBpcnE9MjU1DQplYnVzMDogcmV2aXNpb24gMHgwMQ0KZWJ1czA6IDxQ Q0ktRUJ1czIgYnJpZGdlPiBtZW0gMHhmMTAwMDAwMC0weGYxN2ZmZmZmLDB4 ZjAwMDAwMDAtMHhmMGZmZmZmZiBhdCBkZXZpY2UgMS4wIG9uIHBjaTENCmVi dXMwOiA8YXV4aW8+IGFkZHIgMHgxNDAwNzJmMDAwLTB4MTQwMDcyZjAwMyww eDE0MDA3MmMwMDAtMHgxNDAwNzJjMDAzLDB4MTQwMDcyYTAwMC0weDE0MDA3 MmEwMDMsMHgxNDAwNzI4MDAwLTB4MTQwMDcyODAwMywweDE0MDA3MjYwMDAt MHgxNDAwNzI2MDAzIChubyBkcml2ZXIgYXR0YWNoZWQpDQplYnVzMDogPHBv d2VyPiBhZGRyIDB4MTQwMDcyNDAwMC0weDE0MDA3MjQwMDMgaXJxIDM3IChu byBkcml2ZXIgYXR0YWNoZWQpDQplYnVzMDogPFNVTlcscGxsPiBhZGRyIDB4 MTQwMDUwNDAwMC0weDE0MDA1MDQwMDIgKG5vIGRyaXZlciBhdHRhY2hlZCkN CnBjaWIxOiBkZXZpY2Ugc2FiMCByZXF1ZXN0ZWQgZGVjb2RlZCBtZW1vcnkg cmFuZ2UgMHhmMTQwMDAwMC0weGYxNDAwMDdmDQplYnVzMDogPHNlPiBhZGRy IDB4MTQwMDQwMDAwMC0weDE0MDA0MDAwN2YgaXJxIDQzIChubyBkcml2ZXIg YXR0YWNoZWQpDQplYnVzMDogPHN1PiBhZGRyIDB4MTQwMDMwODNmOC0weDE0 MDAzMDgzZmYgaXJxIDQxIChubyBkcml2ZXIgYXR0YWNoZWQpDQplYnVzMDog PHN1PiBhZGRyIDB4MTQwMDMwNjJmOC0weDE0MDAzMDYyZmYgaXJxIDQyIChu byBkcml2ZXIgYXR0YWNoZWQpDQplYnVzMDogPGVjcHA+IGFkZHIgMHgxNDAw NzAwMDAwLTB4MTQwMDcwMDAwZiwweDE0MDAzMDAxNWMtMHgxNDAwMzAwMTVk LDB4MTQwMDMwNDNiYy0weDE0MDAzMDQzY2IgaXJxIDM0IChubyBkcml2ZXIg YXR0YWNoZWQpDQplYnVzMDogPGZkdGhyZWU+IGFkZHIgMHgxNDAwNzIwMDAw LTB4MTQwMDcyMDAwMywweDE0MDA3MDYwMDAtMHgxNDAwNzA2MDBmLDB4MTQw MDMwMjNmMC0weDE0MDAzMDIzZjcgaXJxIDM5IChubyBkcml2ZXIgYXR0YWNo ZWQpDQplZXByb20wOiA8RUJ1cyBFRVBST00vY2xvY2s+IGFkZHIgMHgxNDAw MDAwMDAwLTB4MTQwMDAwMWZmZiBvbiBlYnVzMA0KcGNpYjE6IGRldmljZSBl ZXByb20wIHJlcXVlc3RlZCBkZWNvZGVkIG1lbW9yeSByYW5nZSAweGYxMDAw MDAwLTB4ZjEwMDFmZmYNCmVlcHJvbTA6IGNvdWxkIG5vdCBhbGxvY2F0ZSBy ZXNvdXJjZXMNCmRldmljZV9wcm9iZV9hbmRfYXR0YWNoOiBlZXByb20wIGF0 dGFjaCByZXR1cm5lZCA2DQplYnVzMDogPGZsYXNocHJvbT4gYWRkciAweDEw MDAwMDAwMDAtMHgxMDAwMGZmZmZmIChubyBkcml2ZXIgYXR0YWNoZWQpDQpl YnVzMDogPFNVTlcsQ1M0MjMxPiBhZGRyIDB4MTQwMDcyMjAwMC0weDE0MDA3 MjIwMDMsMHgxNDAwNzA0MDAwLTB4MTQwMDcwNDAwZiwweDE0MDA3MDIwMDAt MHgxNDAwNzAyMDBmLDB4MTQwMDIwMDAwMC0weDE0MDAyMDAwZmYgaXJxIDM2 LDM1IChubyBkcml2ZXIgYXR0YWNoZWQpDQpobWUwOiA8U3VuIEhNRSAxMC8x MDAgRXRoZXJuZXQ+IG1lbSAweGUwMDAwMDAwLTB4ZTAwMDdmZmYgYXQgZGV2 aWNlIDEuMSBvbiBwY2kxDQpobWUwOiBSZXNlcnZlZCAweDgwMDAgYnl0ZXMg Zm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGUwMDAwMDAwDQptaWlidXMwOiA8 TUlJIGJ1cz4gb24gaG1lMA0KbnNwaHkwOiA8RFA4Mzg0MCAxMC8xMDAgbWVk aWEgaW50ZXJmYWNlPiBvbiBtaWlidXMwDQpuc3BoeTA6ICAxMGJhc2VULCAx MGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCBhdXRvDQpo bWUwOiBicGYgYXR0YWNoZWQNCmhtZTA6IEV0aGVybmV0IGFkZHJlc3M6IDA4 OjAwOjIwOmZmOmMxOmNiDQpobWUwOiBbR0lBTlQtTE9DS0VEXQ0KcGNpMTog PGRpc3BsYXksIFZHQT4gYXQgZGV2aWNlIDIuMCAobm8gZHJpdmVyIGF0dGFj aGVkKQ0KYXRhcGNpMDogPENNRCA2NDYgV0RNQTIgY29udHJvbGxlcj4gcG9y dCAweGMwMDAyMC0weGMwMDAyZiwweGMwMDAxOC0weGMwMDAxYiwweGMwMDAx MC0weGMwMDAxNywweGMwMDAwOC0weGMwMDAwYiwweGMwMDAwMC0weGMwMDAw NyBhdCBkZXZpY2UgMy4wIG9uIHBjaTENCg== --0-101533963-1082653173=:62077 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=SONJA Content-Transfer-Encoding: BASE64 Content-ID: <20040422185933.Q62077@130-149-145-43.dialup.cs.tu-berlin.de> Content-Description: Content-Disposition: attachment; filename=SONJA bWFjaGluZQkJc3BhcmM2NA0KY3B1CQlTVU40VQ0KaWRlbnQJCVNPTkpBDQoN Cm1ha2VvcHRpb25zCURFQlVHPS1nCQkjQnVpbGQga2VybmVsIHdpdGggZ2Ri KDEpIGRlYnVnIHN5bWJvbHMNCg0Kb3B0aW9ucyAJU0NIRURfVUxFCQkjVUxF IHNjaGVkdWxlcg0Kb3B0aW9ucyAJSU5FVAkJCSNJbnRlck5FVHdvcmtpbmcN CiMgb3B0aW9ucyAJSU5FVDYJCQkjSVB2NiBjb21tdW5pY2F0aW9ucyBwcm90 b2NvbHMNCm9wdGlvbnMgCUZGUwkJCSNCZXJrZWxleSBGYXN0IEZpbGVzeXN0 ZW0NCm9wdGlvbnMgCVNPRlRVUERBVEVTCQkjRW5hYmxlIEZGUyBzb2Z0IHVw ZGF0ZXMgc3VwcG9ydA0Kb3B0aW9ucyAJVUZTX0FDTAkJCSNTdXBwb3J0IGZv ciBhY2Nlc3MgY29udHJvbCBsaXN0cw0Kb3B0aW9ucyAJVUZTX0RJUkhBU0gJ CSNJbXByb3ZlIHBlcmZvcm1hbmNlIG9uIGJpZyBkaXJlY3Rvcmllcw0KIyBv cHRpb25zIAlNRF9ST09UCQkJI01EIGlzIGEgcG90ZW50aWFsIHJvb3QgZGV2 aWNlDQpvcHRpb25zIAlORlNDTElFTlQJCSNOZXR3b3JrIEZpbGVzeXN0ZW0g Q2xpZW50DQojIG9wdGlvbnMgCU5GU1NFUlZFUgkJI05ldHdvcmsgRmlsZXN5 c3RlbSBTZXJ2ZXINCm9wdGlvbnMgCU5GU19ST09UCQkjTkZTIHVzYWJsZSBh cyByb290IGRldmljZQ0KI29wdGlvbnMgCU1TRE9TRlMJCQkjTVNET1MgRmls ZXN5c3RlbQ0KIyBvcHRpb25zIAlDRDk2NjAJCQkjSVNPIDk2NjAgRmlsZXN5 c3RlbQ0KIyBvcHRpb25zIAlQUk9DRlMJCQkjUHJvY2VzcyBmaWxlc3lzdGVt IChyZXF1aXJlcyBQU0VVRE9GUykNCiMgb3B0aW9ucyAJUFNFVURPRlMJCSNQ c2V1ZG8tZmlsZXN5c3RlbSBmcmFtZXdvcmsNCm9wdGlvbnMgCUNPTVBBVF80 MwkJI0NvbXBhdGlibGUgd2l0aCBCU0QgNC4zIFtLRUVQIFRISVMhXQ0Kb3B0 aW9ucyAJQ09NUEFUX0ZSRUVCU0Q0CQkjS2VlcCB0aGlzIGZvciBhIHdoaWxl DQpvcHRpb25zIAlTQ1NJX0RFTEFZPTE1MDAwCSNEZWxheSAoaW4gbXMpIGJl Zm9yZSBwcm9iaW5nIFNDU0kgDQojIG9wdGlvbnMgCUtUUkFDRQkJCSNrdHJh Y2UoMSkgc3lzY2FsbCB0cmFjZSBzdXBwb3J0DQojIG9wdGlvbnMgCVNZU1ZT SE0JCQkjU1lTVi1zdHlsZSBzaGFyZWQgbWVtb3J5DQojIG9wdGlvbnMgCVNZ U1ZNU0cJCQkjU1lTVi1zdHlsZSBtZXNzYWdlIHF1ZXVlcw0KIyBvcHRpb25z IAlTWVNWU0VNCQkJI1NZU1Ytc3R5bGUgc2VtYXBob3Jlcw0KI29wdGlvbnMg CV9LUE9TSVhfUFJJT1JJVFlfU0NIRURVTElORyAjUG9zaXggUDEwMDNfMUIg cmVhbC10aW1lIGV4dGVuc2lvbnMNCiMgb3B0aW9ucyAJUEZJTF9IT09LUwkJ IyBwZmlsKDkpIGZyYW1ld29yaw0KDQojIERlYnVnZ2luZyBmb3IgdXNlIGlu IC1jdXJyZW50DQpvcHRpb25zIAlEREIJCQkjRW5hYmxlIHRoZSBrZXJuZWwg ZGVidWdnZXINCiMgb3B0aW9ucyAJSU5WQVJJQU5UUwkJI0VuYWJsZSBjYWxs cyBvZiBleHRyYSBzYW5pdHkgY2hlY2tpbmcNCm9wdGlvbnMgCUlOVkFSSUFO VF9TVVBQT1JUCSNFeHRyYSBzYW5pdHkgY2hlY2tzIG9mIGludGVybmFsIHN0 cnVjdHVyZXMsIHJlcXVpcmVkIGJ5IElOVkFSSUFOVFMNCiMgb3B0aW9ucyAJ V0lUTkVTUwkJCSNFbmFibGUgY2hlY2tzIHRvIGRldGVjdCBkZWFkbG9ja3Mg YW5kIGN5Y2xlcw0KIyBvcHRpb25zIAlXSVRORVNTX1NLSVBTUElOCSNEb24n dCBydW4gd2l0bmVzcyBvbiBzcGlubG9ja3MgZm9yIHNwZWVkDQoNCiMgVG8g bWFrZSBhbiBTTVAga2VybmVsLCB0aGUgbmV4dCBsaW5lIGlzIG5lZWRlZA0K b3B0aW9ucyAJU01QCQkJIyBTeW1tZXRyaWMgTXVsdGlQcm9jZXNzb3IgS2Vy bmVsDQoNCiMgU3RhbmRhcmQgYnVzc2VzDQpkZXZpY2UJCWFwYgkJCSMgU3Vu IEFQQiBQQ0ktUENJIGJyaWRnZQ0KZGV2aWNlCQllYnVzDQpkZXZpY2UJCWlz YQ0KZGV2aWNlCQlwY2kNCmRldmljZQkJc2J1cw0KZGV2aWNlCQljZW50cmFs DQpkZXZpY2UJCWZoYw0KDQpvcHRpb25zIAlPRldfTkVXUENJDQoNCiMgRmxv cHB5IGRyaXZlcw0KIyBkZXZpY2UJCWZkYw0KDQojIEFUQSBhbmQgQVRBUEkg ZGV2aWNlcw0KZGV2aWNlCQlhdGENCmRldmljZQkJYXRhZGlzawkJCSMgQVRB IGRpc2sgZHJpdmVzDQpkZXZpY2UJCWF0YXBpY2QJCQkjIEFUQVBJIENEUk9N IGRyaXZlcw0KI2RldmljZQkJYXRhcGlmZAkJCSMgQVRBUEkgZmxvcHB5IGRy aXZlcw0KI2RldmljZQkJYXRhcGlzdAkJCSMgQVRBUEkgdGFwZSBkcml2ZXMN CiMJRG8gTk9UIGVuYWJsZSBBVEFfU1RBVElDX0lEIC0tIGNtZDY0NiBjb250 cm9sbGVyIHdpbGwgYmUgIWF0YTIhLA0KIwlhbmQgeW91IHdpbGwgbm90IG1v dW50IGFuIEFUQSAvLg0KI29wdGlvbnMgCUFUQV9TVEFUSUNfSUQJCSNTdGF0 aWMgZGV2aWNlIG51bWJlcmluZw0KDQojIFNDU0kgQ29udHJvbGxlcnMNCiNk ZXZpY2UJCWFoYwkJIyBBSEEyOTQwIGFuZCBvbmJvYXJkIEFJQzd4eHggZGV2 aWNlcw0KI2RldmljZQkJaXNwCQkjIFFsb2dpYyBmYW1pbHkNCiNkZXZpY2UJ CW1wdAkJIyBMU0ktTG9naWMgTVBULUZ1c2lvbiAobm90IHlldCkNCiNkZXZp Y2UJCWlzcGZ3CQkjIEZpcm13YXJlIG1vZHVsZSBmb3IgUWxvZ2ljIGhvc3Qg YWRhcHRlcnMNCiNkZXZpY2UJCW5jcgkJIyBOQ1IvU3ltYmlvcyBMb2dpYw0K I2RldmljZQkJc3ltCQkjIE5DUi9TeW1iaW9zIExvZ2ljIChuZXdlciBjaGlw c2V0cyArIHRob3NlIG9mIGBuY3InKQ0KDQojIFNDU0kgcGVyaXBoZXJhbHMN CiNkZXZpY2UJCXNjYnVzCQkjIFNDU0kgYnVzIChyZXF1aXJlZCBmb3IgU0NT SSkNCiNkZXZpY2UJCWNoCQkjIFNDU0kgbWVkaWEgY2hhbmdlcnMNCiNkZXZp Y2UJCWRhCQkjIERpcmVjdCBBY2Nlc3MgKGRpc2tzKQ0KI2RldmljZQkJc2EJ CSMgU2VxdWVudGlhbCBBY2Nlc3MgKHRhcGUgZXRjKQ0KI2RldmljZQkJY2QJ CSMgQ0QNCiNkZXZpY2UJCXBhc3MJCSMgUGFzc3Rocm91Z2ggZGV2aWNlIChk aXJlY3QgU0NTSSBhY2Nlc3MpDQojZGV2aWNlCQlzZXMJCSMgU0NTSSBFbnZp cm9ubWVudGFsIFNlcnZpY2VzIChhbmQgU0FGLVRFKQ0KDQojIFJBSUQgY29u dHJvbGxlcnMNCiNkZXZpY2UJCWFtcgkJIyBBTUkgTWVnYVJBSUQNCiNkZXZp Y2UJCW1seAkJIyBNeWxleCBEQUM5NjAgZmFtaWx5DQoNCg0KIyBzeXNjb25z IGlzIHRoZSBkZWZhdWx0IGNvbnNvbGUgZHJpdmVyLCByZXNlbWJsaW5nIGFu IFNDTyBjb25zb2xlDQojZGV2aWNlCQlzYw0KI2RldmljZQkJY3JlYXRvcgkJ IyBDcmVhdG9yIGdyYXBoaWNzIGNhcmRzDQojZGV2aWNlCQlzcGxhc2gJCSMg U3BsYXNoIHNjcmVlbiBhbmQgc2NyZWVuIHNhdmVyIHN1cHBvcnQNCiNvcHRp b25zCQlLQkRfSU5TVEFMTF9DREVWDQoNCmRldmljZQkJb2Z3X2NvbnNvbGUJ IyBPcGVuQm9vdCBmaXJtd2FyZSBjb25zb2xlIGRldmljZQ0KDQojIEJ1aWx0 aW4gaGFyZHdhcmUNCmRldmljZQkJZ2VuY2xvY2sJIyBHZW5lcmljIGNsb2Nr IGludGVyZmFjZQ0KZGV2aWNlCQllZXByb20JCSMgZWVwcm9tIChyZWFsbHkg YW4gZWJ1cyBkcml2ZXIgZm9yIHRoZSBNSzQ4VHh4KQ0KZGV2aWNlCQkibWs0 OHR4eCIJIyBNb3N0ZWsgTUs0OFQwMiwgTUs0OFQwOCwgTUs0OFQ1OSBjbG9j aw0KDQojIFNlcmlhbCAoQ09NKSBwb3J0cw0KZGV2aWNlCQlzYWIJCSMgU2ll bWVucyBTQUI4MjUzMiBiYXNlZCBzZXJpYWwgcG9ydHMNCmRldmljZQkJenMJ CSMgWmlsb2cgODUzMCBiYXNlZCBzZXJpYWwgcG9ydHMNCiNkZXZpY2UJCXVh cnQJCSMgTXVsdGktdWFydCBkcml2ZXINCiNkZXZpY2UJCXB1YwkJIyBNdWx0 aS1jaGFubmVsIHVhcnRzDQoNCiMgUGFyYWxsZWwgcG9ydA0KI2RldmljZQkJ cHBjDQojZGV2aWNlCQlwcGJ1cwkJIyBQYXJhbGxlbCBwb3J0IGJ1cyAocmVx dWlyZWQpDQojZGV2aWNlCQlscHQJCSMgUHJpbnRlcg0KI2RldmljZQkJcGxp cAkJIyBUQ1AvSVAgb3ZlciBwYXJhbGxlbA0KI2RldmljZQkJcHBpCQkjIFBh cmFsbGVsIHBvcnQgaW50ZXJmYWNlIGRldmljZQ0KI2RldmljZQkJdnBvCQkj IFJlcXVpcmVzIHNjYnVzIGFuZCBkYQ0KIA0KIyBQQ0kgRXRoZXJuZXQgTklD cy4NCiNkZXZpY2UJCWRlCQkjIERFQy9JbnRlbCBEQzIxeDR4IChgYFR1bGlw JycpDQojZGV2aWNlCQlsbmMJCSMgTkUyMTAwLCBORTMyLVZMIExhbmNlIEV0 aGVybmV0IGNhcmRzDQojZGV2aWNlCQl0eHAJCSMgM0NvbSAzY1I5OTAgKGBg VHlwaG9vbicnKQ0KI2RldmljZQkJdngJCSMgM0NvbSAzYzU5MCwgM2M1OTUg KGBgVm9ydGV4JycpDQoNCiMgUENJIEV0aGVybmV0IE5JQ3MgdGhhdCB1c2Ug dGhlIGNvbW1vbiBNSUkgYnVzIGNvbnRyb2xsZXIgY29kZS4NCmRldmljZQkJ bWlpYnVzCQkjIE1JSSBidXMgc3VwcG9ydA0KI2RldmljZQkJZGMJCSMgREVD L0ludGVsIDIxMTQzIGFuZCB3b3JrYWxpa2VzDQojZGV2aWNlCQlmeHAJCSMg SW50ZWwgRXRoZXJFeHByZXNzIFBSTy8xMDBCICg4MjU1NywgODI1NTgpDQoj ZGV2aWNlCQlnZW0JCSMgU3VuIEdFTS9TdW4gRVJJL0FwcGxlIEdNQUMNCmRl dmljZQkJaG1lCQkjIFN1biBITUUgKEhhcHB5IE1lYWwgRXRoZXJuZXQpDQoj ZGV2aWNlCQlwY24JCSMgQU1EIEFtNzlDOTd4IFBDSSAxMC8xMDAgTklDcw0K I2RldmljZQkJcmUJCSMgUmVhbFRlayA4MTM5QysvODE2OS84MTY5Uy84MTEw Uw0KI2RldmljZQkJcmwJCSMgUmVhbFRlayA4MTI5LzgxMzkNCiNkZXZpY2UJ CXNmCQkjIEFkYXB0ZWMgQUlDLTY5MTUgKGBgU3RhcmZpcmUnJykNCiNkZXZp Y2UJCXNpcwkJIyBTaWxpY29uIEludGVncmF0ZWQgU3lzdGVtcyBTaVMgOTAw L1NpUyA3MDE2DQojZGV2aWNlCQlzdGUJCSMgU3VuZGFuY2UgU1QyMDEgKEQt TGluayBERkUtNTUwVFgpDQojZGV2aWNlCQl0bAkJIyBUZXhhcyBJbnN0cnVt ZW50cyBUaHVuZGVyTEFODQojZGV2aWNlCQl2cgkJIyBWSUEgUmhpbmUsIFJo aW5lIElJDQojZGV2aWNlCQl3YgkJIyBXaW5ib25kIFc4OUM4NDBGDQojZGV2 aWNlCQl4bAkJIyAzQ29tIDNjOTB4IChgYEJvb21lcmFuZycnLCBgYEN5Y2xv bmUnJykNCg0KIyBQc2V1ZG8gZGV2aWNlcyAtIHRoZSBudW1iZXIgaW5kaWNh dGVzIGhvdyBtYW55IHVuaXRzIHRvIGFsbG9jYXRlZC4NCiNkZXZpY2UJCXJh bmRvbQkJIyBFbnRyb3B5IGRldmljZQ0KZGV2aWNlCQlsb29wCQkjIE5ldHdv cmsgbG9vcGJhY2sNCmRldmljZQkJZXRoZXIJCSMgRXRoZXJuZXQgc3VwcG9y dA0KI2RldmljZQkJc2wJCSMgS2VybmVsIFNMSVANCiNkZXZpY2UJCXBwcAkJ IyBLZXJuZWwgUFBQDQpkZXZpY2UJCXR1bgkJIyBQYWNrZXQgdHVubmVsLg0K ZGV2aWNlCQlwdHkJCSMgUHNldWRvLXR0eXMgKHRlbG5ldCBldGMpDQojZGV2 aWNlCQltZAkJIyBNZW1vcnkgImRpc2tzIg0KI2RldmljZQkJZ2lmCQkjIElQ djYgYW5kIElQdjQgdHVubmVsaW5nDQojZGV2aWNlCQlmYWl0aAkJIyBJUHY2 LXRvLUlQdjQgcmVsYXlpbmcvKHRyYW5zbGF0aW9uKQ0KDQojIFRoZSBgYnBm JyBkZXZpY2UgZW5hYmxlcyB0aGUgQmVya2VsZXkgUGFja2V0IEZpbHRlci4N CiMgQmUgYXdhcmUgb2YgdGhlIGFkbWluaXN0cmF0aXZlIGNvbnNlcXVlbmNl cyBvZiBlbmFibGluZyB0aGlzIQ0KZGV2aWNlCQlicGYJCSNCZXJrZWxleSBw YWNrZXQgZmlsdGVyDQoNCiMgVVNCIHN1cHBvcnQNCiNkZXZpY2UJCXVoY2kJ CSMgVUhDSSBQQ0ktPlVTQiBpbnRlcmZhY2UNCiNkZXZpY2UJCW9oY2kJCSMg T0hDSSBQQ0ktPlVTQiBpbnRlcmZhY2UNCiNkZXZpY2UJCXVzYgkJIyBVU0Ig QnVzIChyZXF1aXJlZCkNCiNkZXZpY2UJCXVnZW4JCSMgR2VuZXJpYw0KI2Rl dmljZQkJdWhpZAkJIyAiSHVtYW4gSW50ZXJmYWNlIERldmljZXMiDQojZGV2 aWNlCQl1a2JkCQkjIEtleWJvYXJkDQojZGV2aWNlCQl1bHB0CQkjIFByaW50 ZXINCiNkZXZpY2UJCXVtYXNzCQkjIERpc2tzL01hc3Mgc3RvcmFnZSAtIFJl cXVpcmVzIHNjYnVzIGFuZCBkYTANCiNkZXZpY2UJCXVtcwkJIyBNb3VzZQ0K IyBVU0IgRXRoZXJuZXQNCiNkZXZpY2UJCWF1ZQkJIyBBRE10ZWsgVVNCIGV0 aGVybmV0DQojZGV2aWNlCQlheGUJCSMgQVNJWCBFbGVjdHJvbmljcyBVU0Ig ZXRoZXJuZXQNCiNkZXZpY2UJCWN1ZQkJIyBDQVRDIFVTQiBldGhlcm5ldA0K I2RldmljZQkJa3VlCQkjIEthd2FzYWtpIExTSSBVU0IgZXRoZXJuZXQNCg0K IyBGaXJlV2lyZSBzdXBwb3J0DQojZGV2aWNlCQlmaXJld2lyZQkjIEZpcmVX aXJlIGJ1cyBjb2RlDQojZGV2aWNlCQlzYnAJCSMgU0NTSSBvdmVyIEZpcmVX aXJlIChSZXF1aXJlcyBzY2J1cyBhbmQgZGEpDQojZGV2aWNlCQlmd2UJCSMg RXRoZXJuZXQgb3ZlciBGaXJlV2lyZSAobm9uLXN0YW5kYXJkISkNCg== --0-101533963-1082653173=:62077-- From owner-freebsd-sparc64@FreeBSD.ORG Thu Apr 22 10:10:48 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 6076916A4CE; Thu, 22 Apr 2004 10:10:48 -0700 (PDT) Received: from electra.cse.Buffalo.EDU (electra.cse.Buffalo.EDU [128.205.32.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1342043D5C; Thu, 22 Apr 2004 10:10:48 -0700 (PDT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from electra.cse.Buffalo.EDU (localhost [127.0.0.1]) i3MHAl8o015271; Thu, 22 Apr 2004 13:10:47 -0400 (EDT) Received: (from kensmith@localhost) by electra.cse.Buffalo.EDU (8.12.10/8.12.9/Submit) id i3MHAlHZ015270; Thu, 22 Apr 2004 13:10:47 -0400 (EDT) Date: Thu, 22 Apr 2004 13:10:47 -0400 From: Ken Smith To: harti@freebsd.org Message-ID: <20040422171047.GB13967@electra.cse.Buffalo.EDU> References: <20040422185744.J62077@130-149-145-43.dialup.cs.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040422185744.J62077@130-149-145-43.dialup.cs.tu-berlin.de> User-Agent: Mutt/1.4.1i cc: sparc64@freebsd.org Subject: Re: RTC on ultra-10 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, 22 Apr 2004 17:10:48 -0000 On Thu, Apr 22, 2004 at 06:59:33PM +0200, Harti Brandt wrote: > has anybody an idea why the eeprom does not attach on my ultra-10? The > result is that I have no RTC. Attached is the verbose boot and the config. Yup, version 1.238 of src/sys/dev/pci/pci.c. :-) I've been told Thomas is working on a patch so I stopped looking into it. Warner has also been told that this broke a few things, I'm not sure if he's working on it though. This is third-hand info that originated at Thomas, and might be suffering from interpretation on my part: This version of pci.c pre-allocates PCI resources at the point the PCI-to-Ebus bridge attaches. However this range of resources that gets pre-allocated includes the devices which then want to be attached via the Ebus so when the attach routine for these Ebus devices gets run the attach fails because the resources they want are already "claimed". Any inaccuracies in that are due to me and not Thomas... :-) -- 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 Fri Apr 23 08:54: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 2BC8016A4CE; Fri, 23 Apr 2004 08:54:33 -0700 (PDT) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 422B243D1D; Fri, 23 Apr 2004 08:54:32 -0700 (PDT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) i3NFsROY024184; Fri, 23 Apr 2004 17:54:31 +0200 (CEST) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.10/8.12.10/Submit) id i3NFsMlU024183; Fri, 23 Apr 2004 17:54:22 +0200 (CEST) (envelope-from marius) Date: Fri, 23 Apr 2004 17:54:22 +0200 From: Marius Strobl To: harti@freebsd.org Message-ID: <20040423175422.A24101@newtrinity.zeist.de> References: <20040422185744.J62077@130-149-145-43.dialup.cs.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040422185744.J62077@130-149-145-43.dialup.cs.tu-berlin.de>; from novo@cs.tu-berlin.de on Thu, Apr 22, 2004 at 06:59:33PM +0200 X-AntiVirus: checked by AntiVir Milter 1.1-beta; AVE 6.25.0.2; VDF 6.25.0.27 (host: newtrinity.zeist.de) cc: sparc64@freebsd.org Subject: Re: RTC on ultra-10 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, 23 Apr 2004 15:54:33 -0000 On Thu, Apr 22, 2004 at 06:59:33PM +0200, Harti Brandt wrote: > > Hi all, > > has anybody an idea why the eeprom does not attach on my ultra-10? The > result is that I have no RTC. Attached is the verbose boot and the config. > Revision 1.248 of src/sys/dev/pci/pci.c contains a stopgap fix for this until we have a proper solution. From owner-freebsd-sparc64@FreeBSD.ORG Fri Apr 23 09:54: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 8405A16A4CE for ; Fri, 23 Apr 2004 09:54:18 -0700 (PDT) Received: from Gina.esfm.ipn.mx (esfm.ipn.mx [148.204.102.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id C218E43D46 for ; Fri, 23 Apr 2004 09:54:17 -0700 (PDT) (envelope-from mrspock@esfm.ipn.mx) Received: from Gina.esfm.ipn.mx (localhost [127.0.0.1]) by Gina.esfm.ipn.mx (8.12.10/8.12.10) with ESMTP id i3NGs43l005228 for ; Fri, 23 Apr 2004 11:54:04 -0500 (CDT) (envelope-from mrspock@esfm.ipn.mx) Received: from localhost (mrspock@localhost)i3NGs2xp005224 for ; Fri, 23 Apr 2004 11:54:02 -0500 (CDT) (envelope-from mrspock@esfm.ipn.mx) X-Authentication-Warning: Gina.esfm.ipn.mx: mrspock owned process doing -bs Date: Fri, 23 Apr 2004 11:54:02 -0500 (CDT) From: Eduardo Viruena Silva To: sparc64@FreeBSD.org Message-ID: <20040423112801.Q2184@Gina.esfm.ipn.mx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Fast Data Access MMU Miss (fwd) 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, 23 Apr 2004 16:54:18 -0000 Hello, FreeBSD gurus! Some days ago, I sent this message to freebsd-questions@freebsd.org. > Hello, FreeBSD gurus! > > We have a Sun Microsystem Blade 2000 computer. > > I tried to install FreeBSD on it, > when I try to boot from my FreeBSD-5.2.1 CD, > the loader seems to start working and > suddenly it issues this message: > > Fast Data Access MMU Miss > > and dies. > > Do you have any idea of what is happening? > My disc worked ok in an old Sparc 10. ------------------- I received this message, some hours later -------------------- See the following URL on how to obtain debugging information from the panic: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html and post full details to sparc64@FreeBSD.org --------------------- The problem is that the computer is barely booting from its CD because I am trying to install the operating system. I cannot send the debug information. Perhaps if I make my computer start diskless... I'll try but I wonder if you have any better idea. Thanks in advance. From owner-freebsd-sparc64@FreeBSD.ORG Fri Apr 23 10:39:00 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 4EBA216A4CE for ; Fri, 23 Apr 2004 10:39:00 -0700 (PDT) Received: from electra.cse.Buffalo.EDU (electra.cse.Buffalo.EDU [128.205.32.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00A6043D5C for ; Fri, 23 Apr 2004 10:39:00 -0700 (PDT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from electra.cse.Buffalo.EDU (localhost [127.0.0.1]) i3NHcv8o000492; Fri, 23 Apr 2004 13:38:57 -0400 (EDT) Received: (from kensmith@localhost) by electra.cse.Buffalo.EDU (8.12.10/8.12.9/Submit) id i3NHcvVp000490; Fri, 23 Apr 2004 13:38:57 -0400 (EDT) Date: Fri, 23 Apr 2004 13:38:57 -0400 From: Ken Smith To: Eduardo Viruena Silva Message-ID: <20040423173857.GD28521@electra.cse.Buffalo.EDU> References: <20040423112801.Q2184@Gina.esfm.ipn.mx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040423112801.Q2184@Gina.esfm.ipn.mx> User-Agent: Mutt/1.4.1i cc: sparc64@freebsd.org Subject: Re: Fast Data Access MMU Miss (fwd) 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, 23 Apr 2004 17:39:00 -0000 On Fri, Apr 23, 2004 at 11:54:02AM -0500, Eduardo Viruena Silva wrote: > > We have a Sun Microsystem Blade 2000 computer. > > > > I tried to install FreeBSD on it, > > when I try to boot from my FreeBSD-5.2.1 CD, > > the loader seems to start working and > > suddenly it issues this message: > > > > Fast Data Access MMU Miss > > > > and dies. > > > > Do you have any idea of what is happening? > > My disc worked ok in an old Sparc 10. Sorry but FreeBSD doesn't run on UltraSparc-III processors yet and I think that's what is in the SunBlade 2000 machines. -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel |