Forgot to Cc: here:
You can't call kernel strlen on a userland address, you must do
something like this:
How so ? It seems to work for me. For instance, I used userland
address space buffer to simulate __getcwd() syscall on the current
process (I was hacking open() syscall and log full path
* Eugene L. Vorokov [EMAIL PROTECTED] [010713 01:33] wrote:
Forgot to Cc: here:
You can't call kernel strlen on a userland address, you must do
something like this:
How so ? It seems to work for me. For instance, I used userland
address space buffer to simulate __getcwd() syscall on
Hello,
could someone please close kern/24628. This has been fixed.
And could please somebody commit the one-liner in kern/27906.
harti
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
To
* Harti Brandt [EMAIL PROTECTED] [010713 03:03] wrote:
Hello,
could someone please close kern/24628. This has been fixed.
closed.
And could please somebody commit the one-liner in kern/27906.
Assigned to Julian.
--
-Alfred Perlstein [[EMAIL PROTECTED]]
Ok, who wrote this damn
I have 4 DEC Alpha XLT's here (all are 300mhz 256m ram) that I have
wanted to put to use for some time. I really, really wanted to install
FBSD on them but FBSD doesn't support an Alpha that isn't using SRM
firmware. All 4 of mine are equipped with the latest (v5.66) AlphaBIOS
as that is all that
On Jul 13, David O'Brien [EMAIL PROTECTED] wrote:
What? You don't like TCL? Well then, be finished with your effort
before the libh guys do.
Good call. ;-)
To me, the language choice is immaterial on the face of it. The value of the
conversation was based upon some of the feature set that
Actually, this is what I did for Google, we were able to have 40 machines
installed in about an hour:
http://people.freebsd.org/~alfred/pxe/
Or
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pxe/index.html
N
--
FreeBSD: The Power to Serve http://www.freebsd.org/
Hi, folks.
When I switch to DDB to check something or debug something
usefull, mp3 player process (mpg123) hangs up and dissonate
me. So guys how do you do in such a case? I'm shure that
I'm not one having such a problem. ;-)
Maybe someone has allready ported mp3's player to kernel,
or even
Thierry == Thierry Herbelot [EMAIL PROTECTED] writes:
Thierry Alfred Perlstein wrote:
Thierry [SNIP]
http://people.freebsd.org/~alfred/pxe/
Thierry first : a big thank you for your paper : I finally could use
Thierry PXE for diskless booting (not install, just running a full,
Thierry
On Thu, 12 Jul 2001, Matt Dillon wrote:
yield an immediate improvement in available mbuf space. For the receive
side of things we can't really do anything with existing connections
(because we've already advertised that the space is available to the
remote end),
In
After talking with a number of people and reading some more papers,
I think I can put together a better road map for what should be
done to increase network performance. The good news is there are
some immediate bandaids.
In particular, I'd like those who are working on comitting network
There's stuff in the ppp(8) man page about this -- although I've
deprecated the mgetty stuff in favour of getty which is capable of
doing the same thing.
Hello all,
I want to configure a server machine I have at home to answer a phone line via
internal modem and setup a PPP connection to
Group Captain Buzzwang [EMAIL PROTECTED] writes:
I have 4 DEC Alpha XLT's here (all are 300mhz 256m ram) that I have
wanted to put to use for some time. I really, really wanted to install
FBSD on them but FBSD doesn't support an Alpha that isn't using SRM
firmware. All 4 of mine are equipped
|- Message log follows: ---|
| no valid recipients were found for this message |
|--|
| [EMAIL PROTECTED] - unknown user
write() doesn't exist in the kernel. The simple answer is you're
going to have to read what the send() syscall does and emulate it.
First, though, you need to answer the question why do I want to do
this in the kernel?
it actually exists, however the problem is that copyin and friends
On Fri, Jul 13, 2001 at 09:52:28AM -0500, Dan Nelson wrote:
Considering that w2k and Linux both have sack enabled by default, it's
not going away. Do you have a link to the thread that says sack
doesn't help?
The best I can find is at the bottom of
http://ftp.ee.lbl.gov/floyd/sacks.html
On Jul 13, Dan Nelson [EMAIL PROTECTED] wrote:
Considering that w2k and Linux both have sack enabled by default, it's
not going away. Do you have a link to the thread that says sack
doesn't help?
I agree SACK is useful, but like I say, I ended up in a flamewar IIRC
because people couldn't
Have a look at the digi driver in -current where I did this. The
caveat is that the kernel code looks ugly. From the driver's ioctl
routine:
case DIGIIO_IDENT:
return (copyout(sc-name, *(char **)data,
strlen(sc-name)
/*
* return number of characters in a userland address string
* or -1 if an illegal access occurs.
*/
int
user_strlen(uaddr)
char *uaddr;
{
int ret;
ret = -1;
do {
ch = fubyte(uaddr);
ret++;
} while (ch != 0 ch != -1);
ch = fubyte(uaddr);
And one more question, does this mean that I can't use things x = *uaddr
and *uaddr = x for userspace, but always have to use fubyte() and subyte () ?
If so, what is the reason it was done like that ?
Regards,
Eugene
To Unsubscribe: send mail to [EMAIL
In message [EMAIL PROTECTED], [EMAIL PROTECTED] w
rites:
ch = fubyte(uaddr);
And one more question, does this mean that I can't use things x = *uaddr
and *uaddr = x for userspace, but always have to use fubyte() and subyte () ?
Right.
If so, what is the reason it was done like
In a message dated 07/12/2001 6:44:38 PM Eastern Daylight Time, [EMAIL PROTECTED]
writes:
The cooling in the 2U solution is better than the 1U...
Which is pretty much all I was recommending. Im not sure why everyone is
getting so hot under the collar. You agree with me, yet you are arguing
In a message dated 07/12/2001 6:44:38 PM Eastern Daylight Time, [EMAIL PROTECTED]
writes:
The cooling in the 2U solution is better than the 1U...
Which is pretty much all I was recommending. Im not sure why everyone is
getting so hot under the collar. You agree with me, yet you are arguing
On Thu, Jul 12, 2001 at 04:45:31PM +0100, Paul Robinson wrote:
box. It's a nice 1U chasssis with four (4!) hot-swap drive bays and the
Tyan Athlon MP motherboard. http://www.appro.com/1124/index.html
Can anybody please:
1. Confirm that this works fine with FBSD (I assume it does,
Ok, I'm about half way through writing up a patch set to implement
the bandwidth delay product write-buffer calculation. It may still be a
few days before it is presentable. The TCP stack already has almost
everything required to do the calculation. Adding a fair-share piece in
* Nik Clayton [EMAIL PROTECTED] [010713 05:51] wrote:
Actually, this is what I did for Google, we were able to have 40 machines
installed in about an hour:
http://people.freebsd.org/~alfred/pxe/
Or
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pxe/index.html
Whoa leet!
On Fri, Jul 13, 2001 at 10:08:57AM -0700, Matt Dillon wrote:
The basic problem with calculating the bandwidth delay product is that
it is an inherently unstable calculation. It has to be a continuous,
I think you're doing good work, but I'm concerned you're going down
a road that's
* Eugene L. Vorokov [EMAIL PROTECTED] [010713 10:16] wrote:
/*
* return number of characters in a userland address string
* or -1 if an illegal access occurs.
*/
Then I don't get it. Won't this piece of code cycle forever fetching
first byte of the string again and again ? According
* Eugene L. Vorokov [EMAIL PROTECTED] [010713 10:24] wrote:
ch = fubyte(uaddr);
And one more question, does this mean that I can't use things x = *uaddr
and *uaddr = x for userspace, but always have to use fubyte() and subyte () ?
If so, what is the reason it was done like that
Date: Fri, 13 Jul 2001 13:29:03 -0400
From: Leo Bicknell [EMAIL PROTECTED]
(The window autotuning was an interesting read...)
I think you're doing good work, but I'm concerned you're going
down a road that's going to take a very long time to get right.
It is not necessary to calculate the
Matt Dillon wrote:
This is fairly easy to do for the transmit side of things and
would yield an immediate improvement in available mbuf space.
For the receive side of things we can't really do anything
with existing connections (because we've already advertised
that the space is available to
On Fri, Jul 13, 2001 at 10:58:06AM -0700, Terry Lambert wrote:
We can do all of this without ripping out the pre-allocation of
buffer space. I.E. forget trying to do something fancy like
swapping out buffers or virtualizing buffers or advertising more
then we actually have etc etc etc.
For those who have gigabit ethernet NICs based on the National
Semiconductor DP83820 and DP83821 controller chips and want to use
them with FreeBSD 4.2 and 4.3, there is a driver kit now available
at the following URL:
http://www.freebsd.org/~wpaul/National/dp83820_drv.tar.gz
This kit
On Thu, Jul 12, 2001 at 11:25:22AM -0700, Mike Smith wrote, and it was proclaimed:
We support ATAPI devices and has been for a long time (also CD burners)...
I believe I forgot to do a group reply on my previous reply
to Søren.
OK, it seems a misunderstanding of the term ATAPI.
Mike Silbersack wrote:
Actually, we can shrink the window, but that's strongly discouraged
by a lot of papers/books.
I doubt you really need to shrink the window ever - the fact that you've
hit the mbuf limit basically enforces that limit. And, if we're only
upping the limit based on
Alfred Perlstein wrote:
write() doesn't exist in the kernel. The simple answer is you're
going to have to read what the send() syscall does and emulate it.
First, though, you need to answer the question why do I want to do
this in the kernel?
it actually exists, however the problem is
Leo Bicknell wrote:
On Thu, Jul 12, 2001 at 08:17:14PM -0600, Drew Eckhardt wrote:
You can reduce the window size with each ACK, although this is frowned
upon.
There's frowned upon and frowned upon. :-) For instance, if
the only reason it's discouraged is because it causes connections
On Fri, 13 Jul 2001, Leo Bicknell wrote:
[...]
I think you have analysed it very well..
I can summarise:
We want the ability to make the current window to be able to grow
to a very large value if the link needs it. So sndbuf shold eb set high.
We don't want every process buffering in
Group Captain Buzzwang wrote:
I have 4 DEC Alpha XLT's here (all are 300mhz 256m ram) that I have
wanted to put to use for some time. I really, really wanted to install
FBSD on them but FBSD doesn't support an Alpha that isn't using SRM
firmware. All 4 of mine are equipped with the latest
hallo
koennte man bitte diese mail stoppen, es wird langsam laessig sie in der
freebsd-hackers list zu bekommen, wenn diese adresse nicht existiert,
dann bitte ignorieren sie doch endlich diese mail.
danke
On Fri, Jul 13, 2001 at 04:40:46PM +0200, [EMAIL PROTECTED] wrote:
diman wrote:
Hi, folks.
When I switch to DDB to check something or debug something
usefull, mp3 player process (mpg123) hangs up and dissonate
me. So guys how do you do in such a case? I'm shure that
I'm not one having such a problem. ;-)
Maybe someone has allready ported mp3's player
On Fri, Jul 13, 2001 at 01:14:07PM -0700, Julian Elischer wrote:
I would suggest that 2 * the current window may be too small
because the window might be increasing and
reception of one ack might move the window up by
the entire transmitted window size, resulting in starvation
if the
:
:On Fri, Jul 13, 2001 at 10:08:57AM -0700, Matt Dillon wrote:
: The basic problem with calculating the bandwidth delay product is that
: it is an inherently unstable calculation. It has to be a continuous,
:
:I think you're doing good work, but I'm concerned you're going down
:a road
On Fri, Jul 13, 2001 at 11:47:19AM -0700, Matt Dillon wrote:
Well, you'd be surprised. 90% of the world still uses modems, so
from the point of view of a web server it would be a big win. The
Doesn't that sort of make my point though? With the current defaults of
16k/socket there is
Leo Bicknell wrote:
1) FreeBSD's TCP windows cannot grow large enough to allow for
optimum performance. The primary obstical to raising them is
that if you do so, the system can run out of MBUF's. Schemes
need to be put in place to limit MBUF usage, and better allocate
buffers
It appears several of the psc.edu researchers have moved on to bigger
and better projects. For those interested, watch http://www.web100.org/.
They appear to be on a 3 year timeframe. I'm hoping we can get solutions
in place a lot sooner than that. :-)
--
Leo Bicknell - [EMAIL PROTECTED]
Thierry == Thierry Herbelot [EMAIL PROTECTED] writes:
Thierry David Gilbert wrote:
Thierry [SNIP]
I'm still having trouble with diskless operation. If I specify
the swap option in DHCP, the pxeboot chokes on it. If I don't
specify the swap there, things boot, but I have no swap. There
terry is servicing 1,000,000 connections..
so I'm sure the savings are real to him...
Julian
On Fri, 13 Jul 2001, Leo Bicknell wrote:
On Fri, Jul 13, 2001 at 11:47:19AM -0700, Matt Dillon wrote:
Well, you'd be surprised. 90% of the world still uses modems, so
from the point of
On Fri, Jul 13, 2001 at 12:00:04PM -0700, Terry Lambert wrote:
Not quite true. They are administratively limited, because of
the artificial fixed ratio of mbufs to clusters. This is a
design problem, not a physical limitation.
I understand they are administratively limited. Also, I
On Fri, Jul 13, 2001 at 01:48:57PM -0700, Julian Elischer wrote:
terry is servicing 1,000,000 connections..
so I'm sure the savings are real to him...
I will be the first to suggest that there are some small number
of server configurations that require some amount of hand tuning
in order to
Leo Bicknell wrote:
The problem is that the tcpcb's, inpcb's, etc., are all
pre-reserved out of the KVA space map, so that they can
be allocated safely at interrupt, or because that's how
the zone allocator works.
I think the only critical resource here is MBUF's, which today are
On Fri, Jul 13, 2001 at 10:11:07AM -0400, Leo Bicknell wrote:
c - Prevent MBUF exhaustion. Today, when you run out of MBUF's, bad
things start to happen. It would be nice to prevent that from
happening, and also to provide sysadmins some warning when it is
about to happen.
So I
On Fri, Jul 13, 2001 at 03:12:57PM -0400, Leo Bicknell wrote:
On Fri, Jul 13, 2001 at 12:00:04PM -0700, Terry Lambert wrote:
One good way to prevent this is to not unreasonably set
your window size... 8-p.
Ah, I see, so to prevent MBUF exhaustion I should not let
my socket buffers get
Leo Bicknell wrote:
B) When the system runs out of MBUF's, really bad things happen. It
would be nice to make the system handle MBUF exhaustion in a nicer
way, or avoid it.
The easiest way to do this is to know ahead of time how many
you _really_ have. Then bad things don't
Bernd Walter wrote:
On Fri, Jul 13, 2001 at 03:12:57PM -0400, Leo Bicknell wrote:
On Fri, Jul 13, 2001 at 12:00:04PM -0700, Terry Lambert wrote:
One good way to prevent this is to not unreasonably set
your window size... 8-p.
Ah, I see, so to prevent MBUF exhaustion I should not
On Fri, Jul 13, 2001 at 01:03:59PM -0700, Terry Lambert wrote:
When I run out of mbufs, I do not have bad things happen.
The bad things are an artifact of memory overcommit; if you
One thing is clear is that we're talking about two different
level of problems.
On the systems I run
I saw an old message in 1999 freebsd-hackers archive that said that block
devices were being replaced from freebsd. I tried to follow the trail of
the message but could not find anything more...Also I could not find
any bdevsw[] in the code. I shall be thankful if anyone could give any
On Fri, 13 Jul 2001, Leo Bicknell wrote:
reads through huge thread
decides just to reply to the original
Let's go through some new details:
1) FreeBSD's TCP windows cannot grow large enough to allow for
optimum performance. The primary obstical to raising them is
that if you do
:Thierry I don't know : my application was embedded and used much
:Thierry less than the 128MBytes installed in the machines (thus no
:Thierry swap!)
:
:I'm currently running in this configuration ... and have noticed that
:the system will allow clean pages (largely loaded from the
:executable's
Matt == Matt Dillon [EMAIL PROTECTED] writes:
Matt Right, you only need swap to be able to flush dirty pages.
Matt Clean code (and even clean data) pages are simply dropped and
Matt reloaded from the disk image later on if needed again. With
Matt careful program management you can run
:
:Is it not possible (or has nobody done it) to swap with the current
:diskless boot? Of all people, I would have expected Matt to be able
:to help :).
Sure you can swap. I haven't diskless-booted a box in a few months so
someone might have broken something, but I have definitely
In message [EMAIL PROTECTED], David Gilbert write
s:
Is it not possible (or has nobody done it) to swap with the current
diskless boot?
I do remember some problem with PXE and swap, but I forget the
details or if it was resolved. The diskless setup that we have
locally uses an MFS root image in
Alfred Perlstein wrote:
* Greg Lehey [EMAIL PROTECTED] [010712 21:08] wrote:
On Thursday, 12 July 2001 at 6:58:09 -0500, [EMAIL PROTECTED] wrote:
Dear Friends
I have some questions about kernel programming:
You'd be better off sending mail like this to -hackers. I've followed
On Fri, Jul 13, 2001 at 04:37:46PM -0500, Mike Silbersack wrote:
Jiangyi Liu has been working on mbuf limiting code for the past week or
so. What he has is pretty complete, I expect to get most of it committed
once Bosko gets back.
*nod*
There are tons of nice ideas presented here, but I'm
we couldn't find any reason th have block devices except in teh case for
exporting the nodes via NFS.
The buffer caching is done at teh filesystem level, and raw-io is faster
with the raw device, so it was complicating the code without giving us any
real advantage.. If you need a cached device
definitly don't stop. Talk to people doing stuff and get involved...
On Fri, 13 Jul 2001, Leo Bicknell wrote:
On Fri, Jul 13, 2001 at 04:37:46PM -0500, Mike Silbersack wrote:
Jiangyi Liu has been working on mbuf limiting code for the past week or
so. What he has is pretty complete, I
I saw an old message in 1999 freebsd-hackers archive that said that block
devices were being replaced from freebsd. I tried to follow the trail of
the message but could not find anything more...Also I could not find
any bdevsw[] in the code. I shall be thankful if anyone could give any
Julian Elischer [EMAIL PROTECTED] wrote:
we couldn't find any reason th have block devices except in teh case for
exporting the nodes via NFS.
The buffer caching is done at teh filesystem level, and raw-io is faster
with the raw device, so it was complicating the code without giving us
In a message dated 07/13/2001 12:41:06 PM Eastern Daylight Time, [EMAIL PROTECTED]
writes:
If you have the space, 2U is better. Why is that statement so irritating
to
you. Its a fact. you agree with it. So what is the problem?
The problem is that you said that 1U solutions are
In the last episode (Jul 12), Leo Bicknell said:
On Thu, Jul 12, 2001 at 05:55:39PM +0100, Paul Robinson wrote:
When I asked about SACK about 18 months ago (IIRC), the general
consensus was that it was a pile of crap, and that FBSD SHOULDN'T
implement it if possible. I however, agree that
70 matches
Mail list logo
