It seems Greg Lehey wrote:
Unfortunately I don't have a toy i386 system ready and testet on alpha.
There may be some differences how data corruptions efects on this platform.
I found a potentially serious bug in the RAID calculations yesterday:
it assumed that sizeof (int) == 4. I
In article [EMAIL PROTECTED]
Warner Losh [EMAIL PROTECTED] writes:
In message [EMAIL PROTECTED] Takahashi Yoshihiro writes:
: For adv driver:
: http://home.jp.FreeBSD.org/~nyan/patches/advansys.diff.gz
I took a look at this change. For the most part it looks good.
Thanks.
However, I
In message [EMAIL PROTECTED] Takahashi Yoshihiro writes:
: Because, adv_isa.c is not required by PC-98, PC-98 requires only PCI
: frontend. Then it contains isa_dmacascade function which does not
: exist and is not needed for PC-98.
Is that because there's not isa bus on a pc-98? Or that the
On Sun, Apr 02, 2000 at 05:56:22PM -0400, Chuck Robey wrote:
On Sun, 2 Apr 2000, Thomas T. Veldhouse wrote:
Are there any plans to merge perl-5.6.0 into current? I don't have any
plans for using it currently, but I curious.
Hmm. What with the nightmarish build structure of perl, I'm
: a more accurate measure of load.
:
:
:Ahh, and since nearly everything is done on this system via NFS, I can
:imagine that several things are waiting for NFS responses.
:
:It's probably more accurate, but from a PR standpoint it makes it "look"
:like FreeBSD is choking under the load,
On Monday, 3 April 2000 at 7:59:48 +0200, Søren Schmidt wrote:
It seems Greg Lehey wrote:
Unfortunately I don't have a toy i386 system ready and testet on alpha.
There may be some differences how data corruptions efects on this platform.
I found a potentially serious bug in the RAID
On Sun, Apr 02, 2000 at 09:07:33PM +0200, Bernd Walter [EMAIL PROTECTED] wrote:
Just to clearify the things...
Are these problems with 4.0-RELEASE with 4.0-STABLE or with 5.0-CURRENT?
Here's the sequence of what I did:
1. I had i386 system with two 20GB IBM ATA disks and 5.0-current system
It seems Greg Lehey wrote:
This wont fix it on the i386 where the problem is, and btw I havn't seen
any commits yet...
No, I was just about to do something when phk changed the interfaces.
I don't have the time to keep chasing him, so I'll wait until we have
a relatively stable situation
It seems Vallo Kallaste wrote:
Here's the sequence of what I did:
1. I had i386 system with two 20GB IBM ATA disks and 5.0-current system
built from March 31 sources. First I used striping over two disks and
put /usr filesystem onto it, did overnight testing and all was well.
2. Same
From the keyboard of Bruce Evans:
It's just a bug to allocate big structs on the kernel stack.
Please specify "big"! :-)
I wonder how too "big" can be detected. The code in question is perfectly
valid syntactically and semantically correct C-code.
If a piece of code being considered buggy
* Hellmuth Michaelis [EMAIL PROTECTED] [000403 02:12] wrote:
From the keyboard of Bruce Evans:
It's just a bug to allocate big structs on the kernel stack.
Please specify "big"! :-)
have a look at src/sys/nfs/nfs_vnops.c:
line ~2787:
#ifndef NFS_COMMITBVECSIZ
#define NFS_COMMITBVECSIZ
Are there actually any good reasons why we _should_ upgrade in the first
place? Security fixes, added functionality we require, etc. The perl we
have is stable and the problems it has are well known, which is good
enough in 99% of the cases.
Including Perl in the make world build is something
Where are you guys now as far as USB drives are concerned? I've been
looking a lot at the driver lately and would like to hear about any
problems you have.
Nick
On Fri, 31 Mar 2000, Paul Haddad wrote:
Hi,
Boy I wish I had read this message before I went out and bought a USB zip
drive...
In message [EMAIL PROTECTED], Gary Jennejohn writes:
Yes, but it was perfectly legal to put the structure on the stack
_before_ MLEN was doubled.
Just because it worked doesn't mean that it was correct.
We need to be frugal about the kernel stack, for a lot of reasons,
that's just the way it
Just went through a few logfiles:
Checking for rejected mail hosts:
-1d: Cannot apply date adjustment
usage: date [-nu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
On Sat, 01 Apr 2000 17:03:24 PST, Matthew Dillon wrote:
I've committed it into -current and will MFC it into
-stable in a week if there aren't any problems. I
do not intend to MFC it into 3.x.
Hi Matt,
I'd like to suggest that a week is not enough. Given that we seem to be
On Mon, 03 Apr 2000 10:52:13 +0100, Nick Hibma wrote:
Are there actually any good reasons why we _should_ upgrade in the first
place? Security fixes, added functionality we require, etc. The perl we
have is stable and the problems it has are well known, which is good
enough in 99% of the
On Sun, 02 Apr 2000 17:56:22 -0400, Chuck Robey wrote:
Hmm. What with the nightmarish build structure of perl, I'm sure that
reading this is just going to wreck Mark's day.
I doubt it. Not for a while, anyway. Mark and I chatted about the
state of the mailing lists over drinks last
At 11:10 PM -0500 2000/4/2, Kevin Day wrote:
It's probably more accurate, but from a PR standpoint it makes it "look"
like FreeBSD is choking under the load, when it really isn't. Or am I the
only one that even cares about this? :)
It's also extremely confusing for Linux
I converted the amd and adv drivers to new-bus. But, as I am not
familiar with these drivers and new-bus, maybe I have mistaken.
Will somebody please review these changes?
For amd driver:
http://home.jp.FreeBSD.org/~nyan/patches/amd.diff.gz
Hi,
I'm afraid this code fails in
On Mon, 3 Apr 2000, Christopher Masto wrote:
On Sun, Apr 02, 2000 at 05:56:22PM -0400, Chuck Robey wrote:
On Sun, 2 Apr 2000, Thomas T. Veldhouse wrote:
Are there any plans to merge perl-5.6.0 into current? I don't have any
plans for using it currently, but I curious.
Hmm.
On Mon, Apr 03, 2000 at 07:01:10AM -0500, Thomas T. Veldhouse wrote:
I would think the perl upgrade would also be done in current. I would
think you would want to track this sort of thing as closely as
possible - unless there is an pending release - which there isn't.
Users will follow
Folks,
I just did a bit of searching on the website, and garnered enough
information from
http://www.freebsd.org/cgi/getmsg.cgi?fetch=546460+0+/usr/local/www/d
b/text/1998/freebsd-questions/19981115.freebsd-questions to be able
to add a new "quirk" in /usr/src/sys/cam/cam_xpt.c for a
On Sun, 2 Apr 2000, Gary Jennejohn wrote:
Bruce Evans writes:
Big structs need to be malloced.
Yes, but how does one know that a struct is too big ? Before the increase
in MLEN strucct sppp was not too big.
All structs should be considered too big until proven otherwise :-).
I think
From the keyboard of Poul-Henning Kamp:
We need to be frugal about the kernel stack, for a lot of reasons,
that's just the way it is, and as far as I know it is the way
it will continue to be.
Good. I'd like to learn something from it: Shall i avoid allocating
structs on the kernel stack at
In message [EMAIL PROTECTED], Hellmuth Michaelis writes
:
From the keyboard of Poul-Henning Kamp:
We need to be frugal about the kernel stack, for a lot of reasons,
that's just the way it is, and as far as I know it is the way
it will continue to be.
Good. I'd like to learn something from
On Mon, 3 Apr 2000, Alfred Perlstein wrote:
* Hellmuth Michaelis [EMAIL PROTECTED] [000403 02:12] wrote:
From the keyboard of Bruce Evans:
It's just a bug to allocate big structs on the kernel stack.
Please specify "big"! :-)
have a look at src/sys/nfs/nfs_vnops.c:
line
In article [EMAIL PROTECTED]
Warner Losh [EMAIL PROTECTED] writes:
In message [EMAIL PROTECTED] Takahashi Yoshihiro
writes:
: Because, adv_isa.c is not required by PC-98, PC-98 requires only PCI
: frontend. Then it contains isa_dmacascade function which does not
: exist and is not needed
In article [EMAIL PROTECTED]
Brian Somers [EMAIL PROTECTED] writes:
I'm afraid this code fails in bus_alloc_resource(...SYS_RES_IOPORT...).
I know nothing about what that does, but notice that the old code
didn't even call pci_map_port() (which makes the compat code call
Hellmuth Michaelis wrote:
From the keyboard of Poul-Henning Kamp:
We need to be frugal about the kernel stack, for a lot of reasons,
that's just the way it is, and as far as I know it is the way
it will continue to be.
Good. I'd like to learn something from it: Shall i avoid
Bruce Evans writes:
On Sun, 2 Apr 2000, Gary Jennejohn wrote:
I think we should nuke csu_hdr since it's not used anywhere. Is that
what you really mean ?
Yes. I'm trying the following patch. Only tested at compile time.
[patch snipped]
Thank you, Bruce ! This is pretty much the same patch
Nick Hibma wrote:
Are there actually any good reasons why we _should_ upgrade in the first
place? Security fixes, added functionality we require, etc. The perl we
have is stable and the problems it has are well known, which is good
enough in 99% of the cases.
PERL is not just used by the
In article [EMAIL PROTECTED],
Alfred Perlstein [EMAIL PROTECTED] wrote:
If you're worried about such things happening then you can use
the pre-processor to catch things that may make your structures
too large.
I wonder how too "big" can be detected. The code in question is perfectly
On 3/04, John Polstra wrote:
| I doubt if it's possible to implement that at compile time. Remember,
| the preprocessor doesn't understand "sizeof". It doesn't recognize
| keywords in expressions at all.
Then don't use the preprocessor alone and use both the preprocessor and
the compiler. I
:
:
:
:On Sat, 01 Apr 2000 17:03:24 PST, Matthew Dillon wrote:
:
: I've committed it into -current and will MFC it into
: -stable in a week if there aren't any problems. I
: do not intend to MFC it into 3.x.
:
:Hi Matt,
:
:I'd like to suggest that a week is not enough. Given that
On Sun, 2 Apr 2000 23:10:59 -0500 (CDT), Kevin Day [EMAIL PROTECTED] said:
It's probably more accurate, but from a PR standpoint it makes it "look"
like FreeBSD is choking under the load, when it really isn't.
Actually, you have it backwards -- it makes it look as if FreeBSD is
*not* choking
On Sun, 2 Apr 2000 15:08:17 +0200, Jeroen Ruigrok/Asmodai [EMAIL PROTECTED] said:
Someone more acquainted with the daily scripts may want to
investigate/fix that.
In the general case, it's hopeless.
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the
On Sun, 2 Apr 2000 23:10:59 -0500 (CDT), Kevin Day [EMAIL PROTECTED] said:
It's probably more accurate, but from a PR standpoint it makes it "look"
like FreeBSD is choking under the load, when it really isn't.
Actually, you have it backwards -- it makes it look as if FreeBSD is
*not*
It kinda looks like you've stripped your kernel binary. If you havn't,
don't, certain programs need the kernel symbols to access kmem.
-Matt
Matthew Dillon
[EMAIL
On Mon, Apr 03, 2000 at 10:52:13AM +0100, Nick Hibma wrote:
Are there actually any good reasons why we _should_ upgrade in the first
place?
Of course. We now have an obsolete version of Perl. That should be
reason enough to upgrade.
5.6 is the first major release in over a year. It has
: 1. I had i386 system with two 20GB IBM ATA disks and 5.0-current system
: built from March 31 sources. First I used striping over two disks and
: put /usr filesystem onto it, did overnight testing and all was well.
: 2. Same system, same sources plus two same disks. Now I tried raid5 over
:
At 11:59 AM -0400 2000/4/3, Jeroen C. van Gelderen wrote:
PERL is not just used by the FreeBSD system, it's also used by many
applications ran on top of FreeBSD. Those applications are more likely
to require an up-to-date version of PERL. We for one need the (overly
late) 64-bit support
Hi to all the -current people,
I'm running FreeBSD on an Abit BP6 motherboard, which
uses the HighPoint UDMA 66 controller. This is a SMP
machine, with the BP6 running two Celeron 500Mhz.
The hard drive is a Western Digital 7200rpm/DMA66, plugged
in the HPT66 controller. Here's what dmesg tells
In message [EMAIL PROTECTED], Matthew Dillon writes:
: http://phk.freebsd.dk/misc
:
:I belive the patch is now fundamentally ready for commit, I'm running
:it here myself, and the delta in kernel warnings have been analyzed
:and deemed mostly harmless.
:
:Some componenents are still not
It seems Matthew Dillon wrote:
:Same story here, but using softupdates or async mounts I can reproduce
:the hang or panic in less than 60 secs..
:
:Vinum with raid5 is plain broken, include INVARIANTS in the kernel
:and see why...
:
:-Søren
Hang on to that thought. As soon as this
:I'm not sure if this is -current fodder or not, but since it's still
:happening in -current, I'll ask.
:
:We recently upgraded a server from 2.2.8 to 4.0(the same behavior is shown
:on 5.0-current, too). Before, with the exact same load, we'd see load
:averages from between 0.20 and 0.30. Now,
:Ripping up the buffer cache right smack in the middle of Greg trying
:to debug a serious vinum/bio problem is atrocious timing.
:
:Actually, it is the other way around, Greg finally started to look for
:the bug in vinum in the middle of my commits.
:
:How dare he do that ?
:
::-)
:
:--
Hi.
I've been having great unhappiness in trying to get Apache+modSSL and
OpenSSL in 5-current to work.
I do not have the RSA port installed (I'm a South African
citizen residing outside the USA), and built-world today with
USA_RESIDENT=no set.
Basically, the combination of Apache 1.3.12 and
Is there any compelling reason for retaining src/lib/libm
in the source tree? Yes, I realize that libm is the original
libm from CSRG 4.4 BSD-lite. However, the errors noted
below have been in the source since 1994 when rgrimes imported
the initial sources.
The only person that I can of that
Brad Knowles wrote:
At 11:10 PM -0500 2000/4/2, Kevin Day wrote:
It's probably more accurate, but from a PR standpoint it makes it "look"
like FreeBSD is choking under the load, when it really isn't. Or am I the
only one that even cares about this? :)
It's also
At 1:11 PM -0500 2000/4/3, Barry Pederson wrote:
Won't this also goof up programs like Exim (an SMTP MTA), that have some
settings available for how to handle messages under various loads
(process now, queue for later, etc)?
If there has been an actual change in how the load
On Mon, Apr 03, 2000 at 07:37:55PM +0200, Khetan Gajjar wrote:
Hi.
I've been having great unhappiness in trying to get Apache+modSSL and
OpenSSL in 5-current to work.
I do not have the RSA port installed (I'm a South African
citizen residing outside the USA), and built-world today with
It seems Erik de Zeeuw wrote:
atapci1: HighPoint HPT366 ATA66 controller port \
0xb800-0xb8ff,0xb400-0xb403,0xb000-0xb007 \
irq 11 at device 19.0 on pci0
ata2: at 0xb000 on atapci1
atapci2: HighPoint HPT366 ATA66 controller port \
0xc400-0xc4ff,0xc000-0xc003,0xbc00-0xbc07
Brad Knowles wrote:
If there has been an actual change in how the load average is
calculated, then any program that changes it's behaviour based on the
load average may have problems. This would certainly include SMTP
MTAs such as sendmail, Exim, etc
I agree. IMO, the load
On Mon, Apr 03, 2000, Matthew Dillon wrote:
:
:
:Matt,
:
:When I mailed arch@ about this change I got no response from anybody
:but Bruce.
:
:I talked to Kirk about it in Malmø and got his approval.
:
:This is not unplanned.
:
:This is also not untested, I have two complete
On Mon, 3 Apr 2000, Szilveszter Adam wrote:
--- /usr/src/secure/lib/librsaintl/Makefile.old Tue Mar 14 00:25:58 2000
+++ /usr/src/secure/lib/librsaintl/Makefile Sun Apr 2 18:27:27 2000
@@ -10,6 +10,8 @@
CFLAGS+= -I${.OBJDIR}
+LDADD+=-L${.OBJDIR}/../libcrypto
On Mon, 3 Apr 2000, Gary Jennejohn wrote:
Bruce Evans writes:
On Sun, 2 Apr 2000, Gary Jennejohn wrote:
I think we should nuke csu_hdr since it's not used anywhere. Is that
what you really mean ?
Yes. I'm trying the following patch. Only tested at compile time.
[patch snipped]
At 2:56 PM -0400 2000/4/3, Donn Miller wrote:
For example, FreeBSD,
Linux, Solaris, SCO, etc. may all be running the exact same processes,
but will the load avg. always be consistent across those platforms? I
think not.
That's not a
Bruce Evans writes:
On Mon, 3 Apr 2000, Gary Jennejohn wrote:
Bruce Evans writes:
On Sun, 2 Apr 2000, Gary Jennejohn wrote:
I think we should nuke csu_hdr since it's not used anywhere. Is that
what you really mean ?
Yes. I'm trying the following patch. Only tested at compile time.
On Mon, 3 Apr 2000, Matthew Jacob wrote:
These aren't available at boot time when you need them, are they?
You will need probably the ability to create sysctls on the fly, which is
still on my drawing board. If you can live with creating just completely
separate subtrees (no overlap) this
On Sun, 2 Apr 2000 15:08:17 +0200, Jeroen Ruigrok/Asmodai [EMAIL PROTECTED] said:
Someone more acquainted with the daily scripts may want to
investigate/fix that.
In the general case, it's hopeless.
No, not if date -vblah DTRT.
-GAWollman
--
Garrett A. Wollman | O Siem / We are
Check if your /dev/null has been replaced by some stupid `real' file.
The `nlist failed' problem bit me several weeks ago on two machines (one
running 4-stable and the other running -current) and it turned out to be
a /dev/null problem. You may want to remove /dev/null maually and do a
`sh
On Mon, Apr 03, 2000 at 02:56:32PM -0400, Donn Miller wrote:
Brad Knowles wrote:
If there has been an actual change in how the load average is
calculated, then any program that changes it's behaviour based on the
load average may have problems. This would certainly include SMTP
Patrick Mau wrote:
On all Unix-like systems I know, the load average is the average mumber
of processes running during a given time interval. I can't see what use
it may have to count load for _waiting_ processes.
I/O load is not process load, if a process waits for I/O completion it does
/dev/null was not the problem. I removed and remade it. I am using
the latest MAKEDEV.
# ls -l /dev/null
crw-rw-rw- 1 root wheel2, 2 Apr 3 13:40 /dev/null
tomdean
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Richard Wackerbarth wrote:
On Mon, 03 Apr 2000, Donn Miller wrote:
I think we ought to re-examine the definition of load average. By
load, we mean an actual load on the cpu, and waiting processes aren't
really exerting a cpu load. So, by that reasoning I say waiting
processes don't
:
:* His timing did suck
:* He's now doing the right thing, at least, instead of committing the
: second patchset without submitting them for peer review
I disagree. What Poul is doing is committing stuff first, then trying
to get validation after the fact (and in a rather demanding
I'm not sure I follow this.
This subject has come up before in that tape quirks are really busted, etc..
I was going to implement a usage of getenv so that *something* would be
available for 4.0- but I was talked out of it by a number of people (you know
who you are) who said this was the
On Mon, 3 Apr 2000 14:35:44 -0700 (PDT), Matthew Jacob [EMAIL PROTECTED] said:
I'm not sure I follow this.
This subject has come up before in that tape quirks are really busted, etc..
I don't believe sysctl (at least in the form Brad suggested) is at all
the right model. Rather, the kernel
Aha! I am loading the kernel directly.
2:da(2,a)/kernel
I looked in the archives, but, did not see anything.
I am munging with a disk, da1. -current is on da2. 3.4 from the CD
on da0.
Next week I will have a boot manager again!
tomdean
To Unsubscribe: send mail to [EMAIL PROTECTED]
Donn Miller wrote:
Patrick Mau wrote:
On all Unix-like systems I know, the load average is the average mumber
of processes running during a given time interval. I can't see what use
it may have to count load for _waiting_ processes.
I/O load is not process load, if a process waits for
71 matches
Mail list logo
