Hi there,
I'd like to discuss the following issues prior to
modifying the kernel.
First, the current implementation of the utility function
ether_ioctl(), which can do good job common to ethernet drivers,
won't indicate the situation when an ioctl command is unsupported
by it. It will return 0
On Thu, Oct 04, 2001 at 05:32:16PM -0600, Thierry Black wrote:
[ please don't write in HTML. Do it again and I'll drop you in a kill file.]
However, to answer the question why don't we allow users to chroot, I
present you with:
$ mkdir -p hack/usr/lib
$ mkdir -p hack/usr/bin
$ cp evilness.so
setup:
host A: dual pentium III/1GHz (Dell 2450)
host B: dual pentium III/950MHz (Intel STL2)
host C: Pentium III/1GHz (Dell GX150)
all connected at 100Mgb full duplex
all three are running FreeBSD 4.4.
all three have identical troughput when writing to
How many times did you run the test? Could it have been cached in host B, but not C?
What about disk performance?
Maybe one is ATA66 or 100, and tthe other is not? Host C may only be UDMA33, and
possibly have a slow drive, with a
lower amount of memory for caching. Did you rebuild kernels
How many times did you run the test? Could it have been cached in host B, but not
C? What about disk performance?
Maybe one is ATA66 or 100, and tthe other is not? Host C may only be UDMA33, and
possibly have a slow drive, with a
lower amount of memory for caching. Did you rebuild
And what happens when you go from A or B to C? Have you been running a top or systat
-vmstat while this is happening?
I'm thinking it might be a purely IO thing, on the proc box. I have seen similar
slowness with the default FreeBSD
install on single proc boxes, but a few sysctl's seem to do
And what happens when you go from A or B to C? Have you been running a top or systat
-vmstat while this is happening?
I'm thinking it might be a purely IO thing, on the proc box. I have seen similar
slowness with the default FreeBSD
install on single proc boxes, but a few sysctl's seem to
Oh, well, I thought you said 10mb/s, not 10MB/s .. that makes it a bit different.
I wonder if it could still be a
tcp window size or something.. Try these sysctl's on C:
vfs.nfs.gatherdelay=0
vfs.nfs.async=1
vfs.vmiodirenable=1
kern.ipc.maxsockbuf=2097152
kern.ipc.somaxconn=8192
Oh, well, I thought you said 10mb/s, not 10MB/s .. that makes it a bit
different. I wonder if it could still be a tcp window size or something.. Try these
sysctl's on C:
...
i will, but im beginning to believe that it's memory related, not the
quantity (they all have over 256M) but
heheh.. well, that definitely could be it.. Let me know what you find out..
Eric
Danny Braniss wrote:
Oh, well, I thought you said 10mb/s, not 10MB/s .. that makes it a bit
different. I wonder if it could still be a tcp window size or something.. Try these
sysctl's on C:
...
i
Greetings all,
I have two boxes that encountered the problem reported as
kern/19479. The system took 102400K of FFS vnodes, and hang.
They are two SMP boxes that both have 2.5G of physical memory.
maxusers is 384. The problem happens on 4.3-RC#0 and 4.4-RC#0.
I guess that the problem happens
In message [EMAIL PROTECTED] Yar Tikhiy writes:
: First, the current implementation of the utility function
: ether_ioctl(), which can do good job common to ethernet drivers,
: won't indicate the situation when an ioctl command is unsupported
: by it. It will return 0 in this case. Wouldn't it be
Danny Braniss wrote:
setup:
host A: dual pentium III/1GHz (Dell 2450)
host B: dual pentium III/950MHz (Intel STL2)
host C: Pentium III/1GHz (Dell GX150)
all connected at 100Mgb full duplex
all three are running FreeBSD 4.4.
all three have identical
On Mon, Oct 08, 2001 at 09:03:54AM -0600, Warner Losh wrote:
Actaully, it should return ENOTTY rather than EINVAL. ENOTTY means
that the ioctl isn't understood. I've had to fix several drivers at
work that didn't follow this convention due to ignorance on the part
of the driver writer.
I
In doing some kernel profiling analysis it seems that splx is taking up big
chunks of time.
The mbuf macros call splimp()..splx() explicitly..are they required at
interrupt time? Is there a higher performance way of protecting the necessary
code?
B
To Unsubscribe: send mail to [EMAIL
Hello,
I add script call features to newsyslog. This adds a one field to
newsyslog.conf. When newsyslog processed log file, this can execute
arbitrary program.
Situation to assume:
* For the log file which cannot use signal.
* Cases to do statistical application for log file.
A sample
Mark Peek wrote:
I made a change to page align the data segment on the powerpc port and I
noticed something strange with the i386 alignment. The data section appears
to be wasting space by aligning to the same address (offset) in the next
page rather than to the next page boundary. Below is
On Mon, Oct 08, 2001 at 12:08:14PM -0400, [EMAIL PROTECTED] wrote:
In doing some kernel profiling analysis it seems that splx is taking up big
chunks of time.
The mbuf macros call splimp()..splx() explicitly..are they required at
interrupt time? Is there a higher performance way of
I can generate hard lockups on my SMP box pretty easily. When locked,
it fails to respond to anything - I can't even get into the kernel
debugger to fire up. The lockups don't happen on UP machines under the
same conditions, so I can't even see if console debugging would work,
because I don't
Some of you might have been aware for a little while that ftp4.za.freebsd.org's
FreeBSD mirror has been broken. That has, to a large extent been due to
a total lack of space on Internet Solutions' ftp server.
As a result, I've set up a separate machine, which is now carrying
Internet Solutions'
Eric Anderson wrote:
Oh, well, I thought you said 10mb/s, not 10MB/s .. that makes
it a bit different. I wonder if it could still be a tcp window
size or something.. Try these sysctl's on C:
vfs.nfs.gatherdelay=0
vfs.nfs.async=1
vfs.vmiodirenable=1
Alfred stated that he had seen some
On Sun, Oct 07, 2001 at 06:09:45PM -0700, Kris Kennaway wrote:
On Fri, Oct 05, 2001 at 04:17:14PM -0700, Yevgeniy Aleynikov wrote:
And why FreeBSD security officer's email address always bounces my
mail?
Don't know, it's apparently still working fine for others.
Wild guess:
* John Baldwin [EMAIL PROTECTED] [011008 11:46] wrote:
On 08-Oct-01 [EMAIL PROTECTED] wrote:
In doing some kernel profiling analysis it seems that splx is taking up big
chunks of time.
That's becaause splx() can result in interrupts blocked during an spl() getting
a chance to run,
On Mon, 8 Oct 2001 11:32:14 +0400, Yar Tikhiy [EMAIL PROTECTED] said:
Second, let's look at the handling of SIOCADDMULTI/SIOCDELMULTI.
There is code obviously taken from if_loop.c and used in some
drivers, which tries to do something with the third argument data
of the if_ioctl() driver
Looks like a great interview -- congrats :-).
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
On Mon, 8 Oct 2001, Wilko Bulte wrote:
On Mon, Oct 08, 2001 at 12:31:15PM -0700, Matt Dillon wrote:
OSNews
I haven't reviewed that particular piece of code for correctness, but
noticed that the caching of the privilege check there actually does cause
problems for a variety of reasons in my work. I'd much rather individual
uses of suser() appeared in the netinet6 tree, and that appropriate
context for
Toshihiko ARAI wrote:
Hello,
I add script call features to newsyslog. This adds a one field to
newsyslog.conf. When newsyslog processed log file, this can execute
arbitrary program.
Situation to assume:
* For the log file which cannot use signal.
* Cases to do statistical
I'm working on an article that describes how to get started using Vinum
(software RAID). After a gentle introduction, it takes the reader
through the process starting with /stand/sysinstall and ending with a
sever with mirrored volumes. It also covers several hardware failure
scenarios and
28 matches
Mail list logo
