Thanks. Committed.
Nick
On Mon, 31 May 1999, Christopher Masto wrote:
> USB stopped working as of the recent cdevsw cleanup. This fixes it.
>
> Index: usb.c
> ===
> RCS file: /usr/cvs/freebsd/src/sys/dev/usb/usb.c,v
> retrieving
¿Ã·Rªº¥Ã¤á±z¦n:
¥éó±z´¿¤µ¨Ã¥à alpha-call ªº¹q¤l¶l¥ó´£¿ô¶Ã©I(email to pager)
²{¦bÃöµM§A¤w¨ú®ø§Aªºe-mail to pager, §ÃÂä´µM¦¬¨ì§Aªº email to pager
½Ã±z°Ã¥²¤Wºô¨ú®ø,Â¥H¸`¬Ãºô¸ô¸ê·½.
¨ú®øÂ
Thanks Christopher !
Dw.
On Tue, 1 Jun 1999, Nick Hibma wrote:
>
> Thanks. Committed.
>
> Nick
>
> On Mon, 31 May 1999, Christopher Masto wrote:
>
> > USB stopped working as of the recent cdevsw cleanup. This fixes it.
> >
> > Index: usb.c
> > =
Sorry for overlooking that one.
In message
, Dirk-Willem van Gulik writes:
>
>
>Thanks Christopher !
>
>Dw.
>On Tue, 1 Jun 1999, Nick Hibma wrote:
>
>>
>> Thanks. Committed.
>>
>> Nick
>>
>> On Mon, 31 May 1999, Christopher Masto wrote:
>>
>> > USB stopped working as of the recent cdevsw cle
Hi Greg,
It appears as though the recent changes to the cdevsw structure broke
world in vinum:
"
cc -O -pipe -DVINUMDEBUG -g -O -DKERNEL -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MOD
I've blown the dust off an old ISA multiport serial card. In the
old days, I used to make it work with BSD by including "options
COM_MULTIPORT" and using the following config file directives:
device sio2at isa? port 0x280 tty flags 0x0201 irq 5 vector siointr
device sio3at isa? port 0
On Tue, 1 Jun 1999, Mark Newton wrote:
> So, guys -- What is the officially blessed way of sharing IRQs under
> newbus?
If you find out, let me know since the EISA code suffers the same problem
(though the drivers do a bit better job detecting the condition, and just
fail to attach instead of pani
Considering the number of hosts on the net today, which come and
go with no warning and with dynamic IP assignments, I would propose
that we disregard what the "old farts" felt about TCP keepalives,
and enable the sysctl net.inet.tcp.always_keepalive as default.
Setting this will make all TCP con
>
> Considering the number of hosts on the net today, which come and
> go with no warning and with dynamic IP assignments, I would propose
> that we disregard what the "old farts" felt about TCP keepalives,
> and enable the sysctl net.inet.tcp.always_keepalive as default.
>
> Setting this will ma
> Considering the number of hosts on the net today, which come and
> go with no warning and with dynamic IP assignments, I would propose
> that we disregard what the "old farts" felt about TCP keepalives,
> and enable the sysctl net.inet.tcp.always_keepalive as default.
Seeing as the amount of tra
> From: Poul-Henning Kamp
> Date: Tue, 01 Jun 1999 20:41:00 +0200
>
> Considering the number of hosts on the net today, which come and
> go with no warning and with dynamic IP assignments, I would propose
> that we disregard what the "old farts" felt about TCP keepalives,
> and enable the sysct
>Under newbus, of course, things look slightly different, so I tried
>this:
>
>device sio2at isa? port 0x280 flags 0x0201 irq 5
>device sio3at isa? port 0x288 flags 0x0201
>device sio4at isa? port 0x290 flags 0x0201
> [ ... ]
>device sio9at isa? port 0x2b8 flags 0x0201
>
>Natc
I think it is fair to say that the nature of the internet has changed
somewhat since the standards were made. Keepalives by default are not sent
until after two hours, if they are acknowledged no more packets are sent.
If not 10 more probes are sent 75 seconds apart before the connection is
declare
On Tue, Jun 01, 1999 at 12:40:34PM -0700, k...@lyris.com wrote:
> declared dead. I think it somewhat silly to say that this is consuming a
> lot of bandwidth. The average mail message (4k) is 4 packets, the average
The other issue is that you don't necessarily want the TCP connection
to close jus
> ... and keep dynamic lines up when they should otherwise have been
> allowed to fall down.
> [...]
> The second argument falls on the same reasoning in my book, I don't
> know of any on-demand lines with a timeout longer than 10 minutes
> anyway.
But it will bring the line back *up*, to no usefu
Mind you, this is only a problem because FreeBSD is to bloddy
stable: I logged into a customers server a few days a go, it had
been up for over a year, and had accumulated tons of ftpds from
WIN* machines which had gotten a vulcan nerve pinch or a different
IP#. (I'm sure windows NT servers does
this is less and less of a problem because
if you lose your link on PPP
you are liable to get a differetn IP address on your redial.
for network outages in the middle it works though..
but I'd rather have a keepalive of 10 x 4 hour pings before failure..
(or something as long..)
It's really a per
> Mind you, this is only a problem because FreeBSD is to bloddy
> stable: I logged into a customers server a few days a go, it had
> been up for over a year, and had accumulated tons of ftpds from
> WIN* machines which had gotten a vulcan nerve pinch or a different
> IP#. (I'm sure windows NT ser
In message <19990601192912.68cc115...@hub.freebsd.org>, "Jonathan M. Bresler" w
rites:
> we should consult with hte tcp-impl mailing list and get their
>take on the matter before we decide what to do here. the address is
>tcp-i...@grc.nasa.gov.
I already did, but it is such a hot issue tha
> this is less and less of a problem because
> if you lose your link on PPP
> you are liable to get a differetn IP address on your redial.
Not true. Only if you're using a dynamic IP address setup. Most
business connections have a static connection, so they'll end up with
the same IP address eve
In message <199906012011.paa16...@gungnir.fnal.gov>, "Matt Crawford" writes:
>> ... and keep dynamic lines up when they should otherwise have been
>> allowed to fall down.
>> [...]
>> The second argument falls on the same reasoning in my book, I don't
>> know of any on-demand lines with a timeout l
Why not just fix the application programs that really want timeouts but
don't implement them?
DS
> Mind you, this is only a problem because FreeBSD is to bloddy
> stable: I logged into a customers server a few days a go, it had
> been up for over a year, and had accumulated tons
> Saying that it should be an application function is bogus in my
> book, since the problem is valid for all TCP users, and there are
> clearly not any reason to duplicate the code in telnetd, ftpd,
> talkd, &c &c.
But the problem is that every application uses TCP a little bit
differentl
That is a much more genuine concern than bandwidth. Applications should
decide for themselves whether or not to use keepalives.
-Kip
On Tue, 1 Jun 1999, Matthew Hunt wrote:
> On Tue, Jun 01, 1999 at 12:40:34PM -0700, k...@lyris.com wrote:
>
> > declared de
On Tue, Jun 01, 1999 at 02:15:05PM -0600, Nate Williams wrote:
> > Can people live with a one week TCP keepalive as default ?
>
> Compromise. I like it. One week is certainly adequate for me. If I
> leave a link 'active' for longer than that w/out activity, I deserve to
> lose the link
Surely
how about a keepalive of 48 days.. the maximum a W95 machine can stay
alive... :-)
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
> > > Can people live with a one week TCP keepalive as default ?
> >
> > Compromise. I like it. One week is certainly adequate for me. If I
> > leave a link 'active' for longer than that w/out activity, I deserve to
> > lose the link
>
> Surely that violates POLA? That upsets people who have k
In message <19990601212045.a13...@bell.maths.tcd.ie>, David Malone writes:
>On Tue, Jun 01, 1999 at 02:15:05PM -0600, Nate Williams wrote:
>> > Can people live with a one week TCP keepalive as default ?
>>
>> Compromise. I like it. One week is certainly adequate for me. If I
>> leave a link 'ac
Is it that long? I honestly don't think I have ever seen one stay up for a
week. Are you sure you did not mean 48 hours? I don't speak in jest.
-Kip
On Tue, 1 Jun 1999, Julian Elischer wrote:
> how about a keepalive of 48 days.. the maximum a W95
maybe we should fix our SERVER apps..
e.g. telnetd, sshd, etc. to have 1 week timeouts
On Tue, 1 Jun 1999, David Schwartz wrote:
>
> Why not just fix the application programs that really want timeouts but
> don't implement them?
>
> DS
>
> > Mind you, this is only a problem becaus
I think newbus is come a long way now. But I still have a problem wich I
believe is related to newbus.
When I try to play and MP3 file. It's sounds like the soundcard plays the
DMA buffer 3-4 times before reloading new data into it ! (missing ints??)
Would it be possible to increase int. priority
On Tue, Jun 01, 1999 at 01:30:31PM -0700, Julian Elischer wrote:
> maybe we should fix our SERVER apps..
> e.g. telnetd, sshd, etc. to have 1 week timeouts
IIRC, it is not possible to specify how long the keepalive interval
should be, using the socket interface. Do you suggest we add a new
inter
I think he was suggesting that the apps close the connection if they
receive no data from some amount of time. (Isn't this common sense?)
DS
> On Tue, Jun 01, 1999 at 01:30:31PM -0700, Julian Elischer wrote:
>
> > maybe we should fix our SERVER apps..
> > e.g. telnetd, sshd, etc.
On Tue, Jun 01, 1999 at 01:59:48PM -0700, David Schwartz wrote:
> I think he was suggesting that the apps close the connection if they
> receive no data from some amount of time. (Isn't this common sense?)
No, I frequently keep telnet/ssh connections idle for long periods,
and have no parti
Yes, exactly, everybody wants something different. That's why you don't
want to enforce a new policy in the kernel. Let each app choose the policy
that makes the most sense for it, either with or without command line
options or whatnot.
But an application that is not happy with th
On 1999-05-27 22:12 +0400, oZZ!!! wrote:
>
> wmsound with my card too can't work correct.
> SB 128 PCI its a PCI-device & (as i known) it must be detect as es0 + pcm1
> (not pcm0), because pcm0 reserved for ISA-device (right?). Kernel at
> boot-time detect my SB 128 PCI as es0 + pcm0...
You are
This does make sense. I do some work on a mail server and I don't use
keepalives because 2 hours is _too_much_ time to be wasting a descriptor.
I periodically check how long a connection has been open and if it exceeds
a certain amount I close the connection.
-Kip
Poul-Henning Kamp writes:
> Mind you, this is only a problem because FreeBSD is to bloddy
> stable: I logged into a customers server a few days a go, it had
> been up for over a year, and had accumulated tons of ftpds from
If this customer is using wu-ftpd, it's very possible that you saw
daemons
On Wed, 2 Jun 1999, Bruce Evans wrote:
> >Under newbus, of course, things look slightly different, so I tried
> >this:
> >
> >device sio2at isa? port 0x280 flags 0x0201 irq 5
> >device sio3at isa? port 0x288 flags 0x0201
> >device sio4at isa? port 0x290 flags 0x0201
> > [ ... ]
>
> > maybe we should fix our SERVER apps..
> > e.g. telnetd, sshd, etc. to have 1 week timeouts
>
> IIRC, it is not possible to specify how long the keepalive interval
> should be, using the socket interface. Do you suggest we add a new
> interface not present in other Unix implementations, or tha
On Tue, 1 Jun 1999, Matthew N. Dodd wrote:
> On Tue, 1 Jun 1999, Mark Newton wrote:
> > So, guys -- What is the officially blessed way of sharing IRQs under
> > newbus?
>
> If you find out, let me know since the EISA code suffers the same problem
> (though the drivers do a bit better job detectin
On Wed, 2 Jun 1999, Nicolai Petri wrote:
> I think newbus is come a long way now. But I still have a problem wich I
> believe is related to newbus.
>
> When I try to play and MP3 file. It's sounds like the soundcard plays the
> DMA buffer 3-4 times before reloading new data into it ! (missing int
Stefan Esser wrote:
> On 1999-05-27 22:12 +0400, oZZ!!! wrote:
> >
> > wmsound with my card too can't work correct.
> > SB 128 PCI its a PCI-device & (as i known) it must be detect as es0 + pcm1
> > (not pcm0), because pcm0 reserved for ISA-device (right?). Kernel at
> > boot-time detect my SB 12
On Mon, 31 May 1999, Stefan Esser wrote:
> On 1999-05-27 22:12 +0400, oZZ!!! wrote:
> >
> > wmsound with my card too can't work correct.
> > SB 128 PCI its a PCI-device & (as i known) it must be detect as es0 + pcm1
> > (not pcm0), because pcm0 reserved for ISA-device (right?). Kernel at
> >
:...
Sheesh, talk about a topic to generate noise!
I think keepalive's could easily be turned on by default. At BEST, one
of the first things I did 5 years ago was to turn them on permanently
on all of our machines.
The reason is simple: Without keepalives you can end up w
Poul-Henning Kamp wrote:
>Considering the number of hosts on the net today, which come and
>go with no warning and with dynamic IP assignments, I would propose
>that we disregard what the "old farts" felt about TCP keepalives,
>and enable the sysctl net.inet.tcp.always_keepalive as default.
I thi
According to Matthew Hunt:
> I'm thinking of long-lived connections like telnet and ssh; if you're
FWIW ssh has been using keelalives for a long time by default...
KeepAlive
Specifies whether the system should send keepalive
messages to the other side. If t
On Thu, May 27, 1999 at 09:46:51PM -0700, John Polstra wrote:
> In article ,
> Doug White wrote:
>
> > I second the suggestion to 'autoprobe' PASV support, and revert to active
> > mode (w/ an appropriate msg) if PASV is refused.
>
> That won't be a good solution in practice. When passive mode
On Tue, 1 Jun 1999, Doug Rabson wrote:
> For EISA, it should be possible to add RF_SHAREABLE to the
> bus_alloc_resource call (assuming that EISA interrupts are shareable
> like pci interrupts).
The observed behavior suggests that RF_SHAREABLE is not being honored.
dpt99: DPT PM2022A/9X FW Rev. 0
<
said:
> I don't think the sio multiport stuff needs to use RF_SHAREABLE - the
> master device knows how to field interrupts for the slaves (at least thats
> how I understood it).
But the sio non-multiport stuff should be able to use RF_TIMESHARE. --
If I'm not using my serial port, I should be
On Tue, Jun 01, 1999 at 12:17:03PM +0200, Sheldon Hearn wrote:
>
> The offending line is:
>
> cdevsw[CDEV_MAJOR] = NULL; /* no cdevsw any more */
>
> Should that be vinum_cdevsw? Or did I get unlucky and pull sources
> between commits?
>
> Ciao,
> Sheldon.
I got the same err
Charles Anderson wrote:
> On Tue, Jun 01, 1999 at 12:17:03PM +0200, Sheldon Hearn wrote:
> >
> > The offending line is:
> >
> > cdevsw[CDEV_MAJOR] = NULL; /* no cdevsw any more */
> >
> > Should that be vinum_cdevsw? Or did I get unlucky and pull sources
> > between commits?
> >
Harlan Stenn wrote:
> First, what's wrong with stamping the files in a mirror with the timestamp
> it has on the master?
That's what it does already.
> Second, how much work would it be to add, say, md5 checksums to CVS.
CVSup can already do md5 checksums, but I don't see how it would
help her
Steve Kargl wrote:
>
> If you want a robust (but probably really slow) algorithm, you
> could use the revision number of a file.
I'd really prefer to have something for the whole collection. If
it has to check every file, then it will take about as long as doing
an update. I want it to be able
Alex Zepeda wrote:
> Since cvsup can take a revision of a file from a given time, why not
> use the time that the cvsup was started, this way it will ignore
> anything that was modified while cvsup was running, and the mirror
> can say, all the files are from xx.yy.zz point in time.
Something lik
On Wed, 2 Jun 1999, John Birrell wrote:
> > > cdevsw[CDEV_MAJOR] = NULL; /* no cdevsw any more */
> > >
> > > Should that be vinum_cdevsw? Or did I get unlucky and pull sources
> > > between commits?
> > >
> If you were reading the commit messages, you would have noticed that
>
Leif Neland wrote:
> On Wed, 2 Jun 1999, John Birrell wrote:
> > If you were reading the commit messages, you would have noticed that
> > phk said he mailed patches for vinum and i4b to the respective authors.
> > i4b has since been fixed (AFAIK) and vinum is waiting for Greg to stop
> > galavantin
John Birrell wrote in message ID
<199906020405.oaa05...@cimlogic.com.au>:
> If you were reading the commit messages, you would have noticed that
> phk said he mailed patches for vinum and i4b to the respective authors.
> i4b has since been fixed (AFAIK) and vinum is waiting for Greg to stop
> galav
Gary Palmer wrote:
> John Birrell wrote in message ID
> <199906020405.oaa05...@cimlogic.com.au>:
> > If you were reading the commit messages, you would have noticed that
> > phk said he mailed patches for vinum and i4b to the respective authors.
> > i4b has since been fixed (AFAIK) and vinum is wai
>> I don't think the sio multiport stuff needs to use RF_SHAREABLE - the
>> master device knows how to field interrupts for the slaves (at least thats
>> how I understood it).
>
>But the sio non-multiport stuff should be able to use RF_TIMESHARE. --
>If I'm not using my serial port, I should be abl
I'm waiting for Greg to review the patch I sent to him:
Index: vinum.c
===
RCS file: /home/ncvs/src/sys/dev/vinum/vinum.c,v
retrieving revision 1.23
diff -u -r1.23 vinum.c
--- vinum.c 1999/05/15 05:49:19 1.23
+++ vinum.c
61 matches
Mail list logo
