:
::This is complete BULLSHIT, Warner.
:
:Your attitude it totally unacceptible. Learn to play well with
:others, or get the fuck out of the project.
:
:I am *NOT* blocking you. I'm telling you you need to get the SO's
:sign off to make sure that there isn't a security issue because the
:
::This is complete BULLSHIT, Warner.
:
:Your attitude it totally unacceptible. Learn to play well with
:others, or get the fuck out of the project.
Really? You think I should learn to play well with others? You
think it's appropriate to request that I spend a man week
and said I will take on
fixing the API but it will take a month then that's fine with me,
I would not feel that I would have to commit this now. But so far
nobody has stood up and said that.
-Matt
Matthew
:-(
-Matt
Matthew Dillon
[EMAIL PROTECTED]
Index: sbin/ipfw/ipfw.8
===
RCS file: /home/ncvs/src/sbin/ipfw/ipfw.8,v
retrieving
:
:On Sun, 15 Dec 2002 10:26:22 -0800 (PST), Matthew Dillon
:[EMAIL PROTECTED] said:
:
: Now you are forcing me to go to core. It's absolutely ridiculous and
: you know it. Goddamn it, next time I won't even bother posting if all
: I get is this sort of crap.
:
:All the better
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
What it comes down to is what developers are willing to do. My
contribution is 'ipfw unbreak'. If someone else has a solution that
they are willing to work on and commit in the next four weeks, then
fine. But if nobody is willing to work on and commit another solution
in the
:
:How about renaming swapon(8) into swapctl(8) after this function enhancemen=
:t?
:This name reflects it's purpose much better and would be consistent with the
:other BSDs.
:
:- Christian
I think that's an excellent idea. We would have to do some
rewriting to add the expected options
Well, there are two patches in that PR. I was not able to unpack
the second mime-encoded diff that implements the NOCORE method, which
is the one I think we should use. The described methodology is sound,
though. If someone could email the diff to me I will give it a more
Just call me an idiot. I'm looking it over now :-)
-Matt
:http://www.dellroad.org/dropbox/coredump.diff
:
:Thanks,
:-Archie
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
!@#$Q@#$@#$@#$
This is about the 90th time my -current box has become unusable.
First it won't let me installworld because of some signal snafu with
the kernel being too old, then, as usual, IPFW with the new kernel and
old world fails utterly and now the fragging machine
:
:On Sat, Dec 14, 2002 at 12:38:13PM -0800, Matthew Dillon wrote:
: then, as usual, IPFW with the new kernel and
: old world fails utterly and now the fragging machine can't access the
:
:Hear hear!! I am tempted to have /sbin/ipfw moved to src/sys.
How about something like
another undocumented or hard-to-find boot variable.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current
:Now I would really dislike seeing your patch in the tree, since I
:consider it's a rather crude hack to circumvent the ABI problems of
:ipfw. As I've already said to luigi in private e-mail (I would be
:surprised if this hasn't been already discussed in the lists as well),
:the proper way to
:I disagree with committing this hack; keep it as a local mod if you must.
:
:As to the problem; don't wait for Luigi to fix the ABI problems, do it
:yourself. Good things happen when folks are PO'd and won't settle for the
:status quo.
:
:Sam
I'm sorry you disagree, but it doesn't
:The problem appears to be that swapout_procs() is swapping out a process
:that is in the process of exiting (in exit1()) and having already
:relinquished its vmspace, but has not set PRS_ZOMBIE yet (which would be
:preventing the swapout). It's clearly not correct for a process in exit1()
many other places the vmspace might be bumped and then released. The
real bug appears to be in exit1().
I seem to recall we hit this situation a few months ago. I thought
it had been fixed.
-Matt
Matthew
What about something like this. If the vm_refcnt is still being
decremented too early, could it be moved to just before the thread_exit()
call?
-Matt
Index: kern/kern_exit.c
It's a big mess. exit1() sets up vm-vm_freer = p and then
vmspace_exitfree() tests that and calls vmspace_dofree(). It
looks like vm-vm_freer is acting like an exit-lock, so only
one process/thread actually frees the vmspace. But there are
still some serious race conditions.
Here's another go at a patch (untested).
-Matt
Index: kern/kern_exit.c
===
RCS file: /home/ncvs/src/sys/kern/kern_exit.c,v
retrieving revision 1.187
diff -u -r1.187 kern_exit.c
---
oops, sorry, I blew that patch. exitingcnt would have to be incremented
unconditionally.
-Matt
Index: kern/kern_exit.c
===
RCS file: /home/ncvs/src/sys/kern/kern_exit.c,v
retrieving
Whoop. Ok, here's a new patch. I think this covers all the cases.
I've done some testing and it appears to do the right thing, please
look it over (the last patch had type-o's and didn't cover the correct
cases).
-Matt
Index:
.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Those are .tmp files? It could be your /tmp or /var/tmp
that ran out of space, not /usr/obj.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:During a make world, from
:..
:=20
: I've discussed this issue with Poul-Henning Kamp. You need fsck
: from at least 4.7.
:=20
:...
(Ruslan Ermilov writes):
:Is this handled by fsck/setup.c,v 1.17.2.4 commit?
Yes, I believe so.
-Matt
Matthew Dillon
Matthew Dillon
[EMAIL PROTECTED]
:On Wed, Nov 27, 2002 at 04:04:08PM +0100, Marcin Dalecki wrote:
: During a fresh install of the DP2 I noticed that sysinstall didn't
: allow me to configure the system *without* any swap paritions
be blown away just
because user A is reading a large file. We lose a little in a light
load test but gain a lot under real world loads which put constant
pressure on the VM system.
-Matt
Matthew Dillon
I have to agree with Daniel here, John. I've worked on 'A'uto quite
a bit and it is simply not possible to create 'A'uto values that
everyone is satisfied with. It also doesn't make much sense to
arbitrarily scale what are normally small partitions just because
you have a
.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:On Mon, 28 Oct 2002, Seigo Tanimura wrote:
:
: On Thu, 24 Oct 2002 15:05:30 +1000 (EST),
: Bruce Evans [EMAIL PROTECTED] said:
:
: bde Almost exactly what we have
:I was going to comment on fragmentation issues, but that seems to have
:been very well covered. I would like to point out that removing the
:buffer_map not only contributes to kernel map fragmentation, but also
:contention for the kernel map. It might also prevent us from removing
:giant from
or approximately 347uS.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
: On 2002-10-13 13:36, Terry Lambert [EMAIL PROTECTED] wrote:
: I had upgraded the machine with a snapshot from the Japan snapshot
: image server; apparently, no one ever thinks of compressiong ISO's,
: so that was at the limit of what I could download. 8-(.
:
: It may be a good idea to
So, Mark, does all of this extracurricular activity mean that
4.7-RELEASE is done? Or are we still in freeze?
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
: a lot of information on how to use it. I generally recommend
: using a stripe size of 1152 for multitasking loads.
:
:Sectors? Why particularly this value?
It's described in 'tuning'. Basically you want a fairly large stripe
to reduce multi-disk seeking when reading
Yes, ccd is fairly light weight. 'man tuning' and 'man ccd' has
a lot of information on how to use it. I generally recommend
using a stripe size of 1152 for multitasking loads. Only use a
small/tiny stripe size if you need single-tasking sequential
performance (and even
:
:On Fri, 4 Oct 2002 11:34:46 -0700 (PDT)
:Matthew Dillon [EMAIL PROTECTED] wrote:
:
: When you turn the debugging on it will print out various
: parameters used to calculate the bandwidth window. The higher the
: debug value, the more often it prints out the stats (assuming
of the water and dropping packets when
large TCP buffers have been configured, amoung other things).
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL
).
:
:--
:Andrey A. Chernov
:http://ache.pp.ru/
I wouldn't have expected it to have but it's always a good idea to
cover all your bases.
-Matt
Matthew Dillon
[EMAIL PROTECTED
:John Baldwin writes:
: Why? If someone hasn't done a MAKEDEV of the device, it is just as
: dead. MAKEDEV + kill -1 1 will bring it back if they didn't
: (untested, but it is the normal way to do these things).
:
: Agreed, that's why I said maybe b/c it would be preserving the
:
:--
:Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Hold on, let me review the issue. Those changes were supposed to be
low impact.
-Matt
Matthew Dillon
can build
a new world and kernel for my alpha.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current
From the ktrace output it looks like the alpha is confused about
the datasize limit calculation. The program data appears to start
at the 4G mark so it is likely that the confusion is with the
'data_addr' variable whos calculation was changed slightly.
In that rev data_addr
:The attached patch does just change the heuristics used to detect
:text segments to look for executable segments (using an idea from
:Peter). This results in the fact that dynamic section is viewed as
:text, which should not break anything.
:This way, it should be possible to avoid the hole
:
: Can somebody who is feeling adventurous and has an alpha box please
: test whether this fixes it for now?
:
:Nope, if anything it's now worse. :( We should perhaps revert this
:change in -stable until we can get it to work in -current. FWIW, with
:the patch all sorts of programs no longer
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
does
the read-ahead and returns a single, valid, busied page.
I am not volunteering to do this, though, I already have a full plate.
-Matt
Matthew Dillon
[EMAIL
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
could have fdalloc()
return EAGAIN or something like that to indicate that
it had to cycle the lock.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail
:
:* Matthew Dillon [EMAIL PROTECTED] [020718 11:40] wrote:
:
: fdalloc() does not reserve the descriptor number it
: returns, it simply finds a free slot and says 'this
: index is a free slot'. Even in the latest -current,
: fdalloc() releases the fdp lock when it goes
Here is my proposed fix for the page-zeroing problem w/ SMP. It
is untested (I'm about to test it)... I'm looking for comments on
the concept. If the comments are positive and my testing succeeds I
will commit it tonight.
Basically the idea is simple. Provide a function
to both -current and -stable.
Is that the patch you were talking about?
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
time we update.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
I have an idea in regards to the page-zero issue. Presumably we want
to avoid doing an IPI to every cpu to clear the TLB, so what we do
instead is create a lazy TLB clearing mechanism based on the thread.
The scheduler detects the request when it switches the thread in and
:
: critical_enter();
:*CMAP2 = PG_V | PG_RW | phys | PG_A | PG_M;
:invltlb_1pg((vm_offset_t)CADDR2);
: curthread-td_lazytlb = PCPU_GET(cpumask);
: critical_exit();
:
:
:OK. How the * do I get a *!@#$@$#% crash dump on current? I
:did a dumpon to enable the dumping, which appeared to work. I then
:did a savecore after the system came back up (but before any swapping
:happened) and that seemed to work. I then tried to use gdb to read
:the core dump and
Similar things happen to me... Also when I do an 'fsck -y' fsck will
fsck each partition until it hits one with problems. It fixes the
problems, then exits (does not continue to the next partition). I
wind up having to run fsck five or six times to get it to fsck all
the
);
: ...
: TAILQ_REMOVE(q, pthread, p_qe);
: ...
: }
:
:--
:Dan Eischen
Why don't we simply conditionalize sys/queue.h for the _KERNEL
-Matt
Matthew Dillon
Matthew Dillon
[EMAIL PROTECTED]
Things to note:
* sys time is an approximate indicator of I/O and matches-up fairly
well between -stable and -current, indicating that the builds on
-current and -stable
no improvement in cpu-intensive applications when I run a GCC2-generated
binary and a GCC3-generated binary on the same machine, side by side.
-Matt
Matthew Dillon
[EMAIL
test for signal-related
issues).
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body
I can get a panic when ^C'ing buildworld on an SMP build of -current:
-Matt
test3# j
test3# panic: mutex sched lock not owned at
/FreeBSD/FreeBSD-current/src/sys/kern/subr_smp.c:126
cpuid = 1; lapic.id =
Debugger(panic)
Stopped at
)
:programs run slower that would be of interest.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
Just play with a couple of interpreted languages, like csh, perl,
etc... run the same
:
:
:Andrew Gallatin fixed the problem in kern_sig.c, check it out:
:
:gallatin2002/07/02 19:55:48 PDT
:
Will do tomorrow!
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
I've been doing buildworld tests on an SMP build, 2-cpu 2550 w/ 2G of
ram configured. It gets through two or three builds and then crashes.
Unfortunately the crash seems to be completely undebuggable. It drops
into DDB but the serial port is completely screwed up and I can't
SMP builds are still producing panics every 2-4 buildworlds after the
KSE commit, I'm still trying to track that down. But I was able to
complete the softupdates/non-softupdates test with a UP build of
-current:
with softupdates (UP BUILD, CURRENT):
3122.30 real
I got the ithread_loop/setrunqueue panic again while building the
world normally (no memory pressure). I'm too tired to deal with
it tonight but tomorrow morning I'll attach a gdb and track it down.
-Matt
db
db trace
:
:which panic message?
:the code here is still FULL of asserts.
:
Unexpected ke present. I'm resynching and will run the build test
again. If it crunches again I'll do a more detailed check.
-Matt
To Unsubscribe: send mail to [EMAIL
Got another one. Different panic, same place.
panic: setrunqueue: bad thread state
cpuid = 0; lapic.id = 0100
Debugger(panic)
Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0
db trace
Debugger(c02ec2ba) at Debugger+0x46
panic(c02ec8a9,c6461d80,c6461d80,c6461d80,c01afa30) at
:others have seen this one too
:and the common element is that it's always in
:setrunqueue() called from an interrupt.
:it is also often via cv_*SOMETHING*()
:
:I Thought we had cleared these up but apparently not :-/
:
There are a bunch of wakeup race conditions in the CV code where
Oh, this is funny... I started a buildworld on four SMP boxes
simultaniously and my UPS started blinking and ding-donging at me
angrily!
-Matt
:It will be in a couple of stages, so
:don't complain about breakages in the next few
.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:Date: Thu, 27 Jun 2002 16:33:36 +0200
:From: Sheldon Hearn [EMAIL PROTECTED]
:
: Wed Jun 26 19:00:10 PDT 2002
: /usr/libexec/ld-elf.so.1: /usr/bin/cvs
branch and do more KSE testing. Would it be possible for you to
synchronize your KSE branch to -current again, as of now, so I can be
sure it has all the various things that have gone in of late?
-Matt
Matthew
Hey Bruce or David... has GCC3 by any chance fixed the stack alignment
eyesore or is that still the default? If so could we by any chance fix
it in our version? It creates massive bloat when you have lots of tiny
functions and as far as I can tell there is no advantage at all
in comparison
to the time saved by all the third parties that use or work on the FreeBSD
kernel. Using the argument blindly as a justification to stop code
evolution is just plain a dumb idea.
-Matt
Matthew
community.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
:
: Furthermore, it is an extreme and inappropriate imposition on Julian
: to require that he extract all the alleged 'gratuitous braces and
: ()'s)' into a separate commit.
:
:Uh, no it isn't. That is the rules we operate under. This type of
:request comes up _daily_, and is
) {
stmt;
} else {
stmt;
stmt;
}
Same goes with for(), while(), etc.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send
:
:When you make the code more readable, you introduce further diffs, and you
:leave no reference against the original code of where the functional changes
:are. Either make the base code cleaned up by committing non-functional
:changes first, or commit against the base code your functional
When it comes right down to it, I am getting wholely sick and tired
of people acting like rulez-police and complaining about the most
minor, most insignificant syntactical changes imagineable. The
rest of us developers have better things to do with their time then
to spend it
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
alone the world.
I'm going to try make -k next but I don't have high hopes.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
:On Sat, Mar 23, 2002 at 11:02:26AM -0800, Matthew Dillon wrote:
: Anyone have any ideas? I'm trying to build the latest -current
: (from cvs) on an alpha running 4.3-RELEASE, using 'make buildworld'.
:
:I have thought about what could be the problem several times and cannot
:come up
Anyone have any ideas? I'm trying to build the latest -current
(from cvs) on an alpha running 4.3-RELEASE, using 'make buildworld'.
-Matt
Matthew Dillon
[EMAIL
?
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:The RE's are wanting to ship 5.0 DP#1 w/this patch applied.
:If having 'AJ' by default is deemed not useful (by being removed from the
:DP), it sounds like we should just turn
Well, 'current' has spoken I guess! :-)
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:From: [EMAIL PROTECTED]
:To: M. Warner Losh [EMAIL PROTECTED]
:Cc: [EMAIL PROTECTED
:* Terry Lambert [EMAIL PROTECTED] [020322 23:13] wrote:
: Matthew Dillon wrote:
: Unless I am missing something, vnodes hang off their mount points.
: So, effectively, there is a system-wide list.
:
: The lock on a global traverasl will be pretty ugly...
:
:Module loading doesn't
I have no idea what the frig you guys are doing in vm_map.c. I would
recommend that all the changes be backed out. Then I would recommend
that the following be done:
* change the lockmgr vm_map lock to be exclusive-only
* test commit
* change the lockmgr
suggesting that it simply be made into an exclusive lock in -current.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:--- Matthew Dillon [EMAIL PROTECTED] wrote:
: I have
couldn't
do this stuff in the time frame you are talking about even if I wanted
to.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED
this in detail.
MADV_FREE can be used in liu of munmap() but phkmalloc does not use
it quite this way, phkmalloc will still free the page when the cache
is blown out.
-Matt
Matthew Dillon
, as if you fork()d and the parent
was the original area and the child is the new
area.
But I'm not volunteering.
-Matt
Matthew Dillon
: mcopymap(from, to, length, flags)
:
:I'm not sure you want to copy it..
:I mean you want the dta di disappear from the old address.
:It's more a movepages()
MAP_MOVE|MAP_SHARED
-Matt
:
: flags:
:
: MAP_SHARED share the same
Matthew Dillon
[EMAIL PROTECTED]
#include stdio.h
#include stdlib.h
#include unistd.h
int
main(int ac, char **av)
{
char *ptr = NULL;
int i;
for (i = 2; i 100; ++i)
ptr = realloc(ptr, i);
return(0
interrupt it should be able to handle a fast-unpend.
If it doesn't work then it's almost certainly a simple fix to adjust
the fake trap frame which can be done post-commit.
-Matt
Matthew Dillon
:On 08-Mar-02 Matthew Dillon wrote:
:
::I agree that the use of cpu_critical_enter/exit could use cleaning up.
::Can you give an example of where critical_enter is used improperly?
::You mean in fork_exit? Your changes to cpu_switch solve that problem
::with critical_exit almost unchanged
.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
effect on
the project and, frankly, I don't see why anyone, especially John,
would be opposed to it (I don't even think he bothered to read the
patch).
-Matt
Matthew Dillon
101 - 200 of 1105 matches
Mail list logo
