From owner-freebsd-sparc64@FreeBSD.ORG Mon May 17 11:01:44 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5656F16A4CE for ; Mon, 17 May 2004 11:01:44 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12F3F43D54 for ; Mon, 17 May 2004 11:01:44 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) i4HI1hXM097671 for ; Mon, 17 May 2004 11:01:43 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i4HI1hZA097665 for freebsd-sparc64@freebsd.org; Mon, 17 May 2004 11:01:43 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 17 May 2004 11:01:43 -0700 (PDT) Message-Id: <200405171801.i4HI1hZA097665@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, 17 May 2004 18:01:44 -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 o [2004/05/05] sparc64/66314sparc64 SMP kernel panic: ipi_send: couldn't send o [2004/05/13] sparc64/66622sparc64 ypwhich returns bogus data 3 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Mon May 17 13:25:55 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4ADE16A4CE for ; Mon, 17 May 2004 13:25:55 -0700 (PDT) Received: from listsvr1.telepac.pt (indico.telepac.pt [194.65.3.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id B198643D45 for ; Mon, 17 May 2004 13:25:50 -0700 (PDT) (envelope-from telepac.info-request@mail.telepac.pt) To: freebsd-sparc@freebsd.org From: telepac.info-request@mail.telepac.pt Precedence: bulk Date: Mon, 17 May 2004 21:25:45 +0100 Message-ID: <20040517202545.AAA8819@listsvr1.telepac.pt> MIME-Version: 1.0 Content-Type: text/plain Subject: List Manager response X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Reply-To: telepac.info-request@mail.telepac.pt List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2004 20:25:55 -0000 >>>> This is a multi-part message in MIME format. **** Command 'this' not recognized. **** No valid commands found. **** Commands must be in message BODY, not in HEADER. **** Help for telepac.info-request@mail.telepac.pt: Introduction to the List Manager -------------------------------- This is the Mailing List Manager for Post.Office version v3.5.3. The interface is similar to Brent Chapman's "Majordomo". How to Access the List Manager ------------------------------ You can interact with the List Manager by sending commands in the body of an E-mail message addressed to "telepac.info-request@mail.telepac.pt". (Important Note: Commands in the "Subject:" line are NOT processed.) Available List Manager Commands ------------------------------- The Post.Office Mailing List Manager understands the following commands: (Note: In the descriptions below items contained in []'s are optional. When providing the item, do not include the []'s around it.) subscribe [
] Subscribe yourself (or
if specified) to the named . unsubscribe [
] Unsubscribe yourself (or
if specified) from the named . which Find out which lists you are on. who Find out who is on the named . info Retrieve the general introductory information for the named . lists Show the lists served by this List Manager server. help Retrieve this message. end Stop processing commands (useful if your mailer adds a signature). From owner-freebsd-sparc64@FreeBSD.ORG Mon May 17 17:32: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 C8AD916A4CE for ; Mon, 17 May 2004 17:32:39 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8325943D60 for ; Mon, 17 May 2004 17:32:39 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc11) with ESMTP id <20040518003237011000nu5ie>; Tue, 18 May 2004 00:32:38 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA31176 for ; Mon, 17 May 2004 17:32:37 -0700 (PDT) Date: Mon, 17 May 2004 17:32:35 -0700 (PDT) From: Julian Elischer To: sparc64@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: (again) sparc64 kernel code question.. (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: Tue, 18 May 2004 00:32:40 -0000 sorry about cross posting but I meant to send this to sparc64@ ---------- Forwarded message ---------- Date: Mon, 17 May 2004 17:29:50 -0700 (PDT) From: Julian Elischer To: Thomas Moestl Cc: FreeBSD current users Subject: Re: (again) sparc64 kernel code question.. Sorry for the long delay but... On Mon, 10 May 2004, Thomas Moestl wrote: > On Sun, 2004/05/09 at 15:44:40 -0700, Julian Elischer wrote: > > in vm_machdep.c the sparc64 code has > > void > > cpu_sched_exit(struct thread *td) > > { > > struct vmspace *vm; > > struct pcpu *pc; > > struct proc *p; > > > > mtx_assert(&sched_lock, MA_OWNED); > > > > p = td->td_proc; > > vm = p->p_vmspace; > > if (vm->vm_refcnt > 1) > > return; > > SLIST_FOREACH(pc, &cpuhead, pc_allcpu) { > > if (pc->pc_vmspace == vm) { > > vm->vm_pmap.pm_active &= ~pc->pc_cpumask; > > vm->vm_pmap.pm_context[pc->pc_cpuid] = -1; > > pc->pc_vmspace = NULL; > > } > > } > > } > > > > > > > > This is thw only architecture that has this.. > > What does it do? And what does it have to do with the scheduler? > > To quote from the commit log: > date: 2002/06/24 15:48:01; author: jake; state: Exp; lines: +1 -0 > Add an MD callout like cpu_exit, but which is called after sched_lock is > obtained, when all other scheduling activity is suspended. This is needed > on sparc64 to deactivate the vmspace of the exiting process on all cpus. > Otherwise if another unrelated process gets the exact same vmspace structure > allocated to it (same address), its address space will not be activated > properly. This seems to fix some spontaneous signal 11 problems with smp > on sparc64. > > To elaborate on that a bit: > The sparc64 cpu_switch() has an optimization to avoid needlessly > invalidating TLB entries: when we switch to a kernel thread, we need > not switch VM contexts at all, and do with whatever vmspace was active > before. When we switch to a thread that has the vmspace that is > already in use currently, we need not load a new context register > value (which is analog to flushing the TLB). > > We identify vmspaces by their pointers for this purpose, so there can > be a race between freeing the struct vmspace by wait()ing (on another > processor) and switching to another thread (on the first > processor). Specifically, the first processor could be switching to a > newly created thread that has the same struct vmspace that was just > freed, so we would mistakenly assume that we need not bother loading > the context register, and continue using outdated TLB entries. > > To prevent this, cpu_sched_exit() zeros the respective PCPU variables > holding the active vmspace if it is going to be destroyed, so it will > never match any other during the next cpu_switch(). > This seems to be the wrong answer to me.. Surely the answer is to accuratly reference count the vmspace so that it is never recycled if another entity is still using it? The answer would be for wait() to free the last vmspace reference, not to lie about it.. This sort of hack requires inside knowledge to understand and is not robust across kernel changes.. > - Thomas _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-sparc64@FreeBSD.ORG Tue May 18 16:12: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 B029016A622; Tue, 18 May 2004 16:12:24 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id D952044058; Tue, 18 May 2004 13:15:28 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc13) with ESMTP id <20040518195738015008hofse>; Tue, 18 May 2004 19:57:38 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA42764; Tue, 18 May 2004 12:57:35 -0700 (PDT) Date: Tue, 18 May 2004 12:57:34 -0700 (PDT) From: Julian Elischer To: Thomas Moestl In-Reply-To: <20040510010301.GA6829@timesink.dyndns.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD current users cc: sparc64@freebsd.org Subject: Re: sparc64 kernel code question.. 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, 18 May 2004 23:12:33 -0000 looking at this code again and the description as to why it is there.. On Mon, 10 May 2004, Thomas Moestl wrote: > On Sun, 2004/05/09 at 15:44:40 -0700, Julian Elischer wrote: > > in vm_machdep.c the sparc64 code has > > void > > cpu_sched_exit(struct thread *td) > > { > > struct vmspace *vm; > > struct pcpu *pc; > > struct proc *p; > > > > mtx_assert(&sched_lock, MA_OWNED); > > > > p = td->td_proc; > > vm = p->p_vmspace; > > if (vm->vm_refcnt > 1) > > return; > > SLIST_FOREACH(pc, &cpuhead, pc_allcpu) { > > if (pc->pc_vmspace == vm) { > > vm->vm_pmap.pm_active &= ~pc->pc_cpumask; > > vm->vm_pmap.pm_context[pc->pc_cpuid] = -1; > > pc->pc_vmspace = NULL; > > } > > } > > } > > > > > > > > This is thw only architecture that has this.. > > What does it do? And what does it have to do with the scheduler? to answer question 2,, nothing.. in my sources I renamed it to cpu_exit2() > > To quote from the commit log: > date: 2002/06/24 15:48:01; author: jake; state: Exp; lines: +1 -0 > Add an MD callout like cpu_exit, but which is called after sched_lock is > obtained, when all other scheduling activity is suspended. This is needed > on sparc64 to deactivate the vmspace of the exiting process on all cpus. > Otherwise if another unrelated process gets the exact same vmspace structure > allocated to it (same address), its address space will not be activated > properly. This seems to fix some spontaneous signal 11 problems with smp > on sparc64. > > To elaborate on that a bit: > The sparc64 cpu_switch() has an optimization to avoid needlessly > invalidating TLB entries: when we switch to a kernel thread, we need > not switch VM contexts at all, and do with whatever vmspace was active > before. When we switch to a thread that has the vmspace that is > already in use currently, we need not load a new context register > value (which is analog to flushing the TLB). > > We identify vmspaces by their pointers for this purpose, so there can > be a race between freeing the struct vmspace by wait()ing (on another > processor) and switching to another thread (on the first > processor). Specifically, the first processor could be switching to a > newly created thread that has the same struct vmspace that was just > freed, so we would mistakenly assume that we need not bother loading > the context register, and continue using outdated TLB entries. > > To prevent this, cpu_sched_exit() zeros the respective PCPU variables > holding the active vmspace if it is going to be destroyed, so it will > never match any other during the next cpu_switch(). I'm not convinced that this is valid.. consider.. When you cycle through the processors above and remove the pointers to the vmspace, then proceed to destroy this vmspace, there is nothing done to make sure that the other procerssors are actually not USING the page tables etc. associated with the vmspace. If we reclame the page tables.. surely there is a danger that another cpu by still be using them? I think that even "temporary" users of vmspaces, such as kernel threads, should have reference counts and be capable of freeing the vmspace should it go to 0 when they complete using it. > > - Thomas > > -- > Thomas Moestl http://www.tu-bs.de/~y0015675/ > http://people.FreeBSD.org/~tmm/ > "I try to make everyone's day a little more surreal." > -- Calvin and Hobbes > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-sparc64@FreeBSD.ORG Tue May 18 16:12: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 98FF416A663 for ; Tue, 18 May 2004 16:12:36 -0700 (PDT) Received: from hawk.dcu.ie (mail.dcu.ie [136.206.1.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id F30E943FC6 for ; Tue, 18 May 2004 13:05:52 -0700 (PDT) (envelope-from mark@redbrick.dcu.ie) Received: from deathray.redbrick.dcu.ie (136.206.15.3) by hawk.dcu.ie (7.0.016) id 406A6C3800298024 for freebsd-sparc64@freebsd.org; Tue, 18 May 2004 21:03:54 +0100 Received: from carbon.redbrick.dcu.ie ([2001:770:107:15:206:5bff:fefc:fb70] ident=mail) by deathray.redbrick.dcu.ie with esmtp (Exim 4.31) id 1BQAob-0005RR-LH for freebsd-sparc64@freebsd.org; Tue, 18 May 2004 21:03:53 +0100 Received: from mark by carbon.redbrick.dcu.ie with local (Exim 3.35 #1 (Debian)) id 1BQAob-0005mE-00 for ; Tue, 18 May 2004 21:03:53 +0100 Date: Tue, 18 May 2004 15:03:53 -0500 From: Mark Campbell To: freebsd-sparc64@freebsd.org Message-ID: <20040518200353.GA2502@carbon.redbrick.dcu.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Subject: make buildkernel problem. 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, 18 May 2004 23:12:46 -0000 Hey Guys, I've not much experience with FreeBSD on Sparc64, however I've never had many problems with building the generic kernel on other hardware platforms. The compile bained out at this stage.. cc -c -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/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /usr/src/sys/sparc64/sparc64/elf_machdep.c /usr/src/sys/sparc64/sparc64/elf_machdep.c: In function `elf_reloc': /usr/src/sys/sparc64/sparc64/elf_machdep.c:283: warning: declaration of `relocbase' shadows a parameter *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 I know this is way too little information, I'm just wondering what else you need me to provide and I'll forward it on. Can replies also be cc'd to me. Thanks in advance, as I said I'm a little stumped because there's no obvious issues and the buildworld worked without trouble. -- regards, -mark - Mark Campbell http://mark.redbrick.dcu.ie - "Trying is the first step towards Failure"- Homer J. Simpson From owner-freebsd-sparc64@FreeBSD.ORG Tue May 18 18:20:58 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A088516A4ED; Tue, 18 May 2004 18:20:58 -0700 (PDT) Received: from adslsapo-b4-143-68.telepac.pt (adslsapo-b4-143-68.telepac.pt [81.193.143.68]) by mx1.FreeBSD.org (Postfix) with SMTP id A516643D4C; Tue, 18 May 2004 18:20:18 -0700 (PDT) (envelope-from BoyerSandy@kingsley.co.za) From: Benoit-Charlotte To: freebsd-sparc64@freebsd.org Message-Id: Date: Tue, 18 May 2004 21:17:07 -0500 Content-Transfer-Encoding: 7Bit MIME-Version: 1.0 Content-Type: text/plain; charset="ascii-us" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Benoit-Charlotte List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2004 01:20:58 -0000 Freebsd-sparc64 ascend starlet baneberry tetrachloride counterfeit curiosity aldehyde teach dakota downwind superstition Email is Loading . . . . [1][world.jpg] Image not Showin}g? [2] S.a.v.e up.to 7O.%+, O.r.d.e.r H.e.r.e ahmedabad freeway herdsman disastrous kilgore spleenwort roundhouse typeface compulsive dollop plural snuggly confidant impasse deplore abet knightsbridge borough societal mitten precinct niacin viz etymology inaugurate cluster causal hasn't credo cold eugene smug accrue noise cupid versatile croquet infra chiton descend evolve corbett finger dairyman glossolalia embellish bryophyta greenfield technique foamy alveolus lengthy defuse circulate exhibitor repulsion baptiste minstrel skillful usia bonaventure aspirin crabapple coplanar catharsis cancelling extensive bacterial slash crud cinquefoil hellgrammite adulterate checkbook skyhook remunerate robin intercom constructible cranberry paul arid stuffy dirichlet acme broadloom cogent bind chastise efferent cod thermistor miami craven blister cuttlebone jessica moribund sunlight boastful mcknight karamazov lessen dairymen butch reciprocal candelabra pelt sinew danube juvenile palmate asynchrony musician glob acme rice alyssum paramus palsy tipperary besotted potpourri anatomy sacrament woods basilisk glance potpourri vitreous beech field tugging suzanne circumpolar contumacy daybed acorn furtive firewood hog bust attendant advise sepulchral allegoric trace messenger nottingham saskatoon sumatra civic boeing anthracnose spec collector caricature haitian calendar corporate thomistic dove commissariat twirly anticipate deity broadloom back eject jag artery intuitive devilish madhouse dusky sidelong disneyland latitude paunchy exegesis ale eat traffic colonnade deliquescent danubian forceful willow committee countryman simonson lineal pawnshop waveguide silt contrary pfizer yaqui eel convulse mortar toothbrush decent barnard passaic see broccoli pocketbook fair marceau confucius mortgagee bacilli degassing educate disciplinary legato impatient dendrite burton edison indecomposable excelled oust habib miscegenation funereal elliptic acrobatic gastronome caught eidetic wigmake e 's equitable gazette cue octahedral legitimate desicate grindstone potboil sri ashmen appellant bad mendacity pumpkin improve stanch wyandotte bechtel earthmoving loblolly audible garcia amputee orbital tomorrow wive cerberus advisee andes birdwatch cultivate saturable business geodetic combustion lase rudolf animosity indies inflater transpiration ragweed assiduous bissau deja sultanate chautauqua premise brazil reliquary References 1. http://www.asmwn1.com/gp/default.asp?id=SBL 2. http://www.asnzbe21.com/gp/default.asp?id=SBL From owner-freebsd-sparc64@FreeBSD.ORG Tue May 18 18:20:58 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A088516A4ED; Tue, 18 May 2004 18:20:58 -0700 (PDT) Received: from adslsapo-b4-143-68.telepac.pt (adslsapo-b4-143-68.telepac.pt [81.193.143.68]) by mx1.FreeBSD.org (Postfix) with SMTP id A516643D4C; Tue, 18 May 2004 18:20:18 -0700 (PDT) (envelope-from BoyerSandy@kingsley.co.za) From: Benoit-Charlotte To: freebsd-sparc64@freebsd.org Message-Id: Date: Tue, 18 May 2004 21:17:07 -0500 Content-Transfer-Encoding: 7Bit MIME-Version: 1.0 Content-Type: text/plain; charset="ascii-us" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Benoit-Charlotte List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2004 01:20:59 -0000 Freebsd-sparc64 ascend starlet baneberry tetrachloride counterfeit curiosity aldehyde teach dakota downwind superstition Email is Loading . . . . [1][world.jpg] Image not Showin}g? [2] S.a.v.e up.to 7O.%+, O.r.d.e.r H.e.r.e ahmedabad freeway herdsman disastrous kilgore spleenwort roundhouse typeface compulsive dollop plural snuggly confidant impasse deplore abet knightsbridge borough societal mitten precinct niacin viz etymology inaugurate cluster causal hasn't credo cold eugene smug accrue noise cupid versatile croquet infra chiton descend evolve corbett finger dairyman glossolalia embellish bryophyta greenfield technique foamy alveolus lengthy defuse circulate exhibitor repulsion baptiste minstrel skillful usia bonaventure aspirin crabapple coplanar catharsis cancelling extensive bacterial slash crud cinquefoil hellgrammite adulterate checkbook skyhook remunerate robin intercom constructible cranberry paul arid stuffy dirichlet acme broadloom cogent bind chastise efferent cod thermistor miami craven blister cuttlebone jessica moribund sunlight boastful mcknight karamazov lessen dairymen butch reciprocal candelabra pelt sinew danube juvenile palmate asynchrony musician glob acme rice alyssum paramus palsy tipperary besotted potpourri anatomy sacrament woods basilisk glance potpourri vitreous beech field tugging suzanne circumpolar contumacy daybed acorn furtive firewood hog bust attendant advise sepulchral allegoric trace messenger nottingham saskatoon sumatra civic boeing anthracnose spec collector caricature haitian calendar corporate thomistic dove commissariat twirly anticipate deity broadloom back eject jag artery intuitive devilish madhouse dusky sidelong disneyland latitude paunchy exegesis ale eat traffic colonnade deliquescent danubian forceful willow committee countryman simonson lineal pawnshop waveguide silt contrary pfizer yaqui eel convulse mortar toothbrush decent barnard passaic see broccoli pocketbook fair marceau confucius mortgagee bacilli degassing educate disciplinary legato impatient dendrite burton edison indecomposable excelled oust habib miscegenation funereal elliptic acrobatic gastronome caught eidetic wigmake e 's equitable gazette cue octahedral legitimate desicate grindstone potboil sri ashmen appellant bad mendacity pumpkin improve stanch wyandotte bechtel earthmoving loblolly audible garcia amputee orbital tomorrow wive cerberus advisee andes birdwatch cultivate saturable business geodetic combustion lase rudolf animosity indies inflater transpiration ragweed assiduous bissau deja sultanate chautauqua premise brazil reliquary References 1. http://www.asmwn1.com/gp/default.asp?id=SBL 2. http://www.asnzbe21.com/gp/default.asp?id=SBL From owner-freebsd-sparc64@FreeBSD.ORG Wed May 19 02:11:25 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 BBA6116A4CE for ; Wed, 19 May 2004 02:11:25 -0700 (PDT) Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 224F343D3F for ; Wed, 19 May 2004 02:11:25 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (ba3180a425979cd720ce775fb9388f1b@adsl-67-115-73-128.dsl.lsan03.pacbell.net [67.115.73.128])i4INRcsR022439; Tue, 18 May 2004 18:27:39 -0500 (CDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 003F854947; Tue, 18 May 2004 16:27:37 -0700 (PDT) Date: Tue, 18 May 2004 16:27:37 -0700 From: Kris Kennaway To: Mark Campbell Message-ID: <20040518232737.GA43306@xor.obsecurity.org> References: <20040518200353.GA2502@carbon.redbrick.dcu.ie> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <20040518200353.GA2502@carbon.redbrick.dcu.ie> User-Agent: Mutt/1.4.2.1i cc: freebsd-sparc64@freebsd.org Subject: Re: make buildkernel problem. 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, 19 May 2004 09:11:25 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 18, 2004 at 03:03:53PM -0500, Mark Campbell wrote: > Hey Guys, >=20 > I've not much experience with FreeBSD on Sparc64, however I've never had = many > problems with building the generic kernel on other hardware platforms. T= he > compile bained out at this stage.. >=20 > cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-ex= terns > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast= -qual > -fformat-extensions -std=3Dc99 -g -nostdinc -I- -I. -I/usr/src/sys > -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter > -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath > -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KE= RNEL > -include opt_global.h -fno-common -finline-limit=3D15000 -mcmodel=3Dmedl= ow > -msoft-float -ffreestanding -Werror > /usr/src/sys/sparc64/sparc64/elf_machdep.c > /usr/src/sys/sparc64/sparc64/elf_machdep.c: In function `elf_reloc': > /usr/src/sys/sparc64/sparc64/elf_machdep.c:283: warning: declaration of > `relocbase' shadows a parameter > *** Error code 1 >=20 > Stop in /usr/obj/usr/src/sys/GENERIC. > *** Error code 1 >=20 > I know this is way too little information, I'm just wondering what else y= ou > need me to provide and I'll forward it on. Can replies also be cc'd to m= e. > Thanks in advance, as I said I'm a little stumped because there's no obvi= ous > issues and the buildworld worked without trouble. You didn't mention which sources you're trying to build, but it looks like you're building -CURRENT. Update and try again, this is likely fixed by now. Kris --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAqpvpWry0BWjoQKURArsxAKDFcpNnjjOrCPu/1oGQUnTgPEfjPACffzme OhaIjdpLs683POV9Q0gT2O4= =FR2l -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-sparc64@FreeBSD.ORG Wed May 19 12:30:25 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 3D46816A4CE; Wed, 19 May 2004 12:30:25 -0700 (PDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDC7B43D39; Wed, 19 May 2004 12:30:24 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc13) with ESMTP id <2004051919300801600aqt3ie>; Wed, 19 May 2004 19:30:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA58251; Wed, 19 May 2004 12:30:04 -0700 (PDT) Date: Wed, 19 May 2004 12:30:01 -0700 (PDT) From: Julian Elischer To: Thomas Moestl In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD current users cc: sparc64@freebsd.org Subject: Re: sparc64 question.. Anyone out there? 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, 19 May 2004 19:30:25 -0000 Is there anyone out there who really understands this? On Tue, 18 May 2004, Julian Elischer wrote: > > looking at this code again and the description as to why it is there.. > > > On Mon, 10 May 2004, Thomas Moestl wrote: > > > On Sun, 2004/05/09 at 15:44:40 -0700, Julian Elischer wrote: > > > in vm_machdep.c the sparc64 code has > > > void > > > cpu_sched_exit(struct thread *td) > > > { > > > struct vmspace *vm; > > > struct pcpu *pc; > > > struct proc *p; > > > > > > mtx_assert(&sched_lock, MA_OWNED); > > > > > > p = td->td_proc; > > > vm = p->p_vmspace; > > > if (vm->vm_refcnt > 1) > > > return; > > > SLIST_FOREACH(pc, &cpuhead, pc_allcpu) { > > > if (pc->pc_vmspace == vm) { > > > vm->vm_pmap.pm_active &= ~pc->pc_cpumask; > > > vm->vm_pmap.pm_context[pc->pc_cpuid] = -1; > > > pc->pc_vmspace = NULL; > > > } > > > } > > > } > > > > > > > > > > > > This is thw only architecture that has this.. > > > What does it do? And what does it have to do with the scheduler? > > to answer question 2,, > nothing.. in my sources I renamed it to cpu_exit2() > > > > > > To quote from the commit log: > > date: 2002/06/24 15:48:01; author: jake; state: Exp; lines: +1 -0 > > Add an MD callout like cpu_exit, but which is called after sched_lock is > > obtained, when all other scheduling activity is suspended. This is needed > > on sparc64 to deactivate the vmspace of the exiting process on all cpus. > > Otherwise if another unrelated process gets the exact same vmspace structure > > allocated to it (same address), its address space will not be activated > > properly. This seems to fix some spontaneous signal 11 problems with smp > > on sparc64. > > > > To elaborate on that a bit: > > The sparc64 cpu_switch() has an optimization to avoid needlessly > > invalidating TLB entries: when we switch to a kernel thread, we need > > not switch VM contexts at all, and do with whatever vmspace was active > > before. When we switch to a thread that has the vmspace that is > > already in use currently, we need not load a new context register > > value (which is analog to flushing the TLB). > > > > We identify vmspaces by their pointers for this purpose, so there can > > be a race between freeing the struct vmspace by wait()ing (on another > > processor) and switching to another thread (on the first > > processor). Specifically, the first processor could be switching to a > > newly created thread that has the same struct vmspace that was just > > freed, so we would mistakenly assume that we need not bother loading > > the context register, and continue using outdated TLB entries. > > > > To prevent this, cpu_sched_exit() zeros the respective PCPU variables > > holding the active vmspace if it is going to be destroyed, so it will > > never match any other during the next cpu_switch(). > > I'm not convinced that this is valid.. > consider.. > When you cycle through the processors above and remove the pointers to > the vmspace, then proceed to destroy this vmspace, there is nothing done > to make sure that the other procerssors are actually > not USING the page tables etc. associated with the vmspace. > > If we reclame the page tables.. surely there is a danger that another > cpu by still be using them? > > I think that even "temporary" users of vmspaces, such as kernel threads, > should have reference counts and be capable of freeing the vmspace > should it go to 0 when they complete using it. > > > > > > > > - Thomas > > > > -- > > Thomas Moestl http://www.tu-bs.de/~y0015675/ > > http://people.FreeBSD.org/~tmm/ > > "I try to make everyone's day a little more surreal." > > -- Calvin and Hobbes > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-sparc64@FreeBSD.ORG Wed May 19 12:37: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 0230316A4CE; Wed, 19 May 2004 12:37:19 -0700 (PDT) Received: from electra.cse.Buffalo.EDU (electra.cse.Buffalo.EDU [128.205.32.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A646F43D55; Wed, 19 May 2004 12:37:18 -0700 (PDT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from electra.cse.Buffalo.EDU (localhost [127.0.0.1]) i4JJb88o019405; Wed, 19 May 2004 15:37:08 -0400 (EDT) Received: (from kensmith@localhost) by electra.cse.Buffalo.EDU (8.12.10/8.12.9/Submit) id i4JJb7mD019404; Wed, 19 May 2004 15:37:07 -0400 (EDT) Date: Wed, 19 May 2004 15:37:07 -0400 From: Ken Smith To: Julian Elischer Message-ID: <20040519193707.GB18584@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: Thomas Moestl cc: FreeBSD current users cc: sparc64@freebsd.org Subject: Re: sparc64 question.. Anyone out there? 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, 19 May 2004 19:37:19 -0000 On Wed, May 19, 2004 at 12:30:01PM -0700, Julian Elischer wrote: > Is there anyone out there who really understands this? I can't speak for anyone else. For my part I don't understand it yet and other FreeBSD stuff has distracted me from Sparc-64 temporarily. When the other distraction is finished (should be early next week) I'll get back to this stuff. My general target is KSE on sparc64 so what you're talking about now will be of great interest. :-) As always anyone else is welcome to chime in, work on it, etc. If nobody else does I'll be getting around to at least looking at it starting next week. -- 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 May 19 13:31:02 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 3E05816A4CE; Wed, 19 May 2004 13:31:02 -0700 (PDT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C55E343D2D; Wed, 19 May 2004 13:31:01 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i4JKU5pS027105; Wed, 19 May 2004 16:30:06 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Wed, 19 May 2004 16:30:04 -0400 To: Julian Elischer , Thomas Moestl From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: FreeBSD current users cc: sparc64@freebsd.org Subject: Re: sparc64 question.. Anyone out there? 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, 19 May 2004 20:31:02 -0000 At 12:30 PM -0700 5/19/04, Julian Elischer wrote: >Is there anyone out there who really understands this? I do not, but I will be happy to cheer from the sidelines and hope that someone else does understand it... :-) >On Tue, 18 May 2004, Julian Elischer wrote: > > > > >> > To quote from the commit log: > > > date: 2002/06/24 15:48:01; author: jake; > > > Add an MD callout like cpu_exit, but which is called after > > > sched_lock is obtained, when all other scheduling activity > > > is suspended. This is needed on sparc64 to deactivate the > > > vmspace of the exiting process on all cpus. Otherwise if > > > another unrelated process gets the exact same vmspace > > > structure allocated to it (same address), its address space > > > will not be activated properly. This seems to fix some > > > spontaneous signal 11 problems with smp on sparc64. > > > >> > To elaborate on that a bit: >> > The sparc64 cpu_switch() has an optimization to avoid needlessly > > > invalidating TLB entries: when we switch to a kernel thread, > > > we need not switch VM contexts at all, and do with whatever > > > vmspace was active before. When we switch to a thread that > > > has the vmspace that is already in use currently, we need > > > not load a new context register value (which is analog to > > > flushing the TLB). > > > > > > We identify vmspaces by their pointers for this purpose, so > > > there can be a race between freeing the struct vmspace by > > > wait()ing (on another processor) and switching to another > > > thread (on the first processor). Specifically, the first > > > processor could be switching to a newly created thread that > > > has the same struct vmspace that was just freed, so we would > > > mistakenly assume that we need not bother loading the context > > > register, and continue using outdated TLB entries. > > > > > > To prevent this, cpu_sched_exit() zeros the respective PCPU > > > variables holding the active vmspace if it is going to be > > > destroyed, so it will never match any other during the next > > > cpu_switch(). > > > > I'm not convinced that this is valid. > > consider: > > When you cycle through the processors above and remove the > > pointers to the vmspace, then proceed to destroy this vmspace, > > there is nothing done to make sure that the other procerssors > > are actually not USING the page tables etc. associated with > > the vmspace. > > > > If we reclame the page tables.. surely there is a danger that > > another cpu by still be using them? > > > > I think that even "temporary" users of vmspaces, such as kernel > > threads, should have reference counts and be capable of freeing > > the vmspace should it go to 0 when they complete using it. -- 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 Wed May 19 21:19:04 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F114D16A4CE; Wed, 19 May 2004 21:19:03 -0700 (PDT) Received: from k6.locore.ca (k6.locore.ca [216.58.85.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DB3F43D2F; Wed, 19 May 2004 21:19:03 -0700 (PDT) (envelope-from jake@locore.ca) Received: by k6.locore.ca (Postfix, from userid 1000) id 9AF46A923; Thu, 20 May 2004 00:18:24 -0400 (EDT) Date: Thu, 20 May 2004 00:18:24 -0400 From: Jake Burkholder To: Julian Elischer Message-ID: <20040520041824.GA6503@locore.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: Thomas Moestl cc: FreeBSD current users cc: sparc64@freebsd.org Subject: Re: sparc64 question.. Anyone out there? 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, 20 May 2004 04:19:04 -0000 > > I'm not convinced that this is valid.. > > consider.. > > When you cycle through the processors above and remove the pointers to > > the vmspace, then proceed to destroy this vmspace, there is nothing done > > to make sure that the other procerssors are actually > > not USING the page tables etc. associated with the vmspace. The reference count on the vmspace. > > > > If we reclame the page tables.. surely there is a danger that another > > cpu by still be using them? No because there is only one kernel page table and all cpus start using it implicitly when they enter the kernel. Jake From owner-freebsd-sparc64@FreeBSD.ORG Thu May 20 05:24:23 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0990716A4CE for ; Thu, 20 May 2004 05:24:23 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 4FFC543D1D for ; Thu, 20 May 2004 05:24:22 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 22166 invoked by uid 65534); 20 May 2004 12:24:08 -0000 Received: from p50907346.dip.t-dialin.net (EHLO timesink.dyndns.org) (80.144.115.70) by mail.gmx.net (mp017) with SMTP; 20 May 2004 14:24:08 +0200 X-Authenticated: #5374206 Received: by abel (Postfix, from userid 1001) id C79CE6D1; Thu, 20 May 2004 14:24:12 +0200 (CEST) Date: Thu, 20 May 2004 14:24:11 +0200 From: Thomas Moestl To: Julian Elischer Message-ID: <20040520122411.GA795@timesink.dyndns.org> References: <20040510010301.GA6829@timesink.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: FreeBSD current users cc: sparc64@freebsd.org Subject: Re: sparc64 kernel code question.. 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, 20 May 2004 12:24:23 -0000 On Tue, 2004/05/18 at 12:57:34 -0700, Julian Elischer wrote: > On Mon, 10 May 2004, Thomas Moestl wrote: > > On Sun, 2004/05/09 at 15:44:40 -0700, Julian Elischer wrote: > > > in vm_machdep.c the sparc64 code has > > > void > > > cpu_sched_exit(struct thread *td) > > > { > > > struct vmspace *vm; > > > struct pcpu *pc; > > > struct proc *p; > > > > > > mtx_assert(&sched_lock, MA_OWNED); > > > > > > p = td->td_proc; > > > vm = p->p_vmspace; > > > if (vm->vm_refcnt > 1) > > > return; > > > SLIST_FOREACH(pc, &cpuhead, pc_allcpu) { > > > if (pc->pc_vmspace == vm) { > > > vm->vm_pmap.pm_active &= ~pc->pc_cpumask; > > > vm->vm_pmap.pm_context[pc->pc_cpuid] = -1; > > > pc->pc_vmspace = NULL; > > > } > > > } > > > } > > > > > > > > > > > > This is thw only architecture that has this.. > > > What does it do? And what does it have to do with the scheduler? > > to answer question 2,, > nothing.. in my sources I renamed it to cpu_exit2() The name probably derives from the fact that it needs to be called after the sched lock is obtained, as was mentioned in the commit message. > > To quote from the commit log: > > date: 2002/06/24 15:48:01; author: jake; state: Exp; lines: +1 -0 > > Add an MD callout like cpu_exit, but which is called after sched_lock is > > obtained, when all other scheduling activity is suspended. This is needed > > on sparc64 to deactivate the vmspace of the exiting process on all cpus. > > Otherwise if another unrelated process gets the exact same vmspace structure > > allocated to it (same address), its address space will not be activated > > properly. This seems to fix some spontaneous signal 11 problems with smp > > on sparc64. > > > > To elaborate on that a bit: > > The sparc64 cpu_switch() has an optimization to avoid needlessly > > invalidating TLB entries: when we switch to a kernel thread, we need > > not switch VM contexts at all, and do with whatever vmspace was active > > before. When we switch to a thread that has the vmspace that is > > already in use currently, we need not load a new context register > > value (which is analog to flushing the TLB). > > > > We identify vmspaces by their pointers for this purpose, so there can > > be a race between freeing the struct vmspace by wait()ing (on another > > processor) and switching to another thread (on the first > > processor). Specifically, the first processor could be switching to a > > newly created thread that has the same struct vmspace that was just > > freed, so we would mistakenly assume that we need not bother loading > > the context register, and continue using outdated TLB entries. > > > > To prevent this, cpu_sched_exit() zeros the respective PCPU variables > > holding the active vmspace if it is going to be destroyed, so it will > > never match any other during the next cpu_switch(). > > I'm not convinced that this is valid.. > consider.. > When you cycle through the processors above and remove the pointers to > the vmspace, then proceed to destroy this vmspace, there is nothing done > to make sure that the other procerssors are actually > not USING the page tables etc. associated with the vmspace. > > If we reclame the page tables.. surely there is a danger that another > cpu by still be using them? No. The code will only invalidate the vmspace pointers on the exit of the last process that uses them; it will therefore primarily do so on the CPU that is processing the exit(). The other case, as mentioned above, can happen due to the switch optimization that keeps the vmspace of the switched-out process when switching to a kernel thread. Kernel threads only need kernel mappings, which are global, so they will never access the active vmspace or its pmap (sparc64 has different TSBs, which are somewhat analogue to page tables, for kernel and user space, and only the user space one is kept in the pmap, the kernel one being global). So, there are two cases for the per-CPU vmspace pointer: - the vmspace was used by the currently running thread. The thread is the last one using it, and exiting, so we can zero the vmspace pointer and free the vmspace. - the vmspace is not used by the currently running thread, which is a kernel thread. It is kept only as a hint that we can optimize a switch-back to that vmspace. This optimization is not possible any more, so we can zero the vmspace pointer, and free the vmspace which a kernel thread does not use. > I think that even "temporary" users of vmspaces, such as kernel threads, > should have reference counts and be capable of freeing the vmspace > should it go to 0 when they complete using it. That would require reference counting at switch time, which would be prohibitively expensive (requiring Giant, for example). Also, it would complicate the freeing of vmspaces in the rest of the kernel code. As mentioned above, kernel threads do not use the vmspace themselves; it is just kept as a hint for later switching. The per-CPU vmspace pointers are not a strong reference, which needs to stay valid; rather, they are a weak reference, and we just need notification in case they become invalid. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ "The most crucial career decision is picking a good 'ism' so everyone knows how to categorize you without understanding the work." -- Calvin and Hobbes From owner-freebsd-sparc64@FreeBSD.ORG Thu May 20 08:11:27 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A96D716A4CE; Thu, 20 May 2004 08:11:27 -0700 (PDT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4778243D1D; Thu, 20 May 2004 08:11:27 -0700 (PDT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smtp3.sentex.ca (8.12.11/8.12.11) with ESMTP id i4KFBDfP021582; Thu, 20 May 2004 11:11:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i4KFBFfR015151; Thu, 20 May 2004 11:11:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E7FF47303D; Thu, 20 May 2004 11:11:14 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040520151114.E7FF47303D@freebsd-current.sentex.ca> Date: Thu, 20 May 2004 11:11: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: Thu, 20 May 2004 15:11:27 -0000 TB --- 2004-05-20 14:20:14 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-05-20 14:20:14 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-05-20 14:20:14 - checking out the source tree TB --- 2004-05-20 14:20:14 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64 TB --- 2004-05-20 14:20:14 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-05-20 14:25:30 - building world (CFLAGS=-O2 -pipe) TB --- 2004-05-20 14:25:30 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src TB --- 2004-05-20 14:25:30 - /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 -DPTHREAD_KERNEL -D_THREAD_SAFE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../../include -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_autoinit.c cc -O2 -pipe -DPTHREAD_KERNEL -D_THREAD_SAFE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../../include -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_barrier.c cc -O2 -pipe -DPTHREAD_KERNEL -D_THREAD_SAFE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../../include -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_barrierattr.c cc -O2 -pipe -DPTHREAD_KERNEL -D_THREAD_SAFE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../../include -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_cancel.c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_cancel.c: In function `_pthread_cancel': /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_cancel.c:30: warning: passing arg 1 of `atomic_cmpset_int' from incompatible pointer type /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_cancel.c: In function `testcancel': /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_cancel.c:123: warning: passing arg 1 of `atomic_cmpset_int' from incompatible pointer type *** Error code 1 Stop in /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr. *** 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-05-20 15:11:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-05-20 15:11:14 - ERROR: failed to build world TB --- 2004-05-20 15:11:14 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Thu May 20 12:38:51 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 689AF16A4D0 for ; Thu, 20 May 2004 12:38:51 -0700 (PDT) Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.246]) by mx1.FreeBSD.org (Postfix) with SMTP id 4C02C43D41 for ; Thu, 20 May 2004 12:38:51 -0700 (PDT) (envelope-from drosihn@gmail.com) Received: by mproxy.gmail.com with SMTP id u33so56191cwc for ; Thu, 20 May 2004 12:38:45 -0700 (PDT) Received: by 10.11.98.15 with SMTP id v15mr144092cwb; Thu, 20 May 2004 12:38:45 -0700 (PDT) Message-ID: <97880ae040520123841ba954e@mail.gmail.com> Date: Thu, 20 May 2004 15:38:45 -0400 From: Garance Drosehn To: Thomas Moestl In-Reply-To: <20040520122411.GA795@timesink.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040510010301.GA6829@timesink.dyndns.org> <20040520122411.GA795@timesink.dyndns.org> cc: sparc64@freebsd.org cc: Julian Elischer cc: FreeBSD current users Subject: Re: sparc64 kernel code question.. 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, 20 May 2004 19:38:51 -0000 On Thu, 20 May 2004 14:24:11 +0200, Thomas Moestl wrote: > > On Tue, 2004/05/18 at 12:57:34 -0700, Julian Elischer wrote: > > to answer question 2... > > nothing.. in my sources I renamed it to cpu_exit2() > > The name probably derives from the fact that it needs to be called > after the sched lock is obtained, as was mentioned in the commit > message. Maybe call it: cpu_exit_postsched() :-) From owner-freebsd-sparc64@FreeBSD.ORG Thu May 20 12:47: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 B76B116A4CE; Thu, 20 May 2004 12:47:38 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7075F43D41; Thu, 20 May 2004 12:47:38 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <2004052019473701400j9node>; Thu, 20 May 2004 19:47:37 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA73762; Thu, 20 May 2004 12:47:36 -0700 (PDT) Date: Thu, 20 May 2004 12:47:34 -0700 (PDT) From: Julian Elischer To: Jake Burkholder In-Reply-To: <20040520041824.GA6503@locore.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Thomas Moestl cc: FreeBSD current users cc: sparc64@freebsd.org Subject: Re: sparc64 question.. Anyone out there? 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, 20 May 2004 19:47:38 -0000 Firstly, thanks for explaining this to me.. On Thu, 20 May 2004, Jake Burkholder wrote: > > > I'm not convinced that this is valid.. > > > consider.. > > > When you cycle through the processors above and remove the pointers to > > > the vmspace, then proceed to destroy this vmspace, there is nothing done > > > to make sure that the other procerssors are actually > > > not USING the page tables etc. associated with the vmspace. > > The reference count on the vmspace. > > > > > > > If we reclame the page tables.. surely there is a danger that another > > > cpu by still be using them? > > No because there is only one kernel page table and all cpus start using > it implicitly when they enter the kernel. So there are no other resources associated with a vmspace than the page table used at this point, and since they are using the special kernel page table instead, it doesn't matter if it goes away.. All that matters is that processors not try use it again if they are already in the kernel, and have a cached reverence to it.. I assume this is the scenario: processor 1 runs processA, then enters the kernel fo rsome reason becomes idle... processor 2 gets an interrupt and winds up continuing process A. processor 2 calls exit() from process A. processor 2 calls wait() from process C and frees the vm. processor 1 still has a reference to process A's vmspace which has been freed. Since the vmspace is still in existence until wait() is called, removing all the other references as should be safe. WHy does cpu_exit() not just do this work itself? Just because of the schedlock? All the architectures are calling a stub cpu_sched_exit() just for the sake of the sparc optimisation. DO you see this optimisation being eventually applied to other architectures? Thanks for your patience. > From owner-freebsd-sparc64@FreeBSD.ORG Thu May 20 12:58: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 DBA0C16A4CE; Thu, 20 May 2004 12:58:31 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3A0243D2F; Thu, 20 May 2004 12:58:31 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <2004052019582101400jaorme>; Thu, 20 May 2004 19:58:21 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA73903; Thu, 20 May 2004 12:58:20 -0700 (PDT) Date: Thu, 20 May 2004 12:58:19 -0700 (PDT) From: Julian Elischer To: Garance Drosehn In-Reply-To: <97880ae040520123841ba954e@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: sparc64@freebsd.org cc: Thomas Moestl cc: FreeBSD current users Subject: Re: sparc64 kernel code question.. 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, 20 May 2004 19:58:32 -0000 On Thu, 20 May 2004, Garance Drosehn wrote: > On Thu, 20 May 2004 14:24:11 +0200, Thomas Moestl wrote: > > > > On Tue, 2004/05/18 at 12:57:34 -0700, Julian Elischer wrote: > > > to answer question 2... > > > nothing.. in my sources I renamed it to cpu_exit2() > > > > The name probably derives from the fact that it needs to be called > > after the sched lock is obtained, as was mentioned in the commit > > message. but the naming conventions we use has 'sched' to mean that it is related to the scheduler. Probably a scheduler specific callout, just as 'cpu_' means a callout to a cpu-specific mechanism. cpu_sched_ indicates that it is a per-cpu/per-scheduler special case callout. in fac tit is not it is prely for sparc64 use and it is in exit so cpu_exit_{something} would be in order.. We also have historical examples of using mumbble() and mumble2() when a function needs to be called in 2 parts due to some external requirement, so cpu_exit() and cpu_exit2() would be the names by my logic.. certainly _sched_ is wrong.. > > Maybe call it: cpu_exit_postsched() > :-) it is not post_sched maybe cpu_exit_locked() would be more descriptive. From owner-freebsd-sparc64@FreeBSD.ORG Thu May 20 13:39: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 656DB16A4CE; Thu, 20 May 2004 13:39:22 -0700 (PDT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0476E43D45; Thu, 20 May 2004 13:39:22 -0700 (PDT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smtp3.sentex.ca (8.12.11/8.12.11) with ESMTP id i4KKdHVG062827; Thu, 20 May 2004 16:39:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i4KKdKDZ090998; Thu, 20 May 2004 16:39:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 418497303D; Thu, 20 May 2004 16:39:21 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040520203921.418497303D@freebsd-current.sentex.ca> Date: Thu, 20 May 2004 16:39: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: Thu, 20 May 2004 20:39:22 -0000 TB --- 2004-05-20 19:51:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-05-20 19:51:00 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-05-20 19:51:00 - checking out the source tree TB --- 2004-05-20 19:51:00 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64 TB --- 2004-05-20 19:51:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-05-20 19:56:36 - building world (CFLAGS=-O2 -pipe) TB --- 2004-05-20 19:56:36 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src TB --- 2004-05-20 19:56:36 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -DPTHREAD_KERNEL -D_THREAD_SAFE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../../include -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_autoinit.c cc -O2 -pipe -DPTHREAD_KERNEL -D_THREAD_SAFE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../../include -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_barrier.c cc -O2 -pipe -DPTHREAD_KERNEL -D_THREAD_SAFE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../../include -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_barrierattr.c cc -O2 -pipe -DPTHREAD_KERNEL -D_THREAD_SAFE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../../include -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_cancel.c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_cancel.c: In function `_pthread_cancel': /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_cancel.c:30: warning: passing arg 1 of `atomic_cmpset_int' from incompatible pointer type /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_cancel.c: In function `testcancel': /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_cancel.c:123: warning: passing arg 1 of `atomic_cmpset_int' from incompatible pointer type *** Error code 1 Stop in /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr. *** 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-05-20 20:39:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-05-20 20:39:21 - ERROR: failed to build world TB --- 2004-05-20 20:39:21 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Thu May 20 13:43:17 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A1BE16A4CE; Thu, 20 May 2004 13:43:17 -0700 (PDT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C27643D46; Thu, 20 May 2004 13:43:17 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i4KKh7pS029739; Thu, 20 May 2004 16:43:07 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040428224819.A86269@newtrinity.zeist.de> References: <200404281956.i3SJuZxU033263@repoman.freebsd.org> <20040428202237.GA49702@xor.obsecurity.org> <20040428224819.A86269@newtrinity.zeist.de> Date: Thu, 20 May 2004 16:43:06 -0400 To: Marius Strobl , Kris Kennaway From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: current@freebsd.org cc: sparc64@freebsd.org Subject: Re: 32-bit time in (Re: cvs commit: ports/net/pppd23...) 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, 20 May 2004 20:43:17 -0000 At 10:48 PM +0200 4/28/04, Marius Strobl wrote: >On Wed, Apr 28, 2004 at 01:22:37PM -0700, Kris Kennaway wrote: >> > > I wonder if this 32-bitness is related to the accounting > > problems noticed on sparc64 since the 64-bit time_t > > changeover: > > >> struct lastlog { >> int32_t ll_time; >> char ll_line[UT_LINESIZE]; >> char ll_host[UT_HOSTSIZE]; >> }; >> >> struct utmp { >> char ut_line[UT_LINESIZE]; >> char ut_name[UT_NAMESIZE]; >> char ut_host[UT_HOSTSIZE]; >> int32_t ut_time; >> }; >> > >Like I said before, this isn't a sparc64 specific problem, I also >see it on my -current i386 boxes: > >tristan# uname -a >FreeBSD tristan.franken.de 5.2-CURRENT FreeBSD 5.2-CURRENT #0: Wed >Apr 28 22:11:03 CEST 2004 >root@tristan.franken.de:/usr/src/sys/i386/compile/tristan i386 >tristan# /etc/periodic/monthly/200.accounting > >Doing login accounting: >(Skipped 709 of 739 records due to invalid time values) >(Changed 3 of 739 records to have a more likely time value) > root -65080.69 > marius -136664.62 > total -201745.32 > >I think it's connected to SCHED_ULE, but haven't checked that >closely, yet. It isn't documented in the man page, but you could compile /usr/src/usr.sbin/ac with CFLAGS+=-DDEBUG and then run: ac -D -p -w /var/log/wtmp to see a lot more detail about each run. I have the makefile compile `ac' with DEBUG for sparc64. I did not do that for the other architectures because I thought this problem was specific to 64-bit time_t. (in fact, I'm pretty sure that no one complained about this problem on sparc64 until we went to 64-bTT). I still haven't seen this error on my own systems. I'm surprised that you see such a high percentage of suspect records. I'm also surprised that you still ended up with such bogus results even after `ac' has skipped over all the suspect records! -- 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 Fri May 21 02:49:05 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 CBA8E16A4CE; Fri, 21 May 2004 02:49:05 -0700 (PDT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 767ED43D1F; Fri, 21 May 2004 02:49:05 -0700 (PDT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i4L9mona040800; Fri, 21 May 2004 05:48:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i4L9mobh019973; Fri, 21 May 2004 05:48:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 438847303D; Fri, 21 May 2004 05:48:50 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040521094850.438847303D@freebsd-current.sentex.ca> Date: Fri, 21 May 2004 05:48:50 -0400 (EDT) Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2004 09:49:06 -0000 TB --- 2004-05-21 08:53:31 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-05-21 08:53:31 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-05-21 08:53:31 - checking out the source tree TB --- 2004-05-21 08:53:31 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64 TB --- 2004-05-21 08:53:31 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-05-21 08:58:50 - building world (CFLAGS=-O2 -pipe) TB --- 2004-05-21 08:58:50 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src TB --- 2004-05-21 08:58:50 - /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 -DPTHREAD_KERNEL -D_THREAD_SAFE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../../include -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_autoinit.c cc -O2 -pipe -DPTHREAD_KERNEL -D_THREAD_SAFE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../../include -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_barrier.c cc -O2 -pipe -DPTHREAD_KERNEL -D_THREAD_SAFE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../../include -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_barrierattr.c cc -O2 -pipe -DPTHREAD_KERNEL -D_THREAD_SAFE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../../include -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_cancel.c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_cancel.c: In function `_pthread_cancel': /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_cancel.c:30: warning: passing arg 1 of `atomic_cmpset_int' from incompatible pointer type /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_cancel.c: In function `testcancel': /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_cancel.c:123: warning: passing arg 1 of `atomic_cmpset_int' from incompatible pointer type *** Error code 1 Stop in /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr. *** 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-05-21 09:48:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-05-21 09:48:49 - ERROR: failed to build world TB --- 2004-05-21 09:48:49 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Fri May 21 15:29: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 63B7616A4CF; Fri, 21 May 2004 15:29:19 -0700 (PDT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BE1843D39; Fri, 21 May 2004 15:29:18 -0700 (PDT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i4LMTEdw098810; Fri, 21 May 2004 18:29:14 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i4LMTE1j042220; Fri, 21 May 2004 18:29:14 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 69C727303D; Fri, 21 May 2004 18:29:14 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040521222914.69C727303D@freebsd-current.sentex.ca> Date: Fri, 21 May 2004 18:29: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: Fri, 21 May 2004 22:29:19 -0000 TB --- 2004-05-21 21:33:34 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-05-21 21:33:34 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-05-21 21:33:34 - checking out the source tree TB --- 2004-05-21 21:33:34 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64 TB --- 2004-05-21 21:33:34 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-05-21 21:38:53 - building world (CFLAGS=-O2 -pipe) TB --- 2004-05-21 21:38:53 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src TB --- 2004-05-21 21:38:53 - /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 -DPTHREAD_KERNEL -D_THREAD_SAFE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../../include -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_autoinit.c cc -O2 -pipe -DPTHREAD_KERNEL -D_THREAD_SAFE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../../include -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_barrier.c cc -O2 -pipe -DPTHREAD_KERNEL -D_THREAD_SAFE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../../include -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_barrierattr.c cc -O2 -pipe -DPTHREAD_KERNEL -D_THREAD_SAFE -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../libc/include -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread -I/other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/../../include -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_cancel.c /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_cancel.c: In function `_pthread_cancel': /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_cancel.c:30: warning: passing arg 1 of `atomic_cmpset_int' from incompatible pointer type /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_cancel.c: In function `testcancel': /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr/thread/thr_cancel.c:123: warning: passing arg 1 of `atomic_cmpset_int' from incompatible pointer type *** Error code 1 Stop in /other/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthr. *** 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-05-21 22:29:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-05-21 22:29:14 - ERROR: failed to build world TB --- 2004-05-21 22:29:14 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Sat May 22 08:03:15 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9015D16A4CE for ; Sat, 22 May 2004 08:03:15 -0700 (PDT) Received: from herb.port11.net (port11.net [69.93.229.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C7EE43D1D for ; Sat, 22 May 2004 08:03:15 -0700 (PDT) (envelope-from rescue@port11.net) Received: from port11.net (pcp08554827pcs.alxndr01.va.comcast.net [68.86.2.28]) by herb.port11.net (Postfix) with ESMTP id 06F7D20BF for ; Sat, 22 May 2004 11:04:20 -0400 (EDT) Message-ID: <40AF6B88.3000703@port11.net> Date: Sat, 22 May 2004 11:02:32 -0400 From: Thomas Gallaway User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-sparc@FreeBSD.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Working on Cycle UP-20 (USIIi upgrade for SS20) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2004 15:03:15 -0000 FreeBSD/sparc64 runs fine on a Cycle UP-20 (SS20). Technically it is an Ultrasparc IIi upgrade for SparcStation 5 & 20 systems. Mine has a 360mhz processor and 512mb ram. No problems at all booting from the CD-Rom and installing it. Ethernet worked fine too. (Onboard and sunswift). Just wanted to let you know. -- Thomas From owner-freebsd-sparc64@FreeBSD.ORG Sat May 22 10:14:51 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 490B516A4CE for ; Sat, 22 May 2004 10:14:51 -0700 (PDT) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id B832543D3F for ; Sat, 22 May 2004 10:14:48 -0700 (PDT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) i4MHEHfQ059193 for ; Sat, 22 May 2004 19:14:17 +0200 (CEST) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.10/8.12.10/Submit) id i4MHECUO059192 for freebsd-sparc@freebsd.org; Sat, 22 May 2004 19:14:12 +0200 (CEST) (envelope-from marius) Date: Sat, 22 May 2004 19:14:12 +0200 From: Marius Strobl To: freebsd-sparc@freebsd.org Message-ID: <20040522191412.B1600@newtrinity.zeist.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-AntiVirus: checked by AntiVir Milter 1.1-beta; AVE 6.25.0.59; VDF 6.25.0.73 (host: newtrinity.zeist.de) Subject: New utility eeprom(8) [marius@freebsd.org: cvs commit: src/usr.sbin/eeprom Makefile eeprom.8 eeprom.c ofw_options.c ofw_options.h] X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2004 17:14:51 -0000 FYI, in case it didn't break world, -current FreeBSD/sparc64 now has a new utility. ----- Forwarded message from Marius Strobl ----- FreeBSD src repository Added files: usr.sbin/eeprom Makefile eeprom.8 eeprom.c ofw_options.c ofw_options.h Log: Add eeprom(8), a utility to display and modify system configurations stored in EEPROM or NVRAM. It's inspired by the NetBSD eeprom(8) and the SunOS/Solaris eeprom(1M) utilities. Currently, this eeprom(8) only supports systems equipped with Open Firmware and is only tested on Sun machines but should work on any platform using Open Firmware. A bit more specific, eeprom(8) can be used on these systems to do the same under FreeBSD as can be done using the printenv and setenv commandos in the boot monitor. One thing that only hardly can be done using the boot monitor but easily with eeprom(8) is to write a logo to the "oem-logo" property. eeprom(8) may also be useful to recover the boot monitor password (in the default configuration only as root, of course), i.e. when the boot monitor allows you to boot but you can't alter the configuration because the password is unknown. The man page may also be a useful reference of the various configuration variables. The idea of eeprom(8) is that handlers can be written to add support for any firmware that stores such configuration in EEPROM or NVRAM; sort of e.g. eeprom(1M) on Solaris/x86 is used to turn PAE-support on and off (stored in a file then, not hardware). In FreeBSD, a candidate for this would be a handler for the EFI boot environment for FreeBSD/ia64. eeprom(8) uses some code from NetBSD (eeprom.c and the base for eeprom.8), the handler for the Open Firmware /options node (ofw_options.[c,h]) was written using ofw_util.[c,h] from ofwdump(8). Reviewed by: ru (slightly earlier version of the man page) Revision Changes Path 1.3 +12 -0 src/usr.sbin/eeprom/Makefile (new) 1.3 +668 -0 src/usr.sbin/eeprom/eeprom.8 (new) 1.4 +153 -0 src/usr.sbin/eeprom/eeprom.c (new) 1.1 +314 -0 src/usr.sbin/eeprom/ofw_options.c (new) 1.1 +34 -0 src/usr.sbin/eeprom/ofw_options.h (new) _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" ----- End forwarded message -----