From owner-freebsd-current Sun Feb 10 2:23:34 2002 Delivered-To: freebsd-current@freebsd.org Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by hub.freebsd.org (Postfix) with ESMTP id 63FF937B416; Sun, 10 Feb 2002 02:23:31 -0800 (PST) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.11.6/8.11.5) with ESMTP id g1AA8eX08143; Sun, 10 Feb 2002 05:08:41 -0500 (EST) (envelope-from mi@aldan.algebra.com) Message-Id: <200202101008.g1AA8eX08143@aldan.algebra.com> Date: Sun, 10 Feb 2002 05:08:37 -0500 (EST) From: Mikhail Teterin Subject: Re: panic: bdwrite: buffer is not busy To: bde@zeta.org.au Cc: jhb@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <20020210140121.D6710-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 10 Feb, Bruce Evans wrote: > On Sat, 9 Feb 2002, John Baldwin wrote: > >> On 09-Feb-02 Mikhail Teterin wrote: >> > While attempting to ``fdisk fd0.1440''. Or ``fdisk fd0''. Or >> > ``newfs_msdos fd0.1440'' with or without the floppy inside :-\ With >> > todays or Jan 3rd kernel (my previous upgrade). >> >> Only use fdisk on hard disks. Still it shouldn't panic. The bdwrite >> is just extra garbage, the real panic is due to a NULL pointer >> dereference: > > This is a well known bug in the device layer. I reported it on > 2001/12/26 and fixed it locally a little later. See the thread in > -current about "panic during fdisk'ing a md(4) device" for patches. Fdisk I don't really need, but attempting to newfs the floppy caused the same panic :-\ And mounting the already formatted floppy leads to "invalid argument". Could we have this fixed soon, please? The inability to access a floppy is a great setback for my local FreeBSD advocacy efforts :-) -mi >> I'm guessing that devsw() is returning NULL here. You could add a >> KASSERT() to this macro just before the call to d_strategy() along >> the lines of >> >> KASSERT(devsw((bp)->bio_dev) != NULL, ("no devsw for bio")); \ > > Right. From my original bug report: > > ! "fdisk /dev/fd0" now causes a null pointer panic in readdisklabel(). > ! This is because fdioctl() attempts to construct a (slightly > ! wrong) device using dkmodpart(), but dkmodpart() only constructs a > ! half-baked device since it only calls makedev(). The device is > ! missing a devsw so DEV_STRATEGY() in readdisklabel() panics on it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 10 7:10:53 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 029CF37B402; Sun, 10 Feb 2002 07:10:51 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g1AFAbnX016750; Sun, 10 Feb 2002 10:10:38 -0500 (EST) Date: Sun, 10 Feb 2002 10:10:37 -0500 (EST) From: Daniel Eischen To: Kevin Day Cc: current@FreeBSD.ORG, bde@FreeBSD.ORG Subject: Re: function name collision on "getcontext" with ports/editors/joe In-Reply-To: <200202100723.g1A7NtW54701@shell.dragondata.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 10 Feb 2002, Kevin Day wrote: > > I'm the maintainer for ports/editors/joe, and just tried compiling it under > -CURRENT. > > includes which includes ucontext.h > > > cc -O -pipe -c umath.c > > In file included from b.h:6, > > from bw.h:23, > > from umath.c:5: > > rc.h:41: conflicting types for `getcontext' > > /usr/include/sys/ucontext.h:54: previous declaration of `getcontext' > > *** Error code 1 > > > > Stop in /usr/ports/editors/joe/work/joe. > > > I can rename getcontext in joe, but "getcontext" seems like a pretty common > function name, I know I've used it in projects before. Not including > signal.h isn't really an option either. > > I'm not familiar with any of the ucontext.h functions, are they complying > with some kind of standard and can't be renamed or have a prefix added to > it? Yea, getcontext is part of SUSv2 and the 2001 POSIX spec. It has been present in at least Solaris for years now, so it's kind of weird that joe hasn't had the problem when built for it [Solaris]. Hmm, includes . I'm not sure why though. bde might know. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 10 8:32: 4 2002 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id 959BE37B400 for ; Sun, 10 Feb 2002 08:31:57 -0800 (PST) Received: (from david@localhost) by bunrab.catwhisker.org (8.11.6/8.11.6) id g1AGVv707705 for current@freebsd.org; Sun, 10 Feb 2002 08:31:57 -0800 (PST) (envelope-from david) Date: Sun, 10 Feb 2002 08:31:57 -0800 (PST) From: David Wolfskill Message-Id: <200202101631.g1AGVv707705@bunrab.catwhisker.org> To: current@freebsd.org Subject: Panic (runq_choose()) in today's -CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Built today's -CURRENT as usual; booted & ran a few things without incident. Issued: freebeast(5.0-C)[2] sudo boot0cfg -s 1 ad0 && sudo reboot and this showed up on the serial console: FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) login: Fboot() called on cpu#1 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped lock order reversal 1st 0xc0335600 sched lock @ /usr/src/sys/kern/kern_idle.c:105 2nd 0xc038ea60 sio @ /usr/src/sys/dev/sio/sio.c:3137 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = 00000000 fault virtual address = 0xd6820001 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01a638f stack pointer = 0x10:0xd683dcd0 frame pointer = 0x10:0xd683dce0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 11 (idle: cpu0) kernel: type 12 trap, code=0 timeout stopping cpus Stopped at runq_choose+0x83: movl 0(%edx),%eax db> trace runq_choose(c0358880,d683dd0c,c02b01ce,c01a7857,34948) at runq_choose+0x83 choosethread(c01a7857,34948,c0194f10,d682d500,77) at choosethread+0xd sw1(d682d604,d683dd34,c0194d50,0,d683dd48) at sw1+0x20 idle_proc(0,d683dd48,0,c0194f10,0) at idle_proc+0x5c fork_exit(c0194f10,0,d683dd48) at fork_exit+0x9c fork_trampoline() at fork_trampoline+0x8 db> I haven't seen any kernel-related commits since I did the CVSup (from 0347 - about 0356 hrs. today, US/Pacific (8 hrs. west of GMT). (Previous CVSup was 24 hrs. earilier, and the kernel built then -- which is what I was running when I built this one -- had not exhibited the symptom.) Anything else I can do to help find & resolve this? Thanks, david -- David H. Wolfskill david@catwhisker.org I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 10 9:33:32 2002 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id 36E9A37B402 for ; Sun, 10 Feb 2002 09:33:18 -0800 (PST) Received: (from david@localhost) by bunrab.catwhisker.org (8.11.6/8.11.6) id g1AHXHx07880 for current@FreeBSD.ORG; Sun, 10 Feb 2002 09:33:17 -0800 (PST) (envelope-from david) Date: Sun, 10 Feb 2002 09:33:17 -0800 (PST) From: David Wolfskill Message-Id: <200202101733.g1AHXHx07880@bunrab.catwhisker.org> To: current@FreeBSD.ORG Subject: Re: Panic (runq_choose()) in today's -CURRENT In-Reply-To: <200202101631.g1AGVv707705@bunrab.catwhisker.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >Date: Sun, 10 Feb 2002 08:31:57 -0800 (PST) >From: David Wolfskill >db> trace >runq_choose(c0358880,d683dd0c,c02b01ce,c01a7857,34948) at runq_choose+0x83 >choosethread(c01a7857,34948,c0194f10,d682d500,77) at choosethread+0xd >sw1(d682d604,d683dd34,c0194d50,0,d683dd48) at sw1+0x20 >idle_proc(0,d683dd48,0,c0194f10,0) at idle_proc+0x5c >fork_exit(c0194f10,0,d683dd48) at fork_exit+0x9c >fork_trampoline() at fork_trampoline+0x8 >db> >... >Anything else I can do to help find & resolve this? A little more information: * My laptop (running the same sources, though a somewhat different kernel config and a rather different hardware config) did not exhibit the symptoms. * A few other things occurred to me that might be of interest with DDB: db> show pcpu 0 cpuid = 0 curthread = 0xd682d604: pid 11 "idle: cpu0" curpcb = 0xd683dda0 fpcurthread = none idlethread = 0xd682d604: pid 11 "idle: cpu0" currentldt = 0x28 spin locks held: exclusive (spin mutex) sched lock (0xc0335600) locked @ /usr/src/sys/kern/kern_idle.c:105 db> show pcpu 1 cpuid = 1 curthread = 0xda41a604: pid 289 "reboot" curpcb = 0xda432da0 fpcurthread = none idlethread = 0xd682d904: pid 10 "idle: cpu1" currentldt = 0x28 spin locks held: exclusive (spin mutex) clk (0xc0338ee0) locked @ /usr/src/sys/i386/isa/clock.c:415 db> show locks exclusive (spin mutex) sched lock (0xc0335600) locked @ /usr/src/sys/kern/kern_idle.c:105 db> show lockedvnodes Locked vnodes panic: blockable sleep lock (sleep mutex) mountlist @ /usr/src/sys/kern/vfs_subr.c:2371 cpuid = 0; lapic.id = 00000000 Debugger("panic") Stopped at runq_choose+0x83: movl 0(%edx),%eax db> Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill david@catwhisker.org I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 10 10:24:42 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 65EC337B417; Sun, 10 Feb 2002 10:24:38 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id FAA26531; Mon, 11 Feb 2002 05:24:06 +1100 Date: Mon, 11 Feb 2002 05:26:53 +1100 (EST) From: Bruce Evans X-X-Sender: To: Poul-Henning Kamp Cc: Julian Elischer , John Baldwin , Mikhail Teterin , Subject: Re: panic: bdwrite: buffer is not busy In-Reply-To: <32308.1013314746@critter.freebsd.dk> Message-ID: <20020211052422.K8914-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 10 Feb 2002, Poul-Henning Kamp wrote: > In message <20020210142836.D6790-100000@gamplex.bde.org>, Bruce Evans writes: > >On Sat, 9 Feb 2002, Julian Elischer wrote: > > > >> On Sun, 10 Feb 2002, Bruce Evans wrote: > >> > > >> > This is a well known bug in the device layer. I reported it on 2001/12/26 > >> > and fixed it locally a little later. See the thread in -current about > >> > "panic during fdisk'ing a md(4) device" for patches. > >> > > >> Can you commit the fix? > > > >The maintainer should be able to it better. I rarely test the devfs parts, > >but the bulk of the patch is to help devfs. My patch needs some cleanups > >(mainly non-hacked interfaces) anyway. > > The maintainer is busy rewriting that entire area of the code which will > help immensely :-) Do you mean geom? No thanks. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 10 11:30:32 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 9CDDE37B404 for ; Sun, 10 Feb 2002 11:30:07 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id GAA28676; Mon, 11 Feb 2002 06:30:01 +1100 Date: Mon, 11 Feb 2002 06:32:48 +1100 (EST) From: Bruce Evans X-X-Sender: To: Julian Elischer Cc: Subject: Re: final ucred patch In-Reply-To: <3C66133F.43D243E0@elischer.org> Message-ID: <20020211060831.T9036-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > After comments by jhb and bde > > Index: i386/i386/trap.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v > retrieving revision 1.211 > diff -u -r1.211 trap.c > --- i386/i386/trap.c 10 Jan 2002 11:49:54 -0000 1.211 > +++ i386/i386/trap.c 10 Feb 2002 00:52:58 -0000 > @@ -256,9 +256,19 @@ > sticks = td->td_kse->ke_sticks; > td->td_frame = &frame; > KASSERT(td->td_ucred == NULL, ("already have a ucred")); > - PROC_LOCK(p); > - td->td_ucred = crhold(p->p_ucred); > - PROC_UNLOCK(p); > + if (td->td_ucred != p->p_ucred) { > + if (td->td_ucred) { > + mtx_lock(&Giant); > + crfree(td->td_ucred); > + td->td_ucred = NULL; > + mtx_unlock(&Giant); See below about placement of this unlock. > + } > + if (p->p_ucred) { How can this be NULL? The old code didn't check. > + PROC_LOCK(p); > + td->td_ucred = crhold(p->p_ucred); > + PROC_UNLOCK(p); > + } > + } The inner block is large enough and repeated enough to turn into a function. > > switch (type) { > case T_PRIVINFLT: /* privileged instruction fault */ > @@ -644,10 +654,12 @@ > userret(td, &frame, sticks); > mtx_assert(&Giant, MA_NOTOWNED); > userout: > +#ifdef INVARIANTS > mtx_lock(&Giant); > crfree(td->td_ucred); > - mtx_unlock(&Giant); > td->td_ucred = NULL; > + mtx_unlock(&Giant); > +#endif > out: > return; > } I think moving the unlock is just an obfuscation. td_ucred isn't locked by Giant. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 10 12:13: 0 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 47A6837B402; Sun, 10 Feb 2002 12:12:57 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id HAA30459; Mon, 11 Feb 2002 07:12:46 +1100 Date: Mon, 11 Feb 2002 07:15:33 +1100 (EST) From: Bruce Evans X-X-Sender: To: Daniel Eischen Cc: Kevin Day , , Subject: Re: function name collision on "getcontext" with ports/editors/joe In-Reply-To: Message-ID: <20020211070518.F9189-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 10 Feb 2002, Daniel Eischen wrote: > Hmm, includes . I'm not sure why though. > bde might know. includes for the normal namespace pollution that was needed to use sigreturn(2) (except sigreturn(2) itself isn't actually declared anywhere). Including gives the corresponding namespace pollution for using the current sigreturn(2). This is probably a mistake. (Don't believe the sigreturn man page; it documents osigreturn(2) for the i386 only.) Programs shouldn't have any problems with this, since they should define _POSIX_SOURCE if they only want the POSIX namespace ;-). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 10 12:13:15 2002 Delivered-To: freebsd-current@freebsd.org Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by hub.freebsd.org (Postfix) with ESMTP id E8BE237B402 for ; Sun, 10 Feb 2002 12:13:06 -0800 (PST) Received: from horsey.gshapiro.net (gshapiro@localhost [IPv6:::1]) by horsey.gshapiro.net (8.12.2/8.12.3.PreAlpha0) with ESMTP id g1AKD6ku008046 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 10 Feb 2002 12:13:06 -0800 (PST) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.12.2/8.12.2/Submit) id g1AKD5hp008043; Sun, 10 Feb 2002 12:13:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15462.54353.720228.404682@horsey.gshapiro.net> Date: Sun, 10 Feb 2002 12:13:05 -0800 From: Gregory Neil Shapiro To: freebsd-current@FreeBSD.ORG Subject: UPDATED: For Review: sendmail 8.12.2 import into -CURRENT In-Reply-To: <15435.24461.796634.405538@horsey.gshapiro.net> References: <15435.24461.796634.405538@horsey.gshapiro.net> X-Mailer: VM 7.00 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've created a new patch to deal with a problem found during testing (thanks to David Wolfskill). This should fix sites who use sendmail_enable="NO" but still want to be able to process command line mail -- we still need a localhost-only SMTP daemon to accept command line mail. Complete details are in etc/mail/README (after patching). The updated patch is available at the same location: http://people.freebsd.org/~gshapiro/CURRENT-8.12.2 Follow the instructions in that file and please report any successes or failures to me directly. I plan on committing the changes during or soon after BSDCon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 10 12:32:30 2002 Delivered-To: freebsd-current@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 49B2137B417; Sun, 10 Feb 2002 12:32:26 -0800 (PST) Received: (from ache@localhost) by nagual.pp.ru (8.11.6/8.11.6) id g1AKWKK68603; Sun, 10 Feb 2002 23:32:21 +0300 (MSK) (envelope-from ache) Date: Sun, 10 Feb 2002 23:32:18 +0300 From: "Andrey A. Chernov" To: Gregory Neil Shapiro Cc: freebsd-current@FreeBSD.ORG Subject: Re: UPDATED: For Review: sendmail 8.12.2 import into -CURRENT Message-ID: <20020210203218.GA68564@nagual.pp.ru> References: <15435.24461.796634.405538@horsey.gshapiro.net> <15462.54353.720228.404682@horsey.gshapiro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15462.54353.720228.404682@horsey.gshapiro.net> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Feb 10, 2002 at 12:13:05 -0800, Gregory Neil Shapiro wrote: > > http://people.freebsd.org/~gshapiro/CURRENT-8.12.2 --- lib/libmilter/Makefile~orig Sun Jan 20 13:58:03 2002 +++ lib/libmilter/Makefile Sun Jan 20 13:05:02 2002 @@ -0,0 +1,28 @@ +# $FreeBSD$ + +MAINTAINER= gshapiro@FreeBSD.org + +SENDMAIL_DIR=${.CURDIR}/../../contrib/sendmail +.PATH: ${SENDMAIL_DIR}/libmilter ${SENDMAIL_DIR}/libsm + +CFLAGS+=-I${SENDMAIL_DIR}/src -I${SENDMAIL_DIR}/include -I. +CFLAGS+=-DNETINET6 -DNOT_SENDMAIL -Dsm_snprintf=snprintf +CFLAGS+=-pthread ^^^^^^^^^^^^^^^^^^^^^^ Why you add -pthread? IMHO it is needed only on program building 'ld' phase and not in library building. See libc_r/Makefile -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 10 12:43:25 2002 Delivered-To: freebsd-current@freebsd.org Received: from vbook.express.ru (vbook.nc.express.ru [212.24.37.35]) by hub.freebsd.org (Postfix) with ESMTP id 6866A37B404 for ; Sun, 10 Feb 2002 12:43:14 -0800 (PST) Received: from localhost ([127.0.0.1]) by vbook.express.ru with esmtp (Exim 3.33 #1) id 16a0nq-0002au-00; Sun, 10 Feb 2002 23:42:26 +0300 Subject: Re: usdb missing detaches ??? From: "Vladimir B. " Grebenschikov To: Paul van der Zwan Cc: current@freebsd.org In-Reply-To: <200202102029.g1AKTgF21384@trantor.xs4all.nl> References: <200202102029.g1AKTgF21384@trantor.xs4all.nl> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution/1.0.1 Date: 10 Feb 2002 23:42:26 +0300 Message-Id: <1013373746.5030.13.camel@vbook.express.ru> Mime-Version: 1.0 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 2002-02-10 at 23:29, Paul van der Zwan wrote: > > On Sun, 2002-02-03 at 15:08, Paul van der Zwan wrote: > > >=20 > > > I'm experimenting with my Sony DSC S70 and USB. > > > I can get -current to mount the stick in the camera but it won't umou= nt=20 > > > the filesystem on detach.=20 > >=20 > > Just found that on lates -CURRENT my notebook keyboard not returned whe= n > > I have detach USB keyboard - It was working well before.=20 > >=20 > > Somebody have broke usb detaching ? >=20 > The only usb device I have connected is my camera so I have no experience= s=20 > with mice or keyboards, but yours it the first response at all at my=20 > message, so I still have no idea if the behaviour i see is the way it=20 > should be or a bug... So, I have done some invistigations: 'usbd -d -v -v' output here with comments: *** Attaching USB hub with mouse and combo keyboard: usbd: processing event queue on /dev/usb usbd: device-attach event at 1013373305.235405000, UT-USB41 hub, Texas Instruments: vndr=3D0x0451 prdct=3D0x1446 rlse=3D0x0110 clss=3D0x0009 subclss=3D0x0000 prtcl=3D0x0000 device names: uhub1 usbd: Found action 'USB device' for UT-USB41 hub, Texas Instruments at uhub1 usbd: action 0: USB device usbd: Setting DEVNAME=3D'uhub1' usbd: processing event queue on /dev/usb usbd: device-attach event at 1013373305.813311000, Microsoft IntelliMouse=AE Explorer, Microsoft: vndr=3D0x045e prdct=3D0x001e rlse=3D0x0114 clss=3D0x0000 subclss=3D0x0000 prtcl=3D0x0000 device names: ums0 usbd: ums0 matches ums[0-9]+ usbd: Found action 'Mouse' for Microsoft IntelliMouse=AE Explorer, Microsoft at ums0 usbd: action 0: Mouse devname: ums[0-9]+ attach=3D'/usr/sbin/moused -p /dev/${DEVNAME} -I /var/run/moused.${DEVNAME}.pid -m 6=3D4 -m 7=3D5' detach=3D'kill /var/run/moused.${DEVNAME}.pid' usbd: Setting DEVNAME=3D'ums0' usbd: Executing '/usr/sbin/moused -p /dev/${DEVNAME} -I /var/run/moused.${DEVNAME}.pid -m 6=3D4 -m 7=3D5' usbd: '/usr/sbin/moused -p /dev/${DEVNAME} -I /var/run/moused.${DEVNAME}.pid -m 6=3D4 -m 7=3D5' is ok usbd: processing event queue on /dev/usb usbd: device-attach event at 1013373306.424875000, Keyboard with mouse port, Behavior Tech. Computer: vndr=3D0x046e prdct=3D0x6782 rlse=3D0x0100 clss=3D0x0000 subclss=3D0x0000 prtcl=3D0x0000 device names: ukbd0,ums1 usbd: Found action 'Keyboard with Mouse' for Keyboard with mouse port, Behavior Tech. Computer usbd: action 0: Keyboard with Mouse vndr=3D0x046e prdct=3D0x6782 rlse=3D0x0100 attach=3D'/usr/sbin/kbdcontrol -k /dev/kbd1 -r fast < /dev/ttyv0' detach=3D'/usr/sbin/kbdcontrol -k /dev/kbd0 -r fast < /dev/ttyv0' usbd: Executing '/usr/sbin/kbdcontrol -k /dev/kbd1 -r fast < /dev/ttyv0' kbd1 ukbd0, type:generic (0) usbd: '/usr/sbin/kbdcontrol -k /dev/kbd1 -r fast < /dev/ttyv0' is ok *** all seems Ok, moused stared, keyboard activated usbd: doing timeout discovery on /dev/usb0 usbd: processing event queue due to timeout on /dev/usb *** nothing plugged/unpluget on USB bus but got this message usbd: processing event queue on /dev/usb usbd: driver-detach event cookie=3D3217028628 devname=3Duhub1 USB_EVENT_DRIVER_DETACH *** this happens after detach - usbd see some detaching but not execute=20 *** detach scripts :( on dmesg: hub1: Texas Instruments UT-USB41 hub, class 9/0, rev 1.10/1.10, addr 2 uhub1: 4 ports with 4 removable, bus powered ums0: Microsoft Microsoft IntelliMouse=AE Explorer, rev 1.10/1.14, addr 3, iclass 3/1 ums0: 5 buttons and Z dir. uhub1: device problem, disabling port 2 uhub1: at uhub0 port 1 (addr 2) disconnected ums0: detached uhub1: detached p.s.: may be it is time to send PR ? =20 > Paul --=20 SW Soft, Moscow Vladimir B. Grebenschikov, vova@sw.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 10 13:15:52 2002 Delivered-To: freebsd-current@freebsd.org Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by hub.freebsd.org (Postfix) with ESMTP id D3AEF37B43D for ; Sun, 10 Feb 2002 13:06:42 -0800 (PST) Received: from horsey.gshapiro.net (gshapiro@localhost [IPv6:::1]) by horsey.gshapiro.net (8.12.2/8.12.3.PreAlpha0) with ESMTP id g1AL54ku008428 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 10 Feb 2002 13:05:04 -0800 (PST) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.12.2/8.12.2/Submit) id g1AL5421008425; Sun, 10 Feb 2002 13:05:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15462.57471.848179.108604@horsey.gshapiro.net> Date: Sun, 10 Feb 2002 13:05:03 -0800 From: Gregory Neil Shapiro To: "Andrey A. Chernov" Cc: freebsd-current@FreeBSD.ORG Subject: Re: UPDATED: For Review: sendmail 8.12.2 import into -CURRENT In-Reply-To: <20020210203218.GA68564@nagual.pp.ru> References: <15435.24461.796634.405538@horsey.gshapiro.net> <15462.54353.720228.404682@horsey.gshapiro.net> <20020210203218.GA68564@nagual.pp.ru> X-Mailer: VM 7.00 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >> http://people.freebsd.org/~gshapiro/CURRENT-8.12.2 ache> +CFLAGS+=-pthread ache> ^^^^^^^^^^^^^^^^^ ache> Why you add -pthread? IMHO it is needed only on program building 'ld' ache> phase and not in library building. See libc_r/Makefile Thanks, I've changed that line to: CFLAGS+=-D_THREAD_SAFE To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 10 14: 0:17 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.dada.it (mail4.dada.it [195.110.96.56]) by hub.freebsd.org (Postfix) with SMTP id A1FC037B402 for ; Sun, 10 Feb 2002 14:00:10 -0800 (PST) Received: (qmail 24222 invoked from network); 10 Feb 2002 21:59:58 -0000 Received: from unknown (HELO torrini.org) (195.110.114.101) by mail.dada.it with SMTP; 10 Feb 2002 21:59:58 -0000 Received: (from riccardo@localhost) by torrini.org (8.11.6/8.11.6) id g1ALxwR17221; Sun, 10 Feb 2002 22:59:58 +0100 (CET) (envelope-from riccardo) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <1013373746.5030.13.camel@vbook.express.ru> Date: Sun, 10 Feb 2002 22:59:57 +0100 (CET) From: Riccardo Torrini To: "Vladimir B. "@FreeBSD.ORG, Grebenschikov@FreeBSD.ORG, " "@torrini.org Subject: Re: usdb missing detaches ??? Cc: current@FreeBSD.ORG, Paul van der Zwan Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 10-Feb-2002 (20:42:26/GMT) Vladimir B. " Grebenschikov wrote: >>>> I can get -current to mount the stick in the camera but it >>>> won't umount the filesystem on detach. > ums0: detached > uhub1: detached I have the same problem here: I added this to /etc/usbd.conf: ---8<--- device "Scanner Epson, modello Perfection1240 (photo)" # Perfection1240(0x010b), EPSON(0x04b8), rev 0x0114 product 0x010b vendor 0x04b8 release 0x0114 devname "uscanner[0-9]+" attach "/bin/chmod 666 /dev/${DEVNAME} && echo L16cce > /dev/speaker" ## attach "/bin/chmod 666 /dev/uscanner0 && echo L16cce > /dev/speaker" detach "echo L16eec > /dev/speaker" ---8<--- And this happens to /var/log/messages, but I got tune played only on device attach, not on detach (attach/detach means cycle power to scanner, without touching usb cable). -----8<-----[ /var/log/messages ]-----8<----- ...kernel: uscanner0: EPSON Perfection1240, rev 1.00/1.14, addr 2 ...kernel: uscanner0: at uhub0 port 1 (addr 2) disconnected and after usage, when power off: ...kernel: uscanner0: detached If I understand manuals and examples attach/detach can run _any_ action I want. Or not? Riccardo. PS: chmod is needed to use xscanimage from my user. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 10 14:39:25 2002 Delivered-To: freebsd-current@freebsd.org Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (dclient217-162-168-31.hispeed.ch [217.162.168.31]) by hub.freebsd.org (Postfix) with ESMTP id 0181C37B419 for ; Sun, 10 Feb 2002 14:39:18 -0800 (PST) Received: from beerswilling.netscum.dyndns.dk (dcf77-zeit.netscum.dyndns.dk [172.27.72.27] (may be forged)) by dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (8.11.6/8.11.6) with ESMTP id g1AMdDr00244 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Sun, 10 Feb 2002 23:39:17 +0100 (CET) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Received: (from root@localhost) by beerswilling.netscum.dyndns.dk (8.11.6/8.11.6) id g1AMdDH00243; Sun, 10 Feb 2002 23:39:13 +0100 (CET) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Date: Sun, 10 Feb 2002 23:39:13 +0100 (CET) Message-Id: <200202102239.g1AMdDH00243@beerswilling.netscum.dyndns.dk> From: BOUWSMA Beery To: freebsd-current@freebsd.org Subject: Minor things: swi_net: unregistered isr number Organization: Men not wearing any pants that dont shave X-Hacked: via telnet to your port 25, what else? X-Internet-Access-Provided-By: Mountain Informatik AG, Zuerich X-NetScum: Yes X-One-And-Only-Real-True-Fluffy: No Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG If this might be of interest: kernel built 07.feb at boot time... | Doing initial network setup: hostname. * swi_net: unregistered isr number: 18. | xl0: flags=8843 mtu 1500 | options=3 [...] This is (probably) the dhclient being run at this time, maybe. Should I be bothered by the following? unknown: can't assign resources unknown: can't assign resources unknown: <16550 compatible COM device> can't assign resources unknown: <16550 compatible COM device> can't assign resources unknown: can't assign resources unknown: can't assign resources this is after all of these have been detected and assigned (sio0, sio1, etc) ata3: at port 0x36e-0x36f,0x168-0x16f irq 10 o n isa0 Where did that come from, and why don't I know about it? I know about: ata0 at port 0x3f6,0x1f0-0x1f7 irq 14 on isa0 ata1 at port 0x376,0x170-0x177 irq 15 on isa0 and -stable makes no claim I have a third ata controller... machine is ancient digital venturis 575 pc thanks barry bouwsma To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 10 16:10:54 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 91FFF37B41F; Sun, 10 Feb 2002 16:10:40 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g1B0Aafk000025; Sun, 10 Feb 2002 19:10:37 -0500 (EST) Date: Sun, 10 Feb 2002 19:10:36 -0500 (EST) From: Daniel Eischen To: Bruce Evans Cc: Kevin Day , current@FreeBSD.ORG, bde@FreeBSD.ORG Subject: Re: function name collision on "getcontext" with ports/editors/joe In-Reply-To: <20020211070518.F9189-100000@gamplex.bde.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 11 Feb 2002, Bruce Evans wrote: > On Sun, 10 Feb 2002, Daniel Eischen wrote: > > > Hmm, includes . I'm not sure why though. > > bde might know. > > includes for the normal namespace > pollution that was needed to use sigreturn(2) (except sigreturn(2) > itself isn't actually declared anywhere). Including > gives the corresponding namespace pollution for using the current > sigreturn(2). This is probably a mistake. (Don't believe the > sigreturn man page; it documents osigreturn(2) for the i386 only.) > Programs shouldn't have any problems with this, since they should > define _POSIX_SOURCE if they only want the POSIX namespace ;-). Poking about on a Solaris 8 system shows that they have a that defines the {get,set,make,swap}context prototypes. also includes to get the definitions for ucontext_t. Under FreeBSD, is a link to , which both declare ucontext_t and {get,set,make,swap}context. What do you recommend we do? Should we not include from , or do what Solaris does, or just leave everything as is? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 10 16:42: 4 2002 Delivered-To: freebsd-current@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id A1B7537B419; Sun, 10 Feb 2002 16:41:59 -0800 (PST) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.11.4/8.9.3) with ESMTP id g1B0bwi05500; Sun, 10 Feb 2002 16:38:13 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200202110038.g1B0bwi05500@beastie.mckusick.com> To: Ollivier Robert Subject: Re: Unconnected files problem Cc: "FreeBSD Current Users' list" , iedowse@FreeBSD.ORG In-Reply-To: Your message of "Tue, 28 Aug 2001 14:02:24 +0200." <20010828140224.B99849@caerdonn.eurocontrol.fr> Date: Sun, 10 Feb 2002 16:37:58 -0800 From: Kirk McKusick Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have (finally) found and fixed this problem. You need to get version 1.107 or later of /sys/ufs/ffs/ffs_softdep.c (2002/02/07). Kirk McKusick =-=-=-=-=-= Date: Tue, 28 Aug 2001 14:02:24 +0200 From: Ollivier Robert To: "FreeBSD Current Users' list" Cc: iedowse@FreeBSD.ORG, mckusick@FreeBSD.ORG Subject: Unconnected files problem I have a script that generates index for all my mail messages (using glimpse). Sometimes, the disk is full because it has some rather big temporary files (and I have a lot of mail). It seems that we may have a softupdate-related (that's a guess from me) problem because some of these temporaty files end up as unconnected to any directory but link count is still one and they still takes space. The last time fsck ran on the filesystem, it gave me back more than 60000 (!!) fragments (cf the following: -=-=- Aug 23 12:21:38 caerdonn root: /dev/da0s1g: Reclaimed: 0 directories, 22 files, 60424 fragments Aug 23 12:21:38 caerdonn root: /dev/da0s1g: 10295 files, 387087 used, 73408 free (1048 frags, 9045 blocks, 0.2% fragmentation) -=-=- lsof doesn't show them so they're not open by any process. The mtime of the files are exactly when the glimpseindex command is run. We know that SU has some issues when a filesystem is full but this is quite a problem because as you can see below, I'm losing a lot of space till the next reboot... UNREF FILE I=1081 OWNER=roberto MODE=100600 SIZE=523 MTIME=Aug 28 00:46 2001 CLEAR? no UNREF FILE I=18498 OWNER=roberto MODE=100600 SIZE=230665 MTIME=Aug 26 08:05 2001 RECONNECT? no CLEAR? no UNREF FILE I=18508 OWNER=roberto MODE=100600 SIZE=11225707 MTIME=Aug 23 20:02 2001 RECONNECT? no CLEAR? no UNREF FILE I=18530 OWNER=roberto MODE=100600 SIZE=28322748 MTIME=Aug 24 20:09 2001 RECONNECT? no CLEAR? no UNREF FILE I=18573 OWNER=roberto MODE=100600 SIZE=28326193 MTIME=Aug 25 20:09 2001 RECONNECT? no CLEAR? no UNREF FILE I=18575 OWNER=roberto MODE=100600 SIZE=18684173 MTIME=Aug 24 20:08 2001 RECONNECT? no CLEAR? no UNREF FILE I=19204 OWNER=roberto MODE=100600 SIZE=13771800 MTIME=Aug 26 08:05 2001 RECONNECT? no CLEAR? no UNREF FILE I=19353 OWNER=roberto MODE=100600 SIZE=18679309 MTIME=Aug 25 20:08 2001 RECONNECT? no CLEAR? no ** Phase 5 - Check Cyl groups 10223 files, 446324 used, 74595 free (1019 frags, 9197 blocks, 0.2% fragmentation) fsdb (inum: 2)> inode 19353 current inode: regular file I=19353 MODE=100600 SIZE=18679309 MTIME=Aug 25 20:08:18 2001 [0 nsec] CTIME=Aug 25 20:08:18 2001 [0 nsec] ATIME=Aug 25 20:08:11 2001 [0 nsec] OWNER=roberto GRP=staff LINKCNT=1 FLAGS=0 BLKCNT=8ec0 GEN=4c2a6c10 -- Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- Ollivier.Robert@eurocontrol.fr FreeBSD caerdonn.eurocontrol.fr 5.0-CURRENT #46: Wed Jan 3 15:52:00 CET 2001 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 10 16:51: 8 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 7625B37B41C; Sun, 10 Feb 2002 16:50:52 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id LAA26232; Mon, 11 Feb 2002 11:50:40 +1100 Date: Mon, 11 Feb 2002 11:53:28 +1100 (EST) From: Bruce Evans X-X-Sender: To: Daniel Eischen Cc: Kevin Day , , Subject: Re: function name collision on "getcontext" with ports/editors/joe In-Reply-To: Message-ID: <20020211114221.H10505-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 10 Feb 2002, Daniel Eischen wrote: > On Mon, 11 Feb 2002, Bruce Evans wrote: > > includes for the normal namespace > > pollution that was needed to use sigreturn(2) (except sigreturn(2) > > itself isn't actually declared anywhere). Including > > gives the corresponding namespace pollution for using the current > > sigreturn(2). This is probably a mistake. (Don't believe the > > sigreturn man page; it documents osigreturn(2) for the i386 only.) > > Programs shouldn't have any problems with this, since they should > > define _POSIX_SOURCE if they only want the POSIX namespace ;-). > > Poking about on a Solaris 8 system shows that they have a > that defines the {get,set,make,swap}context > prototypes. also includes > to get the definitions for ucontext_t. is just as nonstandard as . > Under FreeBSD, is a link to , > which both declare ucontext_t and {get,set,make,swap}context. The link part is intentional. We have to have for use in the kernel, so it is simpler not to have a separate user header. The only advantage of the Solaris implementation is that it punishes applications that include the nonstandard header. > What do you recommend we do? Should we not include > from , or do what Solaris does, or just leave > everything as is? Don't include from , and fix whatever breaks. I think applications that use the new sigreturn can be required to include both and . There should be fewer of them than there used to be -- they can now use setcontext(). The old sigcontext/sigreturn stuff should be cleaned up too (don't export it to userland). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 10 18:38:12 2002 Delivered-To: freebsd-current@freebsd.org Received: from mta08.mail.mel.aone.net.au (mta08.mail.au.uu.net [203.2.192.89]) by hub.freebsd.org (Postfix) with ESMTP id B1A4C37B404; Sun, 10 Feb 2002 18:37:08 -0800 (PST) Received: from jackiejackie.alburycity.nsw.gov.au ([203.102.157.194]) by mta08.mail.mel.aone.net.au with ESMTP id <20020211023706.VUDD25886.mta08.mail.mel.aone.net.au@jackiejackie.alburycity.nsw.gov.au>; Mon, 11 Feb 2002 13:37:06 +1100 Received: from cip.bwl.uni-muenchen.de (212.45.23.10 [212.45.23.10]) by jackiejackie.alburycity.nsw.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1VBG3WCS; Mon, 11 Feb 2002 13:36:42 +1100 To: From: "Mr. Natural" Subject: Get Stoned...Legally! 11020 Date: Sun, 10 Feb 2002 06:36:05 -2000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <20020211023706.VUDD25886.mta08.mail.mel.aone.net.au@jackiejackie.alburycity.nsw.gov.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Now Offering for your "Sensitive" Delight ... NEW & IMPROVED *** KATHMANDU 2 *** Thanks to recent dramatic advances in the laboratorial processes for the extraction of botanical/herbal alkaloids and glycocides, we are now able to offer what has already been the most incredibly potent marijuana/cannabis alternative available on the planet .... KATHMANDU TEMPLE KIFF!!! It is NEW, IMPROVED and 20 times more stokin'-tokin' potent in its formulation. KATHMANDU 2 ... a viripotent cannabis alternative for blissful regressions of vexatious depressions... * BURNS AND SMOKES EASIER! * TOKES DEEPER! * TASTES SWEETER! * LASTS LONGER! Kathmandu Temple Kiff is a proprietary; Nepalese, sensitive, pipe-smoking/stoking substance. Kathmandu Temple Kiff is indeed the most substantial marijuana/cannabis alternative on the planet. Absolutely Legal! Marvelously Potent! Kathmandu Temple Kiff possesses all of the positive virtues fine ganja/cannabis without any of the negatives. An amalgamation of high concentrates of rare euphoric herbas, Kathmandu is offered in a solid jigget/bar format and is actually more UPLIFTING & POISED than cannabis / marijuana while rendering Euphoria, Happiness, Mood-Enhancement, Stress/Depression Relief and promoting contemplativeness, creativity, better sleep, lucid dreaming ... and enhancing the sexual experience!!! Kathmandu Temple Kiff is simply the best and just a little pinch/snippet of the Kathmandu goes a long, "sensitive" way. Just 4 or 5 draws of the pipe ... (an herb pipe included with each package of Kathmandu Temple Kiff). PLEASE NOTE: Although no botanical factor in Kathmandu Temple Kiff is illegal or considered to be harmful by regulatory agencies and no tobacco is included therein, it is the policy of our company that Kathmandu Temple Kiff may not be offered or sold to any person that has not attained at least 21 years of age. So power-smokin potent is our new formulation, that much to our delight and actually even to our amazement, we have even be able to establish a very happy clientele within the hard core stoner market. Here is what our customers are saying about Kathmandu Temple Kiff: "Thank you so much for the Temple Kiff. It is everything you guys claim, and then some! I was a bit skeptical when I read your description of its effects, but there is literally no exaggeration in your advertisements. How nice that this is legal! It tastes great and feels great too! I am so glad I took a chance and ordered. Blessings to all of you." -- Frankie R. "I'm a man of my 40's and I really know my stuff. I don't drink or do illegal drugs anymore and have found a much more spiritual path. I used to have to take Valium in the past. Not anymore with the Temple Kiff. It really amazes me how this stuff tastes exactly like the lebanese red and blond hash I used to smoke in the 70's and it has a much more pleasurable effect. I am very satisfied with this product. I like it a lot and will be a customer for life for sure. Whoever makes this stuff is an ARTIST at it. Who would have thought?! Folks, this is the real stuff! Look no further!!" -- A.J. ************************************************************ Our other fine herbal, botanical products include the following: 1. Sweet Vjestika Aphrodisia Drops (tm); An erotic aphrodisia; sexual intensifier / enhancer liquid amalgamated extract for MEN and WOMEN. 2. "Seventh Heaven" Prosaka Tablets (tm); a botanical alternative to pharmaceutical medications for calm, balance, serenity and joyful living... 3. "Seventh Heaven" Gentle Ferocity Tablets (tm); a most efficacious, non-caffeine, non-ephedrine, non-MaHuang botanical energizer and cutting-edge appetite suppressant... 4. Extreme Martial Arts Botanical Remedies; Equivalence Tablets & Dragon Wing Remedy Spray ... pain management that works to alleviate pain even for arthritis and fibromyalgia sufferers... ********************************************* Sweet Vjestika Aphrodisia Drops (tm) inspires and enhances: * Penile & clitoral sensitivity * Sensitivity to touch * Desire to touch and be touched * Fantasy, lust, rapture, erogenous sensitivity ... * Prolongs and intensifies foreplay, orgasm & climax ********************************************* "Seventh Heaven" Prosaka Tablets ... Entirely natural, proprietary, botanical prescription comprised of uncommon Asian Herbs for Calm, Balance, Serenity and Joyful Living. "Seventh Heaven" Prosaka is indeed a most extraordinary, viripotent, calming, centering, mood-enhancing, holistically-formulated, exotic herbaceous alternative to pharmaceutical medications for depression, anxiety, stress, insomnia, etc. NO side effects! NO dependency! Vivaciously Mellow! ********************************************** "Seventh Heaven" Gentle Ferocity Tablets (tm) ... a non-caffeine, non-ephedrine, non-ephedra, non-MaHuang; viripotent, herbaceous prescription for the dynamic energization of body, mind and spirit. This Gentle Ferocity Formulation is amalgamated in accordance with the fundamental Taoist herbal principle of botanical interactiveness and precursorship which in essence is a molecular equation of the relevant botanical/herbal alkaloids and glycosides interacting with one another to prolificate molecular communion and thereby to achieve demonstrative herbal efficaciousness without negative implication to any aspect of human composition. These Gentle Ferocity Cordial Tablets are incredulously and thoroughly effective. Enjoy! For those of you who seek to achieve most demonstrative/non-invasive/non-prohibitive appetite suppression without the negative implications of ongoing usage of MaHuang Herb, Ephedra/Ephedrine or Caffeine as are so magnaminously utilized in a multitude of herbal "diet aids" entitled as "Thermogenics" ... this is ABSOLUTELY the herbal agenda/product for you!! Entirely Natural! Increases Energy! Increases Metabolism! Decreases Appetite! *********************************************** Extreme Martial Arts Botanical Remedies Eastern culture has long had a treatment for bone, muscle, tendon, ligament, sinew and joint distress, traumas, afflictions and constrictions. We are pleased to offer Equivalence Tablets & Dragon Wing Remedy Spray (Hei Ping Shun) (Hei Long Chibang) PLEASE NOTE: While it is true that all physiological traumas and injuries are unique and that no product can arbitrarily eliminate all of the pain and discomfort in all people all of the time, the combination of Equivalence Tablets (Hei Ping Shun) and Dragon Wing Remedy (Hei Long Chibang) remedial botanicals does guarantee to at the least: 1. Significantly reduce discomfort and pain! (In many instances most, if not all, traumas and distress can be eliminated!) 2. Significantly increase mobility and strength ratio. (Please remember also the significance of proper diet, excercise, rest and prayer.) Equivalence Tablets & Dragon Wing Spray Remedials are comprised of entirely natural botanical factors. While Equivalence Tablets (Hei Ping Shun) and Dragon Wing Remedy Spray (Hei Long Chibang) are extremely effective individually, they are utilized to maximum advantage when used in conjunction with one another. ======================================================== PRICING INFORMATION: 1. SEVENTH HEAVEN KATHMANDU TEMPLE KIFF (tm) One .75 oz. jigget/bar $65.00 One 2.0 oz. jigget/bar $115.00 (Free Capillaris Herba with 2.0 oz. bar. Refer to Capillaris paragraph at end of text) 2. SWEET VJESTIKA APHRODISIA DROPS (tm) One 1.0 oz. bottle $90.00 Two 1.0 oz. bottles $140.00 3. SEVENTH HEAVEN PROSAKA (tm) One 100 tablet tin $40.00 Three 100 tablet tins $105.00 Six 100 tablet tins $185.00 4. SEVENTH HEAVEN GENTLE FEROCITY (tm) One 300 tablet jar $130.00 5. Equivalence Tablets - Each bottle contains 90 - 500mg tablets. ** 3-pack (270 tablets) $83.00 ** 6-pack (540 tablets) $126.00 (save $40.00) ** 9-pack (810 tablets) $159.00 (save $90.00) ** 12-pack (1,080 tablets) $192.00 (save $140.00) 6. Dragon Wing Spray Remedy - Each spray bottle contains 4 liquid oz. ** 3-pack (3 - 4 oz. bottles) $83.00 ** 6-pack (6 - 4 oz. bottles) $126.00 (save $40.00) ** 9-pack (9 - 4 oz. bottles) $159.00 (save $90.00) ** 12-pack (12 - 4 oz. bottles) $192.00 (save $140.00) 7. Dynamic Duo Introductory Offers ** 3-pack Equivalence Tabs & 3-pack Dragon Wing $126.00 (save $40.00) ** 6-pack Equivalence Tabs & 3-pack Dragon Wing $159.00 (save $50.00) ** 9-pack Equivalence Tabs & 6-pack Dragon Wing $215.00 (save $70.00) ** 12-pack Equivalence Tabs & 9-pack Dragon Wing $271.00 (save $80.00) 8. SWEET APHRODISIA INTRO COMBINATION OFFER Includes one, 2.0 oz. jigget/bar of Kathmandu Temple Kiff & one, 1 oz. bottle of Sweet Vjestika Aphrodisia Drops. For $150.00 (Reg. $205.00 Save $55) (Free Capillaris Herba with this intro offer. Refer to Capillaris paragraph at end of text) 9. BODY, MIND, SPIRIT "HEAVENLY" INTRO COMBINATION OFFER Includes one, 2.0 oz. jigget/bar of Kathmandu Temple Kiff & 1 tin (100 tablets) of Seventh Heaven Prosaka. For $125.00 (Reg. $155.00 Save $30) (Free Capillaris Herba with this intro offer. Refer to Capillaris paragraph at end of text) 10. "PURE ENERGY" INTRO COMBINATION OFFER Includes one, 2.0 oz. jigget/bar of Kathmandu Temple Kiff & 1 jar (300 tablets) of Seventh Heaven Gentle Ferocity. For $170.00 (Reg. $245.00 Save $75) (Free Capillaris Herba with this intro offer Refer to Capillaris paragraph at end of text) 11. "SENSITIVE" PREFERENTIAL INTRO COMBINATION OFFER Includes one, 2.0 oz. jigget/bar of Kathmandu Temple Kiff & 1 tin (100 tablets) of Seventh Heaven Prosaka & 1 jar (300 tablets) of Seventh Heaven Gentle Ferocity For $200.00 (Reg. $285.00 Save $85) (Free Capillaris Herba with this intro offer Refer to Capillaris paragraph at end of text.) 12. ULTIMATE HERBACEOUSNESS INTRO COMBINATION OFFER Includes one - 2.0 oz. jigget / bar of Kathmandu Temple Kiff, one - 1 oz. bottle of Sweet Vjestika Aphrodisia Drops, one - 100 tablet tin of Prosaka, and one - 300 count jar of Gentle Ferocity for a deep discounted Retail Price of $260.00 (Reg. $375.00 Save $115) (Free Capillaris Herba with this intro offer Refer to Capillaris paragraph at end of text.) SPECIAL OFFER: For a limited time only, you will receive a FREE personal brass hookah with the Ultimate Herbaceous Intro Offer as our gift to you. This hookah has a retail value of $25.00. ************************************************** ORDERING INFORMATION: For your convenience, you can call us direct with your orders or questions. Call 1-623-974-2295 Monday - Friday -- 10:30 AM to 7:00 PM (Mountain Time) Saturday -- 11:00 AM to 3:00 PM (Mountain Time) For all domestic orders, add $5.00 shipping & handling (shipped U.S. Priority Mail). Add $20.00 for International orders. ************************************************** SPECIAL DISCOUNT & GIFT Call now and receive a FREE botanical gift! With every order for a 2.0 oz. jigget / bar of Kathmandu Temple Kiff or one of our four (4) Intro Combination Offers, we will include as our free gift to you ... a 2.0 oz. package of our ever so sedate, sensitive Asian import, loose-leaf Capillaris Herba for "happy" smoking or brewing ... (a $65.00 retail value). ==================================================== To remove your address from our list, click "Reply" in your email software and type "Remove" in the subject field, then send. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Feb 10 19:18: 8 2002 Delivered-To: freebsd-current@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id DE16737B402; Sun, 10 Feb 2002 19:18:06 -0800 (PST) Received: from pool0316.cvx21-bradley.dialup.earthlink.net ([209.179.193.61] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16a6ye-0007GC-00; Sun, 10 Feb 2002 19:18:00 -0800 Message-ID: <3C6737E0.7B21E7C0@mindspring.com> Date: Sun, 10 Feb 2002 19:17:52 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Andrey A. Chernov" Cc: Gregory Neil Shapiro , freebsd-current@FreeBSD.ORG Subject: Re: UPDATED: For Review: sendmail 8.12.2 import into -CURRENT References: <15435.24461.796634.405538@horsey.gshapiro.net> <15462.54353.720228.404682@horsey.gshapiro.net> <20020210203218.GA68564@nagual.pp.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Andrey A. Chernov" wrote: > +CFLAGS+=-pthread > ^^^^^^^^^^^^^^^^^^^^^^ > > Why you add -pthread? IMHO it is needed only on program building 'ld' > phase and not in library building. See libc_r/Makefile -D_THREAD_SAFE -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 3:22:26 2002 Delivered-To: freebsd-current@freebsd.org Received: from kashmir.etowns.net (dsl-65-184-96-65.telocity.com [65.184.96.65]) by hub.freebsd.org (Postfix) with ESMTP id EDAA037B400 for ; Mon, 11 Feb 2002 03:22:17 -0800 (PST) Received: (from somebody@localhost) by kashmir.etowns.net (8.11.6/8.11.6) id g1BBNb302321; Mon, 11 Feb 2002 03:23:37 -0800 (PST) (envelope-from somebody) Date: Mon, 11 Feb 2002 03:23:36 -0800 From: whoever To: freebsd-current@freebsd.org Cc: somebody@kashmir.etowns.net Subject: Ethernet tunnel device Message-ID: <20020211032336.A2135@kashmir.etowns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi I am running FreeBSD current and barely got vmware working on it. Now I have another problem which I cant resolve. If I close down the vmware program and restart I get an error that vmnet(1,2,3,0 whatever) device is busy and can not be used. using /usr/local/etc/rc.d/vmware.sh stop and then start again didnt help either. running ifconfig gave me the following output (for vmnet2 which i was and intend to use again) vmnet2: flags=8843 mtu 1500 inet 192.168.254.1 netmask 0xffffff00 broadcast 192.168.254.255 inet6 fe80::2bd:fff:fe0f:2%vmnet2 prefixlen 64 scopeid 0x8 ether 00:bd:0f:0f:00:02 Opened by PID 698 clearly the device is opened by the previous instance of the program and is not closed. deleting the devices and recreating them didnt help any (using devfs which comes stock in current - 5.0) strangely even after deleting these devices from /dev ifconfig still lists them !!!!!! may be its because of devfs ....... but there ought to be someway. trying to destroy the device using ifconfig gives an error too which (i believe) it should because destroy is not for ethernet tunnel device if I am not wrong. but there are no options to destroy the ethernet tunnel device in ifconfig .... Should there be????? I cant think anymore ... would appreciate input from you guys . Any input. Please dont shy about telling me that I am going the wrong ally thanks a bunch Saurabh Gupta To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 3:44:45 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 1F8B437B449; Mon, 11 Feb 2002 03:44:21 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA28011; Mon, 11 Feb 2002 22:44:08 +1100 Date: Mon, 11 Feb 2002 22:46:58 +1100 (EST) From: Bruce Evans X-X-Sender: To: Mikhail Teterin Cc: , Subject: Re: panic: bdwrite: buffer is not busy In-Reply-To: <200202101008.g1AA8eX08143@aldan.algebra.com> Message-ID: <20020211224352.W682-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 10 Feb 2002, Mikhail Teterin wrote: > On 10 Feb, Bruce Evans wrote: > > This is a well known bug in the device layer. I reported it on > > 2001/12/26 and fixed it locally a little later. See the thread in > > -current about "panic during fdisk'ing a md(4) device" for patches. > > Fdisk I don't really need, but attempting to newfs the floppy caused the > same panic :-\ And mounting the already formatted floppy leads to > "invalid argument". Could we have this fixed soon, please? The inability > to access a floppy is a great setback for my local FreeBSD advocacy > efforts :-) Newfs'ing /dev/fd0 (instead of /dev/fd0[a-c]) should work better. Not using devfs might work too. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 4:47:16 2002 Delivered-To: freebsd-current@freebsd.org Received: from mharnois.mdharnois.net (customer-mpls-23.cpinternet.com [209.240.253.23]) by hub.freebsd.org (Postfix) with ESMTP id 2CDEB37B404; Mon, 11 Feb 2002 04:47:02 -0800 (PST) Received: by mharnois.mdharnois.net (Postfix, from userid 1000) id BA2D92477; Mon, 11 Feb 2002 12:47:07 +0000 (GMT) To: "David O'Brien" Cc: freebsd-current@FreeBSD.ORG Subject: Re: Binutils fixed in -current? References: <20020206194515.VOTF3578.rwcrmhc52.attbi.com@rwcrwbc55> From: "Michael D. Harnois" Date: 11 Feb 2002 12:47:07 +0000 Message-ID: <876654rxro.fsf@mharnois.mdharnois.net> Lines: 20 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (bamboo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > first time only: > > cd /usr/src/gnu/usr.bin/binutils > cvs -qR up -D '1/27/2002 11:55 UTC' > cd /usr/src/contrib/binutils > cvs -qR up -D '1/27/2002 11:55 UTC' I thought this sounded like a great idea, but it gives me In file included from /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-i386.c:2159: elf32-target.h:605: `bfd_elf32_bfd_merge_sections' undeclared here (not in a function) elf32-target.h:605: initializer element is not constant elf32-target.h:605: (near initialization for `bfd_elf32_i386_vec._bfd_merge_sections') -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran Church Washburn, Iowa 1L, UST School of Law Minneapolis, Minnesota The price one pays for pursuing any profession, or calling, is an intimate knowledge of its ugly side. -- James Baldwin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 5:17:33 2002 Delivered-To: freebsd-current@freebsd.org Received: from mharnois.mdharnois.net (customer-mpls-23.cpinternet.com [209.240.253.23]) by hub.freebsd.org (Postfix) with ESMTP id E6FA337B405; Mon, 11 Feb 2002 05:17:31 -0800 (PST) Received: by mharnois.mdharnois.net (Postfix, from userid 1000) id E9CA22485; Mon, 11 Feb 2002 13:17:42 +0000 (GMT) To: "Michael D. Harnois" Cc: "David O'Brien" , freebsd-current@FreeBSD.ORG Subject: Re: Binutils fixed in -current? References: <20020206194515.VOTF3578.rwcrmhc52.attbi.com@rwcrwbc55> <876654rxro.fsf@mharnois.mdharnois.net> From: "Michael D. Harnois" Date: 11 Feb 2002 13:17:42 +0000 In-Reply-To: <876654rxro.fsf@mharnois.mdharnois.net> Message-ID: <87ofiwqhs9.fsf@mharnois.mdharnois.net> Lines: 8 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (bamboo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Never mind. My bad. -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran Church Washburn, Iowa 1L, UST School of Law Minneapolis, Minnesota The price one pays for pursuing any profession, or calling, is an intimate knowledge of its ugly side. -- James Baldwin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 6:50:15 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id 878AF37B484 for ; Mon, 11 Feb 2002 06:49:53 -0800 (PST) Received: (qmail 6132 invoked from network); 11 Feb 2002 14:49:52 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([65.90.117.36]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 11 Feb 2002 14:49:52 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020211060831.T9036-100000@gamplex.bde.org> Date: Mon, 11 Feb 2002 09:49:49 -0500 (EST) From: John Baldwin To: Bruce Evans Subject: Re: final ucred patch Cc: current@FreeBSD.ORG, Julian Elischer Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 10-Feb-02 Bruce Evans wrote: >> + } >> + if (p->p_ucred) { > > How can this be NULL? The old code didn't check. Agreed. Julian, can you take it out and replace it with a KASSERT() instead and then get a traceback of the panic? >> switch (type) { >> case T_PRIVINFLT: /* privileged instruction fault */ >> @@ -644,10 +654,12 @@ >> userret(td, &frame, sticks); >> mtx_assert(&Giant, MA_NOTOWNED); >> userout: >> +#ifdef INVARIANTS >> mtx_lock(&Giant); >> crfree(td->td_ucred); >> - mtx_unlock(&Giant); >> td->td_ucred = NULL; >> + mtx_unlock(&Giant); >> +#endif >> out: >> return; >> } > > I think moving the unlock is just an obfuscation. td_ucred isn't locked > by Giant. Yep, definitely agree. > Bruce -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 7:14:13 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id D11C837B416; Mon, 11 Feb 2002 07:14:07 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g1BFE4oe017600; Mon, 11 Feb 2002 10:14:04 -0500 (EST) Date: Mon, 11 Feb 2002 10:14:04 -0500 (EST) From: Daniel Eischen To: Bruce Evans Cc: Kevin Day , current@FreeBSD.ORG, bde@FreeBSD.ORG Subject: Re: function name collision on "getcontext" with ports/editors/joe In-Reply-To: <20020211114221.H10505-100000@gamplex.bde.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 11 Feb 2002, Bruce Evans wrote: > On Sun, 10 Feb 2002, Daniel Eischen wrote: > > > On Mon, 11 Feb 2002, Bruce Evans wrote: > > > includes for the normal namespace > > > pollution that was needed to use sigreturn(2) (except sigreturn(2) > > > itself isn't actually declared anywhere). Including > > > gives the corresponding namespace pollution for using the current > > > sigreturn(2). This is probably a mistake. (Don't believe the > > > sigreturn man page; it documents osigreturn(2) for the i386 only.) > > > Programs shouldn't have any problems with this, since they should > > > define _POSIX_SOURCE if they only want the POSIX namespace ;-). > > > > Poking about on a Solaris 8 system shows that they have a > > that defines the {get,set,make,swap}context > > prototypes. also includes > > to get the definitions for ucontext_t. > > is just as nonstandard as . > > > Under FreeBSD, is a link to , > > which both declare ucontext_t and {get,set,make,swap}context. > > The link part is intentional. We have to have for > use in the kernel, so it is simpler not to have a separate user > header. The only advantage of the Solaris implementation is that > it punishes applications that include the nonstandard header. > > > What do you recommend we do? Should we not include > > from , or do what Solaris does, or just leave > > everything as is? > > Don't include from , and fix whatever > breaks. I think applications that use the new sigreturn can be required > to include both and . There should be fewer > of them than there used to be -- they can now use setcontext(). The > old sigcontext/sigreturn stuff should be cleaned up too (don't export > it to userland). It breaks more than that. Applications that just want to use sigaction, sigaltstack, etc, only need to include , but that also defines sigreturn as: int sigreturn __P((ucontext_t *)); Removing from prevents ucontext_t from being defined, so all users of would choke. We can change the prototype of sigreturn back to struct sigcontext *, or just forward declare ucontext_t in or . -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 7:53:42 2002 Delivered-To: freebsd-current@freebsd.org Received: from probity.mcc.ac.uk (probity.mcc.ac.uk [130.88.200.94]) by hub.freebsd.org (Postfix) with ESMTP id CD33D37B400 for ; Mon, 11 Feb 2002 07:53:37 -0800 (PST) Received: from dogma.freebsd-uk.eu.org ([130.88.200.97]) by probity.mcc.ac.uk with esmtp (Exim 2.05 #7) id 16aIlV-000KOG-00 for freebsd-current@freebsd.org; Mon, 11 Feb 2002 15:53:13 +0000 Received: (from jcm@localhost) by dogma.freebsd-uk.eu.org (8.11.6/8.11.1) id g1BFrDI25839 for freebsd-current@freebsd.org; Mon, 11 Feb 2002 15:53:13 GMT (envelope-from jcm) Date: Mon, 11 Feb 2002 15:53:13 +0000 From: j mckitrick To: freebsd-current@freebsd.org Subject: Where to find docs on newbus vs. cardbus vs. newcard Message-ID: <20020211155313.A25761@dogma.freebsd-uk.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Scanner: exiscan *16aIlV-000KOG-00*5q1fo2zM/ao* (Manchester Computing, University of Manchester) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm a little confused as to what these each mean, which is newest, and which is legacy. Could someone point me to TFM to read? jm -- My other computer is your windows box. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 8:37:53 2002 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id B525E37B41D for ; Mon, 11 Feb 2002 08:37:42 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g1BGbfi44675; Mon, 11 Feb 2002 09:37:41 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g1BGbeL72960; Mon, 11 Feb 2002 09:37:40 -0700 (MST) (envelope-from imp@village.org) Date: Mon, 11 Feb 2002 09:37:08 -0700 (MST) Message-Id: <20020211.093708.27185453.imp@village.org> To: jcm@FreeBSD-uk.eu.org Cc: freebsd-current@FreeBSD.ORG Subject: Re: Where to find docs on newbus vs. cardbus vs. newcard From: "M. Warner Losh" In-Reply-To: <20020211155313.A25761@dogma.freebsd-uk.eu.org> References: <20020211155313.A25761@dogma.freebsd-uk.eu.org> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020211155313.A25761@dogma.freebsd-uk.eu.org> j mckitrick writes: : I'm a little confused as to what these each mean, which is newest, and : which is legacy. Could someone point me to TFM to read? NEWBUS: The current way of doing FreeBSD device configuration. This is approximately sys/kern/subr_bus.c, bus_if.m and device_if.m. CardBus: PCMCIA standard for PCI cards in the PC Card form factor. FreeBSD's CardBus stuff can be found in dev/{pccard,pcic,exca,cardbus,pccbb}/*. I'm in the process of fixing bugs in this code base as well as removing redundant code and expanding support for more bridges and client devieces. This is what I've been calling NEWCARD. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 8:54:10 2002 Delivered-To: freebsd-current@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id D79CA37B41A for ; Mon, 11 Feb 2002 08:54:07 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id g1BGroV95581 for ; Mon, 11 Feb 2002 08:53:50 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: current@freebsd.org Subject: Build errors in usb scanner support on -current snapshot builder Date: Mon, 11 Feb 2002 08:53:50 -0800 Message-ID: <95577.1013446430@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -mpreferred-stack-boundary=2 vers.c linking kernel.debug uscanner.o: In function `uscanner_match': /usr/src/sys/i386/compile/GENERIC/../../../dev/usb/uscanner.c(.text+0x34): undefined reference to `usb_match_device' uscanner.o: In function `uscanner_attach': /usr/src/sys/i386/compile/GENERIC/../../../dev/usb/uscanner.c(.text+0xd6): undefined reference to `usb_match_device' *** Error code 1 Stop in /usr/src/sys/i386/compile/GENERIC. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 9: 0:16 2002 Delivered-To: freebsd-current@freebsd.org Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by hub.freebsd.org (Postfix) with ESMTP id AA25B37B416; Mon, 11 Feb 2002 09:00:13 -0800 (PST) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.11.6/8.11.5) with ESMTP id g1BGtpX21339; Mon, 11 Feb 2002 11:55:53 -0500 (EST) (envelope-from mi@aldan.algebra.com) Message-Id: <200202111655.g1BGtpX21339@aldan.algebra.com> Date: Mon, 11 Feb 2002 11:55:48 -0500 (EST) From: Mikhail Teterin Subject: Re: panic: bdwrite: buffer is not busy To: bde@zeta.org.au Cc: jhb@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <20020211224352.W682-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 11 Feb, Bruce Evans wrote: > On Sun, 10 Feb 2002, Mikhail Teterin wrote: > >> On 10 Feb, Bruce Evans wrote: >> > This is a well known bug in the device layer. I reported it on >> > 2001/12/26 and fixed it locally a little later. See the thread in >> > -current about "panic during fdisk'ing a md(4) device" for patches. >> >> Fdisk I don't really need, but attempting to newfs the floppy caused >> the same panic :-\ And mounting the already formatted floppy leads to >> "invalid argument". Could we have this fixed soon, please? The >> inability to access a floppy is a great setback for my local FreeBSD >> advocacy efforts :-) > > Newfs'ing /dev/fd0 (instead of /dev/fd0[a-c]) should work better. That's what I was doing... > Not using devfs might work too. Kind of grew used to it by now :-) Let's me keep / mounted read-only :-) Thanks! -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 9: 2: 4 2002 Delivered-To: freebsd-current@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id B510B37B416; Mon, 11 Feb 2002 09:02:01 -0800 (PST) Received: from pool0378.cvx22-bradley.dialup.earthlink.net ([209.179.199.123] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16aJpw-0000zP-00; Mon, 11 Feb 2002 09:01:53 -0800 Message-ID: <3C67F8F2.EB36BA9A@mindspring.com> Date: Mon, 11 Feb 2002 09:01:38 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen Cc: Bruce Evans , Kevin Day , current@FreeBSD.ORG, bde@FreeBSD.ORG Subject: Re: function name collision on "getcontext" with ports/editors/joe References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel Eischen wrote: > It breaks more than that. Applications that just want to use > sigaction, sigaltstack, etc, only need to include , > but that also defines sigreturn as: > > int sigreturn __P((ucontext_t *)); > > Removing from prevents ucontext_t > from being defined, so all users of would choke. > > We can change the prototype of sigreturn back to struct sigcontext *, > or just forward declare ucontext_t in or . Forward declare it. People who need its internals will include the proper header. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 9:16:50 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 1A8D337B404; Mon, 11 Feb 2002 09:16:48 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g1BHGiko003046; Mon, 11 Feb 2002 12:16:44 -0500 (EST) Date: Mon, 11 Feb 2002 12:16:44 -0500 (EST) From: Daniel Eischen To: Terry Lambert Cc: Bruce Evans , Kevin Day , current@FreeBSD.ORG, bde@FreeBSD.ORG Subject: Re: function name collision on "getcontext" with ports/editors/joe In-Reply-To: <3C67F8F2.EB36BA9A@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 11 Feb 2002, Terry Lambert wrote: > Daniel Eischen wrote: > > It breaks more than that. Applications that just want to use > > sigaction, sigaltstack, etc, only need to include , > > but that also defines sigreturn as: > > > > int sigreturn __P((ucontext_t *)); > > > > Removing from prevents ucontext_t > > from being defined, so all users of would choke. > > > > We can change the prototype of sigreturn back to struct sigcontext *, > > or just forward declare ucontext_t in or . > > Forward declare it. People who need its internals will > include the proper header. How do you easily forward declare something that is a typedef? You could forward declare struct __ucontext and use a pointer to that as the argument to sigreturn, but that doesn't seem right as it is relying on how ucontext_t is defined. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 9:39: 0 2002 Delivered-To: freebsd-current@freebsd.org Received: from energyhq.homeip.net (213-97-200-73.uc.nombres.ttd.es [213.97.200.73]) by hub.freebsd.org (Postfix) with ESMTP id 5D70B37B41E for ; Mon, 11 Feb 2002 09:38:46 -0800 (PST) Received: by energyhq.homeip.net (Postfix, from userid 1001) id C70FC3FC25; Mon, 11 Feb 2002 18:38:41 +0100 (CET) Date: Mon, 11 Feb 2002 18:38:41 +0100 From: Miguel Mendez To: "M. Warner Losh" Cc: jcm@FreeBSD-uk.eu.org, freebsd-current@FreeBSD.ORG Subject: Re: Where to find docs on newbus vs. cardbus vs. newcard Message-ID: <20020211183841.A51072@energyhq.homeip.net> References: <20020211155313.A25761@dogma.freebsd-uk.eu.org> <20020211.093708.27185453.imp@village.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020211.093708.27185453.imp@village.org>; from imp@village.org on Mon, Feb 11, 2002 at 09:37:08AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 11, 2002 at 09:37:08AM -0700, M. Warner Losh wrote: Hi Warner, > CardBus: > PCMCIA standard for PCI cards in the PC Card form factor. > FreeBSD's CardBus stuff can be found in > dev/{pccard,pcic,exca,cardbus,pccbb}/*. I'm in the process of fixing > bugs in this code base as well as removing redundant code and > expanding support for more bridges and client devieces. This is what > I've been calling NEWCARD. So, in your opinion, how hard would it be to MFC from a recent -CURRENT to 4.5-RELEASE? More or less importing the stuff and little fixing or is a major rewrite of some part needed? Because as it seems that no one is going to do it any time soon I've put it in my TODO list, along with other stuff and was just wondering if it's relativitely easy or too much for a junior kernel hacker. Cheers, --=20 Miguel Mendez - flynn@energyhq.homeip.net GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8aAGgnLctrNyFFPERAryhAKCQcSJWOTE7pvTUamDeubtz7lF1nACdEq4B sfnqMEh6vKUG+liP3aZqsk0= =7zWd -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 12: 9:23 2002 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id E682937B405 for ; Mon, 11 Feb 2002 12:09:17 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g1BK9Gi45579; Mon, 11 Feb 2002 13:09:16 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g1BK9FL74145; Mon, 11 Feb 2002 13:09:15 -0700 (MST) (envelope-from imp@village.org) Date: Mon, 11 Feb 2002 13:08:31 -0700 (MST) Message-Id: <20020211.130831.121669635.imp@village.org> To: flynn@energyhq.homeip.net Cc: jcm@FreeBSD-uk.eu.org, freebsd-current@FreeBSD.ORG Subject: Re: Where to find docs on newbus vs. cardbus vs. newcard From: "M. Warner Losh" In-Reply-To: <20020211183841.A51072@energyhq.homeip.net> References: <20020211155313.A25761@dogma.freebsd-uk.eu.org> <20020211.093708.27185453.imp@village.org> <20020211183841.A51072@energyhq.homeip.net> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020211183841.A51072@energyhq.homeip.net> Miguel Mendez writes: : So, in your opinion, how hard would it be to MFC from a recent -CURRENT : to 4.5-RELEASE? More or less importing the stuff and little fixing or is : a major rewrite of some part needed? Because as it seems that no one is : going to do it any time soon I've put it in my TODO list, along with : other stuff and was just wondering if it's relativitely easy or too much : for a junior kernel hacker. It isn't a huge effort conceptutally, but there is a lot of infrastructure that CardBus depends on that isn't in -stable or only partially MFC'd. If someone wanted to start cranking on it, they could get it done in a few weeks worth of work. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 12:14:43 2002 Delivered-To: freebsd-current@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id E776537B404 for ; Mon, 11 Feb 2002 12:14:33 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id g1BKEWZ28034; Mon, 11 Feb 2002 12:14:32 -0800 Date: Mon, 11 Feb 2002 12:14:32 -0800 From: Brooks Davis To: whoever Cc: freebsd-current@FreeBSD.ORG Subject: Re: Ethernet tunnel device Message-ID: <20020211121432.A22389@Odin.AC.HMC.Edu> References: <20020211032336.A2135@kashmir.etowns.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020211032336.A2135@kashmir.etowns.net>; from somebody@kashmir.etowns.net on Mon, Feb 11, 2002 at 03:23:36AM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 11, 2002 at 03:23:36AM -0800, whoever wrote: > clearly the device is opened by the previous=20 > instance of the program and is not closed.=20 > deleting the devices and recreating them didnt help any > (using devfs which comes stock in current - 5.0) > strangely even after deleting these devices from /dev > ifconfig still lists them !!!!!! may be its because of > devfs ....... but there ought to be someway. There is no notification of last delete in devfs so deleting a node doesn't do anyway. > trying to destroy the device using ifconfig gives an error > too which (i believe) it should because destroy is not > for ethernet tunnel device if I am not wrong. >=20 > but there are no options to destroy the ethernet tunnel > device in ifconfig .... Should there be????? Yes, I think we should add support for network device cloning and consider removing support for devfs cloning since it doesn't behave very logicaly. It's not there now, though it wouldn't be very hard to add. > I cant think anymore ... would appreciate input from you=20 > guys . Any input. Please dont shy about telling me that > I am going the wrong ally It sounds like there's some sort of a bug in the close code. You are sure the previous instance is really gone, right? If it is, that's another issue. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8aCYnXY6L6fI4GtQRAsrzAJsGBJKje2qLcu4yYKaizVbp2gk3NQCeIzrr 4NSEbRRRJm4BTeaLT9KpV60= =F2rR -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 13:27:28 2002 Delivered-To: freebsd-current@freebsd.org Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by hub.freebsd.org (Postfix) with ESMTP id 374E937B400 for ; Mon, 11 Feb 2002 13:27:25 -0800 (PST) Received: from laptop.6bone.nl (penguin.ripe.net [193.0.1.232]) by birch.ripe.net (8.11.6/8.11.6) with SMTP id g1BLRKi09693; Mon, 11 Feb 2002 22:27:20 +0100 Received: (nullmailer pid 79227 invoked by uid 1000); Mon, 11 Feb 2002 16:01:31 -0000 Date: Mon, 11 Feb 2002 17:01:31 +0100 From: Mark Santcroos To: whoever Cc: freebsd-current@FreeBSD.ORG Subject: Re: Ethernet tunnel device Message-ID: <20020211170131.A79104@laptop.6bone.nl> References: <20020211032336.A2135@kashmir.etowns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020211032336.A2135@kashmir.etowns.net>; from somebody@kashmir.etowns.net on Mon, Feb 11, 2002 at 03:23:36AM -0800 X-Handles: MS6-6BONE, MS18417-RIPE Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Feb 11, 2002 at 03:23:36AM -0800, whoever wrote: > I am running FreeBSD current and barely got vmware > working on it. > Now I have another problem which I cant resolve. > If I close down the vmware program and restart I get an > error that vmnet(1,2,3,0 whatever) device is busy > and can not be used. > > using /usr/local/etc/rc.d/vmware.sh stop > and then start again didnt help either. > running ifconfig gave me the following > output (for vmnet2 which i was and intend to use again) > vmnet2: flags=8843 mtu 1500 > inet 192.168.254.1 netmask 0xffffff00 broadcast 192.168.254.255 > inet6 fe80::2bd:fff:fe0f:2%vmnet2 prefixlen 64 scopeid 0x8 > ether 00:bd:0f:0f:00:02 > Opened by PID 698 > > clearly the device is opened by the previous > instance of the program and is not closed. > deleting the devices and recreating them didnt help any > (using devfs which comes stock in current - 5.0) > strangely even after deleting these devices from /dev > ifconfig still lists them !!!!!! may be its because of > devfs ....... but there ought to be someway. > > trying to destroy the device using ifconfig gives an error > too which (i believe) it should because destroy is not > for ethernet tunnel device if I am not wrong. > > but there are no options to destroy the ethernet tunnel > device in ifconfig .... Should there be????? > > I cant think anymore ... would appreciate input from you > guys . Any input. Please dont shy about telling me that > I am going the wrong ally Hi, I recently asked for this on mobile- if more people experienced this behaviour. I will be looking into this now I know more people have it. Monitor mobile@freebsd.org for updates on this. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 14: 5:58 2002 Delivered-To: freebsd-current@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id 08E1837B400; Mon, 11 Feb 2002 14:05:46 -0800 (PST) Received: from elischer.org ([64.164.9.134]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GRE00L2Z2PKU8@mta6.snfc21.pbi.net>; Mon, 11 Feb 2002 14:05:45 -0800 (PST) Date: Mon, 11 Feb 2002 14:05:02 -0800 From: Julian Elischer Subject: ucred holding patch, BDE version To: jhb@freebsd.org, bde@freebsd.org, current@freebsd.org Message-id: <3C68400E.7F3FF1CE@elischer.org> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) Content-type: multipart/mixed; boundary="Boundary_(ID_dSrd7tGZA8RKg/kjSIaytA)" X-Accept-Language: en, hu Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --Boundary_(ID_dSrd7tGZA8RKg/kjSIaytA) Content-type: text/plain; charset=iso-8859-2 Content-transfer-encoding: 7BIT here is the BDE version ready to commit. Extended to other architectures. Bruce, John, comments? As I was adding a prototype to ucred.h I stripped the __Ps of the others in that section (in the spirit of "change it when editing it anyhow" -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v --Boundary_(ID_dSrd7tGZA8RKg/kjSIaytA) Content-type: text/plain; charset=iso-8859-2; name=thediff Content-transfer-encoding: 7BIT Content-disposition: inline; filename=thediff ? i386/conf/LINT ? modules/netgraph/ksocket/ng_ksocket.kld ? modules/netgraph/ksocket/ng_ksocket.ko Index: alpha/alpha/trap.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/trap.c,v retrieving revision 1.82 diff -u -r1.82 trap.c --- alpha/alpha/trap.c 15 Jan 2002 14:17:07 -0000 1.82 +++ alpha/alpha/trap.c 11 Feb 2002 21:59:32 -0000 @@ -298,9 +298,8 @@ sticks = td->td_kse->ke_sticks; td->td_frame = framep; KASSERT(td->td_ucred == NULL, ("already have a ucred")); - PROC_LOCK(p); - td->td_ucred = crhold(p->p_ucred); - PROC_UNLOCK(p); + if (td->td_ucred != p->p_ucred) + aquire_ucred(td, p); } else { sticks = 0; /* XXX bogus -Wuninitialized warning */ KASSERT(cold || td->td_ucred != NULL, @@ -626,10 +625,12 @@ framep->tf_regs[FRAME_SP] = alpha_pal_rdusp(); userret(td, framep, sticks); mtx_assert(&Giant, MA_NOTOWNED); +#ifdef INVARIANTS mtx_lock(&Giant); crfree(td->td_ucred); mtx_unlock(&Giant); td->td_ucred = NULL; +#endif } return; @@ -699,9 +700,8 @@ opc = framep->tf_regs[FRAME_PC] - 4; sticks = td->td_kse->ke_sticks; KASSERT(td->td_ucred == NULL, ("already have a ucred")); - PROC_LOCK(p); - td->td_ucred = crhold(p->p_ucred); - PROC_UNLOCK(p); + if (td->td_ucred != p->p_ucred) + aquire_ucred(td, p); #ifdef DIAGNOSTIC alpha_fpstate_check(td); @@ -822,10 +822,12 @@ */ STOPEVENT(p, S_SCX, code); +#ifdef INVARIANTS mtx_lock(&Giant); crfree(td->td_ucred); mtx_unlock(&Giant); td->td_ucred = NULL; +#endif #ifdef WITNESS if (witness_list(td)) { panic("system call %s returning with mutex(s) held\n", Index: i386/i386/trap.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v retrieving revision 1.211 diff -u -r1.211 trap.c --- i386/i386/trap.c 10 Jan 2002 11:49:54 -0000 1.211 +++ i386/i386/trap.c 11 Feb 2002 21:59:42 -0000 @@ -256,9 +256,8 @@ sticks = td->td_kse->ke_sticks; td->td_frame = &frame; KASSERT(td->td_ucred == NULL, ("already have a ucred")); - PROC_LOCK(p); - td->td_ucred = crhold(p->p_ucred); - PROC_UNLOCK(p); + if (td->td_ucred != p->p_ucred) + aquire_ucred(td, p); switch (type) { case T_PRIVINFLT: /* privileged instruction fault */ @@ -644,10 +643,12 @@ userret(td, &frame, sticks); mtx_assert(&Giant, MA_NOTOWNED); userout: +#ifdef INVARIANTS mtx_lock(&Giant); crfree(td->td_ucred); mtx_unlock(&Giant); td->td_ucred = NULL; +#endif out: return; } @@ -954,9 +955,8 @@ sticks = td->td_kse->ke_sticks; td->td_frame = &frame; KASSERT(td->td_ucred == NULL, ("already have a ucred")); - PROC_LOCK(p); - td->td_ucred = crhold(p->p_ucred); - PROC_UNLOCK(p); + if (td->td_ucred != p->p_ucred) + aquire_ucred(td, p); params = (caddr_t)frame.tf_esp + sizeof(int); code = frame.tf_eax; orig_tf_eflags = frame.tf_eflags; @@ -1099,10 +1099,12 @@ */ STOPEVENT(p, S_SCX, code); +#ifdef INVARIANTS mtx_lock(&Giant); crfree(td->td_ucred); mtx_unlock(&Giant); td->td_ucred = NULL; +#endif #ifdef WITNESS if (witness_list(td)) { panic("system call %s returning with mutex(s) held\n", Index: ia64/ia64/trap.c =================================================================== RCS file: /home/ncvs/src/sys/ia64/ia64/trap.c,v retrieving revision 1.42 diff -u -r1.42 trap.c --- ia64/ia64/trap.c 19 Nov 2001 08:06:56 -0000 1.42 +++ ia64/ia64/trap.c 11 Feb 2002 21:59:46 -0000 @@ -324,9 +324,8 @@ sticks = td->td_kse->ke_sticks; td->td_frame = framep; KASSERT(td->td_ucred == NULL, ("already have a ucred")); - PROC_LOCK(p); - td->td_ucred = crhold(p->p_ucred); - PROC_UNLOCK(p); + if (td->td_ucred != p->p_ucred) + aquire_ucred(td, p); } else { sticks = 0; /* XXX bogus -Wuninitialized warning */ KASSERT(cold || td->td_ucred != NULL, @@ -709,10 +708,12 @@ if (user) { userret(td, framep, sticks); mtx_assert(&Giant, MA_NOTOWNED); +#ifdef INVARIANTS mtx_lock(&Giant); crfree(td->td_ucred); mtx_unlock(&Giant); td->td_ucred = NULL; +#endif } return; @@ -758,9 +759,8 @@ td->td_frame = framep; sticks = td->td_kse->ke_sticks; KASSERT(td->td_ucred == NULL, ("already have a ucred")); - PROC_LOCK(p); - td->td_ucred = crhold(p->p_ucred); - PROC_UNLOCK(p); + if (td->td_ucred != p->p_ucred) + aquire_ucred(td, p); /* * Skip past the break instruction. Remember old address in case @@ -865,10 +865,12 @@ */ STOPEVENT(p, S_SCX, code); +#ifdef INVARIANTS mtx_lock(&Giant); crfree(td->td_ucred); mtx_unlock(&Giant); td->td_ucred = NULL; +#endif #ifdef WITNESS if (witness_list(td)) { panic("system call %s returning with mutex(s) held\n", Index: kern/subr_trap.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_trap.c,v retrieving revision 1.207 diff -u -r1.207 subr_trap.c --- kern/subr_trap.c 11 Feb 2002 20:37:53 -0000 1.207 +++ kern/subr_trap.c 11 Feb 2002 21:59:47 -0000 @@ -56,6 +56,24 @@ #include /* + * small routine to swap a thread's current ucred for the correct one + * taken from the process + */ +void +aquire_ucred(struct thread *td, struct proc *p) +{ + if (td->td_ucred != NULL) { + mtx_lock(&Giant); + crfree(td->td_ucred); + mtx_unlock(&Giant); + td->td_ucred = NULL; + } + PROC_LOCK(p); + td->td_ucred = crhold(p->p_ucred); + PROC_UNLOCK(p); +} + +/* * Define the code needed before returning to user mode, for * trap and syscall. * @@ -161,9 +179,8 @@ p->p_stats->p_prof.pr_ticks = 0; } mtx_unlock_spin(&sched_lock); - PROC_LOCK(p); - td->td_ucred = crhold(p->p_ucred); - PROC_UNLOCK(p); + if (td->td_ucred != p->p_ucred) + aquire_ucred(td, p); if (flags & KEF_OWEUPC && sflag & PS_PROFIL) addupc_task(ke, p->p_stats->p_prof.pr_addr, prticks); if (sflag & PS_ALRMPEND) { @@ -188,10 +205,12 @@ } userret(td, framep, sticks); +#ifdef INVARIANTS mtx_lock(&Giant); crfree(td->td_ucred); mtx_unlock(&Giant); td->td_ucred = NULL; +#endif s = cpu_critical_enter(); } mtx_assert(&Giant, MA_NOTOWNED); Index: powerpc/powerpc/trap.c =================================================================== RCS file: /home/ncvs/src/sys/powerpc/powerpc/trap.c,v retrieving revision 1.5 diff -u -r1.5 trap.c --- powerpc/powerpc/trap.c 5 Nov 2001 00:49:03 -0000 1.5 +++ powerpc/powerpc/trap.c 11 Feb 2002 21:59:54 -0000 @@ -227,9 +227,8 @@ sticks = td->td_kse->ke_sticks; td->td_frame = frame; KASSERT(td->td_ucred == NULL, ("already have a ucred")); - PROC_LOCK(p); - td->td_ucred = crhold(p->p_ucred); - PROC_UNLOCK(p); + if (td->td_ucred != p->p_ucred) + aquire_ucred(td, p); /* User Mode Traps */ switch (type) { @@ -297,10 +296,12 @@ } userret(td, frame, sticks); mtx_assert(&Giant, MA_NOTOWNED); +#ifdef INVARIANTS mtx_lock(&Giant); crfree(td->td_ucred); mtx_unlock(&Giant); td->td_ucred = NULL; +#endif } void Index: sparc64/sparc64/trap.c =================================================================== RCS file: /home/ncvs/src/sys/sparc64/sparc64/trap.c,v retrieving revision 1.22 diff -u -r1.22 trap.c --- sparc64/sparc64/trap.c 1 Jan 2002 20:26:46 -0000 1.22 +++ sparc64/sparc64/trap.c 11 Feb 2002 21:59:56 -0000 @@ -176,9 +176,8 @@ sticks = td->td_kse->ke_sticks; td->td_frame = tf; KASSERT(td->td_ucred == NULL, ("already have a ucred")); - PROC_LOCK(p); - td->td_ucred = crhold(p->p_ucred); - PROC_UNLOCK(p); + if (td->td_ucred != p->p_ucred) + aquire_ucred(td, p); } else { sticks = 0; if ((type & ~T_KERNEL) != T_BREAKPOINT) @@ -380,10 +379,12 @@ user: userret(td, tf, sticks); mtx_assert(&Giant, MA_NOTOWNED); +#ifdef INVARIANTS mtx_lock(&Giant); crfree(td->td_ucred); mtx_unlock(&Giant); td->td_ucred = NULL; +#endif out: CTR1(KTR_TRAP, "trap: td=%p return", td); return; @@ -540,9 +541,8 @@ sticks = td->td_kse->ke_sticks; td->td_frame = tf; KASSERT(td->td_ucred == NULL, ("already have a ucred")); - PROC_LOCK(p); - td->td_ucred = crhold(p->p_ucred); - PROC_UNLOCK(p); + if (td->td_ucred != p->p_ucred) + aquire_ucred(td, p); code = tf->tf_global[1]; /* @@ -677,10 +677,12 @@ */ STOPEVENT(p, S_SCX, code); +#ifdef INVARIANTS mtx_lock(&Giant); crfree(td->td_ucred); mtx_unlock(&Giant); td->td_ucred = NULL; +#endif #ifdef WITNESS if (witness_list(td)) { panic("system call %s returning with mutex(s) held\n", Index: sys/ucred.h =================================================================== RCS file: /home/ncvs/src/sys/sys/ucred.h,v retrieving revision 1.26 diff -u -r1.26 ucred.h --- sys/ucred.h 11 Oct 2001 23:38:17 -0000 1.26 +++ sys/ucred.h 11 Feb 2002 21:59:56 -0000 @@ -81,21 +81,23 @@ }; #ifdef _KERNEL +struct proc; /* needed for aquire_ucred prototype */ +struct thread; /* needed for aquire_ucred prototype */ - -void change_egid __P((struct ucred *newcred, gid_t egid)); -void change_euid __P((struct ucred *newcred, uid_t euid)); -void change_rgid __P((struct ucred *newcred, gid_t rgid)); -void change_ruid __P((struct ucred *newcred, uid_t ruid)); -void change_svgid __P((struct ucred *newcred, gid_t svgid)); -void change_svuid __P((struct ucred *newcred, uid_t svuid)); -void crcopy __P((struct ucred *dest, struct ucred *src)); -struct ucred *crdup __P((struct ucred *cr)); -void crfree __P((struct ucred *cr)); -struct ucred *crget __P((void)); -struct ucred *crhold __P((struct ucred *cr)); -int crshared __P((struct ucred *cr)); -int groupmember __P((gid_t gid, struct ucred *cred)); +void aquire_ucred(struct thread *td, struct proc *p); +void change_egid (struct ucred *newcred, gid_t egid); +void change_euid (struct ucred *newcred, uid_t euid); +void change_rgid (struct ucred *newcred, gid_t rgid); +void change_ruid (struct ucred *newcred, uid_t ruid); +void change_svgid (struct ucred *newcred, gid_t svgid); +void change_svuid (struct ucred *newcred, uid_t svuid); +void crcopy (struct ucred *dest, struct ucred *src); +struct ucred *crdup (struct ucred *cr); +void crfree (struct ucred *cr); +struct ucred *crget (void); +struct ucred *crhold (struct ucred *cr); +int crshared (struct ucred *cr); +int groupmember (gid_t gid, struct ucred *cred); #endif /* _KERNEL */ #endif /* !_SYS_UCRED_H_ */ --Boundary_(ID_dSrd7tGZA8RKg/kjSIaytA)-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 14:28:24 2002 Delivered-To: freebsd-current@freebsd.org Received: from probity.mcc.ac.uk (probity.mcc.ac.uk [130.88.200.94]) by hub.freebsd.org (Postfix) with ESMTP id 926F237B419 for ; Mon, 11 Feb 2002 14:28:17 -0800 (PST) Received: from dogma.freebsd-uk.eu.org ([130.88.200.97]) by probity.mcc.ac.uk with esmtp (Exim 2.05 #7) id 16aOvh-0005iG-00; Mon, 11 Feb 2002 22:28:09 +0000 Received: (from jcm@localhost) by dogma.freebsd-uk.eu.org (8.11.6/8.11.1) id g1BMS8G29780; Mon, 11 Feb 2002 22:28:08 GMT (envelope-from jcm) Date: Mon, 11 Feb 2002 22:28:08 +0000 From: j mckitrick To: "M. Warner Losh" Cc: freebsd-current@FreeBSD.ORG Subject: Re: Where to find docs on newbus vs. cardbus vs. newcard Message-ID: <20020211222808.A29698@dogma.freebsd-uk.eu.org> References: <20020211155313.A25761@dogma.freebsd-uk.eu.org> <20020211.093708.27185453.imp@village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20020211.093708.27185453.imp@village.org>; from imp@village.org on Mon, Feb 11, 2002 at 09:37:08AM -0700 X-Scanner: exiscan *16aOvh-0005iG-00*chrjpn6Z/Kk* (Manchester Computing, University of Manchester) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thanks, Warner! On Mon, Feb 11, 2002 at 09:37:08AM -0700, M. Warner Losh wrote: | NEWBUS: | The current way of doing FreeBSD device configuration. This | is approximately sys/kern/subr_bus.c, bus_if.m and device_if.m. That part is pretty clear. | CardBus: | PCMCIA standard for PCI cards in the PC Card form factor. I was pretty close on this as well. These are specifically 32-bit cards, correct? | dev/{pccard,pcic,exca,cardbus,pccbb}/*. I'm in the process of fixing | bugs in this code base as well as removing redundant code and | expanding support for more bridges and client devieces. This is what | I've been calling NEWCARD. Ah, this was the part I got mixed up. I thought Newcard was already up and running with the last iteration of changes you made (remember me and ToPIC on Toshiba? ;-) I thought this was already in -stable. jm -- My other computer is your windows box. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 14:34:58 2002 Delivered-To: freebsd-current@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 19A0A37B404; Mon, 11 Feb 2002 14:34:57 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id DF99410DDFB; Mon, 11 Feb 2002 14:34:56 -0800 (PST) Date: Mon, 11 Feb 2002 14:34:56 -0800 From: Alfred Perlstein To: Julian Elischer Cc: jhb@freebsd.org, bde@freebsd.org, current@freebsd.org Subject: Re: ucred holding patch, BDE version Message-ID: <20020211143456.I63886@elvis.mu.org> References: <3C68400E.7F3FF1CE@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C68400E.7F3FF1CE@elischer.org>; from julian@elischer.org on Mon, Feb 11, 2002 at 02:05:02PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Julian Elischer [020211 14:06] wrote: > here is the BDE version ready to commit. > Extended to other architectures. > > Bruce, John, comments? > > As I was adding a prototype to ucred.h I stripped the __Ps of the others in that > section > (in the spirit of "change it when editing it anyhow" I've been watching this patch fly back and forth several times now, my question is, what exactly is this supposed to protect us from and/or accomplish? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 14:35:12 2002 Delivered-To: freebsd-current@freebsd.org Received: from draco.over-yonder.net (draco.over-yonder.net [198.78.58.61]) by hub.freebsd.org (Postfix) with ESMTP id 8EB5637B416 for ; Mon, 11 Feb 2002 14:35:06 -0800 (PST) Received: by draco.over-yonder.net (Postfix, from userid 1012) id A0701FC4; Mon, 11 Feb 2002 16:35:05 -0600 (CST) Date: Mon, 11 Feb 2002 16:35:05 -0600 From: "Daniel M. Kurry" To: Brooks Davis Cc: whoever , freebsd-current@FreeBSD.ORG Subject: Re: Ethernet tunnel device Message-ID: <20020211163505.V62432@over-yonder.net> References: <20020211032336.A2135@kashmir.etowns.net> <20020211121432.A22389@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5-fullermd.1i In-Reply-To: <20020211121432.A22389@Odin.AC.HMC.Edu>; from brooks@one-eyed-alien.net on Mon, Feb 11, 2002 at 12:14:32PM -0800 X-OS: FreeBSD Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Feb 11, 2002 at 12:14:32PM -0800, some SMTP stream spewed forth: > On Mon, Feb 11, 2002 at 03:23:36AM -0800, whoever wrote: [...] > > trying to destroy the device using ifconfig gives an error > > too which (i believe) it should because destroy is not > > for ethernet tunnel device if I am not wrong. > > > > but there are no options to destroy the ethernet tunnel > > device in ifconfig .... Should there be????? > > Yes, I think we should add support for network device cloning and > consider removing support for devfs cloning since it doesn't behave very > logicaly. It's not there now, though it wouldn't be very hard to add. > > > I cant think anymore ... would appreciate input from you > > guys . Any input. Please dont shy about telling me that > > I am going the wrong ally > > It sounds like there's some sort of a bug in the close code. You are > sure the previous instance is really gone, right? If it is, that's > another issue. I have seen this same behavior, and the previous instance is, indeed, quite gone. > -- Brooks > > -- > Any statement of the form "X is the one, true Y" is FALSE. > PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 dan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 14:56:59 2002 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 01DDC37B402 for ; Mon, 11 Feb 2002 14:56:48 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g1BMuki46333; Mon, 11 Feb 2002 15:56:46 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g1BMujL75439; Mon, 11 Feb 2002 15:56:45 -0700 (MST) (envelope-from imp@village.org) Date: Mon, 11 Feb 2002 15:56:00 -0700 (MST) Message-Id: <20020211.155600.13462454.imp@village.org> To: jcm@freebsd-uk.eu.org Cc: freebsd-current@FreeBSD.ORG Subject: Re: Where to find docs on newbus vs. cardbus vs. newcard From: "M. Warner Losh" In-Reply-To: <20020211222808.A29698@dogma.freebsd-uk.eu.org> References: <20020211155313.A25761@dogma.freebsd-uk.eu.org> <20020211.093708.27185453.imp@village.org> <20020211222808.A29698@dogma.freebsd-uk.eu.org> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020211222808.A29698@dogma.freebsd-uk.eu.org> j mckitrick writes: : | CardBus: : | PCMCIA standard for PCI cards in the PC Card form factor. : : I was pretty close on this as well. These are specifically 32-bit : cards, correct? Yes. : | dev/{pccard,pcic,exca,cardbus,pccbb}/*. I'm in the process of fixing : | bugs in this code base as well as removing redundant code and : | expanding support for more bridges and client devieces. This is what : | I've been calling NEWCARD. : : Ah, this was the part I got mixed up. I thought Newcard was already up : and running with the last iteration of changes you made (remember me and : ToPIC on Toshiba? ;-) I thought this was already in -stable. NEWCARD is up and running, but has issues for some cards, bridges and lacks some useful features. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 15: 0:20 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id B900237B402; Mon, 11 Feb 2002 15:00:17 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020211230016.XKBU1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Mon, 11 Feb 2002 23:00:16 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA18359; Mon, 11 Feb 2002 14:45:52 -0800 (PST) Date: Mon, 11 Feb 2002 14:45:51 -0800 (PST) From: Julian Elischer To: Alfred Perlstein Cc: jhb@freebsd.org, bde@freebsd.org, current@freebsd.org Subject: Re: ucred holding patch, BDE version In-Reply-To: <20020211143456.I63886@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In the current world, when the thread enters userland, it does: lock giant crfree() (which includes mutexes) unlock giant if there are ASTs it does this once again for each AST waiting as well. And on the way into the system it does: lock process crhold() (which includes mutex ops) unlock process so if there is a single AST (not uncommon) it does on a system call, 4 to 6 locks and 4 to 6 unlocks just to get a reference on the ucred it already had a reference on. By not freeing it when going to userland, and checking if it is the right one when returning to the kernel, we replace that with a pointer comparison (well maybe 2) 99.999% of the time. John still wants to free it if INVARIANTS is on so he canh trap on inapropriate access. I'm not sure it's needed but am willing to do so.. On Mon, 11 Feb 2002, Alfred Perlstein wrote: > * Julian Elischer [020211 14:06] wrote: > > here is the BDE version ready to commit. > > Extended to other architectures. > > > > Bruce, John, comments? > > > > As I was adding a prototype to ucred.h I stripped the __Ps of the others in that > > section > > (in the spirit of "change it when editing it anyhow" > > I've been watching this patch fly back and forth several times now, > my question is, what exactly is this supposed to protect us from > and/or accomplish? > > -Alfred > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 15:39:38 2002 Delivered-To: freebsd-current@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id BFBA537B404; Mon, 11 Feb 2002 15:39:35 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 9227A10DDFB; Mon, 11 Feb 2002 15:39:35 -0800 (PST) Date: Mon, 11 Feb 2002 15:39:35 -0800 From: Alfred Perlstein To: Julian Elischer Cc: jhb@freebsd.org, bde@freebsd.org, current@freebsd.org Subject: Re: ucred holding patch, BDE version Message-ID: <20020211153935.J63886@elvis.mu.org> References: <20020211143456.I63886@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from julian@elischer.org on Mon, Feb 11, 2002 at 02:45:51PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Julian Elischer [020211 15:00] wrote: > In the current world, when the thread enters userland, it does: > > lock giant > crfree() (which includes mutexes) > unlock giant This isn't needed afaik. > if there are ASTs it does this once again for each AST waiting as well. > > And on the way into the system it does: > lock process > crhold() (which includes mutex ops) > unlock process This isn't needed, at least afaik. > so if there is a single AST (not uncommon) it does on a system call, 4 to > 6 locks and 4 to 6 unlocks just to get a reference on the ucred it already > had a reference on. By not freeing it when going to userland, and checking > if it is the right one when returning to the kernel, we replace that with > a pointer comparison (well maybe 2) 99.999% of the time. > > John still wants to free it if INVARIANTS is on so he canh trap on > inapropriate access. I'm not sure it's needed but am willing to do so.. This makes little sense to me. Maybe I'm missing something, but by virtue of ownership we don't have to worry about the ucred's refcount on entry into the kernel because it is the owner and no one else is allowed to change our privledges besideds ourselves via set[ug]id(). Therefore the additional hold on entry is completely useless no matter what and with that the release on exit is also useless. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 16: 4:22 2002 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id AC3B037B402 for ; Mon, 11 Feb 2002 16:04:20 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id g1C04IA20035; Mon, 11 Feb 2002 19:04:18 -0500 (EST) (envelope-from wollman) Date: Mon, 11 Feb 2002 19:04:18 -0500 (EST) From: Garrett Wollman Message-Id: <200202120004.g1C04IA20035@khavrinen.lcs.mit.edu> To: Daniel Eischen Cc: current@FreeBSD.ORG Subject: Re: function name collision on "getcontext" with ports/editors/joe In-Reply-To: References: <3C67F8F2.EB36BA9A@mindspring.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG < said: > How do you easily forward declare something that is a typedef? There is a reason style(9) says not to use such typedefs. Unfortunately, this one it written into a standard. Since We Are The Implementation, there is no difficulty in simply writing the appropriate structure type into the relevant declarations. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 16:18:52 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 862B937B404 for ; Mon, 11 Feb 2002 16:18:49 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g1C0ImMm003537; Mon, 11 Feb 2002 19:18:48 -0500 (EST) Date: Mon, 11 Feb 2002 19:18:48 -0500 (EST) From: Daniel Eischen To: Garrett Wollman Cc: current@FreeBSD.ORG Subject: Re: function name collision on "getcontext" with ports/editors/joe In-Reply-To: <200202120004.g1C04IA20035@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 11 Feb 2002, Garrett Wollman wrote: > < said: > > > How do you easily forward declare something that is a typedef? > > There is a reason style(9) says not to use such typedefs. > Unfortunately, this one it written into a standard. Since We Are The > Implementation, there is no difficulty in simply writing the > appropriate structure type into the relevant declarations. OK, thanks. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 16:20:25 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 7FAEB37B405; Mon, 11 Feb 2002 16:20:09 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020212002008.CCMK1672.rwcrmhc51.attbi.com@InterJet.elischer.org>; Tue, 12 Feb 2002 00:20: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 QAA18707; Mon, 11 Feb 2002 16:15:27 -0800 (PST) Date: Mon, 11 Feb 2002 16:15:26 -0800 (PST) From: Julian Elischer To: Alfred Perlstein Cc: jhb@freebsd.org, bde@freebsd.org, current@freebsd.org Subject: Re: ucred holding patch, BDE version In-Reply-To: <20020211153935.J63886@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 11 Feb 2002, Alfred Perlstein wrote: > * Julian Elischer [020211 15:00] wrote: > > In the current world, when the thread enters userland, it does: > > > > lock giant > > crfree() (which includes mutexes) > > unlock giant > > This isn't needed afaik. Argue with jhb. > > > if there are ASTs it does this once again for each AST waiting as well. > > > > And on the way into the system it does: > > lock process > > crhold() (which includes mutex ops) > > unlock process > > This isn't needed, at least afaik. see below. > > > so if there is a single AST (not uncommon) it does on a system call, 4 to > > 6 locks and 4 to 6 unlocks just to get a reference on the ucred it already > > had a reference on. By not freeing it when going to userland, and checking > > if it is the right one when returning to the kernel, we replace that with > > a pointer comparison (well maybe 2) 99.999% of the time. > > > > John still wants to free it if INVARIANTS is on so he canh trap on > > inapropriate access. I'm not sure it's needed but am willing to do so.. > > This makes little sense to me. > > Maybe I'm missing something, but by virtue of ownership we don't > have to worry about the ucred's refcount on entry into the kernel > because it is the owner and no one else is allowed to change our > privledges besideds ourselves via set[ug]id(). multiple threads can do it.. The proclock is needed to get the reference, guarding against other threads, and giant is needed fo rnot to free it because if it reaches a refcount of 0 it needs to call free(). (which john assures me needs Giant at this time). We could avoid the proclock with judicious use of an atomic refcount incrementing method. When Giant goes away it won't be so bad but it will STILL be quicker to not drop it across userland. > > Therefore the additional hold on entry is completely useless no > matter what and with that the release on exit is also useless. > > -Alfred > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 16:38:48 2002 Delivered-To: freebsd-current@freebsd.org Received: from sparc1.amuser-net.ne.jp (sparc1.amuser-net.ne.jp [210.164.150.34]) by hub.freebsd.org (Postfix) with ESMTP id 25B1E37B405; Mon, 11 Feb 2002 16:38:36 -0800 (PST) Received: from your13jxqacx6s ([210.155.148.84]) by sparc1.amuser-net.ne.jp (8.9.3/3.7Wpl2/DEKIRU1.00) with SMTP id HAA14514; Tue, 12 Feb 2002 07:20:20 +0900 Message-ID: <01da01c1b34a$67797750$c933fea9@your13jxqacx6s> From: "=?iso-2022-jp?B?GyRCRnxLXDFHMmg4JjVmMnEbKEI=?=" To: Subject: =?iso-2022-jp?B?GyRCJU8lJCVTJTglZyVzISYlIiVAJWslSCVTJUclKiROJDQwRkZiGyhC?= Date: Tue, 12 Feb 2002 06:10:01 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG $B%S%G%*$N==G\0J>e$N2hLL>pJs$K$h$kGw??$N1GA|!*(B $B!J%S%G%*#C#GEy$N(B352$B!_(B240$B2hAG$KBP$7(B1024$B!_(B768$B2hAG!K(B $B$b$A$m$sL5=$@5!"$"$i$f$k:YIt$,$/$C$-$j8+$($^$9!#(B $B:G?7$N%G%8%?%k5;=Q$GC0uM-8z!K(B $B")#1#7#0!!K-EgM9JX6I;_$a!!F|K\1G2h8&5f2q(B $B%O%$%S%8%g%s#A#V$N:F@8$K$O0J2<$N4D6-$,I,MW$G$9!#(B $B%Z%s%F%#%"%`-60J>e!"(BWindows98$B!"(B2000$B!"(BXP $B%Q%o!<#P#C!!#G#30J>e!!#O#S#80J9_(B $B$$$:$l$b(B1024$B!_(B768$B0J>e$N%G%#%9%W%l%$!!(B $B!!!!!!!!%a%b%j(B64MB$B0J>e!J(BXP$B$O(B128MB$B0J>e!K(B To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 16:41:57 2002 Delivered-To: freebsd-current@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id D359037B41F for ; Mon, 11 Feb 2002 16:41:47 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id g1C0fIE32925; Tue, 12 Feb 2002 00:41:18 GMT (envelope-from mark@grimreaper.grondar.za) Received: from grimreaper.grondar.org (mark@localhost [127.0.0.1]) by grimreaper.grondar.org (8.11.6/8.11.6) with ESMTP id g1BC4rS00397; Mon, 11 Feb 2002 12:04:54 GMT (envelope-from mark@grimreaper.grondar.za) Message-Id: <200202111204.g1BC4rS00397@grimreaper.grondar.org> To: Beech Rintoul Cc: freebsd-current@FreeBSD.ORG Subject: Re: PAM Error References: <20020207173137.815E833@nebula.anchoragerescue.org> In-Reply-To: <20020207173137.815E833@nebula.anchoragerescue.org> ; from Beech Rintoul "Thu, 07 Feb 2002 08:31:37 -0900." From: markm@FreeBSD.ORG Date: Mon, 11 Feb 2002 12:04:53 +0000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Yesterday I tried to use SWAT for the first time since the PAM configs were > moved from /etc/pam.conf and I'm getting the following error: > > Feb 6 22:54:05 galaxy swat: PAM _pam_init_handlers: could not open > /etc/pam.conf > > What do I need to do to fix this? Recompile the app. I'm guessing it is linked statically, so is not picking up the latest libpam. M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 17:20:15 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id BE87A37B402 for ; Mon, 11 Feb 2002 17:20:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020212012008.EGKX1147.rwcrmhc52.attbi.com@InterJet.elischer.org> for ; Tue, 12 Feb 2002 01:20: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 RAA18940 for ; Mon, 11 Feb 2002 17:16:27 -0800 (PST) Date: Mon, 11 Feb 2002 17:16:26 -0800 (PST) From: Julian Elischer To: FreeBSD current users Subject: BSDCON activities 2night? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Anyone making the usual plans or should I just look for the terminal room? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 17:20:41 2002 Delivered-To: freebsd-current@freebsd.org Received: from rn-re116a13.uwaterloo.ca (rn-re116a13.uwaterloo.ca [129.97.232.81]) by hub.freebsd.org (Postfix) with ESMTP id 69F4237B402 for ; Mon, 11 Feb 2002 17:20:32 -0800 (PST) Received: (from munish@localhost) by rn-re116a13.uwaterloo.ca (8.11.6/8.11.6) id g1C1Fm999592 for freebsd-current@FreeBSD.ORG; Mon, 11 Feb 2002 20:15:48 -0500 (EST) (envelope-from munish) Date: Mon, 11 Feb 2002 20:15:48 -0500 From: Munish Chopra To: freebsd-current@FreeBSD.ORG Subject: Re: PAM Error Message-ID: <20020211201548.M16024@rn-re116a13.uwaterloo.ca> Mail-Followup-To: freebsd-current@FreeBSD.ORG References: <20020207173137.815E833@nebula.anchoragerescue.org> <200202111204.g1BC4rS00397@grimreaper.grondar.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202111204.g1BC4rS00397@grimreaper.grondar.org>; from markm@FreeBSD.ORG on Mon, Feb 11, 2002 at 12:04:53PM +0000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Feb 11, 2002 at 12:04:53PM +0000, markm@FreeBSD.ORG wrote: > > Yesterday I tried to use SWAT for the first time since the PAM configs were > > moved from /etc/pam.conf and I'm getting the following error: > > > > Feb 6 22:54:05 galaxy swat: PAM _pam_init_handlers: could not open > > /etc/pam.conf > > > > What do I need to do to fix this? > > Recompile the app. I'm guessing it is linked statically, so is not > picking up the latest libpam. > Though that sounds logical to me too, I've had the same errors pop up using a self-compiled 'cups'. I haven't had time to try to chase what's going on. -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 17:22:19 2002 Delivered-To: freebsd-current@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id D107737B416; Mon, 11 Feb 2002 17:22:08 -0800 (PST) Received: from pool0022.cvx40-bradley.dialup.earthlink.net ([216.244.42.22] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16aRe1-0007eW-00; Mon, 11 Feb 2002 17:22:05 -0800 Message-ID: <3C686E1E.84A42678@mindspring.com> Date: Mon, 11 Feb 2002 17:21:34 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Alfred Perlstein , jhb@freebsd.org, bde@freebsd.org, current@freebsd.org Subject: Re: ucred holding patch, BDE version References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > > This makes little sense to me. > > > > Maybe I'm missing something, but by virtue of ownership we don't > > have to worry about the ucred's refcount on entry into the kernel > > because it is the owner and no one else is allowed to change our > > privledges besideds ourselves via set[ug]id(). > > multiple threads can do it.. > > The proclock is needed to get the reference, > guarding against other threads, and giant is needed fo rnot to free it > because if it reaches a refcount of 0 it needs to call free(). (which john > assures me needs Giant at this time). > We could avoid the proclock with judicious use of an atomic refcount > incrementing method. > > When Giant goes away it won't be so bad but it will STILL be quicker to > not drop it across userland. The "multiple threads" argument is bogus, since the calls to [gs]et[ug]id() are on a per process, not a per thread basis. An argument which *may* not be bogus (I am unconvinced) is that creds are immutable once instanced, and that the calls to [gs]et[ug]id() instance a new cred and replace, rather than changing an existing cred (this logically follows from credential inheritance, or the first set call would change the cred used by "init" and all other processes). Personally, I still do not understand the need to have a cred reference per thread, the only thing that makes any sense about that is to optimize the degenerate case of a daemon that makes calls as another ID, on behalf of a lot of users (or, sequentially, at least, different users). One example of such a program would be SAMBA (but *not* NFS, due to "access" semantics on objects based on path component access exclusion by credential not being an effective mechanism for NFS file handles). I think that you would need to have [gs]et[ug]id() be on a per thread basis for this to be an efficiency, and I think trying to do this pessimizes everything else. My gut tells me that creds should be per process, and that the references to them should be taken sparingly, and then only if a need can be justified, rather than "just in case some day". Kirk at one time called vnodes "the structure that ate the kernel"; he was wrong: it was creds. Perhaps this dicsussion is enough impetus to justify revisiting the atomic_t type definitions, which would be useful as reference counted hold/release mechanisms that would obviate the need for locks here? This would at least let you defer getting rid of the per thread cred instances until later. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 17:31: 8 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id 4672337B419 for ; Mon, 11 Feb 2002 17:31:06 -0800 (PST) Received: (qmail 22227 invoked from network); 12 Feb 2002 01:31:04 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([65.91.152.142]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Feb 2002 01:31:04 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3C68400E.7F3FF1CE@elischer.org> Date: Mon, 11 Feb 2002 20:30:54 -0500 (EST) From: John Baldwin To: Julian Elischer Subject: RE: ucred holding patch, BDE version Cc: current@freebsd.org, bde@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 11-Feb-02 Julian Elischer wrote: > here is the BDE version ready to commit. > Extended to other architectures. > > Bruce, John, comments? > > As I was adding a prototype to ucred.h I stripped the __Ps of the others in > that > section > (in the spirit of "change it when editing it anyhow" Hmm, acquire_ucred (don't really like that name, maybe thread_updatecred(td) which can use td_proc to get the proc) probably should be declared in sys/proc.h. Well, maybe not, sys/ucred.h is probably fine. But it's implementation should then be in kern_prot.c along with all the other ucred related functions. :) Also, please make the comment above the function into a complete sentence and capitalize appropriately, etc. as per style(9) just to be pedantic. I guess removing __P() as you go is ok if that spirit is what the -arch thread is desired. Personally I thought it should be the other way around just like we don't mix whitespace commits with code commits to avoid obfuscating function changes with style changes. IMO, just commit to ucred.h blowing away __P() first, then commit your functional changes with the rest. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 17:31:36 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id D097037B41B for ; Mon, 11 Feb 2002 17:31:12 -0800 (PST) Received: (qmail 22292 invoked from network); 12 Feb 2002 01:31:11 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([65.91.152.142]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Feb 2002 01:31:11 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020211153935.J63886@elvis.mu.org> Date: Mon, 11 Feb 2002 20:31:02 -0500 (EST) From: John Baldwin To: Alfred Perlstein Subject: Re: ucred holding patch, BDE version Cc: current@freebsd.org, bde@freebsd.org, Julian Elischer Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 11-Feb-02 Alfred Perlstein wrote: > * Julian Elischer [020211 15:00] wrote: >> In the current world, when the thread enters userland, it does: >> >> lock giant >> crfree() (which includes mutexes) >> unlock giant > > This isn't needed afaik. Yes, calling free() without Giant is about as good as calling fdrop() without Giant Alfred. :) >> if there are ASTs it does this once again for each AST waiting as well. >> >> And on the way into the system it does: >> lock process >> crhold() (which includes mutex ops) >> unlock process > > This isn't needed, at least afaik. Not strictly for the comparison as Julian and Terry pointed out since the race can occur anyway (i.e., you don't need the lock to see if p_ucred changed), however, if you are actually doing a crhold(), you want to make sure p_ucred isn't stale, so you need the proc lock. >> so if there is a single AST (not uncommon) it does on a system call, 4 to >> 6 locks and 4 to 6 unlocks just to get a reference on the ucred it already >> had a reference on. By not freeing it when going to userland, and checking >> if it is the right one when returning to the kernel, we replace that with >> a pointer comparison (well maybe 2) 99.999% of the time. >> >> John still wants to free it if INVARIANTS is on so he canh trap on >> inapropriate access. I'm not sure it's needed but am willing to do so.. > > This makes little sense to me. > > Maybe I'm missing something, but by virtue of ownership we don't > have to worry about the ucred's refcount on entry into the kernel > because it is the owner and no one else is allowed to change our > privledges besideds ourselves via set[ug]id(). Umm, do you understand the entire thread ucred reference at all? What if you have two threads on two different CPU's from teh same process and one changes your ucred out from under you while you are handlign a syscall? The idea here is to ensure that a thread has a consistent ucred for an entire user trap or syscall to avoid races involving credentials. > Therefore the additional hold on entry is completely useless no > matter what and with that the release on exit is also useless. No, you just haven't been keeping up. I added td_ucred at least a month or so ago and it was discussed on -arch before it went in. I have a big honking patch to test when I get back from BSDCon that changes the kernel to use td_ucred almost everywhere instead of p_ucred so that we actualyl use the per-thread ucred (which will be needed before we can stop being a 1:1:1:1 system) and also means credential ops such as suser(), and p_can* don't need locks for the current thread. (p_can* still need locks for the target process). > -Alfred -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 17:44:51 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 3070E37B405 for ; Mon, 11 Feb 2002 17:44:48 -0800 (PST) Received: (qmail 5623 invoked from network); 12 Feb 2002 01:44:47 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([65.91.174.125]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Feb 2002 01:44:47 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 11 Feb 2002 20:44:07 -0500 (EST) From: John Baldwin To: Julian Elischer Subject: Re: ucred holding patch, BDE version Cc: current@freebsd.org, bde@freebsd.org, Alfred Perlstein Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 12-Feb-02 Julian Elischer wrote: > The proclock is needed to get the reference, > guarding against other threads, and giant is needed fo rnot to free it > because if it reaches a refcount of 0 it needs to call free(). (which john > assures me needs Giant at this time). > We could avoid the proclock with judicious use of an atomic refcount > incrementing method. _No_! The proc lock is protecting p_ucred, it can't go away! What _can_ go away is the per-ucred mutex to protect the refcount if we ever revive the refcount API. > When Giant goes away it won't be so bad but it will STILL be quicker to > not drop it across userland. Yes. Actually, calling free() can still be rather expensive even when Giant is gone. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 17:45:10 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id C2EFF37B417 for ; Mon, 11 Feb 2002 17:44:51 -0800 (PST) Received: (qmail 5654 invoked from network); 12 Feb 2002 01:44:50 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([65.91.174.125]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Feb 2002 01:44:50 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3C686E1E.84A42678@mindspring.com> Date: Mon, 11 Feb 2002 20:44:40 -0500 (EST) From: John Baldwin To: Terry Lambert Subject: Re: ucred holding patch, BDE version Cc: current@freebsd.org, bde@freebsd.org, Alfred Perlstein , Julian Elischer Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 12-Feb-02 Terry Lambert wrote: > Julian Elischer wrote: >> > This makes little sense to me. >> > >> > Maybe I'm missing something, but by virtue of ownership we don't >> > have to worry about the ucred's refcount on entry into the kernel >> > because it is the owner and no one else is allowed to change our >> > privledges besideds ourselves via set[ug]id(). >> >> multiple threads can do it.. >> >> The proclock is needed to get the reference, >> guarding against other threads, and giant is needed fo rnot to free it >> because if it reaches a refcount of 0 it needs to call free(). (which john >> assures me needs Giant at this time). >> We could avoid the proclock with judicious use of an atomic refcount >> incrementing method. >> >> When Giant goes away it won't be so bad but it will STILL be quicker to >> not drop it across userland. > > The "multiple threads" argument is bogus, since the calls > to [gs]et[ug]id() are on a per process, not a per thread > basis. Thread 1 makes a syscall that blocks. Say it blocks in one of 3 VOP's all of which need a credential. Thread 2 changes the credentials of the process. Thread 1 now resumes assuming that say a VADMIN or VACCESS suceeded with the old cred that may not be valid any longer and performs VOP's with the now newer credential (which it may even read a stale value of w/o a lock thus using some random memory for the creds) to do its other VOP's which may now fail weirdly. The idea of per-thread ucred references is so that a thread will have the same credentials for the lifetime of a syscall so that the entire syscall is self consistent. It also means that except for when we update the ucred reference, we don't need locks to access thread credentials since the thread references are to read-only credentials. We discussed this on -arch _months_ ago and everyone agreed with it then. > Perhaps this dicsussion is enough impetus to justify > revisiting the atomic_t type definitions, which would > be useful as reference counted hold/release mechanisms > that would obviate the need for locks here? This would > at least let you defer getting rid of the per thread > cred instances until later. All having the refcount_t and other refcount_* functions would do is let us get rid of the per-ucred mutex (actually a pool mutex, so the overhead per ucred is just a pointer right now). It wouln't change the fact that we need a lock to make sure p_ucred is up to date before we read a value we need to depend on or actually use. > -- Terry -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18: 0:27 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 7AEBF37B416; Mon, 11 Feb 2002 18:00:16 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020212020015.CHQM1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Tue, 12 Feb 2002 02:00:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA19123; Mon, 11 Feb 2002 17:53:54 -0800 (PST) Date: Mon, 11 Feb 2002 17:53:54 -0800 (PST) From: Julian Elischer To: John Baldwin Cc: current@freebsd.org, bde@freebsd.org Subject: RE: ucred holding patch, BDE version In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 11 Feb 2002, John Baldwin wrote: > > On 11-Feb-02 Julian Elischer wrote: > > here is the BDE version ready to commit. > > Extended to other architectures. > > > > Bruce, John, comments? > > > > As I was adding a prototype to ucred.h I stripped the __Ps of the others in > > that > > section > > (in the spirit of "change it when editing it anyhow" > > Hmm, acquire_ucred (don't really like that name, maybe thread_updatecred(td) > which can use td_proc to get the proc) probably should be declared in > sys/proc.h. Well, maybe not, sys/ucred.h is probably fine. But it's > implementation should then be in kern_prot.c along with all the other ucred > related functions. :) I guess so. The name requires changing anyhow as it was pointed out to me that Bruce mis-spelled acquire and I didn't notice. > > Also, please make the comment above the function into a complete sentence and > capitalize appropriately, etc. as per style(9) just to be pedantic. I guess > removing __P() as you go is ok if that spirit is what the -arch thread is > desired. Personally I thought it should be the other way around just like we > don't mix whitespace commits with code commits to avoid obfuscating function > changes with style changes. IMO, just commit to ucred.h blowing away __P() > first, then commit your functional changes with the rest. hmmm I am completely confused as to which way we ended up deciding then.. :-) > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18: 0:43 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 2B94637B400; Mon, 11 Feb 2002 18:00:18 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020212020017.CHQZ1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Tue, 12 Feb 2002 02:00:17 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA19118; Mon, 11 Feb 2002 17:51:15 -0800 (PST) Date: Mon, 11 Feb 2002 17:51:13 -0800 (PST) From: Julian Elischer To: Terry Lambert Cc: Alfred Perlstein , jhb@freebsd.org, bde@freebsd.org, current@freebsd.org Subject: Re: ucred holding patch, BDE version In-Reply-To: <3C686E1E.84A42678@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 11 Feb 2002, Terry Lambert wrote: > Julian Elischer wrote: > > > This makes little sense to me. > > > > > > Maybe I'm missing something, but by virtue of ownership we don't > > > have to worry about the ucred's refcount on entry into the kernel > > > because it is the owner and no one else is allowed to change our > > > privledges besideds ourselves via set[ug]id(). > > > > multiple threads can do it.. > > > > The proclock is needed to get the reference, > > guarding against other threads, and giant is needed fo rnot to free it > > because if it reaches a refcount of 0 it needs to call free(). (which john > > assures me needs Giant at this time). > > We could avoid the proclock with judicious use of an atomic refcount > > incrementing method. > > > > When Giant goes away it won't be so bad but it will STILL be quicker to > > not drop it across userland. > > The "multiple threads" argument is bogus, since the calls > to [gs]et[ug]id() are on a per process, not a per thread > basis. there is no such thing as a per process syscall. Two threads can always do the same syscall at the same time. there needs to be a proc-lock to stop it from becoming chaotic in there. In actual fact, since you cannot alter a cred but only replace that which the process points to it's not quite that bad, but you need to either lock it or have atomic reference-counting that can handle the possibility that the cred could have bee decremented to 0 by another thread just before you checked it. > > An argument which *may* not be bogus (I am unconvinced) is > that creds are immutable once instanced, and that the calls > to [gs]et[ug]id() instance a new cred and replace, rather > than changing an existing cred (this logically follows from > credential inheritance, or the first set call would change > the cred used by "init" and all other processes). > > > Personally, I still do not understand the need to have a > cred reference per thread, the only thing that makes any > sense about that is to optimize the degenerate case of a > daemon that makes calls as another ID, on behalf of a lot > of users (or, sequentially, at least, different users). > One example of such a program would be SAMBA (but *not* > NFS, due to "access" semantics on objects based on path > component access exclusion by credential not being an > effective mechanism for NFS file handles). the cred that is in force at the time that the syscall STARTS is used for the full syscall otherwise you could have one cred used for the first part of a syscall and a completely differnet one used for the secnd part of a syscall. > > I think that you would need to have [gs]et[ug]id() be on a > per thread basis for this to be an efficiency, and I think > trying to do this pessimizes everything else. > > My gut tells me that creds should be per process, and > that the references to them should be taken sparingly, > and then only if a need can be justified, rather than > "just in case some day". creads can only be changed per process but the threads only pick up the change on next syscall startup. > > > Kirk at one time called vnodes "the structure that ate the > kernel"; he was wrong: it was creds. I believe it was Mike Karels. > > > Perhaps this dicsussion is enough impetus to justify > revisiting the atomic_t type definitions, which would > be useful as reference counted hold/release mechanisms > that would obviate the need for locks here? This would > at least let you defer getting rid of the per thread > cred instances until later. I've made that point before and I believe that jhb has said he would like such primatives. > > -- Terry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:16:54 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id 9CA9137B42A for ; Mon, 11 Feb 2002 18:16:16 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 9B0B4232B6; Mon, 11 Feb 2002 21:16:29 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 866F59EF9C; Mon, 11 Feb 2002 21:11:38 -0500 (EST) Date: Wed, 6 Feb 2002 14:33:21 -0600 From: "David W. Chapman Jr." To: jordan.breeding@attbi.com Cc: freebsd-current@freebsd.org Subject: Re: Binutils fixed in -current? Reply-To: "David W. Chapman Jr." Message-Id: <20020212021138.866F59EF9C@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Does anyone know if the problem with kde and other programs not working with the new binutils not working have been fixed yet? -- David W. Chapman Jr. dwcjr@inethouston.net Raintree Network Services, Inc. dwcjr@freebsd.org FreeBSD Committer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:16:58 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id EFAD437B427 for ; Mon, 11 Feb 2002 18:16:14 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 1113D230A0 for ; Mon, 11 Feb 2002 21:16:27 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 5FE969EF23; Mon, 11 Feb 2002 21:11:37 -0500 (EST) From: jordan.breeding@attbi.com To: freebsd-current@freebsd.org Subject: Binutils fixed in -current? Date: Wed, 06 Feb 2002 19:45:14 +0000 Message-Id: <20020212021137.5FE969EF23@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I read recently on this list that the problem with the -current binutils on Alphas had been fixed, did this also fix the problem on i386 which caused ports such as imlib, imlib2 and gnomelibs to behave weirdly as many of their binaries would segfault during configuring/linking/executing? I only ask because I would like to stop having to update my -current tree and then having to copy an old binutils over it so that things will work. Any information is appreciated. Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:17:11 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id 254E437B41B for ; Mon, 11 Feb 2002 18:16:11 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 1AECB230A9 for ; Mon, 11 Feb 2002 21:16:27 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 422E89EF20; Mon, 11 Feb 2002 21:11:37 -0500 (EST) Date: Wed, 6 Feb 2002 17:42:30 -0500 To: current@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Performance of -current vs -stable Message-Id: <20020212021137.422E89EF20@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 12:10 AM -0500 2/6/02, Garance A Drosihn wrote: >One simple test I tried was that I have a copy of the freebsd cvs >repository in /usr/cvs/free, on it's own partition. Each system >has it's own /usr/src, of course. I cvsup'ed /usr/cvs/free, and >then did a > time cvs status >/dev/null >in each /usr/src, on each system. The popular vote fingered the WITNESS option as the culprit for the significant slowdown I noticed in -current. I compiled a kernel which did nothing but turn that off, and here is an updated chart of my simple-minded benchmark: On current On current On stable +witness NO witness (no witness) ---------- ---------- ---------- real 7m 43.392s 5m 9.443s 4m 53.100s in the /usr/src user 0m 11.692s 0m 11.223s 0m 4.203s for current sys 3m 4.601s 0m 17.353s 0m 2.248s real 6m 40.322s 1m 57.438s 2m 39.361s in the /usr/src user 0m 10.531s 0m 9.474s 0m 6.653s for stable sys 4m 28.863s 0m 12.527s 0m 9.480s So, things are quite reasonable for my purposes if I turn off the WITNESS kernel option, and leave all the other debugging stuff active. reminder: The above is obviously not a scientific benchmark! It was just something adequate enough to show a rough idea of the performance I was "feeling". Thanks for the pointers. Now I'll try recompiling the rest of the ports I have on my -stable system, and see if I can't keep my office machine running in -current instead of -stable... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:18:31 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id 3D5D837B417 for ; Mon, 11 Feb 2002 18:16:20 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 26B1A232CC for ; Mon, 11 Feb 2002 21:16:32 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id E2C5D9EE4E; Mon, 11 Feb 2002 21:11:39 -0500 (EST) Date: Wed, 6 Feb 2002 16:03:16 +0100 (CET) From: BOUWSMA Beery To: freebsd-current@freebsd.org Subject: Lock order reversals, login-related, maybe... Message-Id: <20020212021139.E2C5D9EE4E@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Are the following lock order reversals something that I should mention when I encounter them, in general? On the other hand, this is from an older -current, built 25.Jan, before which I don't see these messages, while after installworld/reboot, I see them, except I haven't normally booted into -current other than after -stable wedges/panics and I want to background-fsck all filesystems. Actually, it looks like once I did, so this, which immediately follows my alternate-r00t-login, is unrelated to the background fsck, but it always follows my login. If that made any sense. Jan 30 08:34:56 dastardly login: ROOT LOGIN (t00r) ON ttyv7 Jan 30 08:34:57 dastardly kernel: lock order reversal Jan 30 08:34:57 dastardly kernel: 1st 0xc188b634 filedesc structure @ /usr/src/sys/kern/kern_descrip.c:925 Jan 30 08:34:57 dastardly kernel: 2nd 0xc031c940 Giant @ /usr/src/sys/kern/kern_descrip.c:959 Feb 1 14:13:36 dastardly login: ROOT LOGIN (t00r) ON ttyv3 Feb 1 14:13:37 dastardly kernel: lock order reversal Feb 1 14:13:37 dastardly kernel: 1st 0xc187e734 filedesc structure @ /usr/src/sys/kern/kern_descrip.c:925 Feb 1 14:13:37 dastardly kernel: 2nd 0xc031c940 Giant @ /usr/src/sys/kern/kern_descrip.c:959 Feb 1 14:22:24 dastardly login: ROOT LOGIN (t00r) ON ttyv7 Feb 1 14:22:25 dastardly kernel: lock order reversal Feb 1 14:22:25 dastardly kernel: 1st 0xc1880034 filedesc structure @ /usr/src/sys/kern/kern_descrip.c:925 Feb 1 14:22:25 dastardly kernel: 2nd 0xc031c940 Giant @ /usr/src/sys/kern/kern_descrip.c:959 [etc] I'll assume that since this is two weeks old, it's been noted already, but in general, I wonder if I should report such occurrences, in a more timely manner... thanks barry bouwsma To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:19:32 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id 617FF37B416; Mon, 11 Feb 2002 18:16:26 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 50614232CE; Mon, 11 Feb 2002 21:16:32 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 1EBC29F105; Mon, 11 Feb 2002 21:11:40 -0500 (EST) Reply-To: From: To: Cc: , , Subject: See Real Babes (0384CuMg3-126YqKc6577@20) Date: Wed, 6 Feb 2002 01:53:27 -0800 (PST) Message-Id: <20020212021140.1EBC29F105@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ------=_NextPart_000_00C4_03E14D8D.A0707E67 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjwvaGVhZD4NCjxib2R5Pg0KPGZvbnQgc2l6ZT0i MiI+PHU+PGI+V0FSTklORzwvYj48L3U+OiBUaGUgZm9sbG93aW5nIG1hdGVy aWFsIGlzIG9mIGFuIGV4dHJlbWUNCmFkdWx0IG5hdHVyZS4gSWYgeW91IGFy ZTxicj4NCm9mZmVuZGVkIGJ5IGV4cGxpY2l0IGFkdWx0IG1hdGVyaWFsIG9y IGFyZSB1bmRlciB0aGUgYWdlIG9mIDE4LCZuYnNwOyBkZWxldGUNCnRoaXMg ZW1haWwgbm93PC9mb250Pjxmb250IHNpemU9IjEiPi48L2ZvbnQ+DQo8cD4N CjxhIGltZyBTUkM9ImcwMS5qcGciIEJPUkRFUj0iMCIgaGVpZ2h0PSIxMDUi IHdpZHRoPSIxNDAiIGhyZWY9Imh0dHA6Ly93d3cuZnJlZXdlYmhvc3Q0dS5j b20vc2V4eTA4L2luZGV4b3MuaHRtIj4NCjxpbWcgU1JDPSJodHRwOi8vd3d3 OS5raW5naG9zdC5jb20vdGVlbi90bTMxNDUwLzIzLmpwZyIgQk9SREVSPTAg aGVpZ2h0PTEwNSB3aWR0aD0xNDA+DQo8aW1nIFNSQz0iaHR0cDovL3d3dzku a2luZ2hvc3QuY29tL3RlZW4vdG0zMTQ1MC9idXR0MS5qcGciIEJPUkRFUj0w IGhlaWdodD0xMDUgd2lkdGg9MTQwPg0KPGltZyBTUkM9Imh0dHA6Ly93d3c5 Lmtpbmdob3N0LmNvbS90ZWVuL3RtMzE0NTAvc2hlMS5qcGciIEJPUkRFUj0w IGhlaWdodD0xMDUgd2lkdGg9MTQwPg0KDQo8L2E+PC9wPg0KPHA+PGEgaW1n IFNSQz0iZzAxLmpwZyIgQk9SREVSPSIwIiBoZWlnaHQ9IjEwNSIgd2lkdGg9 IjE0MCIgaHJlZj0iaHR0cDovL3d3dy5mcmVld2ViaG9zdDR1LmNvbS9zZXh5 MDgvaW5kZXhvcy5odG0iPg0KPHU+VEhFIDxmb250IGNvbG9yPSIjRkYwMDAw Ij48Yj5IT1QtRVNUPC9iPjwvZm9udD4mbmJzcDsmbmJzcDsgKipYWFgqKiZu YnNwOw0KVEVFTiBIQVJEQ09SRSA8YnI+DQpBQ1RJT04gT04gVEhFIE5FVCBU T0RBWSEhPC91PjwvYT48L3A+DQo8cD48YSBpbWcgU1JDPSJnMDEuanBnIiBC T1JERVI9IjAiIGhlaWdodD0iMTA1IiB3aWR0aD0iMTQwIiBocmVmPSJodHRw Oi8vd3d3LmZyZWV3ZWJob3N0NHUuY29tL3NleHkwOC9pbmRleG9zLmh0bSI+ DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQpD TElDSyBIRVJFIEZPUiBJTlNUQU5UIEFDQ0VTUzxicj4NCioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKjwvYT48L3A+DQo8cD48dT48Yj5C ZXN0IGNvbnRlbnQgYXJvdW5kPC9iPjwvdT4gLSA8YnI+DQpDVU1TSE9UIEZh bnRhc2llczxicj4NCkFTUyBGYW50YXNpZXM8YnI+DQpTTVVUIEZhbnRhc2ll czxicj4NCkxFU0JJQU4gRmFudGFzaWVzPGJyPg0KT1JJRU5UQUwgRmFudGFz aWVzIEdBTE9SRTwvcD4NCjxwPjx1PlNQRUNJQUwgQk9OVVMgRk9SIFRSSUFM IE1FTUJFUlNISVA8YnI+DQo8L3U+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDxmb250IHNpemU9IjQiPiEhITkgYnJhbmQgbmV3IGNlbGViIG1vdmllcyEh ITwvZm9udD48L3A+DQo8cD4qKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0 dHA6Ly93d3cuZnJlZXdlYmhvc3Q0dS5jb20vc2V4eTA4L2luZGV4b3MuaHRt Ij5DTElDSw0KSEVSRSBGT1IgSU5TVEFOVCBBQ0NFU1M8L2E+PGJyPg0KKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciZuYnNwOzxi cj4NCmFuZCB3aXNoIHRvIGJlIHJlbW92ZWQgcGxlYXNlIDxhIGhyZWY9Im1h aWx0bzp0bTMxMDQ1NkB5YWhvby5jb20iPmNsaWNrDQpoZXJlPC9hPiBhbmQg cHV0Jm5ic3A7PGJyPg0KJnF1b3Q7R0VUIE1FIE9GRiZxdW90OyBpbiB0aGUg c3ViamVjdCBsaW5lPC9wPg0KPHA+Jm5ic3A7PC9wPg0KPC9ib2R5Pg0KPC9o dG1sPg0KDQpbMDM4NEA0XQ0K To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:19:12 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id 7393037B42C for ; Mon, 11 Feb 2002 18:16:17 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 261DE232B9; Mon, 11 Feb 2002 21:16:30 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id A05AF9F25E; Mon, 11 Feb 2002 21:11:38 -0500 (EST) Date: Wed, 6 Feb 2002 12:32:18 -0800 From: Alfred Perlstein To: Julian Elischer Cc: current@freebsd.org Subject: Re: Non 386 testers REALLY NEEDED Message-Id: <20020212021138.A05AF9F25E@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Julian Elischer [020206 12:20] wrote: > > for the set of patches at: > http://www.freebsd.org/~julian/adiff > > these patches SHOULD NOT EFFECT your system except to do some > slight re-aranging of stuff in the kernel. > > THe aim is to get this committed to 'clarify' the upcoming > KSE commit in http://www.freebsd.org/~julian/thediff > > which includes adiff as a subset. > > when adiff is committed thediff will become a lot easier for people to > read and check. I'd like to get adiff in relatively soon. I commend you on your wait for testers, but I find that after a couple of days of waiting for them to appear and give decent feedback usually just committing the code will bring out a horde of involentary testers which actually gets the code stabilized. This is current, we're allowed some breakage. Cross your I's and dot your T's first though. :-) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:19:23 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id 2CD3137B41C for ; Mon, 11 Feb 2002 18:16:11 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 81595230A8; Mon, 11 Feb 2002 21:16:27 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 779A49EE2F; Mon, 11 Feb 2002 21:11:37 -0500 (EST) To: current@FreeBSD.ORG Cc: mitchy@er.ams.eng.osaka-u.ac.jp Subject: ThinkPad X22 PC-Card slot problem Date: Wed, 06 Feb 2002 23:02:16 +0900 From: non@ever.sanda.gr.jp Message-Id: <20020212021137.779A49EE2F@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----Next_Part(Wed_Feb__6_23:02:07_2002_731)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit I recently installed -current to ThinkPad X22. Though it seems that X22's PC-Card slots work fine with -stable, in -current when probing PCICs I got following message, pcic0: mem 0x50000000-0x50000fff irq 11 at device 3.0 on pci2 pcib2: device pcic0 requested unsupported memory range 0x50000000-0x50000fff (decoding 0xc0200000-0xcfffffff, 0xe8000000-0xf00fffff) pcib2: device pcic0 requested decoded memory range 0x50000000-0x50000fff after this, pcic returns error but some how it is attached and when I install a PC-Card, the machine freezes. The address range above (0x50000000-0x50000fff) is same one that I see with -stable. When PCI_ALLOW_UNSUPPORTED_IO_RANGE is defined in sys/dev/pci/pci_pci.c, pcic does not return error, the machine does not freeze, but when a PC-Card is inserted I get the message, pccard: card inserted, slot 0 pcic0: reset 1 int is 10 stat is 5f pcic0: reset 2 int is 70 stat is 5f pcic0: reset 3 int is 70 stat is 7f pcic0: Event mask 0x9 pcib2: device pccard0 requested decoded I/O range 0x4000-0x25f pcib2: device pccard0 requested decoded I/O range 0x4000-0x25f pcib2: device pccard0 requested decoded I/O range 0x4000-0x25f pcib2: device pccard0 requested decoded I/O range 0x4000-0x25f pcib2: device pccard0 requested decoded I/O range 0x4000-0x25f : and the card does not attached. The complete dmesg with boot -v is attached. Any ideas ? // Noriaki Mitsunaga // ----Next_Part(Wed_Feb__6_23:02:07_2002_731)-- Content-Type: Application/Octet-Stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.X22-current.gz" H4sICCZVXzwCA2RtZXNnLlgyMi1jdXJyZW50AOw8/W/buJI/13/FoHfvkOzZDkl92rcpnuOk ra9Nk4vTfQssHgJZomK92JJWktu4f/3NkJKsOLbjZFssHrBFqlDiDOeDM8MZisowSZdZdDst 4MA/BN7riY5gTMD1VMLbTMqT8SlcZsm/pF90W8M1YKfXxqvL1NVQV1tdXXVVvT2urkJdFUzP bL2i4a/krYyLHJIQCrz9HEdfZJZHxZKeDL1ZFCZZHHldGMxmoMjmkMlcZl9k0G1VzFld1hl+ vro6+3QN/8F5H64XyLmcAFiAt4bd5z343/E1kFgtwH9ZkhR/L1LGuzLrevO8K+PbbpJ7d15n 0fX87r/S/tEiz47yzD/Kl/lRZLj2kZ/M02gmj96dfTq7Gg1bl5mcJV4gA5CzEO5kFssZvD6a 4NhH+q789Rq8Ati9zyxLMsa6a5jzJFjM5Bqm56dR9y55gDoxUf+olEnmFVF8C/4s8e8O8kPo drtwPR7qB31weo5hMm704P23NkSusMyqi/OewR0HO1rDjx9uPo/PbkbUfzMcfBydXA2uRxef IE4KyFPpR2GELHZgkRO1QIbeYlZAmMnfFzL2l63raC79ZBEXMoPXisxrWHVrWq5o0kIm96CU zALwKzmTGOaymCbBQ3I40gNiSma0MVORu/zch0u0rGgxh9FodNRow68yiY+GciYzHPoA8bqG 1Tl//w1s1+74My/PAfEP0U4u0OKiGI7h9TsZL6JYjpA2ziaMAnzI7u0JBxgXMk2J62PgiPNW esUCTfSY3RuuEfbC8Oe3l5/bv5yftU/P2pfjszZy3j4fX7UvB2ft8+FZe/ir2x6fXbbPr6/w 4Tt6OGgPzy9+QYhrwjDs9vn5r+23vyLSeHz2ppVJb4ZKmSfZEpCsyQSzDcNmcGD0hG2yDzBZ FjI/bF1Ol3nkr4D96SImg+m32D0aIuP4H7WubnoyDMM22KbDbVcPAAfcciH1bmksArJcq8Lg Tmg7CsPo2cIUPdOskHq2g6ZXonlfvKimfwyGawnhuox4dWz0x5rXSZTkhujDW5zhAE5GF2ND wBg9PfIlnEYZRh8aYirRb7LKK1joGC6rcc/iQlFh92HgSKRBENQ6BAw1X6gH4KOM1VylfkR4 aCjDkaIHUqGroRHLYf+NYrqylcapBtSsXcaXGjzwCq/JiGQr0IqTkNTc97jBKw54twn2BWlC OPNuaSBzYrYuMA5mevw8uo21MUFIlPuteDGb9eFn+oXuSJppwze04/IGLcOLg2SOICQKRmrI k0VGHTgB+LSchv+C0dHFm1blFBjbgYwP8kWaJlmBevAmMxmQhm6SVMYH/LD/CqOUBA5eEGSg oA7QIvzQPYQoRxW4ypq42UDySiyu3cFl+h8hVu1DBe6Ht/5UYnh6peXAWfpNOeIxswnqn/Db NMiOqYG0SEESDqLg2LAcy2Wufdj6rOLGf16OrqAg3nGNMdV0Rqi8eooCOWGtOL1npAqvmEKa Jb7M8yR7AxRmEhp6knhZUEKNcEHhNkQUckLPly2KyoQ9OjmnZeT6ssNP8fcjdOocDC9HHYaO 0YeffvoJzrIsyfpwrmIZyHvpL1RwC9E/ZNCGwdnNp4vrm7NfR+PrPx2/lDNNvqIxThZFgYCo +imaFwKDh0qFMLrHZqjjHanyNvPmc5oHmvRZ92G8Jm4eBGycvJ5lWhSuvwe3NwVSy2huhNmZ RAWoe5p7o6spYYh/oy0X3Zoxt6N+TWjqlLh6GD9d0CC4ArxZ6ym+UQfN8Rwj6rcklusQsyhQ uAk536xi/mMUwPhrVPjTdXitWEIZz6RM4UTdr0NRnCKY90ledChWTbIouJW1LOiDHbqGKzxE odmrov9kgZ7UejX30t84+2cfimUqAfMwjBa32MC8bOLlEoLSKdsYeb5JEJjBVZFAxZ/Om1cY roIkU85MaR66K61z6IY4GLpugHeYYb1SBHGYWVLQ73AR+8RA5dMdxjpEBp2aWCEkvJuHargn adnbafFNtMx1WnxFS+lE1DoxH+lErZJurROw9tSJMF3R4JM/5FP0HjHqd5ixVSmIjjEIs4xj D/O57PdjzvdlXbyEdXMP1vl+rLOa9clzWTdfwrqzB+viuaz7NetPkDfdFXlzjbzBnmudT8nq b5fV2OgKfJeFPQwPmyeF8bCeFGM1KRrXfALXCM0KV6zjuk/RdbbT9Z+i62yl+7QR2jVdc38j 9PaYmJX/cJoYwtlthKXrC8val3f3JQ5k7MG70XQg6/m+/5SZcX8VcdGj1EIXRPkzjI27fj2C vT7CUyqw9lCBVavA3OVXL1aBMP+oCsRqKQfnuSqw91CBXavAee4KoBOUn1U2s8jrjEfnOqoy 47r7QcKDyVxZIGARRTg0TAUNkGO2GQceFjg4JuWUZZGnOxeTJAsiLKhk2d3oxHIIR/apwin/ YabBKEu5N7DGXQGWBVQDlioLrsJMRzXD8AFCmslQYuqHmXKJxO5lmWchgnTCGoGvZWz86YxN rmVszjNDssEeGNmWkMwf4VYil7jc3hFeEFJUhmX6Vq9hWEwbFt+aKRq7M8UNSZGqWGhHCQRU 9WwOpwxOOZwKODUA/EWWUdV9ykqtPzBDNXNVB7pLOvOWbfjl3aBpfgzN7yDGsjuj/UrsKDya 4sPWYqoNW20UgStcxoeDo+HgHA5Gw/fGIXwen4Cv64MZYuJtZ7CqSlxlFNzlIQkEnDdoil7D 5hf55AVkEFsxWKITEM1FToUVbUsspgt6rkf9/B61QvukgE/boDfGekdMzR+BsyO6tPWOAK+Q BWiVY8EzxZsMHeaLrshz2utU84NmQnzwZ0pw0lCU0IoyNiuKNxX1AjKloniJvlFR/I8oij9L UQIlUFQObmUss8hf57uhGFMrxtqsGLFSjB734JP8qiU4VUCjoEyj9b4Kyr8H8VJdogTfqC6i 1Rj5RVoTe2uNvFjsXEEMtraEiM1LiGh0PlpC3FXnpiXE1EHerVYEsX0JEfUSEq5WBI2wcQlx 6yUkZKxGEGtLiFhfQh6HcuvhEsLFrlDOKaPUoZyZzULcc3UoF1WOsKn6cNZDudhZ3z4vlO8h KP+BgvLnCjr5YYKSMfGGoHxfQS1LPF6c1wV9UDuzDn9yx8LfR9CdIj7Oe8LnGK2waxEN19lQ 3lQiWo+MVnTcH5p/7DWXWwTdK8FzGwmevWcNyBll+Ou7GJWS3A1K+uFJmtiQpKnA7FMWdBX5 yRSuPlpDdFV6m9MZellwghH6pAz7GHMxaFqrvFs1MWg+XiSNelmoI3/Zo8iB2r/OCwzGi7hk HdtlUNczsJnSgQretD2+Md63N0f1wyeY0CvCPgxU6iI9DpM4jG4X5evVPPV82W+Beg/YBx3y KDJQU9BbHeZQ02YOY56rwFyqTxkoJK6QKpIKiRqBj80JYxaWGUK/Y9QACkloSg2k3c2Wrsn2 Q3I8YnqikUyNhKkRZ9xcQfJdlKyXsGe/BMl5CZJbzpO7CdK0DfxvPkLqvYSSVyK5XtmNi4ul DHoH0uQllPwt87QTKdiPUiiZp6ZcIUmFJEyfmfuzFz5XptT3MQzpbQ6giKSSxgMVNTGLrgKZ ryKcz58VyPjKu/nWQMZ3BDK+byB7TOn7BTK+TyB7xEClrh8XyPjmQOYi4p8QyMRfgeyvQPbn BzL+ZCDjVaqWyyzSFWgb3kaZ/Af+f1B7d8Xm7bOv9eZZlkczuMyifA6iaylfH52dnYHLRJfz SRUJQ9YMNFsiobU1pUN6T4egBo26OFeM0kHEAstzZBJ5PEIeu7pDM6l2LmSeo7ZZH6METpbr 9Q2rb3ka7Gt0U26p3GgV9PHJ1MtvvspUnVCapGFf8VhpqBXep6t9v8ssOcJQBWd0JiGWRb0L 5Jb7DswISz014zQ1N+rJ3aonIvu0ojYQKRnWx/pKcBWlcbTbKKeTIVjG0PG5ErKSpVIe6Q5d w+r1Pbdvh33LLgGVRZzmpGzXBqpZQHubYD1EwrJFw50uY28e+TAuvDiYLNXZFDrKUr8JieJ0 uiSl0gFGW5xd4zhKrXMZRN7q7I8+4xNFaNWsRkJYqrWu21Wj8/b0V7rRd82m7vEWRaLnVem0 nljipnwj0hmNB5s2rJrvPBBc2QFBljWRGqHlFV7a3IKmXU4YXA9IoI37hbbeL7TDNq5Kjklv PBynTef7VIdqG6F6HqrnoXoeOg9ZW+24IgdIPkpIalVkhyjmrFg9MEIbJnOa32PNQIky9/K7 Y2ZAkhdewY4tplvimGmIDgLgXPRJnMsRHTiaUJELVXc+877Ibb2r4evRqcE3DV4ho29YJbIW lN7Vlg/UmTISTXmRqV5gadUTAH+gAGddAc5DBbglypoC2JoC+G4F8J0K4OsKYA8VwBsyVg+0 jE4po9WUsbSxZqAfn5+QJT6wCmNzmC+x54sZHdJCLyO/CKJkDdvaiZ1H83Qm0ajn83Wy9paX M/FdnHyN++rUsdJPgMlsGQcOUei7SaA2FD7IpTrG13wzcBC5zBSHtefYZpvyJK2bxoktGoTG GFxDNcwbdcCTDknyBrimphH66vR7teeBD5qUSUKMXeqcLEU2p8K5q9gcnVKiZ3oTOBCHLWKA 9KFZaWl+9E0bjYPCJMY3QbBtooMJdB9Za2susWmog2CtNJ9T6FZbRlAkaMOzxKe979HV/1Gn n8ZpKb9oHD1TWJUoTd77infd//Pl+EjAebLIMcY1hiiVooHUMUJ4p5dIUBhzwmhXU01yq50n UZ5RzCvypVT1NmEpWn2PS9AdLjK0MdY3SqR8GfvkI311cgBvJlFBOK1QW4WMp17s05HHWZKm yzXjEAxDJXw6cwSz0VUyOnAfy5W96OhphPqdsqWEtldq0zTejt5eVJt0bahOYRdTXAmnyQyX f2Va3DRZ58MJHWx8ra1cLQA0hL4F1sqjpNbDIkOmiZ6pLD+KASXDZZe+sSjdAHvzGktxPPeW ChqDSLVrqHtpIESmtOaeN/9X2Crw6HOagOwXdN4cGFq9QAZscKCnIFeKcfVr9pLFWiV6OLW5 iSszI50SQ6iLNImp/mylqV8nF/K+kDElJfQiRg2t0pISZnx5qVo10YlPRH1DEXUa5qvAK5vz p1FKOd7Bp9HJycezThLPloekwOHF+eXgeoTPlJW20lmkErPLj6NLwPTla5LdraUOaaoyB7X2 z5pL/ywtFGqm4Juwukelw9kiLTpqcmMlAzKqT1B4GfolLfRHF03Up2IdHbaQ2qzn2EeK25Ae 2DYFuYZ37zOsP594RfMcrP58A05QYpkt14+3er6nA+YQcz4vrVSwF72/ul/SjYs4LQgepSWZ 9IIlOg/m4vn/QH4X6W9ZoqKG4k9AUcTuV5F7J2xIgOFTUFRJ9st97v3gdnOIHo1g6ROjYbDB FYDC0i6o62xJrSsEuLkkF8FlVjBj83Nzy3N3y3N/83Njy/jGlvGNLeNjsGvJ+xu0gpsooC8/ wuXBYStH5eRP6ObLLVoCXnZD0cDK1m4was6weEP70zZHAPTRTJlgboSke4KLk7jThE0ylS5c pGqD7+riXOd6UaLrWlmdo1I7j+wejUvdB+W9H5T1aFDel/2+X95X9eok1OfnqbBqecEXVq9g Sbmi1Z1Tyv8pd17Qt4i3ao2roLHi/XfofyQcqrSqCA2q9bjhrAQmT9yBoE+cWCv1TSj6v9UI Y83HFfJxTXx0iIVJcVPbQJ+2MVYJg6o5DOO7DGL+8UHE9+BEfA9O+PfghGtOnjX9fr4L3tCH JPlq9mWwC17QC/V70QtrFw5ot0rXAKweJJTPIxo9Bb8ixzaQm70A3Vphx/4TIlf0Avy1oprO 9TdL9YNcJWTjJVb5c0rH8mSmt4Dq+pGtAf/yboD1gA1foqxYYCVeIuVlxXOsmH+jYcMJ1jW6 CsQkax7FCC+xBvcK+tIq9+EgX+Y0QN19SMsif1RGGHuUEXxnGcEflhHC5I+v1Sj7lRN81wSo CkOUFYax0mCUiG05EvYZW/viPYyThetGRisoTm9VW9DeXXWstEL1FWqwcg6vXJ9oeVpZe0hb hTRcm65tVSP1yRQOrMNVGe8w5oQalsbvN8bHuj8rfFXqm23al+2XpNRrESr+FVoUR4Wqb/oC weiLVX1ntOsCv+zV8F+jOEi+9tWyOlFurQtscQe3WI1RA4dZhP1VR6kVlWL8Y3D1afTpHd5h gpLondpcfTinUoxcTUe4mM2WsHphiToppthX1g4tUkOKRREWHTLLYZFSTUTnTTqLtIVVJHdp Tlj9Y6irAOmAY4AZ0k/PAUuAa0BrYgJGGYTApywAJis0B9CrexxcbISY0xEYNloTCzwDQoVD L+aEomACs2iXENEMF4weGB4YE0zJoGUEYEgwEMFXONhwG+ypH2JYUcZx1wVEN1QfC4dYHiuN 4WQ0xeQPxbRRNCUjwrgCLAtcjlyHW8RUPz0fXLkSs2cjQu9Hi3n2bnC0Jio6G3raIqc8Zou0 /66T+qXYnnDuSpebqbIyg3cSI4f67LnfAtZnRhjIkBjpdjkT/BgvAvwl5uQBqrRNz4XROxYm U1/W4xPe7drGsW3QWVhcGXIcBotx/R2vUnxLnxSuVwX97j3EYJFP6a9y0EfVYV6/4MGIr/c8 ksaeh3qSps1tkMbXt7TlkqdSKwPXvC77W93dpz/OQFtiSVGoyqKxXYbk0hzCLJkT1t8Utuha iEw7DPnCp4+9aXT11zM+n54P1CKu35TQXk9riPWN6jwdjT9gTGEa9efRUFifmGCD69MBffBz dDowLgaOjeF7cD3oWFTp3OlN1/pdgkblPeY45yf0pxno1AEaWKlXjNQmZlsmDNu0uf6+Dajz cRssLuCkxLUJOD+K4gJhcKLTYgq/L+RCthX3nJX8pbheoDccmxDMPdUSsKiaFvhYgwXHvHVO k0jSqXPXSk+LMO8foQUd4Ti56dFwOS933TCOt6mQwLXJVh/d0V+94LbhmD36jKP89ANvXfSt Plx8UNiixuY1uuH8fztXsMIgDEPv+wp/QLStVfwAdxK2wy47jYkWBsPDxmCfvyZptYqCrLsM ehPJe6ZFSUxek5cZAx0mkei9kC6JyEGpOHKIgeMqLQc9eOSA9nrOBg6eZoy7HNkSB2IcP9Cv 0Y+SFxi2iMSpTh36qL713Q5pLhAXNTv9ZCdP/SUmcGta/urgBHuEym2c1WICZkNVMPuDFsdw lP10PlYB/RV6ripCzdU2cVNrkivK6X8la5o7sNIsnzx8p1+u1zuq6j2OOjBzFh46uOsF380o DsjhaV4IdCmgOmuUGTpBhy6QNu5gmSTUjVKLIZkCg3I0JFGMGn9wKdXUhlubYt1GLNgUatG/ cvPeQM3ebow5NMGlCvAAD/AA/wN44Qcv/eCNH7z1gysvuGB+cOEHl2pLaMVjhk5k/QBLx4XW MlEAAA== ----Next_Part(Wed_Feb__6_23:02:07_2002_731)---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:20:15 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id B626337B426 for ; Mon, 11 Feb 2002 18:16:28 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 7EB8E232C9 for ; Mon, 11 Feb 2002 21:16:34 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 0CCAC9EE49; Mon, 11 Feb 2002 21:11:42 -0500 (EST) Date: Thu, 7 Feb 2002 01:21:22 -0800 (PST) From: Tom Servo Subject: Re: Promise/ATA-Raid making panic in -CURRENT? To: freebsd-current@freebsd.org Message-Id: <20020212021142.0CCAC9EE49@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > The "bad ivar request (4)" message does *not* come > from the ATA driver, you must have something else > that is ruining your day... Does it boot if you > take out the promise board ? I was in a hurry yesterday and let the kernel compile w/o the ata driver while being under the shower. Without the ata driver it does boot. Just wanted to let you know. I'll take the Promise out when I got some more time (latest friday evening). /tso __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:22: 5 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id B4D1037B43C for ; Mon, 11 Feb 2002 18:16:37 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 6E62C232C7 for ; Mon, 11 Feb 2002 21:16:35 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 44BB29F277; Mon, 11 Feb 2002 21:11:43 -0500 (EST) Date: Tue, 5 Feb 2002 11:50:20 -0800 (PST) From: Tom Servo Subject: Promise/ATA-Raid making panic in -CURRENT? To: freebsd-current@freebsd.org Message-Id: <20020212021143.44BB29F277@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi! I checked and compiled the recent -CURRENT tree, buildworld and buildkernel goes all fine. When booting it seems to crash on initialization of my Promise controller and get "bad ivar request (4)". I stripped all possible drivers out of the kernelconfig, except for the ata driver, and it still crashes. I then see a couple of pci0: (no driver attached), and when it should come to my Promise, BAM! Anyone can tell me how I can disable the ata-raid/Promise driver to test? Thx /tso __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:22:14 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id 0853937B41D for ; Mon, 11 Feb 2002 18:16:18 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 5837E232CB; Mon, 11 Feb 2002 21:16:31 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 7595F9F264; Mon, 11 Feb 2002 21:11:39 -0500 (EST) Date: Wed, 6 Feb 2002 19:30:34 -0800 From: "David O'Brien" To: Terry Lambert Cc: current@FreeBSD.ORG Subject: Re: Non 386 testers REALLY NEEDED Reply-To: obrien@FreeBSD.ORG Message-Id: <20020212021139.7595F9F264@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Feb 06, 2002 at 06:54:22PM -0800, Terry Lambert wrote: > Julian Elischer wrote: > > how about a port that uses the installed sources > > together with some uploaded parts to 'reconstitute' gcj as if it had been > > compiled wit the rest of the system. > > FreeBSD does a fairly evil thing: it takes the compiler > source code post-config instead of pre-config. I do not know what this means. I import [into contrib/] the bits before 'configure' has been run. I put various bits output by 'configure' in the build directory (ie, where the bmake Makefile is). > It's really an incredibly bad idea to import *after* a > config instead of before. What peice of software have we done this to? -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:23:17 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id B839937B434 for ; Mon, 11 Feb 2002 18:16:39 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 123E723025; Mon, 11 Feb 2002 21:16:39 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 668239EFA8; Mon, 11 Feb 2002 21:11:45 -0500 (EST) Date: Thu, 7 Feb 2002 10:10:09 -0800 (PST) From: Adam Nealis Subject: Re: Max size of a process in FreeBSD. To: Dag-Erling Smorgrav , Cc: Adam Nealis , freebsd-current@FreeBSD.ORG Message-Id: <20020212021145.668239EFA8@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --- Dag-Erling Smorgrav wrote: > Doug White writes: > > It's limited to MAXDSIZ (max data size). > > Not quite - the size of the data segment is limited to the value of > 'limits -d', which starts out at DFLDSIZ and cannot be larger than > MAXDSIZ. Likewise, the size of the stack is limited to the value of > 'limits -s', which cannot be larger that MAXSSIZ. I don't think > there's a limit on text size (other than "total address space minus > kernel address space"), but a very large text segment will obviously > limit the size of the data and stack segments. > > > You can raise this up to 2GB or > > so, but you will eventually hit the KVM boundary. I don't recall what the > > KVM limit is right now, I thought it was 2GB but I think it was reduced > > recently ... > > The kernel address space used to be 256 MB in 3.x, but was bumped to 1 > GB before 4.0-RELEASE. See FAQ list entry 17.15. Which FAQ is that? The online FAQ at http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/index.html Only has "funnies" for section 17, and doesn't go up to 17.15. Adam. __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:23:32 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id 4FCA337B432 for ; Mon, 11 Feb 2002 18:16:20 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 56F7D232CA; Mon, 11 Feb 2002 21:16:31 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 632E49F0FF; Mon, 11 Feb 2002 21:11:36 -0500 (EST) Date: Tue, 5 Feb 2002 22:32:46 -0800 From: Kris Kennaway To: John Hay Cc: Kris Kennaway , current@FreeBSD.org, Subject: Re: Not committing WARNS settings... Message-Id: <20020212021136.632E49F0FF@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 06, 2002 at 07:58:53AM +0200, John Hay wrote: > >=20 > > All David has to do is set WARNS=3D0 or NO_WERROR=3D1 in or > > /etc/defaults/make.conf temporarily when he tests and commits the > > changeover, and he'll sidestep all the problems. There's no need to > > impose restrictions on the activities of other committers. > >=20 > > It's really not a big deal, IMO. > >=20 > > Kris >=20 > Let me hijack this a little. How many of you WARNS=3D adding people > consider different compile/code paths than the one your machine > exercise? For instance the one "make release" will exercise? The > WARNS=3D1 in libexec/Makefile.inc breaks "make release" because > telnetd is then compiled, but it isn't warning free. Yeah, I'm going to fix that tonight when I get home and can test it. I try and be careful to consider all code paths, but this one slipped me by. Sorry. Kris --mYCpIKhGyMATD0i+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8YM4OWry0BWjoQKURAopCAJsFhvN3jRPYfM7I1DkBuOcgEKnmFgCg9LhU VzMyGNiWKwrcyKSZt2AFU2c= =Dmc9 -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:24: 0 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id 535F937B446 for ; Mon, 11 Feb 2002 18:16:52 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 4618B230DC for ; Mon, 11 Feb 2002 21:16:43 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 04DAE9EFAA; Mon, 11 Feb 2002 21:11:47 -0500 (EST) Date: Thu, 7 Feb 2002 21:57:47 +0100 (CET) From: BOUWSMA Beery To: freebsd-current@freebsd.org Subject: MODULES_WITH_WORLD=true means no modules? Message-Id: <20020212021147.04DAE9EFAA@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Is it just me, or... I've changed my /etc/make.conf from the default, to be MODULES_WITH_WORLD=true # do not build modules when building kernel since I find myself often building new kernels (plus identical modules) without updating the rest of the source, taking extra time. I just finished the buildworld/kernel/install jig, and I've got a fistful of modules built in /usr/obj/5.0-CURRENT/usr/src/sys/modules but after both installkernel and installworld, I've got an empty /boot/modules, and the only inhabitant of /boot/kernel/ is kernel. /boot/kernel.old/ is where I can find old modules, from when I built things the default way (build a new kernel, modules too) Either the modules aren't getting installed, or some other thing I've changed in /etc/make.conf (like the /usr/obj/5.0-CURRENT prefix) has hosed the modules install process. Is someone else using `MODULES_WITH_WORLD=true' successfully? If so, I'll boot back into -current and see if I can check it out... thanks barry bouwsma To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:24: 9 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id CF5A537B430 for ; Mon, 11 Feb 2002 18:16:17 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 28E80232BA for ; Mon, 11 Feb 2002 21:16:30 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id D3FC89F260; Mon, 11 Feb 2002 21:11:38 -0500 (EST) Date: Wed, 6 Feb 2002 00:10:05 -0500 To: current@FreeBSD.org From: Garance A Drosihn Subject: Performance of -current vs -stable Message-Id: <20020212021138.D3FC89F260@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG With 4.5-release out the door, I thought I'd start trying to use 5.0-current on my "main freebsd machine" instead of 4.x-stable. I figure at some point we (as developers) have got to try to migrate to that release as much as possible. I had been doing some stuff with 5.0-current at home. That seemed a bit slow, but I didn't think too much of it as the home machine is a single-CPU Duron-based machine (600 Mhz). while the machine at work is a dual-CPU Pentium-3 machine (650 MHz). The office machine also has more RAM, so obviously the home machine would be slower. But switching to current on the office machine is also considerably slower. I wasn't expecting "faster", but I'm wondering if other people are also seeing it as much slower, or if I've just got some other odd problem hitting me. One simple test I tried was that I have a copy of the freebsd cvs repository in /usr/cvs/free, on it's own partition. Each system has it's own /usr/src, of course. I cvsup'ed /usr/cvs/free, and then did a time cvs status >/dev/null in each /usr/src, on each system. (that command is just for this timing test, I usually do more useful commands at that point!). On current On stable ---------- ---------- real 7m 43.392s 4m 53.100s in /usr/src for current user 0m 11.692s 0m 4.203s sys 3m 4.601s 0m 2.248s real 6m 40.322s 2m 39.361s in /usr/src for stable user 0m 10.531s 0m 6.653s sys 4m 28.863s 0m 9.480s I realize this example isn't terribly detailed, but it seems to match what I "feel" when doing any major work on current. I'm used to a 'make -j5 buildworld' taking between 42 and 45 minutes for stable on my office machine, but the few times I've rebuilt -current, it's taking more like three and a half hours. That is quite a hit. This current system was initially installed in late-december, doing a full system-install (booting off a CD, newfs'ing the partitions, etc). So, it should have picked up all the recent filesystem improvements (dirprefs, etc) when laying out the files, and even if that wasn't true this test is done using the exact same directories as source & destination for the stable vs current tests. Could it be due to the DDB, INVARIANTS & WITNESS options in the kernel? If it is that's fine with me, I'm just wondering where that magnitude of a slowdown would be coming from. Anything else I should check? I realize there's about a million differences between the two branches, and there might also be something about my machine's setup which is a major culprit here. I'm just looking for a basic idea of what other people have been seeing for performance when they run current. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:25:47 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id 77E5E37B445 for ; Mon, 11 Feb 2002 18:16:50 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id A7636230C0; Mon, 11 Feb 2002 21:16:42 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 89BED9EFA4; Mon, 11 Feb 2002 21:11:47 -0500 (EST) From: Søren Schmidt Subject: Re: Promise/ATA-Raid making panic in -CURRENT? To: Tom Servo Date: Thu, 7 Feb 2002 10:59:32 +0100 (CET) Cc: freebsd-current@FreeBSD.ORG Reply-To: sos@freebsd.dk Message-Id: <20020212021147.89BED9EFA4@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It seems Tom Servo wrote: > > The "bad ivar request (4)" message does *not*?come > > from the ATA driver, you must have something else > > that is ruining your day... Does it boot if you > > take out the promise board ? > > I was in a hurry yesterday and let the kernel compile > w/o the ata driver while being under the shower. > Without the ata driver it does boot. Just wanted to > let you know. I'll take the Promise out when I got > some more time (latest friday evening). Hmm, I need alot more info the, board chipset, what exact Promise controller etc etc, and of cause the usual dmesg -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:25:50 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id 399BF37B433 for ; Mon, 11 Feb 2002 18:16:20 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id D83CF23291; Mon, 11 Feb 2002 21:16:31 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id A963C9F266; Mon, 11 Feb 2002 21:11:39 -0500 (EST) Date: Wed, 6 Feb 2002 11:00:27 -0800 From: "David O'Brien" To: Mikhail Teterin Cc: current@FreeBSD.org Subject: Re: How about gcj? (Re: Not committing WARNS settings...) Reply-To: obrien@FreeBSD.org Message-Id: <20020212021139.A963C9F266@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Feb 06, 2002 at 01:05:16PM -0500, Mikhail Teterin wrote: > > Uh, NO! It is not needed by the base system. We really do not want to > > turn on all the support libs, etc.. that would be needed with this. > > There is a reason the gcc30 port takes 25 minutes to compile on a fast > > 1.2 GHz Athlon. > > That's the thing. gcc30 port, essentially, installs a copy of the > compiler already available as part of the base. No it doesn't. 3.0.3 is a very different compiler from 2.95.3. > But the base is missing > gcj (the port does too for now), so one would be forced to add the port. And the base system does not NEED a java compiler. > Can we have those installed, at least, to ease the work of the future > porter? Nope. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:26: 7 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id CE3E837B43E; Mon, 11 Feb 2002 18:16:49 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 38E5A23099; Mon, 11 Feb 2002 21:16:42 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 592F99EE45; Mon, 11 Feb 2002 21:11:44 -0500 (EST) Date: Tue, 5 Feb 2002 20:14:22 +0100 From: Thomas Quinot To: Garrett Wollman Cc: freebsd-current@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, Subject: Re: Support for atapi cdrw as scsi in -current? Reply-To: thomas@cuivre.fr.eu.org Message-Id: <20020212021144.592F99EE45@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Is there a place where I can find this updated patch which will work for > me in the current -current? Thanks. I put up updated patches at http://www.cuivre.fr.eu.org/~thomas/atapicam/ For -CURRENT, you should be using the latest one (of today) which fixes a silly line inversion. I'd be very interested in success/failuire reports on this patch, especially with ATAPI tape or floppy drives. Thomas. -- Thomas.Quinot@Cuivre.FR.EU.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:26:22 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id 9C44C37B420 for ; Mon, 11 Feb 2002 18:16:28 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id AA259232D5; Mon, 11 Feb 2002 21:16:33 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 46D8F9F0F9; Mon, 11 Feb 2002 21:11:41 -0500 (EST) Date: Wed, 6 Feb 2002 12:17:51 +0100 (CET) From: Alexander Leidinger Subject: Re: Performance of -current vs -stable To: drosih@rpi.edu Cc: current@FreeBSD.ORG Message-Id: <20020212021141.46D8F9F0F9@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 6 Feb, Garance A Drosihn wrote: > Anything else I should check? I realize there's about a million > differences between the two branches, and there might also be > something about my machine's setup which is a major culprit here. > I'm just looking for a basic idea of what other people have been > seeing for performance when they run current. # ll /etc/malloc.conf lrwx------ 1 root wheel 2B Aug 18 21:47 /etc/malloc.conf@ -> aj Bye, Alexander. -- Loose bits sink chips. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:26:53 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id 0B48137B47F for ; Mon, 11 Feb 2002 18:16:59 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 4FBCD2310B for ; Mon, 11 Feb 2002 21:16:44 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 133899EFB8; Mon, 11 Feb 2002 21:11:49 -0500 (EST) Date: Thu, 07 Feb 2002 23:47:49 +0100 From: Michael Nottebrock To: freebsd-current@freebsd.org Subject: Lock order reversal on shutdown Message-Id: <20020212021149.133899EFB8@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In noticed this lock order reversal while shutting down the system to single-user in order to make installworld of my cvsup of today. I then tried again with the new world and the l.o.r. was still there. lock order reversal 1st 0xc0409dc0 allproc @ ../../../kern/vfs_syscalls.c:452 2nd 0xc4141e34 filedesc structure @ ../../../kern/vfs_syscalls.c:457 -- Michael Nottebrock To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:27:15 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id B831937B422 for ; Mon, 11 Feb 2002 18:16:28 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 55936232D1; Mon, 11 Feb 2002 21:16:33 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id BADA29F26A; Mon, 11 Feb 2002 21:11:40 -0500 (EST) Date: Thu, 7 Feb 2002 09:59:13 -0800 From: Alfred Perlstein To: Joe Kelsey Cc: current@freebsd.org Subject: Re: gcc3.x issues Message-Id: <20020212021140.BADA29F26A@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Joe Kelsey [020207 09:36] wrote: > David O'Brien writes: > > On Wed, Feb 06, 2002 at 05:47:07PM -0800, Joe Kelsey wrote: > > > What is so hard about allowing someone to specify the list of frontends > > > to provide at system build time? I thought that gcc was supposed to be > > > a modular compiler system, and that all we are asking for is the ability > > > to add to the default front ends, along with the default support > > > libraries, in the default places. > > > > Uh Joe... WhereTF is your patch to do this? > > My or your MTA seems to have deleted it. > > This is the atypical, smug, "I'm a committer and your're not" attitude > that permeates so much of the upper echelons of the FreeBSD team. It > really makes me sick that people seem to prefer to throw out useless > comments like this instead of giving actual answers to valide questions. These comments are not useless, most committers have day jobs that unfortunetly preclude them from having time to work on every little feature request. Furthermore asking for patches is the exact opposite of being smug at least in the way of flaunting one's commit priveledges, it's providing the user an opportunity to present work for inclusion into the project. > I believe that Terry has already pointed out several of the places in > the Makefile system that prevent anyone from reinstalling gcc over the > top of the standard one. His comments were helpful and succinct. > David's comments are unhelpful and terse. Quite a difference in > attitude. And you wonder why it is so hard to get new volunteers. We have plenty of volunteers willing to point out problems, what would be even more helpful is people _submitting the fixes_ to these problems. Not like problem reporting isn't important, but you can't fault David not being willing to take the time to implement a feature he doesn't find all that important. In fact you should be happy that he'd be willing to review and commit code when it does appear. > David has made it quite clear to me in the past that he is absolutely > not interested in anyone else ever touching the gcc port in the base > system. I have no desire to do anything when faced with such an > attitude. Actually David routinely requests assistance and would like to offload some if not all of the gcc maintainance, the problem he's having is finding people capable and willing to do the work rather than people that just want to draft emails complaining about his current work. > This is a discussion of general principles. After settling the debate, > *then* it is appropriate to ask if anyone would like to work on the > issues. Then, I may or may not try to generate patches. Personally I don't have time to engage in a debate, and I doubt that David does either. By stating that he would consider patches he's already given you the go-ahead to do the work, if it's up to par with the project's guidlines there should be minimal fuss with integration. > Thanks for your helpful and pleasant comments David. Yeah, whatever, don't we all feel better now? :) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:27:56 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id 80C5A37B41A; Mon, 11 Feb 2002 18:16:26 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 20F77232D0; Mon, 11 Feb 2002 21:16:33 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id A5FE89F106; Mon, 11 Feb 2002 21:11:40 -0500 (EST) Cc: "David O'Brien" , current@FreeBSD.ORG, Date: Thu, 07 Feb 2002 18:47:08 +0100 From: Georg-W Koltermann Subject: Re: Performance of -current vs -stable To: John Baldwin Message-Id: <20020212021140.A5FE89F106@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At Wed, 06 Feb 2002 23:33:14 -0500 (EST), John Baldwin wrote: > > [...] > I guess. Note that you can use a loader tunable 'debug.witness_watch' to turn > witness off from the loader. If it's set to 0 witness won't be used even if > it's compiled into the kernel (just a general FYI, witness(4) documents this as > well). Nice feature, thanks for the hint. I can't find it documented in witness(4), however: hunter# grep -i watch /usr/src/share/man/man4/witness.4 hunter# CVSup is from Feb 6. -- Regards, Georg. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:28:10 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id AA38C37B480 for ; Mon, 11 Feb 2002 18:16:59 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 1FF3B23127 for ; Mon, 11 Feb 2002 21:16:45 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 46B139F287; Mon, 11 Feb 2002 21:11:49 -0500 (EST) Date: Fri, 8 Feb 2002 00:14:59 +0100 (CET) From: BOUWSMA Beery To: freebsd-current@freebsd.org Subject: Re: MODULES_WITH_WORLD=true means no modules? Message-Id: <20020212021149.46B139F287@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > MODULES_WITH_WORLD=true # do not build modules when building kernel > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ...you need to read the option you enabled? Never mind, I figured out what happened, and will happen again in the future, since this doesn't quite `optimize' things as I'd like I had actually started writing to ask why /boot/kernel.old hadn't been updated with my previous /boot/kernel, but then I figured it out. Since I had done two `installkernel's, I was using the kernel image in /boot/kernel.old/ from the first installkernel, and a test is made, so that if I'm using it, it doesn't get deleted. Instead, what happened was that the existing /boot/kernel contents were nuked. This had been populated by kernel modules by the installworld step that I did following the first installkernel. So, when the above option is enabled, normally your previous contents of /boot/kernel/ are moved to replace /boot/kernel.old/ by `installkernel' and the new contents of /boot/kernel/ are no more than kernel alone -- look ma, no modules! In order to get /boot/kernel/ populated with modules, either one needs to installworld again, or use one of the targets to install only modules, I guess. Actually, on this machine, a complete installworld probably takes less time than the present way to build a fresh kernel and set of modules as the `buildkernel' step, which I had hoped would be sped up. What I had perhaps been thinking (if you could claim that I was in fact thinking at all) was that the modules would be installed into a location by `installworld' that would be independent of any `build/installkernel's that would follow -- such as /boot/modules, which appears in the sysctl kern.module_path under -current. That way one could build new kernels from the same source, adding or removing devices, only needing to update the modules as part of the installworld when the source gets changed. At least, that was my goal in enabling this /etc/make.conf option, to speed up the buildkernel/installkernel process by skipping module rebuilding any time I swap in a different ethernet or sound card or find a new spiffy kernel option to try out. That's it in a nutshell. FWIW, booting the new kernel just built a few hours ago gives the following: | CPU: Pentium/P54C (75.00-MHz 586-class CPU) | Origin = "GenuineIntel" Id = 0x524 Stepping = 4 | Features=0x1bf = WARNING: Driver mistake: make_dev(perfmon) called before SI_SUB_DRIVERS | real memory = 41943040 (40960K bytes) Once again, I fling off a message before engaging brane barry bouwsma To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:28:40 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id AECE837B48F for ; Mon, 11 Feb 2002 18:17:06 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id E05E72315D for ; Mon, 11 Feb 2002 21:16:46 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id E34489F291; Mon, 11 Feb 2002 21:11:51 -0500 (EST) Date: Fri, 08 Feb 2002 09:54:35 +0900 From: Jun Kuriyama To: Current Subject: World breakage (lib/libroken) Message-Id: <20020212021151.E34489F291@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Is this the problem on my local environment only? ===> libroken awk -f /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken.awk /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken.h.in > make-roken.c awk: /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken.awk:18: warning: escape sequence `\#' treated as plain `#' cc -O -mpentiumpro -pipe -march=pentiumpro -I/usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/include -I/usr/src/kerberos5/lib/libroken/../../include -I/usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I/usr/obj/usr/src/kerberos5/lib/libroken -Wall -I/usr/src/kerberos5/lib/libroken/../../include -I/usr/src/kerberos5/lib/libroken/../../include -DHAVE_CONFIG_H -DINET6 -I/usr/obj/usr/src/i386/usr/include make-roken.c -o make-roken /usr/obj/usr/src/i386/usr/libexec/elf/ld: cannot find -lc *** Error code 1 Stop in /usr/src/kerberos5/lib/libroken. *** Error code 1 -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:28:52 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id AFC1837B428 for ; Mon, 11 Feb 2002 18:16:28 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 2FB5B232D9; Mon, 11 Feb 2002 21:16:34 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id D9B239F26B; Mon, 11 Feb 2002 21:11:40 -0500 (EST) To: Makoto Matsushita Cc: current@FreeBSD.ORG Subject: Re: current.freebsd.org down? Date: Thu, 07 Feb 2002 10:00:54 -0800 From: Jordan Hubbard Message-Id: <20020212021140.D9B239F26B@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a different problem. The stable.freebsd.org machine, on which all the really big NFS storage lives, failed to come back up from a reboot last night and I'm trying to get it restarted now. The terminal server also appears to be sick or I'd be able to intervene remotely. :( - Jordan > > > I know this is probably offtopic but is there any problem with > > current.freebsd.org at the moment? > > Hmm... > > galtvalion % ftp current.freebsd.org > Connected to usw2.freebsd.org. > 220 usw2.freebsd.org FTP server (Version 6.00LS) ready. > Name (current.freebsd.org:matusita): ftp > 331 Guest login ok, send your email address as password. > Password: > 550 Can't set guest privileges. > ftp: Login failed. > ftp> ^D > 221 Goodbye. > galtvalion % ftp stable.freebsd.org > ftp: connect: Connection refused > galtvalion % > > Both snapshots machine are not available for services... anybody knows > what's going on? > > -- - > Makoto `MAR' Matsushita > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:29:29 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id 7DD8F37B48C; Mon, 11 Feb 2002 18:17:05 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id BAAB423185; Mon, 11 Feb 2002 21:16:48 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 043E29F29C; Mon, 11 Feb 2002 21:11:53 -0500 (EST) Date: Tue, 05 Feb 2002 12:49:06 -0600 From: Jordan Breeding To: Garrett Wollman Cc: freebsd-current@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Support for atapi cdrw as scsi in -current? Message-Id: <20020212021153.043E29F29C@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garrett Wollman wrote: > < > >>I noticed a patch on freebsd-scsi a while back that >>added a not very complete form of atapi as scsi support >>to the freebsd kernel. Are there plans to complete >>this and add it to -current sometime before -current >>turns into 5.0-RELEASE? Thanks for any information. >> > > I've been using it somewhat actively in the past week or so in > -current. The patch as it exists needs a few changes to fit in > current -current. > > $ camcontrol devlist > at scbus0 target 0 lun 0 (cd0,pass0) > at scbus0 target 1 lun 0 (cd1,pass1) > > I don't think that ATAPICAM works well enough to use it entirely in > place of the atapi-cd driver; for example, I get the following errors: > > atapicam0: READ_DISK_INFO - ILLEGAL REQUEST asc=0x20 ascq=0x00 error=0x04 > atapicam0: READ_TOC - ILLEGAL REQUEST asc=0x24 ascq=0x00 error=0x04 > > However, it works well-enough to run cdrdao, which is what mattered to > me, for both reading and writing on both of the afore-mentioned ATAPI > devices. > > -GAWollman > > > Is there a place where I can find this updated patch which will work for me in the current -current? Thanks. Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:29:28 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id 8A5EC37B419 for ; Mon, 11 Feb 2002 18:16:26 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 1FD4D232CF; Mon, 11 Feb 2002 21:16:33 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 8D5279EE4A; Mon, 11 Feb 2002 21:11:40 -0500 (EST) Date: Thu, 07 Feb 2002 10:04:35 -0700 (MST) To: non@ever.sanda.gr.jp Cc: current@FreeBSD.ORG Subject: Re: ThinkPad X22 PC-Card slot problem From: "M. Warner Losh" Message-Id: <20020212021140.8D5279EE4A@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020207222625S.non@ever.sanda.gr.jp> non@ever.sanda.gr.jp writes: : From: "M. Warner Losh" : Date: Wed, 06 Feb 2002 19:33:32 -0700 (MST) : > Hmmm. This looks ugly. :-( I can't boot with acpi enabled on my Dell : > Inspiron 8000. I can boot with apm enabled. There are issues with : > routing interrupts accross PCI PCI bridges at the moment when the : > slots on the other side of the bridge are in the PIR table. : : It turned out that this was not a intterupt routing problem. By : disabling the memory/port range checks in sys/dev/pci/pci_pci.c solved : the problem (below is the patch). pci_pci.c claims that both the : memory adderss for pcic and the PC-Cards are not supported but I could : use the addresses. Yes. This is the ISA problem. The checks are there to make sure we don't assign addresses that aren't decoded by the bridge. However, the bridge does decode ISA addresses. I need to check into which ISA stuff a little better before making a fix. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:29:52 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id 8472837B423 for ; Mon, 11 Feb 2002 18:16:28 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id D1174232D7; Mon, 11 Feb 2002 21:16:33 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 2E81D9EE40; Mon, 11 Feb 2002 21:11:41 -0500 (EST) Date: Thu, 7 Feb 2002 19:08:07 +0100 From: Wilko Bulte To: Cejka Rudolf Cc: Garance A Drosihn , current@FreeBSD.ORG Subject: Re: Performance of -current vs -stable Message-Id: <20020212021141.2E81D9EE40@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Feb 07, 2002 at 10:15:02AM +0100, Cejka Rudolf wrote: > Garance A Drosihn wrote (2002/02/06): > > Anything else I should check? I realize there's about a million > > differences between the two branches, and there might also be > > something about my machine's setup which is a major culprit here. > > I'm just looking for a basic idea of what other people have been > > seeing for performance when they run current. > > There is another common source of confusion: If anybody has IDE > disks, write-caching is enabled by default in -stable, but disabled > in -current. I don't think that is true anymore. -stable has WC enabled as well. -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:30:50 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id A4A2E37B449 for ; Mon, 11 Feb 2002 18:17:12 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 27C93231FF; Mon, 11 Feb 2002 21:16:51 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 3868C9F2AD; Mon, 11 Feb 2002 21:11:56 -0500 (EST) Cc: vsilyaev@mindspring.com Date: Thu, 07 Feb 2002 11:04:22 +0100 From: Georg-W Koltermann Subject: /dev/rtc not configured message when starting VMWare2 on -current To: freebsd-current@freebsd.org Message-Id: <20020212021156.3868C9F2AD@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, since many weeks I get "/dev/rtc: device not configured" in -current when I start VMWare2. The VMWare2 port works fine otherwise. Yes, rtc-2001.09.16.1 is installed, and the module is loaded during startup. -- Regards, Georg. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Feb 11 18:30:57 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id AD07B37B48E for ; Mon, 11 Feb 2002 18:17:06 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 5BC72231A2 for ; Mon, 11 Feb 2002 21:16:49 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 769AD9F2A1; Mon, 11 Feb 2002 21:11:54 -0500 (EST) Date: Wed, 6 Feb 2002 22:52:18 +0100 From: Hendrik Scholz To: freebsd-current@freebsd.org Subject: ACPI error "Method execution failed, AE_AML_REGION_LIMIT" Reply-To: hendrik@scholz.net Message-Id: <20020212021154.769AD9F2A1@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi! I updated my notebook from -stable to -current some days ago and get this message ~ every second: ACPI-0294: *** Error: Method execution failed, AE_AML_REGION_LIMIT Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Wed Feb 6 23:42:40 CET 2002 hscholz@deimos.raisdorf.net:/usr/src/sys/i386/compile/DEIMOS5 Preloaded elf kernel "/boot/kernel/kernel" at 0xc0442000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc04420a8. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04420f8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 847427426 Hz CPU: Pentium III/Pentium III Xeon/Celeron (847.43-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x387f9ff real memory = 129957888 (126912K bytes) avail memory = 122019840 (119160K bytes) Pentium Pro MTRR support enabled Using $PIR table, 3 entries at 0xc00f76b0 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard ACPI-0294: *** Error: Method execution failed, AE_AML_REGION_LIMIT Timecounter "ACPI" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x5008-0x500b on acpi0 acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_pcib0: port 0xcf8-0xcff on acpi0 pci0: on acpi_pcib0 atapci0: port 0xffa0-0xffaf,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 irq 0 at device 0.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 isab0: at device 1.0 on pci0 isa0: on isab0 sis0: port 0xd000-0xd0ff mem 0xffdc0000-0xffdc0fff irq 11 at device 1.1 on pci0 sis0: Ethernet address: 00:a0:cc:c5:62:c5 miibus0: on sis0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ohci0: mem 0xffdd0000-0xffdd0fff irq 9 at device 1.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xffde0000-0xffde0fff irq 9 at device 1.3 on pci0 usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pcm0: port 0xd400-0xd4ff mem 0xffdf0000-0xffdf0fff irq 10 at device 1.4 on pci0 pci0: at device 1.6 (no driver attached) pcib1: at device 2.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pcic0: at device 3.0 on pci0 pcic0: PCI Memory allocated: 0x44000000 pcic0: Polling mode pcic0: Warning: O2micro OZ68xx chips may not work pccard0: on pcic0 acpi_cmbat0: on acpi0 acpi_acad0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 acpi_ec0: port 0x66,0x62 on acpi0 fdc0: direction bit not set fdc0: cmd 3 failed at out byte 1 of 3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A fdc0: direction bit not set fdc0: cmd 3 failed at out byte 1 of 3 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it pcic: pcic0 already exists; skipping it sio: sio0 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it orm0: