re useful use of
your time would be to actually describe the problems you have so they can be
addressed. What Unix command doesn't have idiosyncratic syntax anyways?
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to
x27;s the diff?
>>
>> I'd like to preempt the ensuing bikeshed by voting for green.
>
> I'd like to accept your nomination. People, I know you won't regret
> choosing the right person for the job!
So I can cut you up into little places, grind those up in a blender
t;cc" clobbers from the patch now. Any objections to it
now? It's still at ~jhb/patches/i386_asm.patch.
--
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
there are other problems further down in the
> buildworld (mine is still working)
You should only have to include (it includes
already), but that patch looks ok. libkvm will need the same fix. My bad, I
was so busy testing kernels and making sure they worked in various combinations
I didn't
gt; user mode is broken.
That would panic in that case, yes. For now that KASSERT() can just be
commented out until I figure out how to make that a more proper assert.
> Bruce
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the P
sts in this
> file didn't cause problems.
It depends on what the functions do. If they are written in asm, they might be
preserving temporary registers rather than trashing them. I was just changing
the clobbers to assume that only call-safe registers were preserved.
>> -__as
On 13-Dec-01 John Baldwin wrote:
>>> static void
>>> do_cpuid(u_int ax, u_int *p)
>>> {
>>> +
>>> +p[0] = ax;
>>> __asm __volatile(
>>> "cpuid"
>>> -: "=a" (p[0]), "=b"
e WARNS=0 or some such in your build. Or NO_WERROR=yes.
--
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
On 14-Dec-01 David Xu wrote:
> I persist with adding "cc", because it does not hurt anything.
It doesn't do anything either except add repo bloat and obfuscate the code a
bit more.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
&q
_warn
>
> .. initialize the key with opiepasswd
>
> .. use telnet -K to prevent automatic (SRA) login
>
> (Well, my system is probably one month old. If something has been
> broken afterwards, forget the above.)
A note in UPDATING about using opie rather than s
On 17-Dec-01 Warner Losh wrote:
> In message <[EMAIL PROTECTED]> John Baldwin writes:
>: > No problem for me.
>: >
>: > .. enable it in /etc/pam.conf:
>: > login authsufficient pam_opie.so no_warn
>: >
>: > .. initialize the key w
On 18-Dec-01 Ruslan Ermilov wrote:
> Soren!
>
> I bet someone else already mentioned your commit broke Alpha kernels.
Søren didn't commit this, adn there has already been a discussion on this list
about it as it broke all non-i386 kernels.
--
John Baldwin <[EMAIL PROTE
he child before they get the pid back and thus that the pid
should be ignored.
Note that neither fork() nor vfork() can end up in this case. Only a masochist
using rfork() and asking for this case will get it.
--
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
On 19-Dec-01 John Baldwin wrote:
>> It may be that due to some semantics of teh fork calls
>> you cannot have P_PPWAIT and a process queued to run on the other
>> processor while reparented to init(1) but I can't see it..
>> the result would be that the return v
gt; That's not possible, since the parent is waiting the kernel will
> not reparent unless the parent exits, which it doesn't because it's
> waiting for the child.
>
> You owe the Oracle a large bong rip.
Look at RFNOWAIT silly. It forces a parent to init during fork1
ug so I'm comitting it to -current now,
> the question is: Is it the *only* bug?
>
> -Matt
Hmm, why bzero at all if you are just going to free it? Why not move the bzero
to an else after the ISDYNSTRUCT check? (Not that thi
ree it? Why not move the
>:bzero
>:to an else after the ISDYNSTRUCT check? (Not that this is really all that
>:important, but... :)
>:
>:--
>:
>:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
>
> He is invalidating the st
he min(nativepri, highest priority of threads on contested locks
we hold and drop to nativepri after dropping the last contested lock).
However, kthreads should tsleep() with their current priority, not PPAUSE.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb
On 20-Dec-01 Luigi Rizzo wrote:
> On Thu, Dec 20, 2001 at 12:16:03PM -0800, John Baldwin wrote:
> ...
>> Priority propagation will already handle things ok. We drop to pri_native
>> after we drop a lock (although if we still hold a contested lock we bump our
>> prior
consider a thread of one priority class
blocking on a lock held by a thread of a "lower" priority class as you only
have to update pri_level for priority propagation rather than comparing classes
and having to manage that extra gunk.
--
John Baldwin <[EMAIL PROTECTED]> <>
to work with /dev/ums0.
--
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
n. It was right in 4.1 or so, but some nameless
sheep-lover hosed the wording of the question. I fixed it in -current and
should backport it.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeB
you don't have
your loader and 4th scripts out of sync?
--
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
me sort of delay in exit() on
i386 might not be that bad of an idea.
> On Mon, 31 Dec 2001, John Baldwin wrote:
>
>>
>> On 31-Dec-01 Julian Elischer wrote:
>> > I upgraded by cvs on saturday night,
>> > Sunday I didn't use it.
>> > Monday I tr
is is normal. config isn't supposed to warn you about such things.
> -mi
--
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]
w
, the console output is being
> sent down sio0, where there is an external modem now. Turning the modem
> off does not change anything...
No, you have no console because you have no hints. If you statically compile
your hints into your kernel, you will have a console again.
--
On 04-Jan-02 Mikhail Teterin wrote:
> On 3 Jan, John Baldwin wrote:
>>
>> On 04-Jan-02 Mikhail Teterin wrote:
>>> After 25 days of uptime I rebuilt the world, and can no longer boot
>>> as usual. Both boot/loader and boot/loader.old (from Oct 30)
On 04-Jan-02 Michael D. Harnois wrote:
> mergemaster does not pick up changes to the /etc/pam.d directory. Is
> this a feature?
I don't think pam.d is installed right now by default. Once it is turned on by
default I think mergemaster will DTRT.
--
John Baldwin <[E
7;t been for quite some time. Direct booting works great if you
compiler your hints using "hints foo.hints" in your kernel config file.
--
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
On 05-Jan-02 Michael Harnois wrote:
>> I don't think pam.d is installed right now by default.
>
> Hmm. I'm not sure how it got installed on my system at all, then ...
mtree creates the directory but the current makefiles don't install anything
in the directory.
On 07-Jan-02 Andrey A. Chernov wrote:
> On Fri, Jan 04, 2002 at 17:12:56 -0800, John Baldwin wrote:
>>
>> On 05-Jan-02 Michael Harnois wrote:
>> >> I don't think pam.d is installed right now by default.
>> >
>> > Hmm. I'm not sure how it g
d INVARIANTS et al back on. I now have other problems, but I'll report
> them when I've done some more testing...
You must have cvsup'd at a bad time. I removed SWI_NOSWITCH from cam and
everywhere else in one big commit Friday or Saturday.
--
John Baldwin <[EMAIL PROTECTE
ell on my box with kern.giant.proc
> set to zero for more than a month. Could anyone interested please test
> the patch?
>
> Comments and suggestions are welcome.
Yes, I will test it. Sorry I haven't gotten back to you sooner on this.
--
John Baldwin <[EMAIL PROTECTED]> <>&
on this line:
>
> uid = p->p_cred->pc_ucred->cr_uid;
>
> So, my question: how does one obtain the UID from the proc struct in
> CURRENT? Preferably in a way that will both work on CURRENT and STABLE.
p->p_ucred->cr_uid right now, but it will change before too long
t; Seigo Tanimura has a patch for this, just remove the extranious
> FILEDESC_UNLOCK from the bottom of the unp_externalize function.
You could commit it then if it fixes a bug. :)
> -Alfred
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Powe
type sudo it says, after getting my
> password:
> sudo: pam_setcred: Permission denied.
> It also whines on the console if I remove /etc/pam.conf.
>
> Ideas? This is from Saturday's current at about 4am MST.
Do you have a /etc/pam.d/other?
> Warner
--
John Bal
> the kernel.
That wasn't his real panic. If you read teh whole log, a vrele() called from
fdrop_locked() did a vput(0x0), i.e. vput(NULL) which resulted in a page fault
panic.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power User
On 14-Jan-02 M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> John Baldwin <[EMAIL PROTECTED]> writes:
>:
>: On 14-Jan-02 M. Warner Losh wrote:
>: > OK. I did a make buildworld/installworld. I did a mergemaster and
>: > made sure that /
= resume, IOPL = 0
> current process = 178 (rpcbind)
> kernel: type 12 trap, code = 0
> stopped at _mtx_unlock_sleep+0x9f : cmpl $0,0x28(%ebx)
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
1221c8,bfbfd550,2328) at recvmsg+0xdb
> syscall(2f,2f,2f,2328,bfbfd550) at syscall+0x2d4
> syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
> --- syscall(27, FreeBSD ELF, recvmsg), eip=0x280c0657, esp=0xbfbfd500,
> ebp=0xbfb
> fd5cc ---
--
John Baldwin <[EMAIL PROTECTED]&
escrip.c:925
> 2nd 0xc0419b00 Giant @ /usr/src/sys/kern/kern_descrip.c:959
This one is due to not releasing the filedesc lock when grabbing Giant to free
oldofile in fdalloc().
> The panics moan about a kernel trap and some mutex stuff involving
> Giant. It only happens when I start Samb
On 16-Jan-02 David Wolfskill wrote:
> So... is this worth pursuing a bit more?
Two questions:
1) Do you have WITNESS on in your kernel config?
2) If yes, have you tried building with a kernel without witness?
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBS
On 16-Jan-02 David Wolfskill wrote:
>>Date: Tue, 15 Jan 2002 16:46:17 -0800 (PST)
>>From: John Baldwin <[EMAIL PROTECTED]>
>
>>On 16-Jan-02 David Wolfskill wrote:
>>> So... is this worth pursuing a bit more?
>
>>Two questions:
>
>>1) Do y
On 16-Jan-02 Emiel Kollof wrote:
> * John Baldwin ([EMAIL PROTECTED]) wrote:
>>
>> > lock order reversal 1st 0xc185e934 filedesc structure @
>> > /usr/src/sys/kern/kern_descrip.c:925
>> > 2nd 0xc0419b00 Giant @ /usr/src/sys/kern/kern_descrip.c:959
>>
On 17-Jan-02 Mike Brancato wrote:
> Just leting you guys know that the Jan 15th and Jan 16th boot floppies
> aren't working. the Jan 13th snaps are though.
How do they not work? We can't fix anything if you don't tell us what is
wrong. :)
> mike
--
John B
ate its own boot.catalog. If you do that instead of
creating one yourself does it work any better? If not, then you can revert the
revisions that turned off all the debugging output, hook up a serial console on
COM1, and prepare to be spammed with lots of debug output. :)
--
John Baldwin <[E
ing to be based on a preemptible kernel?
>
> Can't answer the gcc question, but yes, John Baldwin currently has support
> for preemption in his SMPng development tree.
The kernel is already somewhat preemptive. The kernel in 5.0 will certainly be
preemptible, as making a kernel
On 05-Feb-02 Michael Reifenberger wrote:
> On Mon, 4 Feb 2002, John Baldwin wrote:
>
>> Date: Mon, 04 Feb 2002 18:47:25 -0500 (EST)
>> From: John Baldwin <[EMAIL PROTECTED]>
>> To: Michael Reifenberger <[EMAIL PROTECTED]>
>> Cc: FreeBSD-Current
turn it off in GENERIC now (I
wouldn't mind if someone else did that.) Before major locking changes people
should still use it to look for bugs, but it isn't very efficient I'm afraid. :(
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org
On 06-Feb-02 Michael Reifenberger wrote:
> On Tue, 5 Feb 2002, John Baldwin wrote:
> ...
>> > Its the loader after showing:
>> > ...
>> > loader Revision...
>> > (root@nihil, ...)
>> > ...
>> > And then a few rotating -\|/ (serching or
On 06-Feb-02 David O'Brien wrote:
> On Wed, Feb 06, 2002 at 01:02:34AM -0500, John Baldwin wrote:
>> WITNESS can really hurt. Quite possibly I should turn it off in
>> GENERIC now (I wouldn't mind if someone else did that.)
>
> I think it should stay. Especi
ore.s
> The resulting kernel booted.
>
> What's the "right" way to do this?
lda t0,thread0 maybe?
> Drew
--
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
On 07-Feb-02 Georg-W Koltermann wrote:
> At Wed, 06 Feb 2002 23:33:14 -0500 (EST),
> John Baldwin wrote:
>>
>> [...]
>> I guess. Note that you can use a loader tunable 'debug.witness_watch' to
>> turn
>> witness off from the loader. If it&#x
crfree's isn't bad I guess. However, the
td_ucred pointer should nto be read if the thread is not in the kernel, and
having it set to NULL when we leave the kernel provides a conveninet way of
ensuring this doesn't happen since we will panic if we do.
--
John Baldwin <[EMAIL PRO
of race conditions involving credentials. If in the future it is
deemed that getting a stale cred is an acceptable race, then this can be
optimized then, but for now we had better get it right.
FreeBSD doesn't run on just the i386 anymore, we have Alpha, ia64, and sparc64
SMP machines to de
6,
> tf_ebx = 264, tf_edx = 980, tf_ecx = 6930, tf_eax = 0, tf_trapno = 12,
> tf_err = 4, tf_eip = 4773, tf_cs = 49152,
> tf_eflags = 721478, tf_esp = 4000, tf_ss = 0}) at
> /usr/src/sys/i386/i386/trap.c:426
> #13 0x12a5 in ?? ()
> Cannot access memory at address 0
On 08-Feb-02 Terry Lambert wrote:
> John Baldwin wrote:
>> No, an unlocked compare is _not_ ok. What if the p_ucred pointer was
>> changed
>> on some other processor by another thread from this processor?
>
> I saw your response to Julian... I understand the
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]> <><
_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
lf. 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
ing 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
ehaviour 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
r 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.
>> > &g
\
if ((!(bp)->bio_cmd) || ((bp)->bio_cmd & ((bp)->bio_cmd - 1))) \
Debugger("bio_cmd botch"); \
(*devsw((bp)->bio_dev)->d_strategy)(bp);
d. 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 res
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
7;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!"
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 ne
On 05-Feb-02 Michael Reifenberger wrote:
> On Mon, 4 Feb 2002, John Baldwin wrote:
>
>> Date: Mon, 04 Feb 2002 18:47:25 -0500 (EST)
>> From: John Baldwin <[EMAIL PROTECTED]>
>> To: Michael Reifenberger <[EMAIL PROTECTED]>
>> Cc: FreeBSD-Current
crfree's isn't bad I guess. However, the
td_ucred pointer should nto be read if the thread is not in the kernel, and
having it set to NULL when we leave the kernel provides a conveninet way of
ensuring this doesn't happen since we will panic if we do.
--
John Baldwin <[EMAIL PRO
On 07-Feb-02 Georg-W Koltermann wrote:
> At Wed, 06 Feb 2002 23:33:14 -0500 (EST),
> John Baldwin wrote:
>>
>> [...]
>> I guess. Note that you can use a loader tunable 'debug.witness_watch' to
>> turn
>> witness off from the loader. If it&#x
6,
> tf_ebx = 264, tf_edx = 980, tf_ecx = 6930, tf_eax = 0, tf_trapno = 12,
> tf_err = 4, tf_eip = 4773, tf_cs = 49152,
> tf_eflags = 721478, tf_esp = 4000, tf_ss = 0}) at
> /usr/src/sys/i386/i386/trap.c:426
> #13 0x12a5 in ?? ()
> Cannot access memory at address 0
On 06-Feb-02 Michael Reifenberger wrote:
> On Tue, 5 Feb 2002, John Baldwin wrote:
> ...
>> > Its the loader after showing:
>> > ...
>> > loader Revision...
>> > (root@nihil, ...)
>> > ...
>> > And then a few rotating -\|/ (serching or
On 08-Feb-02 Terry Lambert wrote:
> John Baldwin wrote:
>> No, an unlocked compare is _not_ ok. What if the p_ucred pointer was
>> changed
>> on some other processor by another thread from this processor?
>
> I saw your response to Julian... I understand the
lf. 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
ing 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
_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
d. 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 res
7;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!"
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]> <&
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 fre
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 ver
looks like you have a typo :-P) isn't stale and that your
increment isn't corrupting something? Esp. since you are using atomic ops that
means your increment might corrupt somethign long enough to become visible to
another CPU and really hose things.
There is a race condition in between that plusplus and minusminus (albeit a
small one) that is just _begging_ for a kernel panic.
> -- 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
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 i
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.
--
Jo
atches, especially tty.
I've looked over other versions of this patch and am happy with them, so I have
no objections. :)
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To
if (i++ < 6000)
This is more a specific problem with Giant and I don't think it will be a
problem with other mutexes, so I'd prefer a solution not quite so tailored to
this particular behavior of Giant.
--
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
el. If we get preempted who cares. We will still be teh same thread when
we continue executing. :)
--
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
soon so you are better off avoiding the context
switch) and block if it is not executing on another CPU (releasing the lock is
already at least one context switch away, so we might as well switch).
> Greg
> --
> See complete headers for address and phone numbers
>
> To Unsubscribe:
>:+#endif
>: if (i++ < 1000)
>:continue;
>:if (i++ < 6000)
>:
>:This is more a specific problem with Giant and I don't think it will be a
>:problem with other mutexes, so I&#x
> Later,
> George
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - ht
of hurting freefall with the extra load.
You are asking for people to do more than they have done before and blaming
their not doing it on the tools they are using.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!&
aving to pass diffs
around. Basically, I don't think p4 was designed for people passing diffs
around, folks are supposed to instead be looking at each others branches.
However, that's not the way FreeBSD works atm (esp. since CVS is our real SCM),
so we end up using p4 in possibly one of
f"
font_type="figlet_font"
The patch includes a sample SYSINIT at the bottom of subr_figlet.c that
demonstrates sending commands to the filter.
So who's going to do subr_jive.c next? :)
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"
uot; execution:
Sort of. The problem is we have added a new user that installworld depends on.
Imagine a 4.x to 5.0 upgrade right now. 4.x doesn't have this user IIRC, and
you are supposed to run installworld before mergemaster. Sounds like a nice
catch 22 to me. :-/
--
John Baldwin &
kage). When I say severe I mean make buildworld takes x3 longer.
Hmm, Feb 3-5 (looks).
You mean the preemptive scheduling committed on Feb 1? Can you try updating
to early this week to see if it goes away?
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http
hed_lock. Hmm...
Got a backtrace? What is really annoying is that preemption has been in the
kernel since Feb 1. I just accidentally turned it off in the ithread code
reorganization and then turned it back on. It was off for a few hours after
only being on for 2 weeks, and now everyone magica
On 22-Feb-01 Maxim Sobolev wrote:
> John Baldwin wrote:
>
>> On 22-Feb-01 Maxim Sobolev wrote:
>> > Dag-Erling Smorgrav wrote:
>> >
>> >> Maxim Sobolev <[EMAIL PROTECTED]> writes:
>> >> > It's not an ata specific problem, but
On 22-Feb-01 Dag-Erling Smorgrav wrote:
> John Baldwin <[EMAIL PROTECTED]> writes:
>> On 22-Feb-01 Maxim Sobolev wrote:
>> > Dag-Erling Smorgrav wrote:
>> >
>> >> Maxim Sobolev <[EMAIL PROTECTED]> writes:
>> >> > It's not a
doing.
>
> It's already have INVARIANTS, MUTEX_DEBUG, WITNESS and WITNESS_DDB.
Hmm, ouch, you do'nt want MUTEX_DEBUG, that'll slow your system to a crawl.
>> Also, if you are feeling industrious, edit
>> sys/i386/i386/trap.c and comment out the enable_intr() call ne
201 - 300 of 2870 matches
Mail list logo
