message regurgitation from bestweb.net, not me...
In case anyone else hasn't figured out why you're seeing a few old messages, it looks like there's a mailer at bestweb.net that's re-sending the mails it has queued up but using the `To:' header field for the new recipient, so that mails from several days ago are appearing again. It's not me and others forgetting and resending old mails. Here's a second copy of a message someone sent me: Feb 12 08:09:40 dastardly sendmail[277]: g1C79dU00277: from=<[EMAIL PROTECTED]>, size=1169, class=0, nrcpts=1, msgid=<[EMAIL PROTECTED] et>, proto=ESMTP, daemon=MTA, relay=newman2.bestweb.net [209.94.102.67] Note that the messages sent to the list have a different msgid than the originals and are all [EMAIL PROTECTED]> . I read this list via usenet, so here's relevant headers from a post that ``I'' just made: Original-Date: Wed, 6 Feb 2002 16:03:16 +0100 (CET) From: BOUWSMA Beery <[EMAIL PROTECTED]> Subject: Lock order reversals, login-related, maybe... Original-Message-Id: <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2002 02:33:19 GMT Message-ID: <[EMAIL PROTECTED]> I see a few other messages others have ``sent'' today too. Hope this helps if anyone's confused by this and ready to direct a flamethrower at the apparent perpetrator. barry bouwsma recycling mail for fun and profit To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: message regurgitation from bestweb.net, not me...
I just wrote > In case anyone else hasn't figured out why you're seeing a few old > I read this list via usenet, so here's relevant headers from a post Murphy's law. The news swerver I read from has stopped getting any new articles after about three bestweb regurgitations, which I didn't realize until just now, so there was plenty of activity since 3am local time that I missed. Sorry about restating the obvious. All news swervers suck, some more than others... barry bouwsma To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Change to sys/sys/proc.h broke -current
I hadn't seen this reported in the archives yet, but the recent change to sys/sys/proc.h removed the kg_pri struct member. This member is still referenced in lib/libkvm/kvm_proc.c at line 331, and sys/kern/kern_poll.c. I assume the fix for kvm_proc.c and kern_poll.c would be something like the attached. Joe --- lib/libkvm/kvm_proc.c.orig Tue Feb 12 00:58:37 2002 +++ lib/libkvm/kvm_proc.c Tue Feb 12 01:14:40 2002 @@ -320,15 +320,18 @@ kp->ki_xstat = proc.p_xstat; kp->ki_acflag = proc.p_acflag; kp->ki_pctcpu = proc.p_kse.ke_pctcpu; /* XXXKSE */ - kp->ki_estcpu = proc.p_ksegrp.kg_estcpu;/* XXXKSE */ - kp->ki_slptime = proc.p_kse.ke_slptime; /* XXXKSE */ + kp->ki_estcpu = mainthread.td_ksegrp->kg_estcpu;/* XXXKSE */ + kp->ki_slptime = mainthread.td_ksegrp->kg_slptime; /* +XXXKSE */ kp->ki_swtime = proc.p_swtime; kp->ki_flag = proc.p_flag; kp->ki_sflag = proc.p_sflag; kp->ki_wchan = mainthread.td_wchan; /* XXXKSE */ kp->ki_traceflag = proc.p_traceflag; kp->ki_stat = proc.p_stat; - kp->ki_pri = proc.p_ksegrp.kg_pri; /* XXXKSE */ + kp->ki_pri.pri_level = mainthread.td_priority; + kp->ki_pri.pri_user = mainthread.td_ksegrp->kg_user_pri; + kp->ki_pri.pri_class = mainthread.td_ksegrp->kg_pri_class; + kp->ki_pri.pri_native = mainthread.td_base_pri; kp->ki_nice = proc.p_ksegrp.kg_nice;/* XXXKSE */ kp->ki_lock = proc.p_lock; kp->ki_rqindex = proc.p_kse.ke_rqindex; /* XXXKSE */ --- sys/kern/kern_poll.c.orig Tue Feb 12 01:34:43 2002 +++ sys/kern/kern_poll.cTue Feb 12 01:38:15 2002 @@ -482,7 +482,7 @@ rtp.prio = RTP_PRIO_MAX;/* lowest priority */ rtp.type = RTP_PRIO_IDLE; mtx_lock_spin(&sched_lock); - rtp_to_pri(&rtp, &td->td_ksegrp->kg_pri); + rtp_to_pri(&rtp, td->td_ksegrp); pri = td->td_priority; mtx_unlock_spin(&sched_lock);
RE: BESTDEB: your Postfix installation is hosed
> > You are reflecting messages back to a mailing list with > > thousands of subscribers. > > > > Cut it out. > > > > -- Terry > > Peter has applied the Big Hammer of Death to the problem for now, so > it should be stopping soon if not already. Thanks Peter Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: BESTDEB: your Postfix installation is hosed
Nate Williams wrote: > > > You are reflecting messages back to a mailing list with > > > thousands of subscribers. > > > > > > Cut it out. > > Peter has applied the Big Hammer of Death to the problem for now, so > > it should be stopping soon if not already. > Thanks Peter Peter is my hero. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Where to find docs on newbus vs. cardbus vs. newcard
In message: <[EMAIL PROTECTED]> j mckitrick <[EMAIL PROTECTED]> writes: : On Mon, Feb 11, 2002 at 03:56:00PM -0700, M. Warner Losh wrote: : | NEWCARD is up and running, but has issues for some cards, bridges and : | lacks some useful features. : : That reminds me, there was something I noticed on my system you might : want to be aware of. :-) : : First, everything works fine, or actually, outstandingly. Very good : job. : : When my laptop is booting (Toshiba with ToPIC97, NoteWorthy modem, : LinkSys modem card) something odd happens: : : IP packet filtering initialized, divert disabled, rule-based forwarding : disabled : , default to accept, unlimited logging : pccard: card inserted, slot 0 : pccard: card inserted, slot 1 : pccard: card removed, slot 1 : pccard: card inserted, slot 0 : pccard: card inserted, slot 1 That's odd. : You can see slot 1 acts like it was removed and reinserted. To make it : even more interesting... You are right. : Mounting root from ufs:/dev/ad0s1a : sio1 at port 0x2f8-0x2ff irq 11 flags 0x4 slot 0 on pccard0 : sio1: type 16550A : sio1: unable to activate interrupt in fast mode - using normal mode : ed1 at port 0x240-0x25f iomem 0xd4000-0xd7fff irq 11 slot 1 on pccard1 : ed1: address e2:0c:0f:05:6d:54, type NE2000 (16 bit) : : You can see the NIC comes up as ed1. This used to be ed0 around 4.3, : IIRC. Is this related to the problems with slot 1 under ToPIC97? : I could be wrong, but I believe my modem used to be sio0 as well. I : remember having to change it in my ppp script after a build world some : time ago. Maybe hints consume ed0 and sio0 likely. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: BESTDEB: your Postfix installation is hosed
On 12-Feb-02 Terry Lambert wrote: > You are reflecting messages back to a mailing list with > thousands of subscribers. > > Cut it out. > > -- Terry Peter has applied the Big Hammer of Death to the problem for now, so it should be stopping soon if not already. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UPDATED: For Review: sendmail 8.12.2 import into -CURRENT
On Sun, 10 Feb 2002, Andrey A. Chernov wrote:
> 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/MakefileSun Jan 20 13:05:02 2002
> @@ -0,0 +1,28 @@
> +# $FreeBSD$
> +
> +MAINTAINER= [EMAIL PROTECTED]
> +
> +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
And in -current, we don't want to use -pthread any longer. A threaded
app built in -current should compile with -D_THREAD_SAFE (for POSIX
semantics, but is really a noop in FreeBSD) and link with -lc_r.
-pthread is deprecated.
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ucred holding patch, BDE version
On 12-Feb-02 Terry Lambert wrote: > John Baldwin wrote: >> Yes, calling free() without Giant is about as good as calling fdrop() >> without >> Giant Alfred. :) > > Alfred would be right, for per processor memory pools. 8-). > >> >> 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. > > No. If you _depend_ on the frequency of change being low, > you can do this with only atomic reference counts. See the > pseudo code in my other posting, in direct response to you. Yes, the broken code with the race condition that can corrupt random kernel structures long enough to trigger a panic or break a condition test in a branch or loop. I saw that, yes. > -- Terry -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ucred holding patch, BDE version
On 12-Feb-02 Terry Lambert wrote:
> Then the combination of calls fails. There is no case where
> it will succeed when previously it would not. I would argue
> that the failure is a lost race condition that exists in the
> code anyway, and that this approach merely makes the race
> failure more reliably reproducible. 8-).
>
> I think you could "fix" this case, in any event, by saving a
> reference to the credential at the start (or, better, as a
> result of the sleep, when you know it's going to happen),
> any time you are going to split a system call across multiple
> potential blocking operations. That certainly is *NOT* as
> common to all system calls as this discussion implies.
>
>
>> 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.
>
> As long as the pointer updates are atomic, you don't need to
> hold a lock to reference it anyway. You don't care over the
> update, since it's a drop of priviledge.
Ok, I'll use really small words and diagrams:
thread's 1 and 2 belong to process p
p->p_ucred starts pointing at memory X
CPU 1 is executing thread 1
CPU 2 is executing thread 2
CPU 3 is executing some other random code in the kernel
At start both thread 1 and thread 2 have td_ucred == X
CPU 1 CPU 2 CPU 3
seteuid(), p_ucred in userland
now points to Y
...
seteuid(), p_ucred
now points to Z
...
some syscall, Y's
only remaining
ref is free'd
... allocates some
other kernel
structure at Y
executes any syscall
because on non-i386
arch's, the value of
p_ucred may still be
sitting in the store
buffer and we aren't
using a lock, we may
get any of the values
X, Y, or Z for p_ucred
when we test to see
if it needs updating.
If we get X, we keep
using the old reference
(this is the acceptable
race from before). If
we get Z, then we gain
a reference to the new
ucred. If we get Y,
then we increment the
refcount of the ucred
formerly at Y, in fact
corrupting the memory
allocated by CPU 3!
*BOOM*
Is that simple enough?
>> > 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.
>
> Not true. You can take a reference to it, and the reference
> is guaranteed to not change out from under you, so long as
> it is counted. Use of a stack variable to store the value
> over the count increment allows a compare after the increment,
> after which a retry is possible (if there was a race during
> the reference taking). Thus there is no need for a lock, e.g.:
>
> cred *
> addreftocred(cred **cpp)
> {
> cred *rcp; /* stack variable */
>
> again:
> rcp = *cp;
> atomic_plusplus( rcp->count); /* magic atomic crap */
> if( rcp != *cp) {
> atomic_mimusminus( rcp->count);
> goto again;
> }
>
> return( rcp);
> }
>
> This depends on the rarity of credential changes; in the
> degenerate case, where there is a credential change between
> each normal system call that is not a credential change, the
> overhead is immense. But people who write code like that
> can be safely punished without fear. 8-).
This code is still broken. How do you know that the value you are reading from
cp (well,
Re: Support for atapi cdrw as scsi in -current?
On Tue, Feb 05, 2002 at 08:14:22PM +0100, Thomas Quinot wrote: > > 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. FYI, I applied the patch to -stable and tested it using cdrdao with my plextor 1610A. Worked like a charm. -- Christopher Nielsen - Metal-wielding pyro techie [EMAIL PROTECTED] "Those who are willing to trade freedom for security deserve neither freedom nor security." --Benjamin Franklin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ucred holding patch, BDE version
On 12-Feb-02 Terry Lambert wrote: > Julian Elischer wrote: >> > 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. > > I would argue that: > > 1)There are a small number of system calls where this > is true. > > 2)It's worth doing the synchornization in-kernel for > the process alone, where this is the case. > > The problem I have with the crd locking is that each process > does not do a gratuitous clone of the active cred before doing > its own thing (if you will remember, I suggested this in the > context of the cred reference count overflow bug, back when I > found the problem last year). ... which has nothing to do with the problem at hand as far as I can tell. Well, if we did, say, embed a cred in each process rather than sharing them, then we wouldn't need to protect p_ucred with a lock, but now we would need to protect all the contents of the cred with a lock, or go with the IPI scheme (yuck, IPI's are very uncheap). > The upshot of this is that the lock will stall anyone using > that cred. This argues that creds should be, minimally, > per process, if not per CPU, instead of shared references > smeared all over the place, and locked on each reference, > even though it's not possible for a cred to be changed at > all out from under you -- only replaced wholesale, since > once instanced, a cred may not be changed. What in the world are you talking about Terry. Have you read the code? The lock _only_ protects the reference count, nothing else! Once I commit the code to make sure that we use p_ucred properly when updating credentials then I can commit the code to chagne all of suser(), p_can*() to use the per-thread ucred. Since teh per-thread ucred is immutable, and since td_ucred is only ever touchced by curthread, thsi involves NO LOCKS for ANY calls to suser() or p_can*() EXCEPT in the few syscalls that update credentials. We went over this _months_ ago. I direct you to the archives of -arch please. > Personally, I think that cred changes are rare enough, > even in the degenerate case, that it's worth taking the > synchronization event as an intraprocess global IPI, > rather than using a lock. Egads. That still doesn't fix the problem of some syscall changing its creds to get weird behavior halfway through a syscall. You still need locks if two threads call setuid() at the same time. Sure it's a program bug but we can't have the kernel panic over it. >> creads can only be changed per process but the threads only pick >> up the change on next syscall startup. > > I think this is the fundamental misunderstanding: creds > never change. The can only be replaced, and then only > with a cred of equal or lesser priviledge. Well, Robert wasn't very comfortable with that change, plus it either requires a horribly expensive and ugly IPI, or it requires lots of lock acquires to read p_ucred that we wouldn't need otherwise. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ucred holding patch, BDE version
On 12-Feb-02 Julian Elischer wrote: > > > On Mon, 11 Feb 2002, John Baldwin wrote: > >> >> 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. > > hmm ok Alfred, here's the way I see it.. This is jhb, not alfred. > You are never permitted to "CHANGE" a cred. > You ALWAYS allocate another and switch them. > When you switch them you decrement the refcount of the old one. > If someone else takes a reference on it at the same moment that you > drop it, then the order is important down to the bus-cycle > as to whether it gets freed or not. We already know that dereferencing it > from the proc structure is not important, because a "stale" ucred pointer > is only preventable from the userland. NO, no! You only know it is stale in that case cause you are comparing a non-stale known-good pointer to p_ucred. If p_ucred is stale, then it is equal to td_ucred which still points to a valid ucred so it is ok in that particular case. If p_ucred is stale but points to a new ucred, getting the proc lock around crhold() ensures that you will gain a reference to the really correct value that is guaranteed to point to a correct value. Don't think in terms of bus cycles. On non-i386 architectures, a write can sit in a store buffer waiting until it is pushed out by a memory barrier or for the CPU to get around to posting it. You can't assume that a write will be visible to other CPU's "soon". > All that is important is that the pointer is a REAL pointer to a cred > and that it is not allowed to go to 0 references in its way to 1 > reference. But if it's a stale pointer, it's not a pointer to a ucred. That memory could have been free'd and now be a mbuf header. Now you go try to increment the refcount of a mbuf header. Bad juju here. :) Trust me, my jhb_proc kernels were locking up cause I missed one instance of setting p_args to NULL during exec so taht during wait we would trash random data memory when we tried to indirect the stale p_args pointer to dec the refcount. The problem is that you actually have 2 locks involved for 2 different things here during your crhold()'s: - proc lock which protects p_ucred in two ways: - 1) it ensures that the ucred has at least one reference that doesn't go away so it's ok for us to deref the poitner and increment the count - 2) it ensures that the value of the pointer we read is up to date - ucred mutex which protects the ucred refcount Only the second mutex can be replaced by pure atomic operations in theory. The first one cannot. In your comparison test, you aren't dereferencing p_ucred, so if it is stale, that is ok due to other issues. However, when you do crhold(p->p_ucred), you dereference the pointer, so it better darn well be pointing at a ucred and not a mbuf. > An atomic reference count increment that checks > against 0 would be part of it but might not be enough. > I think we also need to have a lock on something because > it might get freed and used for something else that happens to place a "1" > in that location inbetween the time that p->p_ucred is read > and the refcount is decremented. That is what the proc lock is doing. :-P > As an asside: > I think that in NT they may have refcounts in the same location in all > structures as I think they derived all their structures from a bas class > that has ref counts. In that case it WOULD have a "1" in that location if > it were re-used. (It's been a long time since I saw NT code so I may be > wrong) That would involve great evil. Let's not do that. How do you know the refcount hasn't been adjusted on some other structure anyways that you have a stale pointer to? Maybe that current structure is just now being freed? -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ucred holding patch, BDE version
John Baldwin wrote:
> > 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.
Then the combination of calls fails. There is no case where
it will succeed when previously it would not. I would argue
that the failure is a lost race condition that exists in the
code anyway, and that this approach merely makes the race
failure more reliably reproducible. 8-).
I think you could "fix" this case, in any event, by saving a
reference to the credential at the start (or, better, as a
result of the sleep, when you know it's going to happen),
any time you are going to split a system call across multiple
potential blocking operations. That certainly is *NOT* as
common to all system calls as this discussion implies.
> 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.
As long as the pointer updates are atomic, you don't need to
hold a lock to reference it anyway. You don't care over the
update, since it's a drop of priviledge.
> > 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.
Not true. You can take a reference to it, and the reference
is guaranteed to not change out from under you, so long as
it is counted. Use of a stack variable to store the value
over the count increment allows a compare after the increment,
after which a retry is possible (if there was a race during
the reference taking). Thus there is no need for a lock, e.g.:
cred *
addreftocred(cred **cpp)
{
cred *rcp; /* stack variable */
again:
rcp = *cp;
atomic_plusplus( rcp->count); /* magic atomic crap */
if( rcp != *cp) {
atomic_mimusminus( rcp->count);
goto again;
}
return( rcp);
}
This depends on the rarity of credential changes; in the
degenerate case, where there is a credential change between
each normal system call that is not a credential change, the
overhead is immense. But people who write code like that
can be safely punished without fear. 8-).
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
BESTWEB: CUT IT OUT!
Quit reflecting old messages back to the losts. Thanks. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
BESTDEB: your Postfix installation is hosed
You are reflecting messages back to a mailing list with thousands of subscribers. Cut it out. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ucred holding patch, BDE version
Julian Elischer wrote: > > 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. I would argue that: 1) There are a small number of system calls where this is true. 2) It's worth doing the synchornization in-kernel for the process alone, where this is the case. The problem I have with the crd locking is that each process does not do a gratuitous clone of the active cred before doing its own thing (if you will remember, I suggested this in the context of the cred reference count overflow bug, back when I found the problem last year). The upshot of this is that the lock will stall anyone using that cred. This argues that creds should be, minimally, per process, if not per CPU, instead of shared references smeared all over the place, and locked on each reference, even though it's not possible for a cred to be changed at all out from under you -- only replaced wholesale, since once instanced, a cred may not be changed. Ask John and Robert about the permissability of changing cred contents, and the NFS changes that resulted (fairly) recently. Personally, I think that cred changes are rare enough, even in the degenerate case, that it's worth taking the synchronization event as an intraprocess global IPI, rather than using a lock. > > 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. Again: the model permits dropping, but not gaining, of priviledges. THe worst case failure, then, is: 1) A call starts on a thread without proper program level stall synchornization between threads. 2) A subsequent thread drops priviledges, and this drop is unprotected by the stall. 3) The call completes, but fails during completion for lack of privledges present when the call was started, because the drop was not stalled. Frankly, I don't see this being a problem: badly written code with a race condition will occasionally lose the race, rather than being implicitly protected (an assumption that is not portable, if it is depended upon), and the code will end up being fixed by its author. > > 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. I think this is the fundamental misunderstanding: creds never change. The can only be replaced, and then only with a cred of equal or lesser priviledge. > > Kirk at one time called vnodes "the structure that ate the > > kernel"; he was wrong: it was creds. > > I believe it was Mike Karels. Whatever. It's "creds" now. > > 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. I'm still not convinced that it's necessary to lock what you are trying to lock, but I certainly agree on atomic_t. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ucred holding patch, BDE version
John Baldwin wrote: > Yes, calling free() without Giant is about as good as calling fdrop() without > Giant Alfred. :) Alfred would be right, for per processor memory pools. 8-). > >> 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. No. If you _depend_ on the frequency of change being low, you can do this with only atomic reference counts. See the pseudo code in my other posting, in direct response to you. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ucred holding patch, BDE version
On Mon, 11 Feb 2002, John Baldwin wrote: > > 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. hmm ok Alfred, here's the way I see it.. You are never permitted to "CHANGE" a cred. You ALWAYS allocate another and switch them. When you switch them you decrement the refcount of the old one. If someone else takes a reference on it at the same moment that you drop it, then the order is important down to the bus-cycle as to whether it gets freed or not. We already know that dereferencing it from the proc structure is not important, because a "stale" ucred pointer is only preventable from the userland. All that is important is that the pointer is a REAL pointer to a cred and that it is not allowed to go to 0 references in its way to 1 reference. An atomic reference count increment that checks against 0 would be part of it but might not be enough. I think we also need to have a lock on something because it might get freed and used for something else that happens to place a "1" in that location inbetween the time that p->p_ucred is read and the refcount is decremented. As an asside: I think that in NT they may have refcounts in the same location in all structures as I think they derived all their structures from a bas class that has ref counts. In that case it WOULD have a "1" in that location if it were re-used. (It's been a long time since I saw NT code so I may be wrong) > > > 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 <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
--BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: > > In your case we need totrace proc 1 I think.. > I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="screenlog.0" Content-Transfer-Encoding: quoted-printable show locks=0D exclusive (sleep mutex) Giant (0xc02e60c0) locked @ /usr/src/sys/kern/kern_= intr.c:532=0D db> ps=0D pid proc addruid ppid pgrp flag stat wmesg wchan cmd=0D 279 cdbdc500 cdc6e0000 1 279 0004002 2 reboot= =0D 185 cc988900 cdbbc0000 0 0 204 3 nfsidl c1d053ac nfsiod= 3=0D 184 cc988c00 cdbb80000 0 0 204 3 nfsidl c1d053a8 nfsiod= 2=0D 183 cc988f00 cdbb40000 0 0 204 3 nfsidl c1d053a4 nfsiod= 1=0D 182 cc989200 cdbb0 0 0 204 3 nfsidl c1d053a0 nfsiod= 0=0D 7 cc98b600 cd1a60000 0 0 204 3 ktsusp cc98b800 syncer= =0D 6 cc98b900 cd1a20000 0 0 204 3 ktsusp cc98bb00 vnlru= =0D 5 cc98bc00 cd19e0000 0 0 204 3 ktsusp cc98be00 bufdae= mon=0D 4 cc98bf00 cd19a0000 0 0 204 3 pgzero c0327f88 pageze= ro=0D 3 cc98c200 cd1960000 0 0 204 3 psleep c0327f9c vmdaem= on=0D 2 cc98c500 cd1920000 0 0 204 3 psleep c02e0698 pageda= emon=0D 31 cc98c800 cc9910000 0 0 204 6 irq8: = rtc=0D 30 cc98cb00 cc98d0000 0 0 204 6 irq0: = clk=0D 29 cc321f00 cc9840000 0 0 204 6 irq4: = sio0=0D 28 cc322200 cc980 0 0 204 6 swi0: = tty:sio=0D 27 cc322500 cc97c0000 0 0 204 6 irq7: = ppc0=0D 26 cc322800 cc9780000 0 0 204 6 irq12:= psm0=0D 25 cc322b00 cc9740000 0 0 204 2 irq1: = atkbd0=0D 24 cc322e00 cc970 0 0 204 3 usbevt c1b60210 usb0=0D 23 cc323100 cc96c0000 0 0 204 6 irq11:= uhci0=0D --More--=0D 22 cc323400 cc9680000 0 0 204 6 = irq15: ata1=0D 21 cc323700 cc9640000 0 0 204 6 irq14:= ata0=0D 20 cc323a00 cc95b0000 0 0 204 6 irq5: = pcm0=0D 19 cc323d00 cc9530000 0 0 204 6 irq13:= =0D 18 cc324000 cc94f0000 0 0 204 6 swi5: = acpitaskq=0D 17 cc324300 cc94b0000 0 0 204 6 swi5: = task queue=0D 16 cc324600 cc9470000 0 0 204 6 swi3: = cambio=0D 15 cc324900 cc9430000 0 0 204 6 swi2: = camnet=0D 14 cc324c00 cc93f0000 0 0 204 3 sleep c04141c0 random= =0D 13 cc324f00 cc93b0000 0 0 204 6 swi4: = vm=0D 12 cc325200 cc9370000 0 0 20c 2 swi6: = tty:sio clock=0D 11 cc325500 cc9330000 0 0 204 6 swi1: = net=0D 10 cc325800 cc32e0000 0 0 20c 2 idle=0D 1 cc325b00 cc32a0000 0 1 0004200 3wait cc325b00 init=0D 0 c02c41c0 c047c0000 0 0 200 3 sched c02c41c0 swappe= r=0D db> tr 279=0D mi_switch(0,cdbdc500,cdbdc604,10,0) at mi_switch+0x153=0D boot(0,cdbdc714,cdc71d40,c0262b80,cdbdc604) at boot+0x200=0D reboot(cdbdc604,cdc71d20,2,0,0) at reboot+0x37=0D syscall(2f,2f,2f,0,0) at syscall+0x254=0D syscall_with_err_pushed() at syscall_with_err_pushed+0x1b=0D --- syscall (55, FreeBSD ELF, reboot), eip =3D 0x8048b8b, esp =3D 0xbfbffb1= c, ebp =3D 0xbfbffb48 ---=0D db> tr 1=0D mi_switch(1,0,cc32dd20,1,0) at mi_switch+0x153=0D msleep(cc325b00,0,15c,c0287e85,0) at msleep+0x322=0D wait1(cc325c04,cc32dd20,0,cc32dd40,c0262b80) at wait1+0x617=0D wait4(cc325c04,cc32dd20,0,bfbffe18,bfbffe24) at wait4+0x12=0D syscall(2f,2f,2f,bfbffe24,bfbffe18) at syscall+0x254=0D syscall_with_err_pushed() at syscall_with_err_pushed+0x1b=0D --- syscall (7, FreeBSD ELF, wait4), eip =3D 0x8050c37, esp =3D 0xbfbffcf8,= ebp =3D 0xbfbffd14 ---=0D db> tr 0=0D mi_switch(c02def10,0,483000,1,0) at mi_switch+0x153=0D msleep(c02c41c0,0,44,c02a7570,3e8) at msleep+0x322=0D scheduler(0,47bc00,47b000,0,c0121d1c) at scheduler+0x146=0D mi_startup() at mi_startup+0x95=0D begin() at begin+0x43=0D db> ~~=08 =08=08 =08show witness=0D Sleep locks:
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
yes,, this exactly fits the symptoms!
I've committed it.
(it's definitly wrong)
assume this will solv ethe problem.
now why doesn't MINE fail?
On Sat, 9 Feb 2002 [EMAIL PROTECTED] wrote:
> > h so what is the difference between your kernel and mine that works?
> >
> > just out of curiosity, have you tried a very latest -current?
> > do you have your own config? how does GENERIC behave?
> > (what kind of disks do you have?)
>
> It looks like a call to setrunqueue() was incorrectly dropped in
> the latest version of kern_shutdown.c.
>
> Index: kern_shutdown.c
> ===
> RCS file: /home/ncvs/src/sys/kern/kern_shutdown.c,v
> retrieving revision 1.118
> diff -u -r1.118 kern_shutdown.c
> --- kern_shutdown.c 7 Feb 2002 20:58:44 - 1.118
> +++ kern_shutdown.c 9 Feb 2002 01:11:18 -
> @@ -272,6 +272,7 @@
> DROP_GIANT();
> for (subiter = 0; subiter < 50 * iter; subiter++) {
> mtx_lock_spin(&sched_lock);
> + setrunqueue(curthread);
> curthread->td_proc->p_stats->p_ru.ru_nvcsw++;
> mi_switch(); /* Allow interrupt
>threads to run */
> mtx_unlock_spin(&sched_lock);
>
>
> - Tor Egge
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
double-free in mtree(1)
I get the following error when running mtree(1) in a jail:
root@p4 /usr/src# gdb =mtree
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/dbxread.c line 2629
in elfstab_build_psymtabs
Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/dbxread.c line 935
in fill_symbuf
(gdb) set args -deU -f /etc/mtree/BSD.root.dist -p /
(gdb) run
Starting program: /usr/sbin/mtree -deU -f /etc/mtree/BSD.root.dist -p /
mtree in free(): error: chunk is already free
Program received signal SIGABRT, Aborted.
0x280b4f07 in kill () from /usr/lib/libc.so.5
(gdb) where
#0 0x280b4f07 in kill () from /usr/lib/libc.so.5
#1 0x28108aa1 in abort () at /usr/src/lib/libc/../libc/stdlib/abort.c:70
#2 0x28107534 in wrterror (p=0x2811193b "chunk is already free\n")
at /usr/src/lib/libc/../libc/stdlib/malloc.c:303
#3 0x28107560 in wrtwarning (p=0x2811193b "chunk is already free\n")
at /usr/src/lib/libc/../libc/stdlib/malloc.c:311
#4 0x28108446 in ifree (ptr=0x8055700)
at /usr/src/lib/libc/../libc/stdlib/malloc.c:989
#5 0x281086d1 in free (ptr=0x8055700)
at /usr/src/lib/libc/../libc/stdlib/malloc.c:1121
#6 0x280aff2a in fts_close (sp=0x8059000)
at /usr/src/lib/libc/../libc/gen/fts.c:235
#7 0x804c0d4 in vwalk () at /usr/src/usr.sbin/mtree/verify.c:155
#8 0x804be12 in verify () at /usr/src/usr.sbin/mtree/verify.c:72
#9 0x804b3c1 in main (argc=6, argv=0xbfbff574)
at /usr/src/usr.sbin/mtree/mtree.c:167
#10 0x80493c9 in _start (arguments=0xbfbff688 "/usr/sbin/mtree")
at /usr/src/lib/csu/i386-elf/crt1.c:96
(gdb) up 6
#6 0x280aff2a in fts_close (sp=0x8059000)
at /usr/src/lib/libc/../libc/gen/fts.c:235
235 free(p);
(gdb) p *p
$1 = {fts_cycle = 0xd0d0d0d0, fts_parent = 0xd0d0d0d0, fts_link = 0xd0d0d0d0,
fts_number = -791621424, fts_pointer = 0xd0d0d0d0,
fts_accpath = 0xd0d0d0d0 ,
fts_path = 0xd0d0d0d0 ,
fts_errno = -791621424, fts_symfd = -791621424, fts_pathlen = 53456,
fts_namelen = 53456, fts_ino = 3503345872, fts_dev = 3503345872,
fts_nlink = 53456, fts_level = -12080, fts_info = 53456, fts_flags = 53456,
fts_instr = 53456, fts_statp = 0xd0d0d0d0, fts_name = ""}
(gdb) p *sp
$2 = {fts_cur = 0x8055700, fts_child = 0x0, fts_array = 0x0, fts_dev = 29708,
fts_path = 0x805a000 "./proc", fts_rfd = 3, fts_pathlen = 1280,
fts_nitems = 0, fts_compar = 0, fts_options = 528}
(gdb) p *(sp->fts_cur)
$3 = {fts_cycle = 0xd0d0d0d0, fts_parent = 0xd0d0d0d0, fts_link = 0xd0d0d0d0,
fts_number = -791621424, fts_pointer = 0xd0d0d0d0,
fts_accpath = 0xd0d0d0d0 ,
fts_path = 0xd0d0d0d0 ,
fts_errno = -791621424, fts_symfd = -791621424, fts_pathlen = 53456,
fts_namelen = 53456, fts_ino = 3503345872, fts_dev = 3503345872,
fts_nlink = 53456, fts_level = -12080, fts_info = 53456, fts_flags = 53456,
fts_instr = 53456, fts_statp = 0xd0d0d0d0, fts_name = ""}
(gdb)
Same thing happens when I run it outside the jail, but pointing to the
jail's root directory. Seems like an fts bug, but I was unable to
discover the exact cause.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
acpi and device.hints
Is it possible to make devices enumerated by acpi to take notice of the flags given to them in device.hints? for example if I allow acpi then I get: sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A despite the fact that I have in device.hints: hint.sio.1.at="isa" hint.sio.1.port="0x2F8" hint.sio.1.irq="3" hint.sio.1.flags="0xc0" which should reserve the port for gdb. My answer is to simply do mv /boot/kernel/acpi.ko /boot/kernel/xacpi.ko but it's be nice to have both the gdb AND the acpi abilities. regards, Julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Non 386 testers REALLY NEEDED
David O'Brien wrote:
> > Ports does the same thing: hand tweaks stuff instead of
> > pushing the patches back to the projects that originated
> > it.
>
> *sigh* Terry I respect your programming knowledge, but you are wrong
> here. I send out a *LOT* of patches to the authors of ports I maintain
> (and I know others that do so also). You might be surprised at the
> number of software authors that either 1. don't care that the package is
> not portable, or 2. wont answer their email.
Actually, I wouldn't.
I started on a pass thorugh the ports a while back, to try
and push patches back to the authors, but it's a daunting
task. A lot of the ports patches (and I'm not trying to
dump on anyone in particular here... I didn't start by going
alphabetically ;-)) are unfortunately not push-backable.
The FreeBSD specific patches break things for other platforms,
or end up changing things for editorial reasons, without
making the targets of those changes site options, instead of
an editorial conflict with the authors of the original code
(DJB is particularly bad at portraying any patch offered him
as if it were an editorial comment, but other authors are not
immune to the same thing, unfortunately).
Needless to say, it would take a concerted effort to get rid
of the FreeBSD specific patches out of the ports tree, entirely,
not just the efforts of one person.
A quick perusal of the /usr/ports on a 4.1 machine I have here
locally ("quick" perusal?!? 8-)) shows that there are ~8000
patch files that are needed to "FreeBSD-ify" things, and that
number is likely much higher with the higher number of ports,
now.
Maybe Open Ports, being a voice for more OSs, will have better
luck.
> > It's far, far better that the Makefile runs the
> > autoconf/automake/configure/etc. on behalf of the contrib
> > code, with no hand-tweaked files dragged in after the
> > config has already been run.
>
> That would be nice, but the problem is autoconf/automake/configure/etc.
> is WAY too sensitive to the environment in which it is running.
> As one example, the C++ API supported by GCC. When configuring it looks
> at the existing C++ API and matches it. Well, a while back I wanted to
> change the C++ API. There is no way to do this using `configure'.
> However, the way I do build the toolchain it is VERY DETERMINISTIC and I
> am able to set how I want things to work in the end. This removes
> dependencies on the current environment.
Ugh. I was unaware that they tried to do that. It seems...
uh... "brilliant"... to want to lock everyone into the 1.0
version of the API because they upgraded through all the
g+ version since day 1. 8-p.
Unless there are overriding concerns like that, though, I
think that people doing ports should "do as you say, not as
you do". 8-). GCC is, unfortunately, a very big pile of
code; if anything's going to be an exception, it's that,
particularly given the "release" and "buildworld" issues.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: bdwrite: buffer is not busy
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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: function name collision on "getcontext" with ports/editors/joe
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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: bdwrite: buffer is not busy
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
final ucred patch
This is a multi-part message in MIME format.
--Boundary_(ID_TA6w1McSahPHMx8+rAaDoQ)
Content-type: text/plain; charset=iso-8859-2
Content-transfer-encoding: 7BIT
After comments by jhb and bde
--
++ __ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ [EMAIL PROTECTED] +-->x USA\ a very strange
| ( OZ)\___ ___ | country !
+- X_.---._/presently in San Francisco \_/ \\
v
--Boundary_(ID_TA6w1McSahPHMx8+rAaDoQ)
Content-type: text/plain; charset=iso-8859-2; name=thediff
Content-transfer-encoding: 7BIT
Content-disposition: inline; filename=thediff
? i386/conf/LINT
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.c10 Jan 2002 11:49:54 - 1.211
+++ i386/i386/trap.c10 Feb 2002 00:52:58 -
@@ -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);
+ }
+ if (p->p_ucred) {
+ PROC_LOCK(p);
+ td->td_ucred = crhold(p->p_ucred);
+ PROC_UNLOCK(p);
+ }
+ }
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;
}
@@ -954,9 +966,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);
+ }
+ if (p->p_ucred) {
+ PROC_LOCK(p);
+ td->td_ucred = crhold(p->p_ucred);
+ PROC_UNLOCK(p);
+ }
+ }
params = (caddr_t)frame.tf_esp + sizeof(int);
code = frame.tf_eax;
orig_tf_eflags = frame.tf_eflags;
@@ -1099,10 +1121,14 @@
*/
STOPEVENT(p, S_SCX, code);
- mtx_lock(&Giant);
- crfree(td->td_ucred);
- mtx_unlock(&Giant);
- td->td_ucred = NULL;
+#ifdef INVARIANTS
+ if (td->td_ucred) {
+ mtx_lock(&Giant);
+ crfree(td->td_ucred);
+ td->td_ucred = NULL;
+ mtx_unlock(&Giant);
+ }
+#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.206
diff -u -r1.206 subr_trap.c
--- kern/subr_trap.c17 Jan 2002 17:49:23 - 1.206
+++ kern/subr_trap.c10 Feb 2002 00:53:00 -
@@ -161,9 +161,19 @@
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) {
+ if (td->td_ucred) {
+ mtx_lock(&Giant);
+ crfree(td->td_ucred);
+ td->td_ucred = NULL;
+ mtx_unlock(&Giant);
+ }
+ if (p->p_ucred) {
+ PROC_LOCK(p);
+ td->td_ucred = crhold(p->p_ucred);
+ PROC_UNLOCK(p);
+ }
+ }
if (flags & KEF_OWEUPC && sflag & PS_PROFIL)
addupc_task(ke, p->p_stats->p_prof.pr_addr, prticks);
if (sflag & PS_ALRMPEND) {
function name collision on "getcontext" with ports/editors/joe
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? -- Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Non 386 testers REALLY NEEDED
--=-c5mu7fd8+iIeadXPJgcR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2002-02-07 at 08:01, Julian Elischer wrote: >=20 > for the set of patches at: > http://www.freebsd.org/~julian/adiff >=20 > these patches SHOULD NOT EFFECT your system except to do some > slight re-aranging of stuff in the kernel. >=20 > THe aim is to get this committed to 'clarify' the upcoming > KSE commit in http://www.freebsd.org/~julian/thediff >=20 > which includes adiff as a subset. >=20 > when adiff is committed thediff will become a lot easier for people to=20 > read and check. I'd like to get adiff in relatively soon. This causes some breakage in PowerPC but I'm working on it. Go ahead and commit and I'll fix PowerPC up after. --=20 Benno Rice [EMAIL PROTECTED] --=-c5mu7fd8+iIeadXPJgcR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjxiXwIACgkQXjRwWofFmQkwBwCbBNexhLf2sKe8ZckvRwyYO6mw IWgAni8WYxq6OsO1904GUM/nRN+P//IT =I2dZ -END PGP SIGNATURE- --=-c5mu7fd8+iIeadXPJgcR-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
I'm not particularly good at reading the lock-related output, but it doesn't have other lines than the one that says about the Giant lock, so it seems there isn't any other locks being held by anyone. Eugene On Fri, Feb 08, 2002 at 04:55:42PM -0800, Julian Elischer wrote: > > > I tlooks as if "show locks" would not show any locks held by anyone.. > is this true? > > > On Fri, 8 Feb 2002, Eugene M. Kim wrote: > > > On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: > > > > > > In your case we need totrace proc 1 I think.. > > > > > > > I got the `reboot' process at this session, so I traced that process. > > Before I had used `shutdown -r', which probably SIGINT'ed the init > > process so it's init (pid 1) calling reboot()... The attached log also > > has its trace JFYI. > > > > One more bit of info: as you see from the pcpu output, mine is not an > > SMP but an UP box. > > > > Thanks, > > Eugene > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
upgrading from 4.4 stable to current
This is a note for someone upgrading from 4.4 stable to current 5.0 comes right out of my experience in doing so the file /usr/src/UPGRADE doesnt detail the following step I didnt see ne 1 post this before may be it will help some newbie like myself and perhaps somebody will add it to the UPGRADE file after rebuilding the world and the kernel for 5.0 (after cvsuping the src to current , ofcourse) on a system previously running on 4.4 stable installed right out of the FreeBSD purchased CD's it is necessary to reinstall the loader to get it to run the new kernel. to do it I just cd(ed) to /usr/src/sys/boot/i386 make all ; make install; if this step is not done the new kernel will never boot -- I spent like 4\5 hours figuring it out couldnt find any documentation about it anywhere the location of the old kernel is /kernel and the modules is /modules however the new kernel and modules resides in /boot/kernel On a personal note I like the new location better have fun Saurabh Gupta To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Binutils fixed in -current?
On 2002-02-08 06:57, Alfred Perlstein wrote:
> * Andrea Campi <[EMAIL PROTECTED]> [020208 03:51] wrote:
> > On Wed, Feb 06, 2002 at 12:35:39PM -0800, Alfred Perlstein wrote:
> > > * David W. Chapman Jr. <[EMAIL PROTECTED]> [020206 12:33] wrote:
> > > > Does anyone know if the problem with kde and other programs not
> > > > working with the new binutils not working have been fixed yet?
> > >
> > > I find that mozilla 0.9.8 dies with pure virtual called or something
> > > to that effect, however I don't have a super recent world, I'm compiling
> > > one now and will let you know if it at least fixes that for me.
> >
> > FYI, I also get this on 4.5-STABLE.
>
> If you do a pkg_deletew of mozilla and then nuke /usr/X11R6/lib/mozilla
> then reinstall it the problem should go away.
Just my $0.02:
A reinstall of the port fixed the problems I was having with the
www/linux-netscape47-communicator port after a buildworld at Jan 7.
Probably unrelated to the mozilla problems, but I thought I'd mention in
case someone else sees netscape start, and dump core before even displaying
the main window in X11.
--
Giorgos Keramidas . . . . . . . . . keramida@{ceid.upatras.gr,freebsd.org}
FreeBSD Documentation Project . . . http://www.freebsd.org/docproj/
FreeBSD: The power to serve . . . . http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Performance of -current vs -stable
Serwoas! %s wrote on %.3s, %lld Sep 1993 > > 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. > WITNESS can really hurt. Quite possibly I should turn it off in GENERIC now (I Hmmm, a few weeks ago I did some totally unscientific testing, noting that -current was much slower than -stable, by playing an mp3 with an optimized `mpg123' on a 75MHz pentium machine, where the difference was far more obvious than on a faster machine. I suspected that WITNESS and similar goodies might be a problem, and even composed a lengthy message wondering about it, but what really got me wondering was the fact that -stable had far less idle time than the same hardware running NetBSD-current, so that I could do `useful' work under NetBSD while playing an mp3 cleanly, but such was difficult with FreeBSD-stable and impossible with -current. However, I suspect that such a question is more on-topic in -hackers or even -stable than here, but I'm wondering if I should extract any useful info from the message I composed but never sent, and post my kernel config and ask if there's anything obvious in there that would explain why FreeBSD's mpg123 takes ~60% CPU and NetBSD's ~30% (vs the ~90+% usage by -current)... Oh, I'll try rebuilding -current Real Soon^W^W later today, without WITNESS, and compare, just to stay on-topic for this list. thanks barry bouwsma To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PAM Error
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? TIA, Beech -- --- Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED] /"\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAM Error
> 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Support for atapi cdrw as scsi in -current?
It seems Gerhard Sittig wrote: > On Thu, Feb 07, 2002 at 12:38 +0100, Søren Schmidt wrote: > > > > [ snipped ATAPI -> SCSI conversion ] > > > > Doesn't burncd work for you on -current ? > > Well, since you asked about it ... :) I asked for *problems* not cosmetic issues :) > The bug (talking about a few million percent completion of > the job, while one hundred should suffice) is still there. > Can you have one more look at > http://www.freebsd.org/cgi/query-pr.cgi?pr=30893 > please? Especially the simple and straight fix in its > opening. This shouldn't take eight months to wait for > or doing hard fights to get it fixed ... :( (I know you > were busy back then changing jobs and moving, but the later > closing wasn't appropriate without a fix.) It is on my TODO list, but its fairly long, and functional errors plus supporting new hardware keeps getting top priority... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Hang on flushing buffers w/today's -CURRENT, SMP system
OK; I got today's -CURRENT built & running on each of my build machine (freebeast) & my laptop. (Got today's -STABLE built earlier; I mention this as a reference point/comparison. I similarly note that I've been tracking each daily on each machine for several months, and that today is the first time I've seen this problem.) Anyway, the laptop seems fairly normal: I got -CURRENT built, booted it up, ran a few things, used boot0cfg to switch to the slice with today's -STABLE, and it came right down (gracefully) and back up again: g1-7(4.5-S)[1] uname -a FreeBSD g1-7.catwhisker.org 4.5-STABLE FreeBSD 4.5-STABLE #74: Fri Feb 8 05:58:01 PST 2002 [EMAIL PROTECTED]:/common/S1/obj/usr/src/sys/LAPTOP_30W i386 g1-7(4.5-S)[2] But on the build machine, I got it running -CURRENT, then did the same procedure (boot0cfg & reboot), but on the (serial) console, I see: Feb 8 08:45:32 freebeast mountd[181]: bad exports list line /cdrom-ro -alldirs apache cvsupd To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bizzare problem..
On Wed, 6 Feb 2002, Jacob Frelinger wrote: > On Wed, Feb 06, 2002 at 01:08:10PM -0800, Doug White wrote: > > On Tue, 5 Feb 2002, Jacob Frelinger wrote: > > > > You aren't using a Linux version of vi, are you? It so happens a common > > freebsd system call maps to linux reboot() > > > > it shouldn't be. > [jolly@spooky ~]# which vi > /usr/bin/vi > [jolly@spooky ~]# strings /usr/bin/vi | head -2 > /usr/libexec/ld-elf.so.1 > FreeBSD > > and that wouldn't explain the shutdowns when i ssh from the problematic > machine into a different one and run vi on the remote machine. > > i wish it was something that simple... i'm completly stumped on this... I think I'd chock it up to bad memory at this point. Teh reboots could be a parity failure and some systems reboot in that condition ... Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ucred for threads
On Thu, 7 Feb 2002, Julian Elischer wrote:
> As part of the KSe stuff I ended up changing ht ebehaviour of threads with
> respect to their ucreds. Previously, they freed their ucred reference when
> they entered user space and picked them up again when they re-entered the
> kernel. It there was an AST then they re-loaded teh already freed ucred to
> perform the AST. (and then freed it again, (For each AST).
> Since each 'get' and free required a lock and unlock of the proc
> structure, this meant that there were at least 2 locks and 2 unlocks, and
> possibly many more, for the average kernel entry/exit pair.
The 2 locks and 2 unlocks pessimized syscall overhead by 10-20%.
> Since the chance that the ucred on the next entry is not the same as the
> thread already had on it's last kernel exit, is almiost negligible,
> it makes sence to hold the ucred acress the user period an dsimply check
> it agains the process's ucred on th enext entry.
>
> In the KSE code I have:
> in trap(), and syscall()
>
> if (td->td_ucred != p->p_ucred) {
> PROC_LOCK(p);
> if (td->td_ucred) {
> crfree(td->td_ucred);
> td->td_ucred = NULL;
> }
> if (p->p_ucred != NULL) {
> td->td_ucred = crhold(p->p_ucred);
> }
> PROC_UNLOCK(p);
> }
I deleted too much of the followup to this, so I can't quote it.
Races here could be reduced by putting some sort of synchronization
instruction at the beginning. Then there would only be a race between
executing the sync instruction and checking p_ucred. The race window
could be very large if the process is preempted in between. But this
race is obviously unavoidable in the current framework. You may end
up with a slightly stale td_ucred, but this is insignificantly different
from ending up with a slightly stale td_ucred when p_ucred changes
just after you release the lock. Both can have almost any amount of
staleness if processes can be preempted...
Without the sync instruction, the race starts a little earlier, in
userland. It's not so obvious that the effects of this race are not
really different from the the effects of p_ucred changing after you
release the lock, but I think they are. Terry argued this point from
a different viewpoint.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ucred for threads
As part of the KSe stuff I ended up changing ht ebehaviour of threads with
respect to their ucreds. Previously, they freed their ucred reference when
they entered user space and picked them up again when they re-entered the
kernel. It there was an AST then they re-loaded teh already freed ucred to
perform the AST. (and then freed it again, (For each AST).
Since each 'get' and free required a lock and unlock of the proc
structure, this meant that there were at least 2 locks and 2 unlocks, and
possibly many more, for the average kernel entry/exit pair.
Since the chance that the ucred on the next entry is not the same as the
thread already had on it's last kernel exit, is almiost negligible,
it makes sence to hold the ucred acress the user period an dsimply check
it agains the process's ucred on th enext entry.
In the KSE code I have:
in trap(), and syscall()
if (td->td_ucred != p->p_ucred) {
PROC_LOCK(p);
if (td->td_ucred) {
crfree(td->td_ucred);
td->td_ucred = NULL;
}
if (p->p_ucred != NULL) {
td->td_ucred = crhold(p->p_ucred);
}
PROC_UNLOCK(p);
}
THis is actually not dependent on KSE (though I originally needed it
for KSE I have since decided that it would be a good idea anyhow).
Do those who deal in ucreds (probably jhb and Robert W)
agree or disagree.. (if so I'll happily commit it as it shrinks the KSE
patches a bit more :-)
Julian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: gcc3.x issues
Terry Lambert writes: > I don't think Joe is debating; I think he wants to have a > meta-discussion about what the problem space looks like, > before submitting patches that light up his little corner, > and dark up everything else. Thank you, Terry. Maybe I need to bring up the issue on -arch? Where is it possible to have design discussions without getting slapped down with the "submit a patch or shut up" attitude? I personally work by doing design first, or at least getting to the point where I understand the problem before tackling it in an incremental design/build cycle. Maybe someone can point out the design documentation for the whole complex mk hierarchy and/or for the design behind the importation of gcc and other GNU stuff into the source tree. Or maybe the design is the code... I appreciate your offer of assistance, Terry. I will take your last pointer into the make files and see what I can deduce on my own. /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc3.x issues
* Nat Lanza <[EMAIL PROTECTED]> [020207 10:30] wrote: > On Thu, 2002-02-07 at 12:59, Alfred Perlstein wrote: > > 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. > > Surely you see the difference between "That's an interesting idea; can > you generate some patches so we can take a look and see how it works > out?" and "WhereTF is your patch to do this?". > > One provides an opportunity for users to contribute, and the other is a > snarling, rude dismissal that really doesn't do very much to encourage > people to stick around and help out. No, they both offer users a chance to conribute, however the second let's the person know that they are bordering on annoying the person and should take some time to work on the actual implementation. Would you rather have someone's irritation or just be killfiled? Some people need to buck up and grow a thicker skin. Neither I nor David are in anyway compensated directly through our involvement in the FreeBSD project to pull punches nor coddle people that should know better. Moving forward, let's postpone taking this conversation any further until the time that the work requested does become available. -- -Alfred Perlstein [[EMAIL PROTECTED]] '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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc3.x issues
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. 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. 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. 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. Thanks for your helpful and pleasant comments David. /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ucred holding patch, BDE version
On Mon, 11 Feb 2002, Alfred Perlstein wrote: > * Julian Elischer <[EMAIL PROTECTED]> [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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current.freebsd.org down?
> 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ucred holding patch, BDE version
* Julian Elischer <[EMAIL PROTECTED]> [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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
BSDCON activities 2night?
Anyone making the usual plans or should I just look for the terminal room? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current.freebsd.org down?
will> Jordan announced recently that Qwest is upgrading the hardware will> and that there would be intermittent problems with the server for will> a certain period (a few days as I recall). It would be: > From: Jordan Hubbard <[EMAIL PROTECTED]> > Subject: stable.freebsd.org AKA releng4.freebsd.org down for next 2 days > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Date: Sat, 02 Feb 2002 13:35:57 -0800 > Most people don't mirror anything from this machine, but just for the > few who do, please consider this a HEADS UP! The machine is being > replaced by a much beefier and faster machine, courtesy of Qwest, and > will be back up just as soon as its new incarnation is clearly doing > everything the old one did. > Now when I say "down" I also don't mean actually down 24/7, and I'll > actually endevor to keep the service mostly "up" for those two days, > I just want you all to know that I'll feel free to reboot it or take > it off-line at any time and without notice during that period until > the service is transitioned. Thanks for your patience. But this doesn't mention about current.FreeBSD.org, and today is Feb/07/2002. I'm anxious about something goes wrong (machine troubles, jkh is still busy working, or something like that). -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ucred holding patch, BDE version
On 11-Feb-02 Alfred Perlstein wrote: > * Julian Elischer <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
current.freebsd.org down?
Hi, I know this is probably offtopic but is there any problem with current.freebsd.org at the moment? I've been unable to log in for almost an hour, the ftp daemon is up, it just doesn't allow me in and I was about to load -CURRENT on my laptop. Any idea? Cheers, -- Miguel Mendez - [EMAIL PROTECTED] Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ucred holding patch, BDE version
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 <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: function name collision on "getcontext" with ports/editors/joe
On Mon, 11 Feb 2002, Garrett Wollman wrote: > <<[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: ucred holding patch, BDE version
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 <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "fast" interrupt handler threads.
On Sat, 9 Feb 2002, Julian Elischer wrote: > On Sun, 10 Feb 2002, Bruce Evans wrote: > > > > Yes, anything that reaches doreti checks for ASTs and runs userret() if > > necessary and possible (only for returns to user mode). > > > > Hmm, this check seems to be inadequate for fast interrupts. There is > > no check for rescheduling if the return is to kernel mode. > > Do you plan on fixing anything you find wrong here? Sure. I think this is only a minor problem. Most processes don't stay in the kernel for long, and things scheduled in fast interrupt handlers aren't very time-critical (but softclock should run before the next hardclock!). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "fast" interrupt handler threads.
Thanks On Sun, 10 Feb 2002, Bruce Evans wrote: > > Yes, anything that reaches doreti checks for ASTs and runs userret() if > necessary and possible (only for returns to user mode). > > Hmm, this check seems to be inadequate for fast interrupts. There is > no check for rescheduling if the return is to kernel mode. Do you plan on fixing anything you find wrong here? > > Bruce > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "fast" interrupt handler threads.
On Fri, 8 Feb 2002, Julian Elischer wrote: > Bruce, for the low-level impared such as myself, can you give a quick > precis on teh difference between "fast" interrupt handlers in -current > and 'normal' interrupt handlers. "Fast" interrupt handlers are harder to program and should rarely be used. There are no correctly programmed ones in -current. A correctly programmed one would do not much more than something like: some_sort_of_lock_not_using_mtx(); buf[writeindex++ & mask] = bus_space_read_1(...); some_sort_of_unlock_not_using_mtx(); > Do fast interrupt handlers enter through "trap()" ? No. They are called directly from XfastintrN. A really fast one would be inside XfastintrN. > if they interrupt a user process, do they take on the cred of the running > thread? No. Accessing almost anothing except correctly locked local (static) storage in a fast interrupt handler is a bug. > do they return via doreti() They always do in -current. This is a pessimization (never merged into my version). In -stable, they can only return via doreti if they metamorphose into a normal interrupt handler, which they do in most the few cases where doreti would do something other than just return. Note that it would only do somthing for return to _user_ mode if the fast interrupt handler scheduled a software interrupt (no other interrupts or ASTs can be pending since there must have been none when the fast interrupt occurred, and fast interrupts disable other interrupts). > on returning do they check for ASTs and run userret()? Yes, anything that reaches doreti checks for ASTs and runs userret() if necessary and possible (only for returns to user mode). Hmm, this check seems to be inadequate for fast interrupts. There is no check for rescheduling if the return is to kernel mode. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Making bootable recovery CD using cdboot/loader fails
On Tue, 5 Feb 2002, John Baldwin wrote: ... > > Its the loader after showing: > > ... > > loader Revision... > > (root@nihil, ...) > > ... > > And then a few rotating -\|/ (serching or loading loader.conf, kernel, ?) > > Then silence. > > Hmm. Is your loader completely up to date? Does it have a BIOS CD device cd0 > in the output prior to that line? Yes, yes. Can the loader be compiled to be more verbose? Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
Mikhail Teterin wrote: > That's the thing. gcc30 port, essentially, installs a copy of the > compiler already available as part of the base. But the base is missing > gcj (the port does too for now), so one would be forced to add the port. Compilers from ports suck. If you set DESTDIR, it screws up your header and include patch for C++, and you get the old headers and libraries, so things like RTTI break. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mergemaster niggle
> The real question here is: why is the RCSid changing when the file > isn't? Sometimes things get changed and then backed out to their original state, but you cannot keep the original RCSID To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Non 386 testers REALLY NEEDED
I don't know the alpha at all but how about leaq t0, thread0 or some similar thing or even.. ldq t0,$thread0 or something similar.. who's assembler is being used? On Wed, 6 Feb 2002, Andrew Gallatin wrote: > > Andrew Gallatin writes: > > > > Since thread0 is no longer a pointer, this looks suspicious in locore.s: > > > > /* > > * Switch to proc0's PCB. > > */ > > ldq t0,thread0 /* get phys addr of pcb */ > > ldq a0,TD_MD_PCBPADDR(t0) > > SWITCH_CONTEXT > > Yeah.. that's it. I hacked around it by taking thread0's address in > machdep.c, shoving it into a global and using that global in locore.s > The resulting kernel booted. > > What's the "right" way to do this? > > Drew > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Not committing WARNS settings...
> On Wed, Feb 06, 2002 at 11:12:38AM +, Mark Murray wrote: > > IMO, this is a good reason to not have WARNS contain -Werror at this > > time. NO_WERROR is a good way to fix this (again IMO). I see a great > > need to let warnings "hang out", and in an ideal world I see an need > > for (new) warnings to break things. I see no need for warnings to > > hold back a project as important as GCC3, and NO_WERROR is the > > cleanest solution. > > > > I do not expect others to agree with (or like) this. > > I do not. Right. I am about to commit a WARNS?= backout in anticipation of your GCC3 work. While I believe we should be going the other way, you are the (un)lucky fellow doing the hard work, so I'll defer. In the meanwhile we shal continue to disagree on a more theoretical level. OK? :-) M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
On 09-Feb-02 Julian Elischer wrote: > yes,, this exactly fits the symptoms! > > I've committed it. > (it's definitly wrong) > assume this will solv ethe problem. > now why doesn't MINE fail? Probably cause you are running your other tree that makes mi_switch() auto do the setrunqueue? :) -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current World stops at rcp.yppasswdd
>Date: Tue, 5 Feb 2002 06:21:34 -0800
>From: Edwin Culp <[EMAIL PROTECTED]>
>World is breaking for me at:
>===> usr.sbin/rpc.yppasswdd
>...
Following patch got through it for me:
Index: usr.sbin/rpc.yppasswdd/pw_util.c
===
RCS file: /cvs/freebsd/src/usr.sbin/rpc.yppasswdd/pw_util.c,v
retrieving revision 1.5
diff -u -r1.5 pw_util.c
--- usr.sbin/rpc.yppasswdd/pw_util.c9 Jul 2001 09:24:02 - 1.5
+++ usr.sbin/rpc.yppasswdd/pw_util.c5 Feb 2002 16:53:43 -
@@ -143,7 +143,7 @@
int
pw_mkdb(username)
-char *username;
+const char *username;
{
yp_error("rebuilding the database...");
@@ -174,7 +174,7 @@
void
pw_error(name, err, eval)
- char *name;
+ const char *name;
int err, eval;
{
if (err && name != NULL)
Index: usr.sbin/rpc.yppasswdd/yppasswdd_extern.h
===
RCS file: /cvs/freebsd/src/usr.sbin/rpc.yppasswdd/yppasswdd_extern.h,v
retrieving revision 1.9
diff -u -r1.9 yppasswdd_extern.h
--- usr.sbin/rpc.yppasswdd/yppasswdd_extern.h 28 Aug 1999 01:19:41 - 1.9
+++ usr.sbin/rpc.yppasswdd/yppasswdd_extern.h 5 Feb 2002 15:38:25 -
@@ -64,7 +64,7 @@
extern voidinstall_reaper __P(( int ));
extern int pw_copy __P(( int, int, struct passwd * ));
extern int pw_lock __P(( void ));
-extern int pw_mkdb __P(( char * ));
+extern int pw_mkdb __P((const char * ));
extern int pw_tmp __P(( void ));
extern voidpw_init __P(( void ));
extern char*ok_shell __P (( char * ));
[Still building the kernel as I type, but the "make buildworld"
completed OK.]
Cheers,
david (links to my resume at http://www.catwhisker.org/~david)
--
David H. Wolfskill [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Non 386 testers REALLY NEEDED
Julian Elischer writes: > > 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. Today's alpha kernel, plus those changes results in a ksp not valid halt with the PC near the beginning of mi_startup: /boot//kernel.bad/kernel data=0x4150c0+0x39360 syms=[0x8+0x62e68+0x8+0x4a36d] Entering /boot//kernel.bad/kernel at 0xfc33b680... sio1: gdb debugging port halted CPU 0 halt code = 2 kernel stack not valid halt PC = fc47e80c >>> Since thread0 is no longer a pointer, this looks suspicious in locore.s: /* * Switch to proc0's PCB. */ ldq t0,thread0 /* get phys addr of pcb */ ldq a0,TD_MD_PCBPADDR(t0) SWITCH_CONTEXT Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
MFREE()
The following files under sys/ still use MFREE(): alpha/tc/am7990.c netatm/port.h security/lomac/kernel_socket.c Please fix. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
>Date: Fri, 8 Feb 2002 17:34:45 -0800 (PST) >From: Julian Elischer <[EMAIL PROTECTED]> >Thats it for sure! >committing now.. >On Sat, 9 Feb 2002 [EMAIL PROTECTED] wrote: >> It looks like a call to setrunqueue() was incorrectly dropped in >> the latest version of kern_shutdown.c. Applying that one-line patch to the kernel sources from this morning, then rebuilding the kernel, yielded a kernel that no longer exhibited the earlier-reported symptoms did not occur. Thanks to all! Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cred stuff..
On Fri, 8 Feb 2002, Julian Elischer wrote:
> I'd like to commit the code to keep the ucred across userland,
> with the code to clear it to NULL kept under DEBUG ifdefs.
>
> i.e.
>
> > in trap(), ast() and syscall()
> >
> > if (td->td_ucred != p->p_ucred) {
> > PROC_LOCK(p);
> > if (td->td_ucred) {
> > crfree(td->td_ucred);
> > td->td_ucred = NULL;
> > }
> > if (p->p_ucred != NULL) {
> > td->td_ucred = crhold(p->p_ucred);
> > }
> > PROC_UNLOCK(p);
> > }
Please fix the style bugs in this before committing:
- explicit NULL in only one null pointer checks
- excessive braces for one of the ifs.
> and in userret() and ast()
>
> >#ifdef DEBUG /*your choice of variable here*/
> > PROC_LOCK(p);
> > if (td->td_ucred) {
> > crfree(td->td_ucred);
> > td->td_ucred = NULL;
> > }
> > PROC_UNLOCK(p);
> >#endif
I think this is better left where it is in the functions that aquire
the locks. It can then be done unconditionally, and not in a loop.
The style of the null pointer check in this is bug for bug compatible
with the corresponding one above.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: cred stuff..
I'm a little worried about invariants because the behaviour when INVARIANTS is set wil be different to teh behaviour when it is off, which is 'strange' to say the least. Normally the behaviour si the same but you just check for invariant conditions. On Fri, 8 Feb 2002, John Baldwin wrote: > > On 08-Feb-02 Julian Elischer wrote: > > > > I'd like to commit the code to keep the ucred across userland, > > with the code to clear it to NULL kept under DEBUG ifdefs. > > Use INVARIANTS for the ifdef macro name, but sure. > > -- > > John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: cred stuff..
John, (peter? others?) How is it that getting a ucred reference is guarded by PROC_LOCK(p) but freeing it is guarded by mtx_lock(&Giant); ? Call me naive, but shouldn't they be guarded by the same thing? Julian On Fri, 8 Feb 2002, Julian Elischer wrote: > I'm a little worried about invariants because the behaviour when > INVARIANTS is set wil be different to teh behaviour when it is off, which > is 'strange' to say the least. Normally the behaviour si the same but you > just check for invariant conditions. > > > On Fri, 8 Feb 2002, John Baldwin wrote: > > > > > On 08-Feb-02 Julian Elischer wrote: > > > > > > I'd like to commit the code to keep the ucred across userland, > > > with the code to clear it to NULL kept under DEBUG ifdefs. > > > > Use INVARIANTS for the ifdef macro name, but sure. > > > > -- > > > > John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: function name collision on "getcontext" with ports/editors/joe
< 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
No, I just never went into that particular clause of code But is has made me rethink the whole issue. On Fri, 8 Feb 2002, John Baldwin wrote: > > On 09-Feb-02 Julian Elischer wrote: > > yes,, this exactly fits the symptoms! > > > > I've committed it. > > (it's definitly wrong) > > assume this will solv ethe problem. > > now why doesn't MINE fail? > > Probably cause you are running your other tree that makes mi_switch() auto do > the setrunqueue? :) > > -- > > John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PCCARD not working on HP Omnibook 6100
Hi,
I can't get my PCMCIA card to work on my HP Omnibook 6100. -current
is from Feb 6.
During boot I get:
Feb 7 10:14:04 hunter kernel: pcic0: irq 5 at
device 5.0 on pci2
Feb 7 10:14:04 hunter kernel: pcic0: PCI Memory allocated: 0xd020
Feb 7 10:14:04 hunter kernel: pcic0: TI12XX PCI Config Reg: [ring enable][speaker
enable][pwr save][FUNC pci int + CSC serial isa irq]
Feb 7 10:14:04 hunter kernel: pccard0: on pcic0
Feb 7 10:14:04 hunter kernel: pci_cfgintr_linked: linked (63) to hard-routed irq
10
Feb 7 10:14:04 hunter kernel: pci_cfgintr: 0:30 INTD routed to irq 10
Feb 7 10:14:04 hunter kernel: pcib2: routed slot 5 INTB to irq 10
Feb 7 10:14:04 hunter kernel: pcic1: irq 10 at
device 5.1 on pci2
Feb 7 10:14:04 hunter kernel: pcic1: PCI Memory allocated: 0xd0201000
Feb 7 10:14:04 hunter kernel: pcic1: TI12XX PCI Config Reg: [ring enable][speaker
enable][pwr save][FUNC pci int + CSC serial isa irq]
Feb 7 10:14:04 hunter kernel: pccard1: on pcic1
Feb 7 10:14:04 hunter kernel: fxp0: port 0x3440-0x347f
mem 0xd020-0xd0200fff irq 10 at device 8.0 on pci2
Feb 7 10:14:04 hunter kernel: fxp0: Ethernet address 00:c0:9f:05:88:52
Feb 7 10:14:05 hunter kernel: inphy0: on miibus0
Feb 7 10:14:05 hunter kernel: inphy0: 10baseT, 10baseT-FDX, 100baseTX,
100baseTX-FDX, auto
Feb 7 10:14:05 hunter kernel: isab0: at device 31.0 on pci0
Feb 7 10:14:05 hunter kernel: isa0: on isab0
Feb 7 10:14:05 hunter kernel: atapci0: port
0x1820-0x182f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 mem
0xd000-0xd3ff at device 31.1 on pci0
Feb 7 10:14:05 hunter kernel: ata0: at 0x1f0 irq 14 on atapci0
Feb 7 10:14:05 hunter kernel: ata1: at 0x170 irq 15 on atapci0
Feb 7 10:14:05 hunter kernel: pci0: at device 31.3 (no driver
attached)
Feb 7 10:14:05 hunter kernel: ata: ata0 already exists; skipping it
Feb 7 10:14:05 hunter kernel: ata: ata1 already exists; skipping it
Feb 7 10:14:05 hunter kernel: pcic: pcic0 already exists; skipping it
Feb 7 10:14:05 hunter kernel: pcic: pcic1 already exists; skipping it
and later when pccardd starts:
Feb 7 10:16:35 hunter kernel: pcib2: device pccard0 requested unsupported memory
range 0xd-0xd (decoding 0xd020-0xd02f, 0xf000-0xf00f)
Feb 7 10:16:35 hunter kernel: pcib2: device pccard0 requested unsupported memory
range 0xd4000-0xd4000 (decoding 0xd020-0xd02f, 0xf000-0xf00f)
Feb 7 10:16:35 hunter pccardd[480]: ioctl (PIOCRWMEM): Invalid argument
Feb 7 10:16:40 hunter pccardd[480]: No card in database for "(null)"("(null)")
Feb 7 10:16:40 hunter pccardd[480]: pccardd started
Also, only the upper PCMCIA slots seems to be active. I get a beep
and some messages when I remove/insert a card in the upper slot, but
with the lower slot nothing happens at all.
My card is a Psion Dacom Gold Card modem.
--
Regards,
Georg.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Non 386 testers REALLY NEEDED
Apparently, On Wed, Feb 06, 2002 at 12:01:44PM -0800, Julian Elischer said words to the effect of; > > 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. This seems to work fine on sparc64. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: double-free in mtree(1)
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes: > Same thing happens when I run it outside the jail, but pointing to the > jail's root directory. Seems like an fts bug, but I was unable to > discover the exact cause. FWIW, I unmounted the jail's /proc and the problem went away. Perhaps fts makes assumptions that do not hold for procfs? Strange that it works on my / but not on the jail directory... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On 6 Feb, David O'Brien wrote: >> http://www.gnu.org/manual/bfd-2.9.1/ >> >> for example, seems to imply, that there was, in fact, at some point a >> release 2.9.1 of bfd... It does not quite match the bfd, > No, that document describes the BFD that was included with Binutils > 2.9.1. If you looked at another tree of documents you would also think > that bfd was at version 5.1.1 (ie, the latest GDB). > What part about two of us telling you that there are no released > versions (ie, of bfd or libiberty as a unique, separate package) > aren't you believing? I know the GNU toolchain, its development, > release cycle, and packaging VERY well. I believe, what I see. And that is, FreeBSD includes both -- gdb and gcc, but only one libbfd, thankfully. And I want to be able to use that same libbfd for my own development and for porting of other compilers and tools. This IS the problem I'm trying to solve. > WHY do you want to cause this problem of non-matching bits? So they'll be matched and fixed, leading to a better world 8-) > This is my last email you on this topic, as you've yet to answer the > question of what problem you are trying to solve! See above. >> Plenty of packages come bundled with the third-party software, and a >> good port makes them build with the already installed versions of >> such software (like zlib, OpenSSL) or with the version available from >> another port (like c-client). > Well the GNU bits do not do that. If you report a GDB bug and they > find out you weren't using the BFD or Libiberty included with GDB, the > bug report would probably be dropped on the floor. Evidently, this does not prevent the FreeBSD project from using the same libbfd for its gdb and gcc. Even though, the presense of both /usr/obj/usr/src/gnu/usr.bin/binutils/libbfd/libbfd.a and /usr/obj/usr/src/i386/ccd/src/gnu/usr.bin/binutils/libbfd/libbfd.a is somewhat mistifying to me, but I'm sure they are built from the same source. > No I want to drop Alpha because no one cares about it and not just the > compiler, but much more often kernel, WARNS, and other changes break > the Alpha. Alright, so you do find it nightmarish. But we still support Alpha, for whatever reason. This means, that the simple "it would be a nightmare" is not an argument. "It is not worth the trouble" -- would be, and I'm arguing, that it is not true in this case. >> > HOW will it help to add software? What is so wrong with compiling >> > the bundled libiberty or bfd that comes with each of the "new >> > software" when building them? What is so wrong with having >> > libiberty or bfd statically linked into the "new software"? >> It is _inelegant_ and is inconsistent with our use of shared >> libraries for most of the rest of the system. Look, we wanted ssh and >> we added it. > Go find a REAL problem to solve than something that you don't like the > esthetics of. This is a REAL problem. "Your theorem is ugly, so it must be incorrect." (Some famous mathematician) >> > I frankly just don't see what "problem" it is you are trying to solve. >> >> I want libbfd (and libiberty) to be installed as part of the OS. >> Preferably -- in both, static and dynamic fashions, consistent with >> the rest of the libraries. > > That is NOT a problem. That is just some mis-founded goal with no > basis of purpose. Well, than nothing is a problem. Which problem is FreeBSD's very existence trying to solve, huh? Why don't we all go and "get a life", instead of spending hours in front of the computers? Please... >> Because FreeBSD's base source already includes the libbfd source and >> builds the library during build. It just does not install it, for >> some reason. If all targets are enabled, this cross-toolchain ports >> would not even need their own versions of this libraries, most >> likely... > FEH!! You are going to patch the nightmare (yes I will use that term > to describe this) autoconf and autoMake bits that come with the GNU > tools? Good luck! In general with GNU tools, JUST LEAVE THINGS THE WAY > THE ORIGINAL AUTHOR INTENDED THEM TO BE. Yes, I very well might. Or, may be, I'll introduce Makefiles of my own -- Something already done for the C compiler and all the other GNU tools in the base, BTW. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Non 386 testers REALLY NEEDED
Apparently, On Wed, Feb 06, 2002 at 06:17:38PM -0500, Andrew Gallatin said words to the effect of; > > Andrew Gallatin writes: > > > > Since thread0 is no longer a pointer, this looks suspicious in locore.s: > > > > /* > > * Switch to proc0's PCB. > > */ > > ldq t0,thread0 /* get phys addr of pcb */ > > ldq a0,TD_MD_PCBPADDR(t0) > > SWITCH_CONTEXT > > Yeah.. that's it. I hacked around it by taking thread0's address in > machdep.c, shoving it into a global and using that global in locore.s > The resulting kernel booted. > > What's the "right" way to do this? I think you want lda, its used to load an address constant in support.s: lda t0, fusufault /* trap faults */ Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
It's an UP kernel running on an UP box. Eugene On Fri, Feb 08, 2002 at 04:53:28PM -0800, Julian Elischer wrote: > > > yes but is it a SMP or UP kernel? (SMP kernel can run on some UP h/w) > > thanks! > > > On Fri, 8 Feb 2002, Eugene M. Kim wrote: > > > On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: > > > > > > In your case we need totrace proc 1 I think.. > > > > > > > I got the `reboot' process at this session, so I traced that process. > > Before I had used `shutdown -r', which probably SIGINT'ed the init > > process so it's init (pid 1) calling reboot()... The attached log also > > has its trace JFYI. > > > > One more bit of info: as you see from the pcpu output, mine is not an > > SMP but an UP box. > > > > Thanks, > > Eugene > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On 6 Feb, David O'Brien wrote: > On Wed, Feb 06, 2002 at 03:46:22PM -0500, Mikhail Teterin wrote: >> > dynamically linked libiberty would be a nightmare. >> >> > libbfd and libiberty do not have version numbers, are not >> > maintained (i.e. there is no official releases). every project >> > includes its own libiberty and imho an attempt to find least common >> > denominator will fail >> >> Well, they come to FreeBSD as part of the binutils, right? > > NO! Is that a "NO!" as in "no, it does not come as part of the binutils", or is that a "NO!" as in "I'M NOT GOING TO AGREE WITH ANYTHING YOU SAY?" > Max told you what a nightmare it would be. He is 110% right. Max only objected to using dynamic versions of this two libraries, BTW. > PLEASE take some advice from two people that are experienced in the > issues. I'd like to take any advice, but it has to be founded. Plenty of pieces of the FreeBSD project are "a nightmare" -- including the binutils, and the compilers, and the whole Alpha port, to name a few -- if the postings to this mailing lists (including those from you) are any indication. Yet, we (including you) do them anyway, because they are worth it (for whatever reasons). I'm trying to persuade the audience, that installing the libbfd and libiberty (which we build anyway!) into /usr/lib is also worth the trouble, because it will help add new software through the ports system -- like the gcj-compiler, or different versions of GCC, etc. (With all available targets enabled, preferably.) I mean, I can add arm-aout or arm-elf binutils to the system through the devel ports, or mingw -- all with their own libbfd, but I don't have access to the native version, which is built as part of the base OS, just never installed? Is not this a bit ridiculous? -mi P.S. NetBSD installs shared libbfd: http://wuarchive.wustl.edu/systems/unix/NetBSD/NetBSD-release-1-5/src/gnu/lib/libbfd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bizzare problem..
On Tue, 5 Feb 2002, Jacob Frelinger wrote: > I have a new current system that is having the strangest problem. > using vi or its clones often abruptly powers the system down, no panics, > no syslog messages. the computer is an ABIT BP6 w/ 2 500 mhz cellerons > (NOT OVERCLOCKED), two harddrives, a cdrom drive and 256M ram. You aren't using a Linux version of vi, are you? It so happens a common freebsd system call maps to linux reboot() Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Current World stops at rcp.yppasswdd
World is breaking for me at: ===> usr.sbin/rpc.yppasswdd cc -nostdinc -O -pipe -I/usr/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/vipw -I/usr/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/ypserv -I/usr/src/usr.sbin/rpc.yppasswdd/../../libexec/ypxfr -I/usr/src/usr.sbin/rpc.yppasswdd/../../usr.bin/chpass -I/usr/src/usr.sbin/rpc.yppasswdd -I. -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/rpc.yppasswdd/pw_copy.c In file included from /usr/src/usr.sbin/rpc.yppasswdd/pw_copy.c:53: /usr/src/usr.sbin/rpc.yppasswdd/yppasswdd_extern.h:67: conflicting types for `pw_mkdb' /usr/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/vipw/pw_util.h:42: previous declaration of `pw_mkdb' *** Error code 1 Stop in /usr/src/usr.sbin/rpc.yppasswdd. *** Error code 1 Stop in /usr/src/usr.sbin. *** Error code 1 Thanks, ed --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cred stuff..
I'd like to commit the code to keep the ucred across userland,
with the code to clear it to NULL kept under DEBUG ifdefs.
i.e.
> in trap(), ast() and syscall()
>
> if (td->td_ucred != p->p_ucred) {
> PROC_LOCK(p);
> if (td->td_ucred) {
> crfree(td->td_ucred);
> td->td_ucred = NULL;
> }
> if (p->p_ucred != NULL) {
> td->td_ucred = crhold(p->p_ucred);
> }
> PROC_UNLOCK(p);
> }
and in userret() and ast()
>#ifdef DEBUG /*your choice of variable here*/
> PROC_LOCK(p);
> if (td->td_ucred) {
> crfree(td->td_ucred);
> td->td_ucred = NULL;
> }
> PROC_UNLOCK(p);
>#endif
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ucred for threads
On Fri, 8 Feb 2002, Bruce Evans wrote:
[...]
> >
> > if (td->td_ucred != p->p_ucred) {
> > PROC_LOCK(p);
> > if (td->td_ucred) {
> > crfree(td->td_ucred);
> > td->td_ucred = NULL;
> > }
> > if (p->p_ucred != NULL) {
> > td->td_ucred = crhold(p->p_ucred);
> > }
> > PROC_UNLOCK(p);
> > }
>
> I deleted too much of the followup to this, so I can't quote it.
>
> Races here could be reduced by putting some sort of synchronization
> instruction at the beginning. Then there would only be a race between
> executing the sync instruction and checking p_ucred. The race window
> could be very large if the process is preempted in between. But this
> race is obviously unavoidable in the current framework. You may end
> up with a slightly stale td_ucred, but this is insignificantly different
> from ending up with a slightly stale td_ucred when p_ucred changes
> just after you release the lock. Both can have almost any amount of
> staleness if processes can be preempted...
>
> Without the sync instruction, the race starts a little earlier, in
> userland. It's not so obvious that the effects of this race are not
> really different from the the effects of p_ucred changing after you
> release the lock, but I think they are. Terry argued this point from
> a different viewpoint.
That's my point. There is already an unavoidable (by us here) race on the
macro level between two threads of the same process. The micro race
introduced here is irrelevant in comparison, and if you solve the macro
race, the micro one is solved for free, so it's pointless trying to
protect against it here.
John would like to clear the ucred while the thread is in user space
just as a debug aid to help catch any bad uses (I guess during fast
interrupts or something), but that reason asside there is no reason to
do so, and a good reason to keep the ucreds.
>
> Bruce
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
can you try a kernel from JUST BEFORE I did the KSE commit yesterday? I heard someone else complain of thisyesterday afternoon. At that time I wascertain it was too soon after my commit for him to already have got it, but it would be nice tio know if I screwed something... On Fri, 8 Feb 2002, David Wolfskill wrote: > OK; I got today's -CURRENT built & running on each of my build > machine (freebeast) & my laptop. (Got today's -STABLE built > earlier; I mention this as a reference point/comparison. I > similarly note that I've been tracking each daily on each machine > for several months, and that today is the first time I've seen > this problem.) > > Anyway, the laptop seems fairly normal: I got -CURRENT built, booted > it up, ran a few things, used boot0cfg to switch to the slice with > today's -STABLE, and it came right down (gracefully) and back up again: > > g1-7(4.5-S)[1] uname -a > FreeBSD g1-7.catwhisker.org 4.5-STABLE FreeBSD 4.5-STABLE #74: Fri Feb 8 05:58:01 >PST 2002 [EMAIL PROTECTED]:/common/S1/obj/usr/src/sys/LAPTOP_30W i386 > g1-7(4.5-S)[2] > > > But on the build machine, I got it running -CURRENT, then did the > same procedure (boot0cfg & reboot), but on the (serial) console, I > see: > > > Feb 8 08:45:32 freebeast mountd[181]: bad exports list line /cdrom-ro >-alldirs > apache cvsupd > . > Additional TCP options:. > Starting background filesystem checks > > Fri Feb 8 08:45:34 PST 2002 > > FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) > > login: boot() called on cpu#0 > Waiting (max 60 seconds) for system process `vnlru' to stop...stopped > Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped > Waiting (max 60 seconds) for system process `syncer' to stop...stopped > > syncing disks... 15 15 > > > ...and it's been sitting like that for about half an hour. This is the > second time I've tried this with today's -CURRENT on the box; the > first time, it hung at "syncing disks... 7 7 " -- and I finally hit > the reset button. (I don't have a keyboard on the machine, though > I suppose I could try putting one on. Getting a (PC) monitor would > be a little harder, though, since the only one we have is on my > spouse's M$ machine, and the only spare monitor I have is a Sun-badged > Sony for the SPARCstation. > > One other thing: the machine is pingable: > bunrab(4.5-S)[1] ping freebeast > PING freebeast.catwhisker.org (172.16.8.10): 56 data bytes > 64 bytes from 172.16.8.10: icmp_seq=0 ttl=64 time=0.398 ms > 64 bytes from 172.16.8.10: icmp_seq=1 ttl=64 time=0.189 ms > ^C > --- freebeast.catwhisker.org ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.189/0.293/0.398/0.105 ms > bunrab(4.5-S)[2] > > So I'd guess that while things that require process creation are > unlikely to succeed, the network is still capable of (primitive) > functioning. > > I don't run much fancy stuff on the build machine -- Apache (so I can > easily use cvsweb locally); cvsupd (for internal use); sshd (so I can > login to the machine); that's about it. > > Is there a way to force the debugger from the serial console? > > About the only salient difference between the two machines that > occurs to me is that the laptop has a single CPU (750 MHz PIII), while > the build machine has a pair of them (2x866 MHz PIII). > > It's not a serious problem (in and of itself) for me at this time, but > it certainly appears broken, so I'd like to help fix it. (I've reduced > the list of likely candidate files that contributed to this down to 71 > via a quick, casual inspection. I don't want to spam the list any worse > than I already have, though) > > Thanks, > david > -- > David H. Wolfskill[EMAIL PROTECTED] > 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 [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Non 386 testers REALLY NEEDED
Ok so since I don't know alpha assembly. can it be changed to teh address of the thread0 structure? (I'll bet the same thing needs to be done on the other architectures) THANKS! On Wed, 6 Feb 2002, Andrew Gallatin wrote: > > Julian Elischer writes: > > > > 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. > > Today's alpha kernel, plus those changes results in a ksp not valid > halt with the PC near the beginning of mi_startup: > > /boot//kernel.bad/kernel data=0x4150c0+0x39360 > syms=[0x8+0x62e68+0x8+0x4a36d] > Entering /boot//kernel.bad/kernel at 0xfc33b680... > sio1: gdb debugging port > > halted CPU 0 > > halt code = 2 > kernel stack not valid halt > PC = fc47e80c > >>> > > > Since thread0 is no longer a pointer, this looks suspicious in locore.s: > > /* > * Switch to proc0's PCB. > */ > ldq t0,thread0 /* get phys addr of pcb */ > ldq a0,TD_MD_PCBPADDR(t0) > SWITCH_CONTEXT > > > > Drew > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ucred holding patch, BDE version
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 <[EMAIL PROTECTED]> [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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: bdwrite: buffer is not busy
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).
IdlePTD at phsyical address 0x004ed000
initial pcb at physical address 0x00411560
panicstr: bdwrite: buffer is not busy
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id =
fault virtual address = 0x1c
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc022d923
stack pointer = 0x10:0xce9c0b10
frame pointer = 0x10:0xce9c0b24
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 405 (fdisk)
trap number = 12
panic: page fault
cpuid = 1; lapic.id =
boot() called on cpu#1
syncing disks... panic: bdwrite: buffer is not busy
cpuid = 1; lapic.id =
boot() called on cpu#1
Uptime: 1m40s
pfs_vncache_unload(): 1 entries remaining
(kgdb) where
#0 dumpsys () at /ccd/src/sys/kern/kern_shutdown.c:504
#1 0xc021cee8 in boot (howto=260) at /ccd/src/sys/kern/kern_shutdown.c:336
#2 0xc021d3d9 in panic (fmt=0xc03728c1 "bdwrite: buffer is not busy")
at /ccd/src/sys/kern/kern_shutdown.c:646
#3 0xc0253583 in bdwrite (bp=0xc7cb7af4) at /ccd/src/sys/kern/vfs_bio.c:856
#4 0xc02d28ee in ffs_update (vp=0xce8657a0, waitfor=0)
at /ccd/src/sys/ufs/ffs/ffs_inode.c:120
#5 0xc02dff6e in ffs_fsync (ap=0xce9c09cc)
at /ccd/src/sys/ufs/ffs/ffs_vnops.c:292
#6 0xc02de386 in ffs_sync (mp=0xc16cbe00, waitfor=2, cred=0xc1026b00,
td=0xc03cf2c0) at vnode_if.h:441
#7 0xc026034a in sync (td=0xc03cf2c0, uap=0x0)
at /ccd/src/sys/kern/vfs_syscalls.c:669
#8 0xc021cb14 in boot (howto=256) at /ccd/src/sys/kern/kern_shutdown.c:245
#9 0xc021d3d9 in panic (fmt=0xc03914de "%s")
at /ccd/src/sys/kern/kern_shutdown.c:646
#10 0xc03299e2 in trap_fatal (frame=0xce9c0ad0, eva=28)
at /ccd/src/sys/i386/i386/trap.c:842
#11 0xc0329709 in trap_pfault (frame=0xce9c0ad0, usermode=0, eva=28)
at /ccd/src/sys/i386/i386/trap.c:756
#12 0xc0329147 in trap (frame={tf_fs = 24, tf_es = -828637168,
tf_ds = -1071513584, tf_edi = -1049875456, tf_esi = 0,
tf_ebp = -828634332, tf_isp = -828634372, tf_ebx = -942596204,
(kgdb) where
#0 dumpsys () at /ccd/src/sys/kern/kern_shutdown.c:504
#1 0xc021cee8 in boot (howto=260) at /ccd/src/sys/kern/kern_shutdown.c:336
#2 0xc021d3d9 in panic (fmt=0xc03728c1 "bdwrite: buffer is not busy")
at /ccd/src/sys/kern/kern_shutdown.c:646
#3 0xc0253583 in bdwrite (bp=0xc7cb7af4) at /ccd/src/sys/kern/vfs_bio.c:856
#4 0xc02d28ee in ffs_update (vp=0xce8657a0, waitfor=0)
at /ccd/src/sys/ufs/ffs/ffs_inode.c:120
#5 0xc02dff6e in ffs_fsync (ap=0xce9c09cc)
at /ccd/src/sys/ufs/ffs/ffs_vnops.c:292
#6 0xc02de386 in ffs_sync (mp=0xc16cbe00, waitfor=2, cred=0xc1026b00,
td=0xc03cf2c0) at vnode_if.h:441
#7 0xc026034a in sync (td=0xc03cf2c0, uap=0x0)
at /ccd/src/sys/kern/vfs_syscalls.c:669
#8 0xc021cb14 in boot (howto=256) at /ccd/src/sys/kern/kern_shutdown.c:245
#9 0xc021d3d9 in panic (fmt=0xc03914de "%s")
at /ccd/src/sys/kern/kern_shutdown.c:646
#10 0xc03299e2 in trap_fatal (frame=0xce9c0ad0, eva=28)
at /ccd/src/sys/i386/i386/trap.c:842
#11 0xc0329709 in trap_pfault (frame=0xce9c0ad0, usermode=0, eva=28)
at /ccd/src/sys/i386/i386/trap.c:756
#12 0xc0329147 in trap (frame={tf_fs = 24, tf_es = -828637168,
tf_ds = -1071513584, tf_edi = -1049875456, tf_esi = 0,
tf_ebp = -828634332, tf_isp = -828634372, tf_ebx = -942596204,
tf_esp = -942596204, tf_ss = -1049268480})
at /ccd/src/sys/i386/i386/trap.c:426
#13 0xc022d923 in readdisklabel (dev=0xc1756f00, lp=0xc16c2c00)
at /ccd/src/sys/kern/subr_disklabel.c:220
#14 0xc0338c61 in fdioctl (dev=0xc1756e00, cmd=1091855461, addr=0xc16bb200 "",
flag=1, td=0xce8daf04) at /ccd/src/sys/isa/fd.c:2707
#15 0xc01f4d1c in spec_ioctl (ap=0xce9c0ba4)
at /ccd/src/sys/fs/specfs/spec_vnops.c:320
#16 0xc01f499d in spec_vnoperate (ap=0xce9c0ba4)
at /ccd/src/sys/fs/specfs/spec_vnops.c:119
#17 0xc0266fb3 in vn_ioctl (fp=0xc1854bc0, com=1091855461, data=0xc16bb200 "",
td=0xce8daf04) at vnode_if.h:357
#18 0xc0237eeb in ioctl (td=0xce8daf04, uap=0xce9c0d20)
at /ccd/src/sys/sys/file.h:200
#19 0xc0329e98 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077936865, tf_esi = -1077937104, tf_ebp = -1077937112,
tf_isp = -828633740, tf_ebx = -1077937100, tf_edx = -1077936866,
tf_ecx = 134627389, tf_eax = 54, tf_trapno = 12, tf_err = 2,
tf_eip = 134546567, tf_cs = 31, tf_eflags = 659, tf_esp = -1077937504,
tf_ss = 47}) at /ccd/src/sys/i386/i386/trap.c:1034
#20 0xc031945d in syscall_with_err_pushed ()
(kgdb) up 3
#3 0xc0253583 in bdwrite (bp=0xc7cb7af4) at /ccd/src/sys/kern/vfs_bio.c:856
856
Re: anon ftp access at current
On Sat, 09 Feb 2002 10:54:06 -0800 Jason Nordwick <[EMAIL PROTECTED]> wrote: > > I am trying to install one of the -current snapshots, but > current.freebsd.org doesn't seem to want to let me log in as anonymous > (some problem saying it cannot set guest access). Has the procedure > changed to get -current? I believe current.FreeBSD.org is in the process of being upgraded. Meanwhile, you could either CVSup from some of your local CVSup servers (if you already have some FreeBSD version installed) or download a snapshot from snapshots.jp.FreeBSD.org. > > thanks > -j > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: cred stuff..
On 09-Feb-02 Julian Elischer wrote: > I'm a little worried about invariants because the behaviour when > INVARIANTS is set wil be different to teh behaviour when it is off, which > is 'strange' to say the least. Normally the behaviour si the same but you > just check for invariant conditions. In this case it is providing the support for the implicit KASSERT(td_ucred != NULL)) everyhwere that td_ucred is used. :) If it makes you feel better, put it under INVARIANT_SUPPORT. It is the same type of test though, as it is a way of asserting that we aren't using td_ucred when a thread isn't in the kernel. > On Fri, 8 Feb 2002, John Baldwin wrote: > >> >> On 08-Feb-02 Julian Elischer wrote: >> > >> > I'd like to commit the code to keep the ucred across userland, >> > with the code to clear it to NULL kept under DEBUG ifdefs. >> >> Use INVARIANTS for the ifdef macro name, but sure. >> >> -- >> >> John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ >> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ >> > -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
On 09-Feb-02 Eugene M. Kim wrote: > I'm not particularly good at reading the lock-related output, but it > doesn't have other lines than the one that says about the Giant lock, so > it seems there isn't any other locks being held by anyone. show locks only shows the locks held by a single thread. Trying to show all locks in the system would be a bit more work. You would basically need to add a new DDB command that walked the allproc list doing a show locks on each thread. show witness really isn't useful in most cases unless you are working on witness itself. It merely shows the tree of lock order relationships. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
In your case we need totrace proc 1 I think.. On Fri, 8 Feb 2002, Eugene M. Kim wrote: > Attached is the requested DDB log (I guessed pid 7 `syncer' is the > process doing the sync; if this is wrong let me know). > > Eugene > > PS. I used the serial console, so don't feel sorry to ask. =) > > On Fri, Feb 08, 2002 at 02:41:30PM -0800, Julian Elischer wrote: > > > > > > > > > > On Fri, 8 Feb 2002, Eugene M. Kim wrote: > > > > > On Fri, Feb 08, 2002 at 01:43:54PM -0800, Julian Elischer wrote: > > > > > > > > On Fri, 8 Feb 2002, David Wolfskill wrote: > > > > > > > > > > Waiting (max 60 seconds) for system process `vnlru' to stop...stopped > > > > > Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped > > > > > Waiting (max 60 seconds) for system process `syncer' to stop...stopped > > > > > > > > > > syncing disks... 7 7 > > > > > > > > can you hit and get into the debugger? > > > > > > My box shows the same symptom, and yes I can enter DDB. How may I help? > > > > > > Eugene > > > > > > > "show locks" whould be good. > > also 'ps' > > and the stack trace of the process doing the sync... > > > > > > tr > > > > if you can get a serial console that would be best of course. > > > > you may wait a while to see if dave can get into ddb on his serial > > console. > > that may save you a lot of writing :-) > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
> > Eh; I suspect that's showing the entry to ddb. > > Hmmm... gow about: > > db> show witness > Sleep locks: > 0 Giant -- last acquired @ /usr/src/sys/kern/kern_intr.c:532 > 1 eventhandler -- last acquired @ /usr/src/sys/kern/subr_eventhandler.c:162 > 3lockmgr -- last acquired @ /usr/src/sys/kern/kern_lock.c:227 > 4 malloc -- last acquired @ /usr/src/sys/kern/kern_malloc.c:303 > 5 zone -- last acquired @ /usr/src/sys/vm/vm_zone.c:506 > 1 pbuf mutex -- last acquired @ /usr/src/sys/vm/vm_pager.c:466 > 6 ucred -- last acquired @ /usr/src/sys/kern/kern_prot.c:1601 > 1 sf_bufs list lock -- last acquired @ /usr/src/sys/kern/uipc_syscalls.c:1556 > 4 malloc -- last acquired @ /usr/src/sys/kern/kern_malloc.c:303 > 3lockmgr -- last acquired @ /usr/src/sys/kern/kern_lock.c:227 Looking at the ps I can't even see the process doing the exit.. it may be proc 0 or proc 1 can you trace them? also show pcpu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
david,
On Fri, 8 Feb 2002, Julian Elischer wrote:
> cool..
> ok, how about adding "show witness"
[...]
can you do a cvs diff -D{time1] -D[time2] /sys
where time2 is the earliest kernel that has the problem and time1 is the
last kernel that doesn't?
there may be some other diffs in there I'm not aware of..
I want to check it against my diff as I believe I committed it.
(there could be someone else's commit in there too)
julian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Non 386 testers REALLY NEEDED
On Wed, Feb 06, 2002 at 12:32:18PM -0800, Alfred Perlstein wrote: > * Julian Elischer <[EMAIL PROTECTED]> [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. :-) C'mon guys: it is not so long ago (days..) that the Alpha started buildworlding -current again. Alpha builds tend to take much longer (on most people's hardware that is) so a bit of patience would be nice. FWIW: I'm trying to get 2 of my Alphas to go to -current again. W/ -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc3.x issues
hi, there! On Wed, Feb 06, 2002 at 05:47:07PM -0800, Joe Kelsey wrote: > So what? Just because it wasn't part of 4.2 BSD, does that mean that we > should never support it? > > > 2. What is so hard with installing the port. No one has answered *THAT* > > question yet. > > Ports are installed in /usr/local. gcc is installed in /usr. Either > provide a way to install *all* of gcc as part of the system, or provide > a *suppported* way to *replace* it with a port. I do not want to have > two versions of gcc fighting for disk space and confusing users over > PATH issues. please calm down. seems that you have never installed gcc from ports. gcc 2.95 from ports is installed as gcc295/g++295 and correctly gets its bits from /usr/local/lib/gcc-lib/xxx, gcc 3.0x from ports is named gcc30/g++30 and so on. There is no PATH issue. Switching between compilers is as easy as setting correct CC/CXX environment/Makefile variables. argument about disk space sounds a bit funny these days. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
>Date: Fri, 8 Feb 2002 10:54:55 -0800 (PST) >From: Julian Elischer <[EMAIL PROTECTED]> >can you try a kernel from JUST BEFORE I did the KSE commit yesterday? OK; results below >I heard someone else complain of thisyesterday afternoon. At that time I >wascertain it was too soon after my commit for him to already have got it, >but it would be nice tio know if I screwed something... >Date: Fri, 8 Feb 2002 11:29:51 -0800 (PST) >From: Julian Elischer <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: reboot and sync behaviour. >This succeeded, but looks suspicious to me. >syncing disks... 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 >I've never seen it like that before.. >It might be related to the problem some have seen with syncing.. I was able to build a kernel from just prior to the "Pre-KSE/M3" commit (http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1278231+0+current/cvs-all); it did not exhibit the problem. I then updated the sources to just after that commit, booted, then on the reboot (while running this new kernel), I get the hang again: Additional TCP options:. Starting background filesystem checks Fri Feb 8 13:22:59 PST 2002 FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) login: boot() called on cpu#0 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 7 7 So, yes, Julian, I think there's something not quite right there. How can I help debug this? Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc3.x issues
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. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On 6 Feb, David O'Brien wrote: > Yes it comes as part of binutils. Ok. > No we should not go down this path. You've already been told that > there is no official libiberty or bfd release. Well, the following URL http://www.gnu.org/manual/bfd-2.9.1/ for example, seems to imply, that there was, in fact, at some point a release 2.9.1 of bfd... It does not quite match the bfd, that's part of -current -- because of your work on bringing the binutils-3.x in. So there is _something_... > Every software package that needs either comes with its own copy -- > that always has bug fixes or minor changes from all the other copies > out there. Well, that would be a porter's job to figure out which changes the package relies on, or which it simply did not bother to sync with the bfd, that comes with binutils. Plenty of packages come bundled with the third-party software, and a good port makes them build with the already installed versions of such software (like zlib, OpenSSL) or with the version available from another port (like c-client). >> I'd like to take any advice, but it has to be founded. Plenty of >> pieces of the FreeBSD project are "a nightmare" -- including the >> binutils, > > Why is binutils a nightmare?? I don't find it to be one. You edited out the rest from my list of examples. Ok. You did want to drop Alpha, because supporting the compiler on it seemed too difficult at some point -- how is that for an example? Or do you claim the proposed addition is the most nightmarish of them all? > HOW will it help to add software? What is so wrong with compiling the > bundled libiberty or bfd that comes with each of the "new software" > when building them? What is so wrong with having libiberty or bfd > statically linked into the "new software"? It is _inelegant_ and is inconsistent with our use of shared libraries for most of the rest of the system. Look, we wanted ssh and we added it. It requires OpenSSL and we added it. Do we link OpenSSL staticly into ssh and/or not install -lssl into /usr/lib? > I frankly just don't see what "problem" it is you are trying to solve. I want libbfd (and libiberty) to be installed as part of the OS. Preferably -- in both, static and dynamic fashions, consistent with the rest of the libraries. >> I mean, I can add arm-aout or arm-elf binutils to the system through >> the devel ports, or mingw -- all with their own libbfd, but I don't >> have access to the native version, which is built as part of the base >> OS, just never installed? Is not this a bit ridiculous? > Why is it ridiculous? Because FreeBSD's base source already includes the libbfd source and builds the library during build. It just does not install it, for some reason. If all targets are enabled, this cross-toolchain ports would not even need their own versions of this libraries, most likely... > Personally I don't think a cross-toolchain build should be installing > those bits. And in my opinion, they should not even be building those bits for themselves. I mean, I would've come up with a port of this libraries, but it just seems silly to port something, that's already in the base system. >> P.S. NetBSD installs shared libbfd: >> >http://wuarchive.wustl.edu/systems/unix/NetBSD/NetBSD-release-1-5/src/gnu/lib/libbfd/ > > Of the two -- bfd and libiberty, bfd is the one we would have the most > success at installing as a shared lib in /usr/lib. Alright! One step at a time... I understand, that this is an additional burden for you as Mr. Binutils, but let's admit, this might be useful and move it from "NO!" to "May be, some day, when someone does the work." Yours, -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
cool.. ok, how about adding "show witness" (we need to figure out which process SHOULD be doing the reboot, but it's not obvious from this ps, which one we should be looking at.) if you have it compiled in, show ktr (a couple of pages of it anyhow) MIGHT show something. On Fri, 8 Feb 2002, Eugene M. Kim wrote: > Attached is the requested DDB log (I guessed pid 7 `syncer' is the > process doing the sync; if this is wrong let me know). > > Eugene > > PS. I used the serial console, so don't feel sorry to ask. =) > > On Fri, Feb 08, 2002 at 02:41:30PM -0800, Julian Elischer wrote: > > > > > > > > > > On Fri, 8 Feb 2002, Eugene M. Kim wrote: > > > > > On Fri, Feb 08, 2002 at 01:43:54PM -0800, Julian Elischer wrote: > > > > > > > > On Fri, 8 Feb 2002, David Wolfskill wrote: > > > > > > > > > > Waiting (max 60 seconds) for system process `vnlru' to stop...stopped > > > > > Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped > > > > > Waiting (max 60 seconds) for system process `syncer' to stop...stopped > > > > > > > > > > syncing disks... 7 7 > > > > > > > > can you hit and get into the debugger? > > > > > > My box shows the same symptom, and yes I can enter DDB. How may I help? > > > > > > Eugene > > > > > > > "show locks" whould be good. > > also 'ps' > > and the stack trace of the process doing the sync... > > > > > > tr > > > > if you can get a serial console that would be best of course. > > > > you may wait a while to see if dave can get into ddb on his serial > > console. > > that may save you a lot of writing :-) > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc3.x issues
Joe Kelsey wrote: > David O'Brien writes: > > 3. Are you going to maintain them? If we did do this work and allowed > > people to optinally install gjc and Ada, I bet only 5% would do so > > (other than the initial turning it on just to see what the compilers > > looked like). > > 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. 1: Are you going to provide the Makefile glue to do this? If not, then shut the hell up. 2: We need to get a *basic* compiler up and running first. Give David a break, ok? There are far bigger problems to deal with first before futzing around on obscure languages that we have no critical need for in the base system. We ***NEED*** the ability to compile basic C code for the sparc64, ia64 and x86-64 platforms. Until that is dealt with, the rest is a luxury. 3: Once we have the basics running, *then* maybe we can talk about compile knobs. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
