At 8:26 AM +0100 2003/02/05, [EMAIL PROTECTED] wrote:
Is a disk 100% busy if it has requests outstanding at all times,
but could handle five times as many requests because they could be
sorted into the current stream of requests free of cost ? Or is
it only 20% busy ? How do you measure it
In message a05200f02ba66778c5b08@[10.0.1.2], Brad Knowles writes:
At 8:26 AM +0100 2003/02/05, [EMAIL PROTECTED] wrote:
My understanding was that a disk is 100% busy, if the heads are
constantly moving to and fro, and there is no period of time when
they aren't being yanked around. In
Hi,
I updated 4.7-RELEASE-p2 to 5.0-RELEASE using source
upgrade. Everything is fine until now.
One problem is cron. I have the following crontab of root user:
--
CVSUP=/usr/local/bin/cvsup -g -L2 -h localhost
CVSUPDIR=/b/FreeBSD/cvsup
# source sync
0 */1 *
At 9:54 AM +0100 2003/02/05, [EMAIL PROTECTED] wrote:
My understanding was that a disk is 100% busy, if the heads are
constantly moving to and fro, and there is no period of time when
they aren't being yanked around. In other words, it would be 100% if
there is always at least one outstanding
On Wed, Feb 05, 2003 at 05:57:30PM +0900, CHOI Junho wrote:
[...]
--
CVSUP=/usr/local/bin/cvsup -g -L2 -h localhost
CVSUPDIR=/b/FreeBSD/cvsup
# source sync
0 */1 * * * $CVSUP $CVSUPDIR/4_7-supfile /dev/null
20*/1 * * *
Hi
In the last ~three months now I've had 24 kernel crashes, all the
same, all happening in the same circumstances. Happens while cvsup
is running, everytime... except if I remove the checkouts file which
probably causes slowdown of cvsup operation. I have recreated the
filesystem on /dev/da2s1e
Hi All.
It's seems that smp kernel configuration doesn't work correctly on
Intel SE7500WV2 motherboard
with 2 xeon processors in 5.0-RELEASE.
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University
Ok, the problem solved. Thanks.
crontab(5) page of 4.7-RELEASE and 5.0-RELEASE cite the same thing
about variable assignment:
The name string may also be placed in quote(single or double, but
matching) to preserver leading, trailing or inner blanks.
I think the current implementation(r1.11
On Wed, 5 Feb 2003, Hidetoshi Shimokawa wrote:
Date: Wed, 05 Feb 2003 12:07:05 +0900
From: Hidetoshi Shimokawa [EMAIL PROTECTED]
To: mike [EMAIL PROTECTED]
Cc: Hidetoshi Shimokawa [EMAIL PROTECTED],
FreeBSD-Current [EMAIL PROTECTED]
Subject: Re: -current, IBM A30p 2 external FW-disks
Hi,
Looks like bad hw. Have you run memtestx86 on this machine
about 2-3 hours ? I had the same effects on one machine ...
Martin
Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED]
--
ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29,
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Muhannad Asfour
Sent: Tuesday, February 04, 2003 9:25 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Server locking hard -- A LOT!!!
Hello. I've recently faced a rather odd issue that I've
On Wed, 5 Feb 2003, Robert Covell wrote:
haven't come up with anything as I stated earlier. I'm not overclocking
or anything if that's what you're wondering. If anyone could assist me
in any way shape or form to get this working, I would appreciate it very
very much. Also, if you
I'm getting an error when trying to boot any of the 5.0-RELEASE cd's
something like:
CD Loader 1.01
Building txxx boot loader arguments
Could not find primary volume descriptor
and then it dies there. txxx is illegible in my notes, but somehow I don't
think that is significant. When booting
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
The keyword mtxname was changed to logname in the list of keywords
in bin/ps/keyword.c
Unfortunately, this table needs to be sorted, and the change broke the
sort-order.
The incredibly complex patch is included below, if someone wants to
commit it. :-)
Index: keyword.c
What exactly are you pointing out that doesn't work? It looks like
you're using the default GENERIC uni-processor kernel from the 5.0
release. You'll need to recompile your kernel for SMP.
Scott
Victor Ponomarev wrote:
Hi All.
It's seems that smp kernel configuration doesn't work
Looks like the stack got horribly corrupted... Bonus points for double
panic while dumping.
This is 5.0-RELEASE running on a Dell Inspiron 8200 laptop with ACPI
disabled (it crashes once or twice per day when ACPI is enabled).
Fatal trap 12: page fault while in kernel mode
fault virtual address
On Mon, Feb 03, 2003 at 09:24:10PM -0700, Chad David wrote:
We are having minor problems with a newer gcc generating warnings
for yacc due to yyrcsid not being used. Does anyone object to the
following patch to skeleton.c or have a better way of handling this?
-Dlint causes other problems.
Hi Scott!
You right only partially :)
The old method of kernel building doesn't work correctly (config
KERNEL;cd ../compile/KERNEL;make depend;make)
Using make buildkernel ones produces a real support for SMP but warnig
remains and power button doesn't work :(
Scott Long wrote:
What exactly
Hi Lanny!
I've used the last BIOS (0501.P05) from Intel (BMC 0.19, FRU/SDR 5.0.9,
BIOS production release 4.0 (dated 2003-12-14))
BIOS shipped with the board didn't recognize XEON 2600 Mgz processors.
Old BIOS (0468.P01) on another machine shows the same warning...
SMP work well for 4.7-STABLE
Please test this patch and let me know if you see any trouble:
http://phk.freebsd.dk/patch/tsc.patch
Things to look out for:
Detected CPU/TSC frequency, is it what it should be ?
NTP performance: is the frequency correction stable ?
Thanks in advance!
--
On Wed, Feb 05, 2003 at 11:47:44AM +0200, Vallo Kallaste wrote:
---
panic: ufs_dirbad: bad dir
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
I get those on the bento cluster when the disk is starting to fail.
dd'ing /dev/zero over it usually gives it some more life by forcing it
to
On Wed, Feb 05, 2003 at 09:46:56AM -0800, David O'Brien wrote:
On Mon, Feb 03, 2003 at 09:24:10PM -0700, Chad David wrote:
We are having minor problems with a newer gcc generating warnings
for yacc due to yyrcsid not being used. Does anyone object to the
following patch to skeleton.c or
On Sun, 2 Feb 2003, Andrey A. Chernov wrote:
On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote:
Why not? Arc4 is a) deterministic and b) good for all bits.
If you mean arc4random() function - not, because it use true randomness,
if you mean RC4 algorithm, probably yes, but we
On Sun, 2 Feb 2003 [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Andrey A. Chernov writes:
On Sun, Feb 02, 2003 at 19:32:50 +0100, [EMAIL PROTECTED] wrote:
Anyway, last time we discussed this, I think we stuck with the rand()
we had because we feared that people were using it's
On Sun, 2 Feb 2003, Juli Mallett wrote:
* De: David Malone [EMAIL PROTECTED] [ Data: 2003-02-02 ]
[ Subjecte: Re: rand() is broken ]
On Sun, Feb 02, 2003 at 02:37:25PM -0800, Steve Kargl wrote:
FreeBSD Redhat SunOS
660787754660787754645318364
FWIW - AIX
Victor,
You have something messed up. Did you update the bios correctly? Look
at your kernel as well.
We use the westville for several Servers and it boots multi-processor
just fine. In fact, the hyperthreading works and when booting you should
see 4 cpu's come up.
Cheers,
Lanny Baron
Look at the snapshot below, taken right after boot time. Most entries are
at Feb 5 22:34 which is boot time, but some other are Feb 6 01:34
which is in the future! It looks like TZ offset added for them by mistake.
Please fix this bug.
total 1
crw--- 1 root wheel 152, 0 Feb 5 22:34
In message [EMAIL PROTECTED], Andrey A. Chernov writes:
Look at the snapshot below, taken right after boot time. Most entries are
at Feb 5 22:34 which is boot time, but some other are Feb 6 01:34
which is in the future! It looks like TZ offset added for them by mistake.
Please fix this bug.
My
First of all, is this the right mailing list for issues
with FreeBSD 5.0-Release? I apologize if it is not.
I've installed it on an Athlon-500, and it's running quite
well (except it seems a bit less performant than 4.x, but
that's OK). However, I have two questions.
1. I have some shell
In message [EMAIL PROTECTED], Oliver Fromme writes
:
1. I have some shell scripts that make use of redirections
with file descriptors (31 and /dev/fd/3 etc.). Those
worked under 4.x out of the box, but didn't work in 5.0,
because there is no /dev/fd/3 in DEVFS. I solved this by
manually
Title: ¦L¶r¾÷
·s¦~§ª«°e±z¤@¥x¦L¶r¾÷
...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Is there ever a case when a vnode is locked for longer than the duration
of the syscall that locked it?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
On Wed, Feb 05, 2003 at 20:52:54 +0100, [EMAIL PROTECTED] wrote:
My guess: Your RTC has the wrong time and ntpdate or similar stepped
your clock to be correct.
It is each boot repeated effect, not one time.
I run local clock in BIOS and use adjkerntz(8) to correct kernel time to
GMT, via
In message [EMAIL PROTECTED], Andrey A. Chernov writes:
On Wed, Feb 05, 2003 at 20:52:54 +0100, [EMAIL PROTECTED] wrote:
My guess: Your RTC has the wrong time and ntpdate or similar stepped
your clock to be correct.
It is each boot repeated effect, not one time.
I run local clock in BIOS and
The problem reared it's ugly head when maildrop started mishandling
mesasges. Here is what I've tracked it down to:
I've used the code at the bottom of this message to isolate this
bug. The summary is that when I compile the code as root, and then
make it setuid (chmod u+s a.out) and then try
Title: ¦L¶r¾÷
·s¦~§ª«°e±z¤@¥x¦L¶r¾÷
...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
õ×ÁÖÁÅÍÙÅ çÏÓÐÏÄÁ
!
ðÒÅÄÓÔÁ×ÉÔÅÌØÓÔ×Ï Capital Standard Corporation ÓÏ×ÍÅÓÔÎÏ Ó
ËÏÍÐÁÎÉÅÊ A-Group ÐÒÉÇÌÁÛÁÅÔ ÷ÁÓ ÐÒÉÎÑÔØ ÕÞÁÓÔÉÅ ×
ÓÅÍÉÎÁÒÅ ÎÁ ÔÅÍÕ:
ðÒÁËÔÉÞÅÓËÉÅ ÁÓÐÅËÔÙ ÂÉÒÖÅ×ÏÊ ÔÏÒÇÏ×ÌÉ ÎÁ ÍÅÖÄÕÎÁÒÏÄÎÙÈ ÆÉÎÁÎÓÏ×ÙÈ ÒÙÎËÁÈ.
óÅÍÉÎÁÒ ÓÏÓÔÏÉÔÓÑ:
14
Anoop Ranganath wrote:
The problem reared it's ugly head when maildrop started mishandling
mesasges. Here is what I've tracked it down to:
I've used the code at the bottom of this message to isolate this
bug. The summary is that when I compile the code as root, and then
make it setuid
I've used the code at the bottom of this message to isolate this
bug. The summary is that when I compile the code as root, and then
make it setuid (chmod u+s a.out) and then try to run it as a user, the
tmpfile() fails. If I run it as root, it works fine. Conversely, I
can give user
On Wed, Feb 05, 2003 at 22:10:41 +0100, [EMAIL PROTECTED] wrote:
You can try this patch instead. It has a different side effect:
if you reset your clock the (untouched) timestamps will change.
It not helps, see 00:48 - 03:48 future jump for some entries (00:48 is
boot time):
total 1
Anoop Ranganath wrote:
I've used the code at the bottom of this message to isolate this
bug. The summary is that when I compile the code as root, and then
make it setuid (chmod u+s a.out) and then try to run it as a user, the
tmpfile() fails. If I run it as root, it works fine.
In message [EMAIL PROTECTED], Andrey A. Chernov writes:
On Wed, Feb 05, 2003 at 22:10:41 +0100, [EMAIL PROTECTED] wrote:
You can try this patch instead. It has a different side effect:
if you reset your clock the (untouched) timestamps will change.
It not helps, see 00:48 - 03:48 future jump
On Wed, Feb 05, 2003 at 23:23:26 +0100, [EMAIL PROTECTED] wrote:
Try to remove the three fix lines, and see what you get then.
Very strange effect: 3 kinds of entries appearse:
1) Jan 1 1970
2) Feb 6 01:36 (boot time)
3) Feb 6 04:36 (+3 TZ future jump)
total 1
crw-r--r-- 1 root
In message [EMAIL PROTECTED], Andrey A. Chernov writes:
On Wed, Feb 05, 2003 at 23:23:26 +0100, [EMAIL PROTECTED] wrote:
Try to remove the three fix lines, and see what you get then.
Very strange effect: 3 kinds of entries appearse:
1) Jan 1 1970
These are the intact untouched timestamps.
Terry Lambert wrote:
We need to know how we think it's supposed to work, not how you
think it's supposed to work to determine if the error is in the
code OR in the fact some old bug was fixed going from 4.7-5.0,
and the fix is biting you, OR it's a real bug.
For anyone who cares:
Additional
On Wed, Feb 05, 2003 at 23:44:08 +0100, [EMAIL PROTECTED] wrote:
2) Feb 6 01:36 (boot time)
3) Feb 6 04:36 (+3 TZ future jump)
These timestamps have been touched, and the clock has made a 3 hour
jump either forward or backward at some point.
The problem is the clock jump, not DEVFS.
On Wed, Feb 05, 2003 at 02:59:15PM -0800, Terry Lambert wrote:
Terry Lambert wrote:
We need to know how we think it's supposed to work, not how you
think it's supposed to work to determine if the error is in the
code OR in the fact some old bug was fixed going from 4.7-5.0,
and the fix is
The original poster was right.
The following patch should fix it. I'll check it in as soon as my test cycle is
over.
Cheers.
--
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
Index:
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
Mike Makonnen wrote:
The original poster was right.
The following patch should fix it. I'll check it in as soon as my test cycle is
over.
Holy heck.
Good freaking catch!
I would never have thought of looking for zebras, since it worked on
my 5.0 system, with all my test programs.
I thought
Mike Makonnen [EMAIL PROTECTED] writes:
The original poster was right.
The following patch should fix it. I'll check it in as soon as my test cycle is
over.
Cheers.
--
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9
Jacques A. Vidrine wrote:
Apparently, there was a bug fixed in 4.7 - 5.0, where the
effective UID was being tested instead of the real UID.
This is probably something that someone should MFC.
Really? I just took a quick look at this, but I have to shove off
for now. In initial tests,
Mike Barcroft wrote:
Looks like kris broke it. Shame on us for not having a WARNS level on
libc big enough to catch simple regressions like this.
FWIW, the warning doesn't show up unless the optimizer is on, even
with -Wall. So it's probable that the optimizer is not on by
default, so no
On Wed, 2003-02-05 at 08:23, Forrest W. Christian wrote:
On Wed, 5 Feb 2003, Robert Covell wrote:
haven't come up with anything as I stated earlier. I'm not overclocking
or anything if that's what you're wondering. If anyone could assist me
in any way shape or form to get this
I have seen things like this that are not software related at all but due to
a faulty power supply.
Two second story about faulty power supplies.
We had someone integrating machines for us, and we would test them
over the net. Our test was to compile perl. (Don't ask me
On Wed, 2003-02-05 at 08:20, Robert Covell wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Muhannad Asfour
Sent: Tuesday, February 04, 2003 9:25 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Server locking hard -- A LOT!!!
On Wed, 2003-02-05 at 19:23, Peter Kostouros wrote:
Hi Muhannad
Your dmesg output had the following:
lock order reversal 1st 0xc2b5d230 process lock (process lock) @
../../../kern/kern_descrip.c:2104
2nd 0xc2b5bd34 filedesc structure (filedesc structure) @
On Wed, 2003-02-05 at 20:03, Peter Kostouros wrote:
Not sure this is much help, but I have been getting many hard locks too,
from about a kernel I built around the 27th January. My symptoms are that
under a relatively heavy CPU load, upon invoking or terminating an
application, the machine
On Wed, 2003-02-05 at 21:03, Peter Kostouros wrote:
Hi
I experienced the problem with kernels from last weekend. I rebuilt
yesterday, but have not undergone high loads since. I will do thorough tests
over the weekend.
Keep in mind there have been some complaints recently, and there is new
Check your RAM.http://www.memtest86.com/
Check your BIOS settings. Try running the system with the
failsafe settings if your BIOS has that.
If all else fails put the debug options into the kernel,
add a serial console, and see if you can break into ddb.
--On Tuesday, February 04, 2003
In message [EMAIL PROTECTED], Andrey A. Chernov writes:
On Wed, Feb 05, 2003 at 23:44:08 +0100, [EMAIL PROTECTED] wrote:
2) Feb 6 01:36 (boot time)
3) Feb 6 04:36 (+3 TZ future jump)
These timestamps have been touched, and the clock has made a 3 hour
jump either forward or backward at
At 4:23 PM -0800 2003/02/05, Terry Lambert wrote:
I would never have thought of looking for zebras, since it worked on
my 5.0 system, with all my test programs.
This has been a very interesting conversation to watch. Can I
assume that there will be some more regression tests set up that
64 matches
Mail list logo
