First off, sorry for the silence. This is gay freedom weekend
in San Francisco, and I've been rather busy socially. It was
poor timing on my part to commit such a big change just before
I was going to be gone all weekend. I have tried to answer
several questions below.
Date: Sat, 26 Jun 1
On Sun, 27 Jun 1999, Kirk McKusick wrote:
> I see that Peter has already committed it.
>
> On the subject of BUF_KERNPROC, this must be done as I have coded
> it, not later in biodone. The problem is when the filesystem does
> a readahead. It starts the I/O on the buffer that it really wants,
:On the subject of BUF_KERNPROC, this must be done as I have coded
:it, not later in biodone. The problem is when the filesystem does
:a readahead. It starts the I/O on the buffer that it really wants,
:...
:recursive locking is allowed, then it will get the buffer (since
:it holds the exclusive l
Kirk McKusick wrote:
[..]
Re: kern_lock.c - looks like a reasonable fix. There isn't much point
panicing for a poll.
> I do not see the problem that you are pointing out with missing
> BUF_KERNPROC in cluster_callback, but it is well past midnight,
> so I may not be thinking clearly.
No, you ar
On Sat, Jun 26, 1999 at 10:22:29PM -0600, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> "Justin T. Gibbs" writes:
> : The hope is to provide a consistent interface across
> : all *BSDs which is why I've addressed this to all of the *BSD projects.
>
> More generally, I'd like to identify are
On Monday, 28 June 1999 at 16:36:31 +0800, Peter Wemm wrote:
> Kirk McKusick wrote:
> [..]
> Re: kern_lock.c - looks like a reasonable fix. There isn't much point
> panicing for a poll.
>
>> I do not see the problem that you are pointing out with missing
>> BUF_KERNPROC in cluster_callback, but i
On Sun, 27 Jun 1999 18:37:51 MST, Doug wrote:
> This is going to sound like I'm attacking sheldon, but I'm not
> since he's already stated that the got approval for this change from
> Jordan.
Jordan will be the first to admit that he's been wrong before and I have
a thick skin.
>
* From: "David O'Brien" <[EMAIL PROTECTED]>
*
* On your next ``make world'', you will need to change any "user.group"
* specifications in /etc/newsyslog.conf to "user:group".
This is not the right way to do it.
===
-if ((group = strchr(q, '.')) != NULL) {
+if
> * On your next ``make world'', you will need to change any "user.group"
> * specifications in /etc/newsyslog.conf to "user:group".
>
> This is not the right way to do it.
>
> Please first change it to accept both syntaxes, with a warning in the
> manpage that the old one will go away in the
* From: "David O'Brien" <[EMAIL PROTECTED]>
* > Please first change it to accept both syntaxes, with a warning in the
* > manpage that the old one will go away in the future. Then remove the
* > old syntax after a few months.
*
* How about we leave it this way in -CURRENT, and the MFC wil
> First, the setting in /etc/defaults/rc.conf should default to off, as
> defaulting it to on violates POLA for the many many people who haven't
> updated to 3.x from 2.2 yet.
Personally, I don't care what is the default in 3.x, but it should be ON
by default in 4.0.
> I propose tha
Greg Lehey wrote:
> On Monday, 28 June 1999 at 16:36:31 +0800, Peter Wemm wrote:
> > Kirk McKusick wrote:
> > [..]
> >> Greg Lehey has sent me a panic with the buffer locking in the NFS code.
> >> I am too tired to attack it tonight, but will look at it in the morning.
> >
> > I might have a look
Peter Wemm wrote:
[..]
> Also, the swap IO clustering/chainging etc is troubled since it turns on
> and off B_ASYNC and does it's own freeing and waiting. I haven't got my
> brain around it yet but I don't think it's going to be too hard to fix.
[..]
This is a false alarm, it's not directly swap
Today is a schedulued power outage at RPI. I am going to take this
opportunity to install Matt's backported (to -STABLE) NFS patches on our
primary NFS server. This is the first real chance we have had to put these
under real-world load. As another datapoint, everything will be mounting
this se
> >>The panic occurs at 'swtch_com+0x6e: ltr %si'. At the time, %si is
> >>0x20, which indexes to what appears to be a busy tss (type=01011b)
> >>with a limit of 0x67. That instruction generates a general protection
> >>fault with an error code of 0. The current process was Idle.
>
> The busy
On Mon, Jun 28, 1999 at 02:37:50AM -0700, Satoshi - Ports Wraith - Asami wrote:
> *
> * On your next ``make world'', you will need to change any "user.group"
> * specifications in /etc/newsyslog.conf to "user:group".
>
> Please first change it to accept both syntaxes, with a warning in the
>
I hate reeplying to myself, especially when it's to tell me that I'm an
idiot.. I just realised (i think) that what I suggest below is exactly
what you are doing...
julian
On Mon, 28 Jun 1999, Julian Elischer wrote:
>
>
> On Sun, 27 Jun 1999, Kirk McKusick wrote:
>
> > I see that Peter ha
Hi,
after 4 crashes in 1 hour without a panic I've got a trace, but it's a
trace from a panic produced by "savecore". I didn't think the 4 crashes
are related to this trace.
I was only able to reboot after commenting savecore in /etc/rc.
Btw. after aborting fsck (+) I've got:
fsck in free(): wa
Date: Mon, 28 Jun 1999 01:21:21 -0700 (PDT)
From: Julian Elischer <[EMAIL PROTECTED]>
To: Kirk McKusick <[EMAIL PROTECTED]>
cc: Matthew Dillon <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]>,
Mike Smith <[EMAIL PROTECTED]>, Peter Wemm <[EMA
Kirk McKusick wrote:
[..]
I've been tinkering around for a while and think I have at least a
partial fix for the remaining problems.
Certain places use B_CALL and have biodone() from the b_iodone routine,
so we can't reliably use B_ASYNC as an indicator of needing to reassign
to LK_KERNPROC. We
:Certain places use B_CALL and have biodone() from the b_iodone routine,
:so we can't reliably use B_ASYNC as an indicator of needing to reassign
:to LK_KERNPROC. We have to do it on a case-by-case basis.
:
:It's easier to do cluster_head processing at the point it's gathered
:rather than in BUF_
You are proposing replacing the current buffer locks with two separate
locks, one for ownership and the other for I/O. Frankly, I do not find
this simpler or easier to understand than what we have now. I also
take some issue with the cost of the lockmgr code. It is large, but
the critical paths t
:
:You are proposing replacing the current buffer locks with two separate
:locks, one for ownership and the other for I/O. Frankly, I do not find
:this simpler or easier to understand than what we have now. I also
The simplicity that I am requesting is that we do not add all these
BUF_KE
:and B_WANTED code also required protection to avoid races), it would
:make a big performance improvement to just go make sure that all the
:BUF_ calls are already protected rather than needlessly add those splbio
:and splx calls.
:
: Kirk
Not as big as removing the lockmgr() code and r
Date: Mon, 28 Jun 1999 10:35:21 -0700 (PDT)
From: Matthew Dillon <[EMAIL PROTECTED]>
To: Peter Wemm <[EMAIL PROTECTED]>
Cc: Kirk McKusick <[EMAIL PROTECTED]>,
Julian Elischer <[EMAIL PROTECTED]>, Alan Cox <[EMAIL PROTECTED]>,
Mike Smith <[EMAIL PROTE
> The PAO3 changes to FreeBSD 3.2 are about to be integrated into the
> FreeBSD CVS repository as its own branch off RELENG_3. itojin-san and
> the other nomads reached this agreement with -core at Usenix.
Warner didn't mention any other list to report problems to, but
I just cvsup'd this mornin
What is MAX_PERF option?
It's in sys/i386/i386/pmap.c, sys/kern/kern_lock.c,
sys/vm/swap_pager.c and others.
Thanx,
Val
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
To Unsubscribe: send mail to [EMAIL PROT
:You are right that the buffer cache is very tricky. It is hard to
:change it in ways that preserves functionality and performance.
:The port of my buffer locking code from BSD/OS has caused problems
:largely because of a different buffer cache implementation and
:especially SMP models between the
In message <[EMAIL PROTECTED]> "Matt Crawford" writes:
: Warner didn't mention any other list to report problems to, but
: I just cvsup'd this morning and checked out RELENG_3_2_PAO.
: "make buildworld" died at usr.sbin/wicontrol/wicontrol.c, for
: lack of and ensuing errors.
:
: The file is pre
Since the latest patches for vinum were commited I am getting a panic
immediately after vinum has started. This is on a UP -current (as of
today).
---
changing root device to da0s1a
da0 at ahc0 bus 0 target 0 lun 0
da0: Fixed Direct Access SCSI-2 device
da0: 10.000MB/s transfers (10.000MHz,
:
:What is MAX_PERF option?
:It's in sys/i386/i386/pmap.c, sys/kern/kern_lock.c,
:sys/vm/swap_pager.c and others.
:
:Thanx,
:
:Val
It stands for 'maximum performance'. If you set this option, the kernel
will not bother making certain sanity checks within itself.
Basically you sh
In message <[EMAIL PROTECTED]> "Matt Crawford" writes:
: I never touched that file -- every line is still commented out. But
: I don't see how make.conf could check out a file from CVS for me
: that's missing in the source tree when I "make buildworld". "make
: update" would be different, but wi
This looks correct to me. I originally had the BUF_KERNPROC macro
just changing the target buffer, but then changed it to follow
chains in the hopes of reducing the instances of its use. The
way that you have used it below is much clearer and should definitely
be put in. Also I hope that your fix
Just to let someone know... I recently (a couple of hours ago) have been
having a problem with kernel panics I tried to remake the world and
the kernel panics saying:
panic: lockmgr:
then what follows is different every time... all I know is that it doesn't
happen until the process number i
> : Warner didn't mention any other list to report problems to, but...
> : lack of and ensuing errors.
> : The file is present under the RELENG_3 tag, though.
>
> I didn't mention it because it didn't break. It works for me. What
> are your configuration parameters in /etc/make.conf.
I never
In message <[EMAIL PROTECTED]> "Matt Crawford" writes:
: And I'm doing a new buildworld with a copy of the missing file
: inserted into src/sys/i386/include by hand. It's suspicious that
: if_wavelan_ieee.h has only one CVS tag on it (RELENG_3), and other
: files in that directory have a dozen or
ok
hadn't seen this one when I sent the previous email..
Julian
On Mon, 28 Jun 1999, Matthew Dillon wrote:
> :You are right that the buffer cache is very tricky. It is hard to
> :change it in ways that preserves functionality and performance.
> :The port of my buffer locking code fr
subscribe freebsd-ports
Get your free email from AltaVista at http://altavista.iname.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
[Format recovered--see http://www.lemis.com/email/email-format.html]
On Monday, 28 June 1999 at 23:26:24 +0200, Niels Chr. Bank-Pedersen wrote:
> Since the latest patches for vinum were commited I am getting a panic
> immediately after vinum has started. This is on a UP -current (as of
> today).
:ok
:
:hadn't seen this one when I sent the previous email..
:
:Julian
:
:
:On Mon, 28 Jun 1999, Matthew Dillon wrote:
:
:> :You are right that the buffer cache is very tricky. It is hard to
:> :change it in ways that preserves functionality and performance.
:...
I've had a long pho
>
> Date: Mon, 28 Jun 1999 17:22:22 -0400 (EDT)
> From: Kenneth Wayne Culver <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
>
>
> Just to let someone know... I recently (a couple of hours ago) have been
> having a problem with kernel panics I tried to remake the world and
> the kernel panics sayi
Peter Holm wrote:
> >
> > Date: Mon, 28 Jun 1999 17:22:22 -0400 (EDT)
> > From: Kenneth Wayne Culver <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> >
> >
> > Just to let someone know... I recently (a couple of hours ago) have been
> > having a problem with kernel panics I tried to remake the
On Mon, 28 Jun 1999, Matthew Dillon wrote:
>
> :ok
> :
> : hadn't seen this one when I sent the previous email..
> :
> :Julian
> :
> :
> :On Mon, 28 Jun 1999, Matthew Dillon wrote:
> :
> :> :You are right that the buffer cache is very tricky. It is hard to
> :> :change it in ways that pr
:The problem I see with this is teh resource load in times of critical
:resource shortage. If you need to suddenly generate a writable page..
:where does the page come from? If resources are not available, I guess you
:could just stall the write until the original page is reconstituted (after
:so
44 matches
Mail list logo
