Re: Aureal Vortex soundcard
Kenneth Wayne Culver wrote: I was just wondering if anyone has gotten a soundcard based on the Vortex chip to work under FreeBSD. I know that OSS (www.opensound.com) supports it, but I don't want to use OSS because of the problems with it. If nobody has gotten that card to work, then can someone point me in the right direction to getting specs for the card and any how-to type advice on writing the driver myself for FreeBSD. I'd be willing to donate the driver to the project if I get it working well. Thanks. It's not supported, mostly because Aureal refused to release the specs (as far as I know). However, several people (Cameron Grant and Doug Rabson) are currently working on the new sound code, and according to their postings to freebsd-multimedia, they already have an almost functional Aureal Vortex 1 driver. Dean To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FS Driver writing tactic
Ustimenko Semen se...@iclub.nsu.ru writes: Is this a good tactic to write working VOP_BMAP and VOP_STRATEGY handlers, and implement VOP_READ and VOP_WRITE via bread and bwrite of own vnodes? Considering that that's how the primary filesystem layers (ufs/ffs) do it, it should be fair to assume that it's at least a reasonable way of doing things. If you *don't* do it that way...the alternative (unless you want to bypass the cache) is to bread/bwrite the underlying device from VOP_READ/VOP_WRITE, which avoids a layer of indirection when the cache doesn't get hit (not very useful). The problem is, you're not going to be able to associate cached data with vm_objects usefully because you're buffers are associated with the underlying (device) vnode rather than the file vnode. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: USB fixes for cdevsw change
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 revision 1.12
diff -u -r1.12 usb.c
--- usb.c 1999/05/30 16:51:51 1.12
+++ usb.c 1999/06/01 00:30:23
@@ -129,7 +129,7 @@
/* strategy */ nostrategy,
/* name */ usb,
/* parms */ noparms,
- /* maj */ -1,
+ /* maj */ USB_CDEV_MAJOR,
/* dump */ nodump,
/* psize */ nopsize,
/* flags */ 0,
Index: usbdi.c
===
RCS file: /usr/cvs/freebsd/src/sys/dev/usb/usbdi.c,v
retrieving revision 1.17
diff -u -r1.17 usbdi.c
--- usbdi.c 1999/05/31 11:25:21 1.17
+++ usbdi.c 1999/06/01 00:30:23
@@ -80,12 +80,6 @@
static SIMPLEQ_HEAD(, usbd_request) usbd_free_requests;
-#if defined(__FreeBSD__)
-#define USB_CDEV_MAJOR 108
-
-extern struct cdevsw usb_cdevsw;
-#endif
-
#ifdef USB_DEBUG
char *usbd_error_strs[USBD_ERROR_MAX] = {
NORMAL_COMPLETION,
Index: usbdi.h
===
RCS file: /usr/cvs/freebsd/src/sys/dev/usb/usbdi.h,v
retrieving revision 1.11
diff -u -r1.11 usbdi.h
--- usbdi.h 1999/05/20 20:02:37 1.11
+++ usbdi.h 1999/06/01 00:30:23
@@ -115,6 +115,12 @@
#define USBD_NO_TIMEOUT 0
#define USBD_DEFAULT_TIMEOUT 5000 /* ms = 5 s */
+#if defined(__FreeBSD__)
+#define USB_CDEV_MAJOR 108
+
+extern struct cdevsw usb_cdevsw;
+#endif
+
usbd_status usbd_open_pipe
__P((usbd_interface_handle iface, u_int8_t address,
u_int8_t flags, usbd_pipe_handle *pipe));
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
--
e-Mail: hi...@skylink.it
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
�бz�ȥ��W�������q�l�l�䣿��ǩI���]�w
¿Ë·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¸`¬Ùºô¸ô¸ê·½.
¨ú®øªººô§}¬O:
http://www.pager.com.tw/web/service/cancele2p.asp
Y¦³°ÝÃD: ½Ð»P§ÚÌÁpµ¸ e2p...@mail.pager.com.tw
ÁpµØ¹q«Hºô¸ôªA°È²Õ,¯¬§A«Ø±d§Ö¼Ö.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: [usb-bsd] Re: USB fixes for cdevsw change
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
===
RCS file: /usr/cvs/freebsd/src/sys/dev/usb/usb.c,v
retrieving revision 1.12
diff -u -r1.12 usb.c
--- usb.c 1999/05/30 16:51:51 1.12
+++ usb.c 1999/06/01 00:30:23
@@ -129,7 +129,7 @@
/* strategy */ nostrategy,
/* name */ usb,
/* parms */ noparms,
- /* maj */ -1,
+ /* maj */ USB_CDEV_MAJOR,
/* dump */ nodump,
/* psize */ nopsize,
/* flags */ 0,
Index: usbdi.c
===
RCS file: /usr/cvs/freebsd/src/sys/dev/usb/usbdi.c,v
retrieving revision 1.17
diff -u -r1.17 usbdi.c
--- usbdi.c 1999/05/31 11:25:21 1.17
+++ usbdi.c 1999/06/01 00:30:23
@@ -80,12 +80,6 @@
static SIMPLEQ_HEAD(, usbd_request) usbd_free_requests;
-#if defined(__FreeBSD__)
-#define USB_CDEV_MAJOR 108
-
-extern struct cdevsw usb_cdevsw;
-#endif
-
#ifdef USB_DEBUG
char *usbd_error_strs[USBD_ERROR_MAX] = {
NORMAL_COMPLETION,
Index: usbdi.h
===
RCS file: /usr/cvs/freebsd/src/sys/dev/usb/usbdi.h,v
retrieving revision 1.11
diff -u -r1.11 usbdi.h
--- usbdi.h 1999/05/20 20:02:37 1.11
+++ usbdi.h 1999/06/01 00:30:23
@@ -115,6 +115,12 @@
#define USBD_NO_TIMEOUT 0
#define USBD_DEFAULT_TIMEOUT 5000 /* ms = 5 s */
+#if defined(__FreeBSD__)
+#define USB_CDEV_MAJOR 108
+
+extern struct cdevsw usb_cdevsw;
+#endif
+
usbd_status usbd_open_pipe
__P((usbd_interface_handle iface, u_int8_t address,
u_int8_t flags, usbd_pipe_handle *pipe));
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: [usb-bsd] Re: USB fixes for cdevsw change
Sorry for overlooking that one.
In message pine.bsf.4.05.9906011039390.404-100...@brunte.ispra.webweaving.org
, 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 cleanup. This fixes it.
Index: usb.c
===
RCS file: /usr/cvs/freebsd/src/sys/dev/usb/usb.c,v
retrieving revision 1.12
diff -u -r1.12 usb.c
--- usb.c 1999/05/30 16:51:51 1.12
+++ usb.c 1999/06/01 00:30:23
@@ -129,7 +129,7 @@
/* strategy */ nostrategy,
/* name */ usb,
/* parms */ noparms,
- /* maj */ -1,
+ /* maj */ USB_CDEV_MAJOR,
/* dump */ nodump,
/* psize */ nopsize,
/* flags */ 0,
Index: usbdi.c
===
RCS file: /usr/cvs/freebsd/src/sys/dev/usb/usbdi.c,v
retrieving revision 1.17
diff -u -r1.17 usbdi.c
--- usbdi.c1999/05/31 11:25:21 1.17
+++ usbdi.c1999/06/01 00:30:23
@@ -80,12 +80,6 @@
static SIMPLEQ_HEAD(, usbd_request) usbd_free_requests;
-#if defined(__FreeBSD__)
-#define USB_CDEV_MAJOR108
-
-extern struct cdevsw usb_cdevsw;
-#endif
-
#ifdef USB_DEBUG
char *usbd_error_strs[USBD_ERROR_MAX] = {
NORMAL_COMPLETION,
Index: usbdi.h
===
RCS file: /usr/cvs/freebsd/src/sys/dev/usb/usbdi.h,v
retrieving revision 1.11
diff -u -r1.11 usbdi.h
--- usbdi.h1999/05/20 20:02:37 1.11
+++ usbdi.h1999/06/01 00:30:23
@@ -115,6 +115,12 @@
#define USBD_NO_TIMEOUT 0
#define USBD_DEFAULT_TIMEOUT 5000 /* ms = 5 s */
+#if defined(__FreeBSD__)
+#define USB_CDEV_MAJOR108
+
+extern struct cdevsw usb_cdevsw;
+#endif
+
usbd_status usbd_open_pipe
__P((usbd_interface_handle iface, u_int8_t address,
u_int8_t flags, usbd_pipe_handle *pipe));
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org Real hackers run -current on their laptop.
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
cdevsw changes broke world in vinum
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_MODULE -nostdinc -I- -I/usr/obj/usr/src/sys/modules/vinum -I/usr/obj/usr/src/sys/modules/vinum/@ -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/sys/modules/vinum/../../dev/vinum/vinum.c /usr/src/sys/modules/vinum/../../dev/vinum/vinum.c:55: `nullreset' undeclared here (not in a function) /usr/src/sys/modules/vinum/../../dev/vinum/vinum.c:55: initializer element for `vinum_cdevsw.d_bogoreset' is not constant /usr/src/sys/modules/vinum/../../dev/vinum/vinum.c: In function `vinumattach': /usr/src/sys/modules/vinum/../../dev/vinum/vinum.c:88: warning: implicit declaration of function `cdevsw_add_generic' /usr/src/sys/modules/vinum/../../dev/vinum/vinum.c: In function `vinum_modevent': /usr/src/sys/modules/vinum/../../dev/vinum/vinum.c:239: `cdevsw' undeclared (first use in this function) /usr/src/sys/modules/vinum/../../dev/vinum/vinum.c:239: (Each undeclared identifier is reported only once /usr/src/sys/modules/vinum/../../dev/vinum/vinum.c:239: for each function it appears in.) *** Error code 1 Stop. [...] 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. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
IRQ sharing with newbus
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 0x288 tty flags 0x0201 device sio4at isa? port 0x290 tty flags 0x0201 device sio5at isa? port 0x298 tty flags 0x0201 device sio6at isa? port 0x2a0 tty flags 0x0201 device sio7at isa? port 0x2a8 tty flags 0x0201 device sio8at isa? port 0x2b0 tty flags 0x0201 device sio9at isa? port 0x2b8 tty flags 0x0201 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 Natch: panic: NULL irq resource! from nexus_setup_intr() in sys/i386/i386/nexus.c while probing sio3 (and I know that sio2 is probing successfully - see below). Assuming (from the panic message) that it wants an IRQ, I've tried this: device sio2at isa? port 0x280 flags 0x0201 irq 5 conflicts device sio3at isa? port 0x288 flags 0x0201 irq 5 conflicts [ ... ] device sio9at isa? port 0x2b8 flags 0x0201 irq 5 conflicts Same bat-panic, same bat-probe. If I boot -c and disable sio3-thru-sio9, the kernel successfully probes and boots, but the slave ports on the serial card will, of course, never be seen. (This is how I know it's the sio3 probe that's causing the panic). I'm guessing the reason for this is that an IRQ that has been eaten by a device under the newbus architecture is made unavailable for subsequent devices, so the irq 5 hint on sio3-thru-sio9 is ignored, and there are no alternatives the device can try instead. So, guys -- What is the officially blessed way of sharing IRQs under newbus? - mark I tried an internal modem,new...@atdot.dotat.org but it hurt when I walked. Mark Newton - Voice: +61-4-1620-2223 - Fax: +61-8-82231777 - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IRQ sharing with newbus
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 panicing.) -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | win...@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
net.inet.tcp.always_keepalive on as default ?
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 connections send a probing ACK every couple of hours if no other activity were present on the connection, this enables the TCP stack to figure out if the other end has gone or is still there. The typical symptom that you need this is that netstat shows many connections which have been standing there for any amount of time up to your uptime, simply because your machine is waiting to receive something from the other end, and for all practical purposes, the other end doesn't exist anymore. The argument against is that this will increas trafic and keep dynamic lines up when they should otherwise have been allowed to fall down. The former argument doesn't hold water, since we're talking about a TCP segment per hour (or less) per connection. 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. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 connections send a probing ACK every couple of hours if no other activity were present on the connection, this enables the TCP stack to figure out if the other end has gone or is still there. The typical symptom that you need this is that netstat shows many connections which have been standing there for any amount of time up to your uptime, simply because your machine is waiting to receive something from the other end, and for all practical purposes, the other end doesn't exist anymore. I have no problem with this, though the traffic load created by the aggregate base of installed FreeBSD boxes over the global internet might even be measurable :-). The argument against is that this will increas trafic and keep dynamic lines up when they should otherwise have been allowed to fall down. The former argument doesn't hold water, since we're talking about a TCP segment per hour (or less) per connection. 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. Well, we run many at 1 to 3 hours, but then they have ``activity filters'' that could be tweaked to not consider these packets as real traffic so they would still timeout. I would rather save the connection table for things that are useful than save a few port/hours of connect time :-). This may have more drastic effects for others though. -- Rod Grimes - KD7CAX - (RWG25) rgri...@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD http://www.aai.dnsmgr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 traffic and congestion in the Internet, I propose we diregard what the 'old fart' PHK says and not increase the congestion with the use of keepalives. :) The 'old farts' did a good job of designing a system that happens to work better than all of the systems the 'young farts' were able to design. PHK's arguments are specious, since *any* traffic when the link is congested is more congestion. The argument against is that this will increas trafic and keep dynamic lines up when they should otherwise have been allowed to fall down. The former argument doesn't hold water, since we're talking about a TCP segment per hour (or less) per connection. That's still traffic, and congestion is congestion. On one systems that isn't a lot, but with alot of connections it can add up to a significant amount of bandwidth. 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. You don't know of any, but that doesn't mean they don't exist. Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
From: Poul-Henning Kamp p...@freebsd.org 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 sysctl net.inet.tcp.always_keepalive as default. 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. jmb To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IRQ sharing with newbus
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 Natch: panic: NULL irq resource! from nexus_setup_intr() in sys/i386/i386/nexus.c while probing sio3 (and I know that sio2 is probing successfully - see below). This was apparently broken when sio was converted to new-bus. The driver (actually mainly isa.c) used to simply skip irq allocation for devices with no irq (COM_MULTIPORT non-master ones and polled ones). Assuming (from the panic message) that it wants an IRQ, I've tried this: device sio2at isa? port 0x280 flags 0x0201 irq 5 conflicts device sio3at isa? port 0x288 flags 0x0201 irq 5 conflicts [ ... ] device sio9at isa? port 0x2b8 flags 0x0201 irq 5 conflicts Same bat-panic, same bat-probe. I don't understand why this doesn't get further, since the RF_SHAREABLE flag is (incorrectly) specified. sio fast interrupts are particularly unshareable. sio now forces fast interrupts, although this is wrong for sio pccard devices. So, guys -- What is the officially blessed way of sharing IRQs under newbus? It should be almost the same as it used to be: specify RF_SHAREABLE for allocating shared irq resources; this corresponds to not specifying INTR_EXCL in the pre-new-bus interface (intr_create()?). Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 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 telnet session is at least several hundred and an ftp session is going to be many, many more. Back in the day when people were arguing about the congestion it would create a 300baud modem was considered completely normal. Nowadays, when the average gaudy web page is 20k (read ~20 1k packets) it is safe to say that things have changed. -Kip On Tue, 1 Jun 1999, Nate Williams 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. Seeing as the amount of traffic and congestion in the Internet, I propose we diregard what the 'old fart' PHK says and not increase the congestion with the use of keepalives. :) The 'old farts' did a good job of designing a system that happens to work better than all of the systems the 'young farts' were able to design. PHK's arguments are specious, since *any* traffic when the link is congested is more congestion. The argument against is that this will increas trafic and keep dynamic lines up when they should otherwise have been allowed to fall down. The former argument doesn't hold water, since we're talking about a TCP segment per hour (or less) per connection. That's still traffic, and congestion is congestion. On one systems that isn't a lot, but with alot of connections it can add up to a significant amount of bandwidth. 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. You don't know of any, but that doesn't mean they don't exist. Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 just because you lose connectivity for a few hours. If we send keepalives by default, might that not surprise users who don't expect it? I'm thinking of long-lived connections like telnet and ssh; if you're doing work over such a connection, it would be nice if the connection endured an outage while you're away sleeping, like it does without keepalives. -- Matthew Hunt m...@astro.caltech.edu * UNIX is a lever for the http://www.pobox.com/~mph/ * intellect. -J.R. Mashey To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
... 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 useful purpose. Always think very hard before messing with TCP. And then don't. Matt Crawford To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 doesn't have this problem at all) It doesn't have to be 2h timeout. I would be happy with a default of 24h, even one week would be OK with me. But infinity is too long for my taste. Can people live with a one week TCP keepalive as default ? -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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-connection decision on what makes sense julian On Tue, 1 Jun 1999, Matthew Hunt wrote: 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 just because you lose connectivity for a few hours. If we send keepalives by default, might that not surprise users who don't expect it? I'm thinking of long-lived connections like telnet and ssh; if you're doing work over such a connection, it would be nice if the connection endured an outage while you're away sleeping, like it does without keepalives. -- Matthew Hunt m...@astro.caltech.edu * UNIX is a lever for the http://www.pobox.com/~mph/ * intellect. -J.R. Mashey To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 doesn't have this problem at all) It doesn't have to be 2h timeout. I would be happy with a default of 24h, even one week would be OK with me. But infinity is too long for my taste. 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 Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 that they don't get into it. A good summary of the traditionalist view can be found in: http://tcp-impl.grc.nasa.gov/tcp-impl/list/archive/1246.html I agree in principle, but not in practice. Having no keep-alives just doesn't work when WIN* boxes drop carrier and get another IP# when they come back, or when they just randomly crashes... 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. Of course if the application has particular hysteric requirements (ircd anyone) it can implement its own methods as well. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 everytime. 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..) I think PHK's one-week KEEPALIVE is acceptable to me. It lets me logon to freefall and have the link go bad overnight, yet still keep me on in the morning when I check it. Nate It's really a per-connection decision on what makes sense julian On Tue, 1 Jun 1999, Matthew Hunt wrote: 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 just because you lose connectivity for a few hours. If we send keepalives by default, might that not surprise users who don't expect it? I'm thinking of long-lived connections like telnet and ssh; if you're doing work over such a connection, it would be nice if the connection endured an outage while you're away sleeping, like it does without keepalives. -- Matthew Hunt m...@astro.caltech.edu * UNIX is a lever for the http://www.pobox.com/~mph/ * intellect. -J.R. Mashey To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 longer than 10 minutes anyway. But it will bring the line back *up*, to no useful purpose. set your filters right. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: net.inet.tcp.always_keepalive on as default ?
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 of ftpds from WIN* machines which had gotten a vulcan nerve pinch or a different IP#. (I'm sure windows NT servers doesn't have this problem at all) It doesn't have to be 2h timeout. I would be happy with a default of 24h, even one week would be OK with me. But infinity is too long for my taste. Can people live with a one week TCP keepalive as default ? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: net.inet.tcp.always_keepalive on as default ?
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 differently, and so the type of timeout logic that is appropriate for one application is not the same as the timeout that's appropriate for another. What type of timeout you want in a TCP connection really depends upon what you are going to do with it, and that the kernel cannot know. If an application does not timeout a TCP connection in a sane way, it is broken. It should be fixed. 'Fixing' it in the kernel simply allows the application to remain broken. DS To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 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 just because you lose connectivity for a few hours. If we send keepalives by default, might that not surprise users who don't expect it? I'm thinking of long-lived connections like telnet and ssh; if you're doing work over such a connection, it would be nice if the connection endured an outage while you're away sleeping, like it does without keepalives. -- Matthew Hunt m...@astro.caltech.edu * UNIX is a lever for the http://www.pobox.com/~mph/ * intellect. -J.R. Mashey To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 that violates POLA? That upsets people who have keepalive turned on already and find 1 week is way too long. For instance, we use keepalive to get rid of stuck netscapes, and we'd probably run out of swap or mbufs if it went up to a week. We just managed by putting this in rc.local: sysctl -w net.inet.tcp.always_keepalive=1 Make it a rc.conf knob if anything. David. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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
Re: net.inet.tcp.always_keepalive on as default ?
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 keepalive turned on already and find 1 week is way too long. For instance, we use keepalive to get rid of stuck netscapes, and we'd probably run out of swap or mbufs if it went up to a week. We just managed by putting this in rc.local: sysctl -w net.inet.tcp.always_keepalive=1 As I understand it, it would always on, and 'one-week' would be the default. Old (traditional) programs that turned it on would be given the 'traditional' timeout of 1 hour. Or something like that. Off == 1 week KEEPALIVE ON == traditiona 1 hour KEEPALIVe. Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 'active' for longer than that w/out activity, I deserve to lose the link Surely that violates POLA? That upsets people who have keepalive turned on already and find 1 week is way too long. For instance, we use keepalive to get rid of stuck netscapes, and we'd probably run out of swap or mbufs if it went up to a week. We just managed by putting this in rc.local: sysctl -w net.inet.tcp.always_keepalive=1 My intent was an implementation which would set: net.inet.tcp.keepidle: 86400 net.inet.tcp.keepintvl: 64800 net.inet.tcp.always_keepalive: 1 Leaving people to set whatever they want for a local policy. All I'm talking about is what our default should be... -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 machine can stay alive... :-) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: net.inet.tcp.always_keepalive on as default ?
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 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 doesn't have this problem at all) It doesn't have to be 2h timeout. I would be happy with a default of 24h, even one week would be OK with me. But infinity is too long for my taste. Can people live with a one week TCP keepalive as default ? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
How do I change IRQ priority for pcm ?
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 the card.. And could it make a difference ?? Nicolai Petri n...@swamp.dk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 interface not present in other Unix implementations, or that we make SO_KEEPALIVE always have a one-week timeout, surprising the other applications that expect it to be faster? Both of these seem remarkably unappealing to me. Matt -- Matthew Hunt m...@astro.caltech.edu * Inertia is a property http://www.pobox.com/~mph/ * of matter. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: net.inet.tcp.always_keepalive on as default ?
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. 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 that we make SO_KEEPALIVE always have a one-week timeout, surprising the other applications that expect it to be faster? Both of these seem remarkably unappealing to me. Matt -- Matthew Hunt m...@astro.caltech.edu * Inertia is a property http://www.pobox.com/~mph/ * of matter. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 particular desire for them to close on me. -- Matthew Hunt m...@astro.caltech.edu * Stay close to the Vorlon. http://www.pobox.com/~mph/ * To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: net.inet.tcp.always_keepalive on as default ?
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 the default TCP timeout semantics and doesn't enforce something else is broken. DS 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 particular desire for them to close on me. -- Matthew Hunt m...@astro.caltech.edu * Stay close to the Vorlon. http://www.pobox.com/~mph/ * To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: No sound (Ensoniq Audio PCI 1370)
On 1999-05-27 22:12 +0400, oZZ!!! o...@etrust.ru 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 using -current, and that will in fact attach the PCI card as pcm0. Please try the following line your kernel config file: device pcm0 at pci? And be sure to remove any line that configures pcm0 on ISA ... What's going on ? I guess that after the PCI attach of es0/pcm0, the ISA probe tries to attach an ISA card as pcm0, too, and stomps over the values filled into the device structure for the PCI card ... But I did not have time to look into this more closer, currently it is just an assumption based on the behaviour you describe (and I found a few days ago ;-) Regards, STefan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: net.inet.tcp.always_keepalive on as default ?
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 On Tue, 1 Jun 1999, 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?) 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. 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 that we make SO_KEEPALIVE always have a one-week timeout, surprising the other applications that expect it to be faster? Both of these seem remarkably unappealing to me. Matt -- Matthew Hunt m...@astro.caltech.edu * Inertia is a property http://www.pobox.com/~mph/ * of matter. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 blocked inside of accept() for PASV data connections. We used to see the same behavior here wrt. ftpds hanging around and it was almost always the case that the socket was in the LISTEN state. The code (ftpd.c:dataconn()) was changed to time out the data connection establishment using select() before calling accept(). If the client doesn't connect within 15 minutes, we log the event and the daemon exits. A diff against our code wouldn't be helpful, since we've added our own ugly warts to it (but I'll do so if you want it). If this is indeed the same problem you're seeing, tcp keepalives won't help. I haven't looked at the FreeBSD ftpd code to see if the accept is timed out somehow to prevent this (possibly inadvertent) DOS attack. -- Sudish Joseph MindSpring Enterprises To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IRQ sharing with newbus
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 [ ... ] device sio9at isa? port 0x2b8 flags 0x0201 Natch: panic: NULL irq resource! from nexus_setup_intr() in sys/i386/i386/nexus.c while probing sio3 (and I know that sio2 is probing successfully - see below). This was apparently broken when sio was converted to new-bus. The driver (actually mainly isa.c) used to simply skip irq allocation for devices with no irq (COM_MULTIPORT non-master ones and polled ones). This is almost certainly just simple breakage. I'll take a look at the code and see if I can spot something. The slave devices shouldn't be trying to allocate interrupts at all. Assuming (from the panic message) that it wants an IRQ, I've tried this: device sio2at isa? port 0x280 flags 0x0201 irq 5 conflicts device sio3at isa? port 0x288 flags 0x0201 irq 5 conflicts [ ... ] device sio9at isa? port 0x2b8 flags 0x0201 irq 5 conflicts Same bat-panic, same bat-probe. I don't understand why this doesn't get further, since the RF_SHAREABLE flag is (incorrectly) specified. sio fast interrupts are particularly unshareable. sio now forces fast interrupts, although this is wrong for sio pccard devices. So, guys -- What is the officially blessed way of sharing IRQs under newbus? It should be almost the same as it used to be: specify RF_SHAREABLE for allocating shared irq resources; this corresponds to not specifying INTR_EXCL in the pre-new-bus interface (intr_create()?). 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). -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 that we make SO_KEEPALIVE always have a one-week timeout, surprising the other applications that expect it to be faster? There *is* a well defined interface for this, namely the TCP_KEEPALIVE socket option. This is a *per connection* keepalive timer, and is implemented by for instance Solaris 2.6. See http://www.unix-systems.org/single_unix_specification_v2/xns/xti.h.html Also mentioned in Stevens vol. 2 as far as I can remember. If the FreeBSD kernel implemented TCP_KEEPALIVE, it would be rather simple to set this on an application basis. (No, unfortunately, I'm not offering to implement it.) Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IRQ sharing with newbus
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 detecting the condition, and just fail to attach instead of panicing.) 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). -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How do I change IRQ priority for pcm ?
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 ints??) Would it be possible to increase int. priority on the card.. And could it make a difference ?? I don't think interrupt priority is the problem. Its probably something dumb which I have missed so far but I haven't spotted the problem yet. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: No sound (Ensoniq Audio PCI 1370)
Stefan Esser wrote:
On 1999-05-27 22:12 +0400, oZZ!!! o...@etrust.ru 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...
What's going on ?
I guess that after the PCI attach of es0/pcm0, the ISA probe tries to
attach an ISA card as pcm0, too, and stomps over the values filled into
the device structure for the PCI card ...
That's right, and it's because the implementation is broken: the PCI driver
part in /sys/pci/es1370.c uses the name es instead of pcm. I.e. if it
used pcm, different unit numbers would get assigned to ISA and PCI
devices and no clashes would result.
Sorry I didn't make this a PR before, but I'm working on the driver and
it's in no condition to be released. This was my fault, so here's the fix:
Index: es1370.c
===
RCS file: /usr/CVS-Repository/src/sys/pci/es1370.c,v
retrieving revision 1.4
diff -u -r1.4 es1370.c
--- es1370.c1999/05/09 17:06:45 1.4
+++ es1370.c1999/06/01 21:51:37
@@ -147,7 +147,7 @@
*/
static struct pci_device es_pci_driver = {
- es,
+ pcm,
es_pci_probe,
es_pci_attach,
nsnd,
cu Jo
-
PGP Key is at http://www.mathematik.uni-ulm.de/~kuebart/kuebart.asc
What am I doing here? God, these people drinking milk!
But the clothes they wear look rather cool to me. Joachim Kuebart
I wear the same -- what am I doing here? Ulm, Germany
--- Banana Fishbones
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: No sound (Ensoniq Audio PCI 1370)
On Mon, 31 May 1999, Stefan Esser wrote: On 1999-05-27 22:12 +0400, oZZ!!! o...@etrust.ru 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 using -current, and that will in fact attach the PCI card as pcm0. Please try the following line your kernel config file: device pcm0 at pci? i have following string at my kernel: device pcm0 And be sure to remove any line that configures pcm0 on ISA ... What's going on ? I guess that after the PCI attach of es0/pcm0, the ISA probe tries to attach an ISA card as pcm0, too, and stomps over the values filled into the device structure for the PCI card ... But I did not have time to look into this more closer, currently it is just an assumption based on the behaviour you describe (and I found a few days ago ;-) I talk about my problem with Joachim Kuebart he send me a patch. Regards, STefan Rgdz, Osokin Sergey aka oZZ, o...@etrust.ru http://www.freebsd.org.ru To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
:... 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 with stale connections that hang forever due to users hanging up their modems without disconnecting telnet, pop, and other assorted sessions. Turning on keepalives will produce NO DISCERNABLE INCREASE IN NETWORK TRAFFIC. Period. Anybody who says they do doesn't understand how keepalives work. You could have a thousand active connections and it still wouldn't show a discernable increase. Daemons do not usually bother to turn on per-connection keepalives. I do not consider this a bug in the daemon, but instead simply a the default nature of this daemon is to use the default keepalive state assigned to the system as a whole. Simple. Not a bug. We should NOT go around trying to 'fix' all of our daemons. The only argument against turning on keepalives by default is that occassionally someone will expect their telnet to hang around after the network inbetween them and the remote site has been down for hours. This used to be a HUGE argument in the days where networks were less reliable and dialup lines were scarse. It is not an argument now, however. Whatever we do, we should not start messing around with the internals of the kernel trying to 'fix' a non-problem. Keepalives work just dandy as they are currently implemented, we do not have to mess with it beyond possibly changing the default in rc.conf. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
Poul-Henning Kamp p...@freebsd.org 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 think this sounds reasonable, but in this case, all the relevant knobs need to be documented. There's currently no documententation strings for any of net.inet.tcp.keepidle, net.inet.tcp.keepintvl or net.inet.tcp.keepinit. It's also not immediately obvious that these counters are all in 500msec intervals I believe we should also add sysctl knobs for tcp_keepcnt and tcp_maxpersistidle (the latter because it shares the same default value - TCPTV_KEEP_IDLE - with tcp_keepidle). And, whilst studying the code, I notice that the comments in netinet/tcp_timer.h state: * an ack segment in response from the peer. If, despite the TCPT_KEEP * initiated segments we cannot elicit a response from a peer in TCPT_MAXIDLE * amount of time probing, then we drop the connection. But there's no variable or macro `TCPT_MAXIDLE'. The connection is dropped after tcp_maxidle = tcp_keepcnt [fixed at TCPTV_KEEPCNT=8] * tcp_keepintvl [initially TCPTV_KEEPINTVL=75s, adjust via net.inet.tcp.keepintvl]. Does one of the committers feel like fixing this, or should I just send-pr it? Matthew Hunt m...@astro.caltech.edu wrote: I'm thinking of long-lived connections like telnet and ssh; if you're doing work over such a connection, it would be nice if the connection endured an outage while you're away sleeping, like it does without keepalives. I'm not sure this point is valid. An increasing percentage of such connections will be using dynamic IP addresses - so you can't be sure that you'll get the same address back. And this presupposes that neither system tries to send anything across the link whilst it's dead. Nate Williams n...@mt.sri.com wrote: Off == 1 week KEEPALIVE ON == traditiona 1 hour KEEPALIVe. ^^ 2 hours actually. I think that definitely violates POLA. If I have keepalives off (for whatever reason), I expect there to be _no_ keepalives - not just less frequent keepalives. We'd need to make net.inet.tcp.always_keepalive a 3-way switch: on, off and 'i_dont_want_an...@%$!#@_keepalives' :-) Poul-Henning Kamp p...@critter.freebsd.dk wrote: My intent was an implementation which would set: net.inet.tcp.keepidle: 86400 12-hour keepalives. That's different to previous suggestions :-). net.inet.tcp.keepintvl: 64800 I don't see any real need to extend the default keepintvl. I suspect a slow burst (currently every 75 secs) is probably better than this chinese water-torture approach. Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
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 they are sent, death of the connection or crash of one of the machines will be properly noticed. However, this means that connections will die if the route is down temporarily, and some people find it annoying. The default is yes (to send keepalives), and the client will notice if the network goes down or the remote host dies. This is important in scripts, and many users want it too. To disable keepalives, the value should be set to no in both the server and the client configura- tion files. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #71: Sun May 9 20:16:32 CEST 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FTP passive mode - a new default?
On Thu, May 27, 1999 at 09:46:51PM -0700, John Polstra wrote: In article pine.bsf.4.03.9905271100280.16577-100...@resnet.uoregon.edu, Doug White dwh...@resnet.uoregon.edu 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 doesn't work, it's almost always because a firewall on the server side is blocking the incoming data connection. The client doesn't see a refusal; its connect() call just times out. The trouble is, the timeout takes a long time (on the order of a minute or more). Certain shareware lose95 FTP servers don't know how to do passive mode. The NetBSD ftp client uses passive mode by default, but will send a PORT if the PASV is unsuccessful. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong -- Nathan Dorfman nat...@rtfm.net The statements and opinions in my Unix Admin @ Frontline Communicationspublic posts are mine, not FCC's. The light at the end of the tunnel is the headlight of an approaching train. --/usr/games/fortune To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IRQ sharing with newbus
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. 07CK, 1 channel, 64 CCBs dpt0: DPT PM2x22A/9X at slot 4 on eisa0 dpt0: DPT PM2022A/9X FW Rev. 07CK, 1 channel, 64 CCBs dpt99: DPT PM2022A/9X FW Rev. 005A, 1 channel, 64 CCBs dpt1: DPT PM2x22A/9X at slot 5 on eisa0 dpt1: No irq?! device_probe_and_attach: dpt1 attach returned -1 (The 'dpt99' lines are an artifact of the mechanism I'm using to complete the probe.) Now, since the resource ranges aren't printed anymore, you can't see that both cards are using (set to use) the same IRQ. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | win...@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IRQ sharing with newbus
On Tue, 1 Jun 1999 22:46:40 +0100 (BST), Doug Rabson d...@nlsystems.com 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 able to use my infrared -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw changes broke world in vinum
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 error, I supped around 10, did a buildworld, look at the results later in the afternoon, saw the error, did a make dirclean, re- supped, and rebuilt, same error. So I say unless the commits were REAL far apart, it wasn't between commits. -Charlie -- Charles Andersonc...@midgard.dhs.org No quote, no nothin' To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw changes broke world in vinum
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? Ciao, Sheldon. I got the same error, I supped around 10, did a buildworld, look at the results later in the afternoon, saw the error, did a make dirclean, re- supped, and rebuilt, same error. So I say unless the commits were REAL far apart, it wasn't between commits. 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 galavanting around China on his way to Usenix I doubt that he'll be able to do anything for a few weeks. Just be patient. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Announcing a new cvsup server - cvsup6.freebsd.org
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 here. Remember the problem we're trying to solve: find out quickly whether a given server would regress any of the client's files. Third, isn't the version number useful for something? Yes, there's promise there. But there are things such as tags that don't have any history associated with them. Also, not all files are RCS files. John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Announcing a new cvsup server - cvsup6.freebsd.org
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 to decide very quickly on a per-collection basis before updating anything. Isn't this a monotonically increasing number? The version numbers should monotonically increase. But they don't always do so, in practice. CVS repository managers occasionally have to do damage control that entails deleting deltas. Would it be possible to compute md5 signatures on a per-file per-collection basis? The cvsup server would have, for example, src-bin.md5 which contains a list of all files in the src-bin collection and their md5 signatures. When a connection is made to the server, the server sends src-bin.md5 to the client. The client compares the local src-bin.md5 with the server's src-bin.md5. Any difference would indicate a file has changed, and the client then requests the server to send the changed file(s). But comparing checksums only tells you whether the files are (probably) the same or not. It doesn't tell you which one is more up-to-date. John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Announcing a new cvsup server - cvsup6.freebsd.org
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 like that might help. It's true that CVSup could ignore deltas newer than when it started. Tags don't have dates associated with them, so they're harder. But they do point to deltas, so still there's hope. And then have xntpd or somesuch running, so that all the cvsup mirrors have the same idea of when xx.yy.zz was.. Cheater! ;-) Seriously, there are all kinds of mirrors out there, and you really can't be sure they'll all have accurate timekeeping. John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw changes broke world in vinum
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 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 galavanting around China on his way to Usenix I doubt that he'll be able to do anything for a few weeks. Just be patient. I don't use vinum, but how do I turn it off in my config-file? Leif To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw changes broke world in vinum
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 galavanting around China on his way to Usenix I doubt that he'll be able to do anything for a few weeks. Just be patient. I don't use vinum, but how do I turn it off in my config-file? You should just edit the parent Makefile (sys/modules/Makefile) and remove vinum if that's where the build barfs. [ IMHO this is one situation where phk should just go ahead and make the edit. ] -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw changes broke world in vinum
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 galavanting around China on his way to Usenix I doubt that he'll be able to do anything for a few weeks. Just be patient. If its on the order of weeks for this to get fixed, I think removing the vinum module from the build process is in order ... its breaking the snapshots by stopping make world/make release... Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw changes broke world in vinum
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 waiting for Greg to stop galavanting around China on his way to Usenix I doubt that he'll be able to do anything for a few weeks. Just be patient. If its on the order of weeks for this to get fixed, I think removing the vinum module from the build process is in order ... its breaking the snapshots by stopping make world/make release... I think it would be better to make phk's commits. That way vinum should keep working and be up-to-date for those people who would be hurt by using an incompatible module. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
