On Fri, 19 Nov 1999, Daniel O'Connor wrote:
> On 19-Nov-99 Wes Peters wrote:
> > install -c -o root -g wheel -m 444 obliterate.8.gz /usr/local/man8
>
> This should install to /usr/local/man/man8
..and if the page is compressed already you need to set:
MANCOMPRESSED= yes
Andrew
To Unsub
On 19-Nov-99 Wes Peters wrote:
> install -c -o root -g wheel -m 444 obliterate.8.gz /usr/local/man8
This should install to /usr/local/man/man8
> /usr/local/man//man8/obliterate.8: No such file or directory
---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.g
OK, so I finally got around to crafting up a port kit for my obliterate
program, since it's been getting some notice once again. I have one
little problem left. When I "make install" I get the following snivels:
root@homer# make install
===> Installing for obliterate-0.3
install -c -s -o root
On Thu, 18 Nov 1999, Matthew Dillon wrote:
!>
!>Sounds like a reasonable plan. I wonder if we should consider getting
!>rid of the mbuf macros entirely and simply proceduralizing them. Then
!>everything could be collected together into a single file.
!>
!>
Garance A Drosihn wrote:
> At 10:40 AM -0800 11/18/99, John Polstra wrote:
>>I don't dispute that point, but it is worth mentioning that POSIX
>>specifically guarantees that st_dev and st_ino "taken together
>>uniquely identify the file within the system." So it is OK for
>>applications to rely o
: I'm not sure if you have read the [original] patch that I had posted
:about a week ago. Both the mbuf-wait and mbuf-cluster-wait routines (as well
:as their "wakeup" routines) are just that, separate routines. The sleep
:routines are called through the MGET, MGETHDR, and MCLALLOC macros,
You should do a 'config' again before making a kernel from
-stable sources. No code changes will result but a new options file
"opt_netgraph.h" will be required by if_ethersubr.c.
an alternative is to do
touch opt_netgraph.h
in /sys/compile/MYKERNEL
This will build an empty version of this f
At 10:40 AM -0800 11/18/99, John Polstra wrote:
>I don't dispute that point, but it is worth mentioning that POSIX
>specifically guarantees that st_dev and st_ino "taken together
>uniquely identify the file within the system." So it is OK for
>applications to rely on that.
Given how many people
Hello
I'm trying to build new X terminals for my lab.
To do so I use FreeBSD 3.3-RELEASE.
The X terminal is a diskless PC with 64 Mo of ram. It perfectly boots
and I can launch the X server perfectly. Everything just runs fine.
Except for one little piece of thing.
As i wanted to mak
| You need to make sure that you are compiling against the right kernel
| headers. Not that I'm saying that you are, just making sure.
|
| Warner
Doh! Are my cheeks red.
After rebuilding /usr/include, and recompiling pccard all is well.
Thanks!
--
Dan Moschuk ([EMAIL PROTECTED])
"Cure for
John Polstra wrote:
>
> In article <01bf260d$837c8770$[EMAIL PROTECTED]>,
> Stephane Potvin <[EMAIL PROTECTED]> wrote:
> >
> > Do you think it would be possible to change the
> > .type ,@object
> > for
> > .type ,object
> > in gensetdef? By looking in the gas code I found that the
In message <[EMAIL PROTECTED]> Dan Moschuk writes:
: The steps I take are as follows:
: i) cvsup
ia) make includes in src
: ii) make/make install usr.sbin/pccard
: iii) copy new pccard.conf into place
: iv) build and reboot new kernel
You need to make sure that you are compiling against the ri
| : | if (ioctl(sp->fd, PIOCSDRV, &drv)) {
|
| Do you have any cards that work? Are you 100% positive that your
| kernel and pccardd match? ENOTTY is returned only when the pccard
| driver doesn't know about the ioctl.
|
| Warner
The steps I take are as follows:
i) cvsup
ii) make/make inst
On Wed, 17 Nov 1999, Nik Clayton wrote:
> Assuming this does go in, in time for 3.4, I'd like to mention this fact
> in a write up I'll be doing for Slashdot.
It's in 3.x and being cleaned up. Not being compiled by default yet.
> Unfortunately, I'm hampered by not knowing what on Earth the net
>
> The solution that I took with BestWWWD was to have just one process
> accept all the connections and then have it dole the descriptor out to the
> appropriate sub-processes over a unix-domain socket.
>
> -Matt
>
yes. clear
In message <[EMAIL PROTECTED]> Dan Moschuk writes:
: | if (ioctl(sp->fd, PIOCSDRV, &drv)) {
Do you have any cards that work? Are you 100% positive that your
kernel and pccardd match? ENOTTY is returned only when the pccard
driver doesn't know about the ioctl.
Warner
To Unsubscribe: send mai
In message <[EMAIL PROTECTED]> Josef Karthauser writes:
: I've got problems with F290 and ep0 and 'zzz' :)
: I've running a kernel from 20th Oct (FreeBSDCon ;) to solve it.
:
: It may be fixed more recently, but last week's kernel didn't solve it.
The suspend/card eject problem is still there.
On Wed, 17 Nov 1999, Nik Clayton wrote:
> Assuming this does go in, in time for 3.4, I'd like to mention this fact
> in a write up I'll be doing for Slashdot.
Check ftp://ftp.whistle.com/pub/archie/netgraph/index.html - that should
give you the information you need.
Kris
Cthulhu for Presi
| Greetings,
[snip]
| usr.sbin/pccard/pccardd/cardd.c, line 590:
| if (ioctl(sp->fd, PIOCSDRV, &drv)) {
|
| This is now the only thing holding me back. Anyone had a similar experience?
| Relevant configuration follows.
It's worth nothing that the problem is not ep0 specific. My 56k modem
[.]
> io 0x240-0x360
> irq 3 5 10 11 13 15
> memory 0xd4000 96k
> card "3Com" "Megahertz 589E"
> config 0x1 "ep0" ?
[.]
FWIW, I've got:
io 0x240-0x360
irq 10 11 13
memory 0xc 96k
card "3Com Corporation" "3C589"
config 0x1 "ep0" 11
[.]
so we
On Thu, Nov 18, 1999 at 09:43:34AM -0800, John Polstra wrote:
> In article <01bf260d$837c8770$[EMAIL PROTECTED]>,
> Stephane Potvin <[EMAIL PROTECTED]> wrote:
> >
> > Do you think it would be possible to change the
> > .type ,@object
> > for
> > .type ,object
> > in gensetdef? By look
I've got problems with F290 and ep0 and 'zzz' :)
I've running a kernel from 20th Oct (FreeBSDCon ;) to solve it.
It may be fixed more recently, but last week's kernel didn't solve it.
Joe
--
Josef KarthauserFreeBSD: How many times have you booted today?
Technical Manager Viagra fo
Julian (or anyone else on -hackers who can assist)
On Tue, Nov 16, 1999 at 05:28:48PM -0800, Julian Elischer wrote:
> I admit that it doesn't seem a minor addition, but
> I'd like ot get netgraph down -nto 3.x now that it has been shaken down a
> bit in 4.x
Assuming this does go in, in time fo
On Thu, 18 Nov 1999, Matthew Dillon wrote:
!>wakeup_one is really a very dangerous routine to use if you
!>aren't careful. If the one process that is woken up does not
!>do the correct thing (call wakeup_one again if it cannot
!>immediately get the resource it was waiting on) yo
In article
<[EMAIL PROTECTED]>, Robert
Watson <[EMAIL PROTECTED]> wrote:
> On Mon, 15 Nov 1999, Wes Peters wrote:
>
> > On a single system, if st_dev and st_ino are equal, you must be
> > referring to the same object. If not, I'd like to hear about it.
>
> This assumption has always caused lots o
On 18 Nov, Zach Brown wrote:
>
>> >(sysctl-ized) in FBSD (Some work have been done in Linux, since a
>> >well-known comparative benchmark offense). Would be even more usefull
>> >in SMP context.
>
> I don't think the wake-many problem was ever the cause of the poor numbers
> that comparitve benc
> Ugh. SIGIO is evil and should never be used. I tried using SIGIO for
> tty I/O many years ago and it was a total disaster - it used an
> unbelievable amount of cpu due to the signal overhead :-)
blocked, queued real-time sigio with siginfo goop slurped sync via
sigwaitinfo().. i
:
:phhttpd does this by changing who the sigio signal for incoming accepts
:gets delivered too.. after each accept it is handed to the next thread.
:
:-- zach
Ugh. SIGIO is evil and should never be used. I tried using SIGIO for
tty I/O many years ago and it was a total disaster - it use
In article <01bf260d$837c8770$[EMAIL PROTECTED]>,
Stephane Potvin <[EMAIL PROTECTED]> wrote:
>
> Do you think it would be possible to change the
> .type ,@object
> for
> .type ,object
> in gensetdef? By looking in the gas code I found that the assembler just
> ignores the @ charac
> Well, the wake-many problem hit me several times at BEST both with
> Apache and with the WWW server I wrote. We had the problem under both
> FreeBSD and IRIX. These were heavily loaded web servers and the wakeup
> issue turned into an O(N^2) problem. Every time a connection w
>FreeBSD has used wakeup_one() for this purpose since I wrote wakeup_one().
> In fact, it was the main reason I wrote it. Shortly after doing this the Apache
> Group changed to using file locking to coordinate access to the socket and
It may not be understanding the dialog correctly, but it s
:> >(sysctl-ized) in FBSD (Some work have been done in Linux, since a
:> >well-known comparative benchmark offense). Would be even more usefull
:> >in SMP context.
:
:I don't think the wake-many problem was ever the cause of the poor numbers
:that comparitve benchmark unearthed. This is only a pr
> >(sysctl-ized) in FBSD (Some work have been done in Linux, since a
> >well-known comparative benchmark offense). Would be even more usefull
> >in SMP context.
I don't think the wake-many problem was ever the cause of the poor numbers
that comparitve benchmark unearthed. This is only a problem
wakeup_one is really a very dangerous routine to use if you
aren't careful. If the one process that is woken up does not
do the correct thing (call wakeup_one again if it cannot
immediately get the resource it was waiting on) you can lockup
the system.
I would not recomm
On Thu, 18 Nov 1999, Daniel C. Sobral wrote:
> "Louis A. Mamakos" wrote:
> >
> > You don't have to use vile language in public :-)
> >
> > MH has been storing mail in it's folders like this for years/decades. While
> > it might be a little hard on the file system, it works great for the user.
>On 18 Nov, Bosko Milekic wrote:
>>
>> Although I've presently received little feedback on this...
>>
>> I found a potential problem with the patch, so I am taking the following
>> approach to bypass it. I have a feeling that there's another way, though
>> (perhaps better, conceptually).
>>
>>
On 18 Nov, Bosko Milekic wrote:
>
> Although I've presently received little feedback on this...
>
> I found a potential problem with the patch, so I am taking the following
> approach to bypass it. I have a feeling that there's another way, though
> (perhaps better, conceptually).
>
> Consider
"Louis A. Mamakos" wrote:
>
> You don't have to use vile language in public :-)
>
> MH has been storing mail in it's folders like this for years/decades. While
> it might be a little hard on the file system, it works great for the user.
Works great? Seriously, how long does it take to open a f
Although I've presently received little feedback on this...
I found a potential problem with the patch, so I am taking the following
approach to bypass it. I have a feeling that there's another way, though
(perhaps better, conceptually).
Consider a case where there are 40 instances of tsleep al
Yoshinobu Inoue wrote:
> If explicit needs for "multiple addrs per address family" are
> not clear now, I would like to try to implement just adding
> ip6_number member for this time.
I think sockaddrs are better because it allows you to change to
multiple IP-support without changing the interfac
40 matches
Mail list logo
