Re: ATA & 82C596 bug in 4.0-RELEASE?

It seems John Hay wrote: > > > > I tried to install 4.0-RELEASE on a completely new PC system, but the > > install failed with ATA write errors and resets. I moved the disk to another > > PC and installed 4.0 via manual disklabels, newfs, bin + src extraction. > > 4.0 booted fine on this system (

Re: OpenSSL and Apache+ModSSL

Around Yesterday, "Kris Kennaway" wrote : KK> I'll take a closer look at this tonight and try and commit it to internat KK> (and freefall), lag willing (if it passes a world build). If someone can KK> confirm the world build for me in the meantime, it would save me the KK> trouble. I didn't

Re: MLEN and crashes

Gary Jennejohn wrote: > 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 t

Re: 2nd call for reviews and tests: buf->bio patch

-On [2404 04:01], Adrian Chadd ([EMAIL PROTECTED]) wrote: >This really isn't constructive. I haven't looked at the patchset that >phk has posted up but I think it'd be more useful if people gave >comments about the changes and their usefulness rather than the bickering >going on now. Agreed.

Re: 2nd call for reviews and tests: buf->bio patch

-On [2404 04:02], Matthew Dillon ([EMAIL PROTECTED]) wrote: >: >:* 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 tryi

Re: 2nd call for reviews and tests: buf->bio patch

-On [2403 20:05], Matthew Dillon ([EMAIL PROTECTED]) wrote: > >: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 un

Re: OpenSSL and Apache+ModSSL

On Mon, Apr 03, 2000 at 12:18:28PM -0700, Kris Kennaway wrote: > 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 @@ > > CFLAG

Re: Perl 5.6.0?

On Mon, 3 Apr 2000, Jeroen C. van Gelderen wrote: > Which either gives me two different versions of PERL to worry about or > forces me to use an unsupported version for making the world. It's bad > enough that I have to work around the sendmail bug in the base system > ;-) The issue with perl, t

Re: ATA & 82C596 bug in 4.0-RELEASE?

> > I tried to install 4.0-RELEASE on a completely new PC system, but the > install failed with ATA write errors and resets. I moved the disk to another > PC and installed 4.0 via manual disklabels, newfs, bin + src extraction. > 4.0 booted fine on this system (a Dell Optiplex GX1). > > Back on

ATA & 82C596 bug in 4.0-RELEASE?

[ Hope this is the right mailing list. I'm expecting I need some patches in - current to fix my problem. ] I tried to install 4.0-RELEASE on a completely new PC system, but the install failed with ATA write errors and resets. I moved the disk to another PC and installed 4.0 via manual disklabel

Re: Load average calculation?

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

Re: cvs commit: src/sys/i386/i386 support.s src/sys/kern init_sysent.c kern_prot.c kern_sig.c

On Sunday, 2 April 2000 at 17:23:49 -0700, Alfred Perlstein wrote: > * Matthew Dillon <[EMAIL PROTECTED]> [000402 17:04] wrote: >> >> :I did look at the code, struct proc is allocated from a zone, >> :meaning it won't "go away" once allocated, there's no danger in >> :dereferencing p_pptr, I don'

Re: Deadlock with vinum raid5

On Monday, 3 April 2000 at 19:23:34 +0200, Søren Schmidt wrote: > 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 >>>

Re: Deadlock with vinum raid5

On Monday, 3 April 2000 at 10:23:08 +0200, Vallo Kallaste wrote: > 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 di

Re: Perl 5.6.0?

Brad Knowles wrote: > > 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

Re: Top, vmstat, systat, etc. Broken

Thanks for the reply. Booting directly was the problem. 2:da(2,a)/boot/loader cured the problem. tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message

Re: Top, vmstat, systat, etc. Broken

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] wit

Re: Sysctl for CAM SCSI quirks?

< 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 should accept a simply-formatted text blob which lists the quirks. Th

Re: Sysctl for CAM SCSI quirks?

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 wrong

Re: 2nd call for reviews and tests: buf->bio patch

: :* 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 way

Re: Load average calculation?

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 > > proce

Re: Load average calculation?

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 count. I think you have an inc

Re: Top, vmstat, systat, etc. Broken

/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

Re: Top, vmstat, systat, etc. Broken

On Mon, 3 Apr 2000, Thomas Dean wrote: > # file /kernel > /kernel: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), > dynamically linked, not stripped I deleted the original, but are you booting through the loader, or loading the kernel directly? Doing the latter used to have proble

Re: Load average calculation?

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 d

Re: Load average calculation?

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 includ

Re: Top, vmstat, systat, etc. Broken

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 MAKE

Re: Summer/winter time problems with daily/460

> < 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 all family / O Siem / We're all the same > [EMAIL PROTECTED]

Re: Sysctl for CAM SCSI quirks?

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 c

Re: MLEN and crashes

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

Re: Load average calculation?

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

Re: MLEN and crashes

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. > > > [patc

Re: OpenSSL and Apache+ModSSL

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

Re: 2nd call for reviews and tests: buf->bio patch

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 compl

Re: Load average calculation?

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

Re: HighPoint UDMA66 ICRC READ ERROR

It seems Erik de Zeeuw wrote: > atapci1: port \ > 0xb800-0xb8ff,0xb400-0xb403,0xb000-0xb007 \ > irq 11 at device 19.0 on pci0 > ata2: at 0xb000 on atapci1 > atapci2: port \ > 0xc400-0xc4ff,0xc000-0xc003,0xbc00-0xbc07 \ > irq 11 at device 19.1 on pci0 > ... > ad4: 19574MB

Re: OpenSSL and Apache+ModSSL

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

Re: Load average calculation?

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 ave

Re: Load average calculation?

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 als

remove src/lib/libm from source tree

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 m

Re: 2nd call for reviews and tests: buf->bio patch

: : :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 prototypes behind me. : :It is regretable that vinum was broken, a

OpenSSL and Apache+ModSSL

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 m

Re: 2nd call for reviews and tests: buf->bio patch

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 prototypes behind me. It is regretable that vinum was broken, and I hope that i

Re: 2nd call for reviews and tests: buf->bio patch

:>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 ? : ::-) : :--

Re: Load average calculation?

>: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. N

Re: Another current crash (cvs-cur.6183

[formatting recovered] On Mon, Apr 03, 2000 at 10:57:46AM +0100, Nick Hibma wrote: > On Fri, 31 Mar 2000, Paul Haddad wrote: > > On Wed, 22 Mar 2000, Christopher Masto wrote: > > > I've been playing around with one of those iopener things and got > > > myself into a state I thought I could get ou

Re: Deadlock with vinum raid5

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

Re: Top, vmstat, systat, etc. Broken

To build the kernel, I # cd sys/i386/conf # config -r # cd ../../compile/ # make depend # make -j36 # make install /etc/make.conf has no uncommented lines in it. # file /kernel /kernel: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped tomdean To

Re: 2nd call for reviews and tests: buf->bio patch

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 stil

Re: 2nd call for reviews and tests: buf->bio patch

: 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 converted and use a cast from bio to :buf, prominently v

HighPoint UDMA66 ICRC READ ERROR

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

Re: Perl 5.6.0?

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 suppo

Re: Deadlock with vinum raid5

:> 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 :>

Re: Perl 5.6.0?

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 si

Re: Top, vmstat, systat, etc. Broken

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 PRO

Re: Load average calculation?

> > < 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 under what appears to be a very heavy load >

Summer/winter time problems with daily/460

< 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 same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those

Re: Load average calculation?

< 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 under what appears to be a very heavy load -GAWollman -- Gar

Re: FreeBSD random I/O performance issues

: : : :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

Re: MLEN and crashes

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 s

Re: MLEN and crashes

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 per

Re: Perl 5.6.0?

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

Re: MLEN and crashes

Poul-Henning Kamp wrote: > 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, fo

Re: Sysctl for CAM SCSI quirks?

These aren't available at boot time when you need them, are they? On Mon, 3 Apr 2000, Brad Knowles wrote: > Folks, > > I just did a bit of searching on the website, and garnered enough > information from > b/tex

Re: MLEN and crashes

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

Top, vmstat, systat, etc. Broken

# uname -a FreeBSD celebris 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Apr 3 06:49:43 PDT 2000 tomdean@celebris:/usr/src/sys/compile/CELEBRIS-SMP i386 cvsup'ed April 2 at 1230, make world April 2 2200. I think I missed something. Several things in /usr/bin are broken. # top top: nlist failed #

Re: MLEN and crashes

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 av

Re: Please review newbus patch for amd and adv

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 > bus_alloc_r

Re: Please review newbus patch for amd and adv

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

Re: MLEN and crashes

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.

hostcache

Is net/hostcache.h interface obsoleted by other or developers just don't need them? There is no uses of them in kernel sources. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message

Re: MLEN and crashes

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 somet

Re: MLEN and crashes

>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

Re: MLEN and crashes

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 th

Sysctl for CAM SCSI quirks?

Folks, I just did a bit of searching on the website, and garnered enough information from to be able to add a new "quirk" in /usr/src/sys/cam/cam_xpt.c for

Re: Perl 5.6.0?

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 c

2nd call for reviews and tests: buf->bio patch

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 converted and use a cast from bio to buf, prominently vinum an

Re: Perl 5.6.0?

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. > >

Re: Please review newbus patch for amd and adv

> 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 bus_a

Re: Load average calculation?

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 users/a

Re: Perl 5.6.0?

I have no real reason for including its functionality - I am as of yet - pretty much a perl novice. However, judging by the past, the C compiler upgrade is done in current - and I would think the perl upgrade would also be done in current. I would think you would want to track this sort of thing

Re: Perl 5.6.0?

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 Frid

Re: Perl 5.6.0?

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 th

Re: FreeBSD random I/O performance issues

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

Re: Summer/winter time problems with daily/460

> 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]] ... >

Re: MLEN and crashes

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 i

Re: Another current crash (cvs-cur.6183

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

Re: MLEN and crashes

Alfred Perlstein writes: >* Hellmuth Michaelis <[EMAIL PROTECTED]> [000403 02:12] wrote: >> Please don't misunderstand. I can fully accept accecpt and acknowledge what >> you write (i've converted the piece of code in question to malloc'ing its >> data already), i'm just a bit concerned because it

Re: Perl 5.6.0?

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 en

Re: MLEN and crashes

* 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_COMMITB

Re: MLEN and crashes

>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 d

Re: Deadlock with vinum raid5

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. Sa

Re: Deadlock with vinum raid5

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 si

Re: Deadlock with vinum raid5

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 syste

Re: Deadlock with vinum raid5

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 R

Re: Load average calculation?

:> 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, wh