From owner-freebsd-hackers Sun Dec 2 0: 5:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.10]) by hub.freebsd.org (Postfix) with ESMTP id 9BA2A37B419 for ; Sun, 2 Dec 2001 00:05:49 -0800 (PST) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=exim) by cs.huji.ac.il with esmtp (Exim 3.32 #1) id 16ARdB-00024x-00; Sun, 02 Dec 2001 10:05:45 +0200 Received: from localhost ([127.0.0.1] helo=pampa.cs.huji.ac.il ident=danny) by pampa.cs.huji.ac.il with esmtp (Exim 3.22 #2) id 16ARdB-000FHc-00; Sun, 02 Dec 2001 10:05:45 +0200 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: Richard Sharpe , freebsd-hackers@FreeBSD.ORG Subject: Re: Patch #2 (was Re: Found the problem, w/patch (was Re: FreeBSD performing worse than Linux?)) In-Reply-To: Message from Matthew Dillon of "Sat, 01 Dec 2001 13:21:05 PST." <200112012121.fB1LL5w36881@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 02 Dec 2001 10:05:45 +0200 From: Danny Braniss Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG hum, do i get a speed ticket? i did some tests before applying your patches: lizard> ./tbench 1 dev .1 clients started ..............+* Throughput 6.10567 MB/sec (NB=7.63209 MB/sec 61.0567 MBit/sec) lizard> ./tbench 2 dev ..2 clients started ........................+....+** Throughput 7.71796 MB/sec (NB=9.64745 MB/sec 77.1796 MBit/sec) lizard> ./tbench 3 dev ...3 clients started .....................................+....+.+*** Throughput 9.17012 MB/sec (NB=11.4627 MB/sec 91.7012 MBit/sec) lizard> ./tbench 4 dev ....4 clients started ........................................................++++**** Throughput 10.3365 MB/sec (NB=12.9207 MB/sec 103.365 MBit/sec) lizard> ./tbench 5 dev .....5 clients started .............................................................+.......++.+.+**** * Throughput 10.5219 MB/sec (NB=13.1523 MB/sec 105.219 MBit/sec) > Richard (and others), please try this patch. With this patch I > get the following between two machines connected via a 100BaseTX > switch (full duplex): > > ---------------- > > test1:/home/dillon/dbench> ./tbench 1 test2 > .1 clients started > ..............+* > Throughput 6.13925 MB/sec (NB=7.67406 MB/sec 61.3925 MBit/sec) 1 procs > test1:/home/dillon/dbench> ./tbench 2 test2 > ..2 clients started > ............................++** > Throughput 8.37795 MB/sec (NB=10.4724 MB/sec 83.7795 MBit/sec) 2 procs > > ---------------- > > On localhost I get: > > ---------------- > > test1:/home/dillon/dbench> ./tbench 1 localhost > .1 clients started > ..............+* > Throughput 25.7156 MB/sec (NB=32.1445 MB/sec 257.156 MBit/sec) 1 procs > test1:/home/dillon/dbench> ./tbench 2 localhost > ..2 clients started > ............................++** > Throughput 36.5428 MB/sec (NB=45.6785 MB/sec 365.428 MBit/sec) 2 procs > test1:/home/dillon/dbench> > > ---------------- > > This is WITHOUT changing the default send and receive tcp buffers.. > they're both 16384. > > The bug I found is that when recv() is used with MSG_WAITALL, > which is what tbench does, soreceive() will block waiting for all > available input WITHOUT ever calling pr->pr_usrreqs->pru_rcvd(), > which means that if the sender filled up the receive buffer (16K default) > the receiver will never ack the 0 window... that is until the idle code > takes over after 5 seconds. > > -Matt > > Index: uipc_socket.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v > retrieving revision 1.68.2.16 > diff -u -r1.68.2.16 uipc_socket.c > --- uipc_socket.c 2001/06/14 20:46:06 1.68.2.16 > +++ uipc_socket.c 2001/12/01 21:09:13 > @@ -910,6 +910,14 @@ > !sosendallatonce(so) && !nextrecord) { > if (so->so_error || so->so_state & SS_CANTRCVMORE) > break; > + /* > + * The window might have closed to zero, make > + * sure we send an ack now that we've drained > + * the buffer or we might end up blocking until > + * the idle takes over (5 seconds). > + */ > + if (pr->pr_flags & PR_WANTRCVD && so->so_pcb) > + (*pr->pr_usrreqs->pru_rcvd)(so, flags); > error = sbwait(&so->so_rcv); > if (error) { > sbunlock(&so->so_rcv); > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 0:11: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id B460037B405 for ; Sun, 2 Dec 2001 00:10:53 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB28Arr77757; Sun, 2 Dec 2001 00:10:53 -0800 (PST) (envelope-from dillon) Date: Sun, 2 Dec 2001 00:10:53 -0800 (PST) From: Matthew Dillon Message-Id: <200112020810.fB28Arr77757@apollo.backplane.com> To: Matthew Dillon Cc: Richard Sharpe , freebsd-hackers@FreeBSD.ORG Subject: Patch #3 (TCP / Linux / Performance) References: <20011128153817.T61580@monorchid.lemis.com> <15364.38174.938500.946169@caddis.yogotech.com> <20011128104629.A43642@walton.maths.tcd.ie> <5.1.0.14.1.20011130181236.00a80160@postamt1.charite.de> <200111302047.fAUKlT811090@apollo.backplane.com> <200111302130.fAULUU324648@apollo.backplane.com> <3C08CF9D.2030109@ns.aus.com> <200112012138.fB1LcG837063@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've fixed a couple of additional problems. * tbench() assumes that accept() propogates the NODELAY tcp option. It doesn't in FreeBSD. Er, it didn't in FreeBSD... my patch fixes this. * If the transwmitter sees a 0 window it stalls waiting for an ack. However, if delayed acks are turned on the receiver will not acknowledge a drain of the buffer immediately, it will delay. This causes severe issues with localhost. I've included my patch as it currently stands. This patch is against -stable. With this patch tbench should work properly with delayed acks turned on (as well as newreno). There are still a couple of unresolved issues. I noticed that when connecting locally TCP is non-optimal... when sending a 4100 byte data block it sends two 1460 byte packets (maxseg), then one 1176 byte packet and one 4 byte packet. The 1176 byte packet is sent in response to a received ack, causing the last bit of info to be written out using a small packet. This only occurs on localhost connections due to the way the stack works. I will be committing these to both -current now, and -stable tomorrow. tbench results: test1 (from test1) - uses TCP's 16K receive & xmit buffers localhost (from test1) - uses localhost's 48K buffers test2 (from test1) - uses TCP's 16K receive & xmit buffers (100BaseTX full duplex switch) delayed acks turned on (default) new reno turned on (default) ./tbench 1 test1 Throughput 23.3951 MB/sec (NB=29.2439 MB/sec 233.951 MBit/sec) 1 procs ./tbench 1 localhost Throughput 29.6299 MB/sec (NB=37.0374 MB/sec 296.299 MBit/sec) 1 procs ./tbench 2 localhost Throughput 42.963 MB/sec (NB=53.7038 MB/sec 429.63 MBit/sec) 2 procs ./tbench 3 localhost Throughput 43.9328 MB/sec (NB=54.9161 MB/sec 439.328 MBit/sec) 3 procs ./tbench 1 test2 Throughput 6.43315 MB/sec (NB=8.04144 MB/sec 64.3315 MBit/sec) 1 procs ./tbench 2 test2 Throughput 8.94636 MB/sec (NB=11.183 MB/sec 89.4636 MBit/sec) 2 procs ./tbench 3 test2 Throughput 9.82137 MB/sec (NB=12.2767 MB/sec 98.2137 MBit/sec) 3 procs With delayed acks turned off: ./tbench 1 test1 Throughput 19.8444 MB/sec (NB=24.8055 MB/sec 198.444 MBit/sec) 1 procs ./tbench 1 localhost Throughput 26.1442 MB/sec (NB=32.6802 MB/sec 261.442 MBit/sec) 1 procs ./tbench 2 localhost Throughput 37.1861 MB/sec (NB=46.4826 MB/sec 371.861 MBit/sec) 2 procs ./tbench 3 localhost Throughput 37.5582 MB/sec (NB=46.9477 MB/sec 375.582 MBit/sec) 3 procs ./tbench 1 test2 Throughput 6.32798 MB/sec (NB=7.90998 MB/sec 63.2798 MBit/sec) 1 procs ./tbench 2 test2 Throughput 8.4896 MB/sec (NB=10.612 MB/sec 84.896 MBit/sec) 2 procs ./tbench 3 test2 Throughput 9.57453 MB/sec (NB=11.9682 MB/sec 95.7453 MBit/sec) 3 procs -Matt Index: netinet/tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.107.2.18 diff -u -r1.107.2.18 tcp_input.c --- netinet/tcp_input.c 2001/11/12 22:11:24 1.107.2.18 +++ netinet/tcp_input.c 2001/12/02 07:47:01 @@ -158,10 +158,15 @@ #endif /* - * Indicate whether this ack should be delayed. + * Indicate whether this ack should be delayed. We can delay the ack if + * - delayed acks are enabled and + * - there is no delayed ack timer in progress and + * - our last ack wasn't a 0-sized window. We never want to delay + * the ack that opens up a 0-sized window. */ #define DELAY_ACK(tp) \ - (tcp_delack_enabled && !callout_pending(tp->tt_delack)) + (tcp_delack_enabled && !callout_pending(tp->tt_delack) && \ + (tp->t_flags & TF_RXWIN0SENT) == 0) static int tcp_reass(tp, th, tlenp, m) @@ -840,7 +845,7 @@ #endif tp = intotcpcb(inp); tp->t_state = TCPS_LISTEN; - tp->t_flags |= tp0->t_flags & (TF_NOPUSH|TF_NOOPT); + tp->t_flags |= tp0->t_flags & (TF_NOPUSH|TF_NOOPT|TF_NODELAY); /* Compute proper scaling value from buffer space */ while (tp->request_r_scale < TCP_MAX_WINSHIFT && Index: netinet/tcp_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_output.c,v retrieving revision 1.39.2.11 diff -u -r1.39.2.11 tcp_output.c --- netinet/tcp_output.c 2001/11/30 21:34:28 1.39.2.11 +++ netinet/tcp_output.c 2001/12/02 07:37:29 @@ -116,7 +116,9 @@ u_char opt[TCP_MAXOLEN]; unsigned ipoptlen, optlen, hdrlen; int idle, sendalot; +#if 0 int maxburst = TCP_MAXBURST; +#endif struct rmxp_tao *taop; struct rmxp_tao tao_noncached; #ifdef INET6 @@ -268,28 +270,38 @@ win = sbspace(&so->so_rcv); /* - * Sender silly window avoidance. If connection is idle - * and can send all data, a maximum segment, - * at least a maximum default-size segment do it, - * or are forced, do it; otherwise don't bother. - * If peer's buffer is tiny, then send - * when window is at least half open. - * If retransmitting (possibly after persist timer forced us - * to send into a small window), then must resend. + * Sender silly window avoidance. We transmit under the following + * conditions when len is non-zero: + * + * - We have a full segment + * - This is the last buffer in a write()/send() and we are + * either idle or running NODELAY + * - we've timed out (e.g. persist timer) + * - we have more then 1/2 the maximum send window's worth of + * data (receiver may be limited the window size) + * - we need to retransmit */ if (len) { if (len == tp->t_maxseg) goto send; - if (!(tp->t_flags & TF_MORETOCOME) && - (idle || tp->t_flags & TF_NODELAY) && - (tp->t_flags & TF_NOPUSH) == 0 && - len + off >= so->so_snd.sb_cc) + /* + * NOTE! on localhost connections an 'ack' from the remote + * end may occur synchronously with the output and cause + * us to flush a buffer queued with moretocome. XXX + * + * note: the len + off check is almost certainly unnecessary. + */ + if (!(tp->t_flags & TF_MORETOCOME) && /* normal case */ + (idle || (tp->t_flags & TF_NODELAY)) && + len + off >= so->so_snd.sb_cc && + (tp->t_flags & TF_NOPUSH) == 0) { goto send; - if (tp->t_force) + } + if (tp->t_force) /* typ. timeout case */ goto send; if (len >= tp->max_sndwnd / 2 && tp->max_sndwnd > 0) goto send; - if (SEQ_LT(tp->snd_nxt, tp->snd_max)) + if (SEQ_LT(tp->snd_nxt, tp->snd_max)) /* retransmit case */ goto send; } @@ -688,6 +700,20 @@ if (win > (long)TCP_MAXWIN << tp->rcv_scale) win = (long)TCP_MAXWIN << tp->rcv_scale; th->th_win = htons((u_short) (win>>tp->rcv_scale)); + + /* + * Adjust the RXWIN0SENT flag - indicate that we have advertised + * a 0 window. This may cause the remote transmitter to stall. This + * flag tells soreceive() to disable delayed acknowledgements when + * draining the buffer. This can occur if the receiver is attempting + * to read more data then can be buffered prior to transmitting on + * the connection. + */ + if (win == 0) + tp->t_flags |= TF_RXWIN0SENT; + else + tp->t_flags &= ~TF_RXWIN0SENT; + if (SEQ_GT(tp->snd_up, tp->snd_nxt)) { th->th_urp = htons((u_short)(tp->snd_up - tp->snd_nxt)); th->th_flags |= TH_URG; Index: netinet/tcp_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_var.h,v retrieving revision 1.56.2.8 diff -u -r1.56.2.8 tcp_var.h --- netinet/tcp_var.h 2001/08/22 00:59:13 1.56.2.8 +++ netinet/tcp_var.h 2001/12/01 21:40:46 @@ -95,6 +95,7 @@ #define TF_SENDCCNEW 0x08000 /* send CCnew instead of CC in SYN */ #define TF_MORETOCOME 0x10000 /* More data to be appended to sock */ #define TF_LQ_OVERFLOW 0x20000 /* listen queue overflow */ +#define TF_RXWIN0SENT 0x40000 /* sent a receiver win 0 in response */ int t_force; /* 1 if forcing out a byte */ tcp_seq snd_una; /* send unacknowledged */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 0:28:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 24A8937B416 for ; Sun, 2 Dec 2001 00:28:40 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB28S5R86316; Sun, 2 Dec 2001 00:28:05 -0800 (PST) (envelope-from dillon) Date: Sun, 2 Dec 2001 00:28:05 -0800 (PST) From: Matthew Dillon Message-Id: <200112020828.fB28S5R86316@apollo.backplane.com> To: Danny Braniss Cc: Richard Sharpe , freebsd-hackers@FreeBSD.ORG Subject: Re: Patch #2 (was Re: Found the problem, w/patch (was Re: FreeBSD performing worse than Linux?)) References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG That's reasonable with patch #2 and delayed acks turned off (assuming this is a 100BaseTX network you are testing on). You should get slightly better results with Patch #3 and delayed acks turned on. -Matt :hum, do i get a speed ticket? :i did some tests before applying your patches: : :lizard> ./tbench 1 dev :.1 clients started :..............+* :Throughput 6.10567 MB/sec (NB=7.63209 MB/sec 61.0567 MBit/sec) :lizard> ./tbench 2 dev :..2 clients started :........................+....+** :Throughput 7.71796 MB/sec (NB=9.64745 MB/sec 77.1796 MBit/sec) :lizard> ./tbench 3 dev :...3 clients started :.....................................+....+.+*** :Throughput 9.17012 MB/sec (NB=11.4627 MB/sec 91.7012 MBit/sec) :lizard> ./tbench 4 dev :....4 clients started :........................................................++++**** :Throughput 10.3365 MB/sec (NB=12.9207 MB/sec 103.365 MBit/sec) :lizard> ./tbench 5 dev :.....5 clients started :.............................................................+.......++.+.+**** :* :Throughput 10.5219 MB/sec (NB=13.1523 MB/sec 105.219 MBit/sec) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 0:36:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.10]) by hub.freebsd.org (Postfix) with ESMTP id 0A41737B405 for ; Sun, 2 Dec 2001 00:36:32 -0800 (PST) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=exim) by cs.huji.ac.il with esmtp (Exim 3.32 #1) id 16AS6v-0002lP-00; Sun, 02 Dec 2001 10:36:29 +0200 Received: from localhost ([127.0.0.1] helo=pampa.cs.huji.ac.il ident=danny) by pampa.cs.huji.ac.il with esmtp (Exim 3.22 #2) id 16AS6u-000FKm-00; Sun, 02 Dec 2001 10:36:28 +0200 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: Richard Sharpe , freebsd-hackers@FreeBSD.ORG Subject: Re: Patch #2 (was Re: Found the problem, w/patch (was Re: FreeBSD performing worse than Linux?)) In-reply-to: Your message of Sun, 2 Dec 2001 00:28:05 -0800 (PST) . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 02 Dec 2001 10:36:28 +0200 From: Danny Braniss Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > That's reasonable with patch #2 and delayed acks turned off (assuming > this is a 100BaseTX network you are testing on). You should get > slightly better results with Patch #3 and delayed acks turned on. > > -Matt i did not apply any patches - yet -, net.inet.tcp.newreno is 1, on both hosts. they are connected at 100mb, so the strange numbers are when the number of clients is > 3! (att 100Mbit/sec how come i get > 100?) danny PS: just forgot, congrat on a terrific job!!! im still amazed > > :hum, do i get a speed ticket? > :i did some tests before applying your patches: > : > :lizard> ./tbench 1 dev > :.1 clients started > :..............+* > :Throughput 6.10567 MB/sec (NB=7.63209 MB/sec 61.0567 MBit/sec) > :lizard> ./tbench 2 dev > :..2 clients started > :........................+....+** > :Throughput 7.71796 MB/sec (NB=9.64745 MB/sec 77.1796 MBit/sec) > :lizard> ./tbench 3 dev > :...3 clients started > :.....................................+....+.+*** > :Throughput 9.17012 MB/sec (NB=11.4627 MB/sec 91.7012 MBit/sec) > :lizard> ./tbench 4 dev > :....4 clients started > :........................................................++++**** > :Throughput 10.3365 MB/sec (NB=12.9207 MB/sec 103.365 MBit/sec) > :lizard> ./tbench 5 dev > :.....5 clients started > :.............................................................+.......++.+.+**** > :* > :Throughput 10.5219 MB/sec (NB=13.1523 MB/sec 105.219 MBit/sec) > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 0:44:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 24F6737B417; Sun, 2 Dec 2001 00:44:36 -0800 (PST) Received: (from sos@localhost) by freebsd.dk (8.11.6/8.11.6) id fB28iTi52838; Sun, 2 Dec 2001 09:44:29 +0100 (CET) (envelope-from sos) From: Søren Schmidt Message-Id: <200112020844.fB28iTi52838@freebsd.dk> Subject: Re: UDMA33 and SiS5591 on FreeBSD 4.4-RELEASE In-Reply-To: <3C09D6F9.7070504@ns.aus.com> To: rsharpe@ns.aus.com Date: Sun, 2 Dec 2001 09:44:29 +0100 (CET) Cc: Greg Lehey , Zwane Mwaikambo , freebsd-hackers@FreeBSD.ORG Reply-To: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It seems Richard Sharpe wrote: > Attached is the patch I am using, which is based on what Greg gave me. > It tries UDMA5 first, and steps down ... The following patch is bogus, it doesn't set the chip to the prober mode (always sets it to UDMA2), it just set the disk, this wont work guys... I have a SiS patch in the works (for current that is), that should take care of the ATA mode setup... The geometry is a different matter.... > Richard Sharpe, rsharpe@ns.aus.com, LPIC-1 > www.samba.org, www.ethereal.com, SAMS Teach Yourself Samba > in 24 Hours, Special Edition, Using Samba > --- ata-dma.c.orig Wed Oct 31 07:29:52 2001 > +++ ata-dma.c Fri Nov 30 14:38:52 2001 > @@ -519,30 +519,61 @@ > break; > > case 0x55131039: /* SiS 5591 */ > - if (udmamode >= 2 && pci_get_revid(parent) > 0xc1) { > - error = ata_command(scp, device, ATA_C_SETFEATURES, 0, 0, 0, > - ATA_UDMA2, ATA_C_F_SETXFER, ATA_WAIT_READY); > - if (bootverbose) > - ata_printf(scp, device, > - "%s setting UDMA2 on SiS chip\n", > - (error) ? "failed" : "success"); > - if (!error) { > - pci_write_config(parent, 0x40 + (devno << 1), 0xa301, 2); > - scp->mode[ATA_DEV(device)] = ATA_UDMA2; > - return; > + if (bootverbose) > + printf ("SiS 5513/5591, udmamode %d\n", udmamode); > + if (pci_get_revid(parent) > 0xc1) { > + udmamode = 5; /* Force it to 100 */ > + if (udmamode >= 5) { /* Claims UDMA 100 */ > + error = ata_command(scp, device, ATA_C_SETFEATURES, 0, 0, 0, > + ATA_UDMA5, ATA_C_F_SETXFER, ATA_WAIT_READY); > + if (bootverbose) > + ata_printf(scp, device, > + "%s setting UDMA5 on SiS chip\n", > + (error) ? "failed" : "success"); > + if (!error) { > + pci_write_config(parent, 0x40 + (devno << 1), 0xa301, 2); > + scp->mode[ATA_DEV(device)] = ATA_UDMA5; > + return; > + } > } > - } > - if (wdmamode >=2 && apiomode >= 4) { > - error = ata_command(scp, device, ATA_C_SETFEATURES, 0, 0, 0, > - ATA_WDMA2, ATA_C_F_SETXFER, ATA_WAIT_READY); > - if (bootverbose) > - ata_printf(scp, device, > - "%s setting WDMA2 on SiS chip\n", > - (error) ? "failed" : "success"); > - if (!error) { > - pci_write_config(parent, 0x40 + (devno << 1), 0x0301, 2); > - scp->mode[ATA_DEV(device)] = ATA_WDMA2; > - return; > + if (udmamode >= 4) { /* Claims UDMA 66 */ > + error = ata_command(scp, device, ATA_C_SETFEATURES, 0, 0, 0, > + ATA_UDMA4, ATA_C_F_SETXFER, ATA_WAIT_READY); > + if (bootverbose) > + ata_printf(scp, device, > + "%s setting UDMA4 on SiS chip\n", > + (error) ? "failed" : "success"); > + if (!error) { > + pci_write_config(parent, 0x40 + (devno << 1), 0xa301, 2); > + scp->mode[ATA_DEV(device)] = ATA_UDMA4; > + return; > + } > + } > + if (udmamode >= 2) { > + error = ata_command(scp, device, ATA_C_SETFEATURES, 0, 0, 0, > + ATA_UDMA2, ATA_C_F_SETXFER, ATA_WAIT_READY); > + if (bootverbose) > + ata_printf(scp, device, > + "%s setting UDMA2 on SiS chip\n", > + (error) ? "failed" : "success"); > + if (!error) { > + pci_write_config(parent, 0x40 + (devno << 1), 0xa301, 2); > + scp->mode[ATA_DEV(device)] = ATA_UDMA2; > + return; > + } > + } > + if (wdmamode >=2 && apiomode >= 4) { > + error = ata_command(scp, device, ATA_C_SETFEATURES, 0, 0, 0, > + ATA_WDMA2, ATA_C_F_SETXFER, ATA_WAIT_READY); > + if (bootverbose) > + ata_printf(scp, device, > + "%s setting WDMA2 on SiS chip\n", > + (error) ? "failed" : "success"); > + if (!error) { > + pci_write_config(parent, 0x40 + (devno << 1), 0x0301, 2); > + scp->mode[ATA_DEV(device)] = ATA_WDMA2; > + return; > + } > } > } > /* we could set PIO mode timings, but we assume the BIOS did that */ -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 0:56:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 5FDFE37B405 for ; Sun, 2 Dec 2001 00:56:13 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB28ted90601; Sun, 2 Dec 2001 00:55:40 -0800 (PST) (envelope-from dillon) Date: Sun, 2 Dec 2001 00:55:40 -0800 (PST) From: Matthew Dillon Message-Id: <200112020855.fB28ted90601@apollo.backplane.com> To: Danny Braniss Cc: Richard Sharpe , freebsd-hackers@FreeBSD.ORG Subject: Re: Patch #2 (was Re: Found the problem, w/patch (was Re: FreeBSD performing worse than Linux?)) References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> slightly better results with Patch #3 and delayed acks turned on. :> :> -Matt :i did not apply any patches - yet -, net.inet.tcp.newreno is 1, on both hosts. :they are connected at 100mb, so the strange numbers are when the number of :clients is > 3! (att 100Mbit/sec how come i get > 100?) It's a synchronous protocol, so the number of bits per byte is not necessarily 10... it can be 8, 9, or 10. Approximately. : danny :PS: just forgot, congrat on a terrific job!!! im still amazed -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 3:43: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from netfinity.realnet.co.sz (swazi.realnet.co.sz [196.28.7.2]) by hub.freebsd.org (Postfix) with ESMTP id 2EF5737B417; Sun, 2 Dec 2001 03:42:54 -0800 (PST) Received: by netfinity.realnet.co.sz (Postfix, from userid 502) id 44815FA4B; Sun, 2 Dec 2001 13:47:33 +0200 (SAST) Received: from localhost (localhost [127.0.0.1]) by netfinity.realnet.co.sz (Postfix) with ESMTP id 40949653E2; Sun, 2 Dec 2001 13:47:33 +0200 (SAST) Date: Sun, 2 Dec 2001 13:47:33 +0200 (SAST) From: Zwane Mwaikambo X-X-Sender: To: Greg Lehey Cc: =?iso-8859-1?Q?S=F8ren?= Schmidt , , Richard Sharpe Subject: Re: UDMA33 and SiS5591 on FreeBSD 4.4-RELEASE In-Reply-To: <20011202115509.B61248@monorchid.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 2 Dec 2001, Greg Lehey wrote: > Note that there are other chips out there which return the same PCI > information but which appear to be capable of ATA 100. I recently > gave a patch to Richard Sharpe (copied) which he says was able to get > his "SiS 5591" to run at ATA 100. I'm still waiting for feedback from > him before forwarding it to you. I also have a machine with a "SiS > 5591" which can't go beyond ATA 33. Here are the pciconf outputs for > each chip: > > Mine (ATA 33): > > atapci0@pci0:0:1: class=0x01018a card=0x00000000 chip=0x55131039 rev=0xd0 hdr=0x00 > > Richard's (ATA 100): > pci0:0:1 Class=0x010180 card=0x55131039 chip=0x55131039 red=0xd0 hdr=0x00 > > Dwayne's: > > atapci0@pci0:0:1: class=0x010180 card=0x55131039 chip=0x55131039 rev=0xd0 hdr=0x00 Mine does UDMA66 as well, but haven't checked 100 (no ATA4 disks), looks similar to Richard's atapci0@pci0:0:1: class=0x010180 card=0x55131039 chip=0x55131039 rev=0xd0 hdr=0x00 Cheers, Zwane Mwaikambo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 4:11:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 9AD3A37B416; Sun, 2 Dec 2001 04:11:44 -0800 (PST) Received: (from sos@localhost) by freebsd.dk (8.11.6/8.11.6) id fB2CBRX54534; Sun, 2 Dec 2001 13:11:27 +0100 (CET) (envelope-from sos) From: Søren Schmidt Message-Id: <200112021211.fB2CBRX54534@freebsd.dk> Subject: Re: UDMA33 and SiS5591 on FreeBSD 4.4-RELEASE In-Reply-To: To: Zwane Mwaikambo Date: Sun, 2 Dec 2001 13:11:27 +0100 (CET) Cc: Greg Lehey , freebsd-hackers@FreeBSD.ORG, Richard Sharpe Reply-To: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It seems Zwane Mwaikambo wrote: > On Sun, 2 Dec 2001, Greg Lehey wrote: > > > Note that there are other chips out there which return the same PCI > > information but which appear to be capable of ATA 100. I recently > > gave a patch to Richard Sharpe (copied) which he says was able to get > > his "SiS 5591" to run at ATA 100. I'm still waiting for feedback from > > him before forwarding it to you. I also have a machine with a "SiS > > 5591" which can't go beyond ATA 33. Here are the pciconf outputs for > > each chip: You cannot use the revision of the ATA part alone, you have to take the master part of the chip (southbridge) into account also (they are on the same silicon) to get the real capabilities of the chip. I've just committed what I think is the right support for all current SiS chips in -current, based on docs from SiS... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 4:22:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relay1.macomnet.ru (relay1.macomnet.ru [195.128.64.10]) by hub.freebsd.org (Postfix) with ESMTP id 8BB1B37B417; Sun, 2 Dec 2001 04:22:10 -0800 (PST) Received: from news1.macomnet.ru (maxim@news1.macomnet.ru [195.128.64.14]) by relay1.macomnet.ru (8.11.3/8.11.3) with ESMTP id fB2CM9R1273135; Sun, 2 Dec 2001 15:22:09 +0300 (MSK) Date: Sun, 2 Dec 2001 15:22:09 +0300 (MSK) From: Maxim Konovalov To: hackers@freebsd.org Cc: jasone@freebsd.org Subject: [PATCH]: missing references in pthread.3 Message-ID: <20011202150618.B22487-100000@news1.macomnet.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, Could someone review and commit the following patch: Index: pthread.3 =================================================================== RCS file: /home/ncvs/src/share/man/man3/pthread.3,v retrieving revision 1.20 diff -u -r1.20 pthread.3 --- pthread.3 1 Oct 2001 16:09:20 -0000 1.20 +++ pthread.3 2 Dec 2001 12:13:47 -0000 @@ -73,6 +73,11 @@ Creates a new thread of execution. .It Xo .Ft int +.Fn pthread_cancel "pthread_t thread" +.Xc +Cancels execution of a thread. +.It Xo +.Ft int .Fn pthread_detach "pthread_t thread" .Xc Marks a thread for deletion. @@ -93,9 +98,9 @@ Causes the calling thread to wait for the termination of the specified thread. .It Xo .Ft int -.Fn pthread_cancel "pthread_t thread" +.Fn pthread_kill "pthread_t thread" "int sig" .Xc -Cancels execution of a thread. +Delivers a signal to a specified thread. .It Xo .Ft int .Fn pthread_once "pthread_once_t *once_control" "void (*init_routine)(void)" @@ -106,6 +111,26 @@ .Fn pthread_self void .Xc Returns the thread ID of the calling thread. +.It Xo +.Ft int +.Fn pthread_setcancelstate "int state" "int *oldstate" +.Xc +Sets the current thread's cancelability state. +.It Xo +.Ft int +.Fn pthread_setcanceltype "int type" "int *oldtype" +.Xc +Sets the current thread's cancelability type. +.It Xo +.Ft void +.Fn pthread_testcancel void +.Xc +Creates a cancellation point in the calling thread. +.It Xo +.Ft void +.Fn pthread_yield void +.Xc +Allows the scheduler to run another thread instead of the current one. .El .Sh ATTRIBUTE OBJECT ROUTINES .Bl -tag -width Er @@ -415,6 +440,7 @@ .Xr pthread_getspecific 3 , .Xr pthread_join 3 , .Xr pthread_key_delete 3 , +.Xr pthread_kill 3 , .Xr pthread_mutex_destroy 3 , .Xr pthread_mutex_init 3 , .Xr pthread_mutex_lock 3 , @@ -431,7 +457,10 @@ .Xr pthread_rwlock_unlock 3 , .Xr pthread_rwlock_wrlock 3 , .Xr pthread_self 3 , -.Xr pthread_setspecific 3 +.Xr pthread_setspecific 3 , +.Xr pthread_setcancelstate 3 , +.Xr pthread_setcanceltype 3 , +.Xr pthread_testcancel 3 .Sh STANDARDS The functions in .Fa libc_r -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: maxim@macomnet.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 5:12:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cu518.adelaide.adsl.on.net (cu518.adelaide.adsl.on.net [150.101.236.10]) by hub.freebsd.org (Postfix) with ESMTP id 7A41D37B405 for ; Sun, 2 Dec 2001 05:12:46 -0800 (PST) Received: from ns.aus.com (laptop.ns.aus.com [10.0.2.6]) by cu518.adelaide.adsl.on.net (8.11.0/8.11.0) with ESMTP id fB2FKM724657; Mon, 3 Dec 2001 01:50:22 +1030 Message-ID: <3C0A3204.3010009@ns.aus.com> Date: Mon, 03 Dec 2001 00:22:04 +1030 From: Richard Sharpe Reply-To: rsharpe@ns.aus.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010917 X-Accept-Language: en-us MIME-Version: 1.0 To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Patch #3 (TCP / Linux / Performance) References: <20011128153817.T61580@monorchid.lemis.com> <15364.38174.938500.946169@caddis.yogotech.com> <20011128104629.A43642@walton.maths.tcd.ie> <5.1.0.14.1.20011130181236.00a80160@postamt1.charite.de> <200111302047.fAUKlT811090@apollo.backplane.com> <200111302130.fAULUU324648@apollo.backplane.com> <3C08CF9D.2030109@ns.aus.com> <200112012138.fB1LcG837063@apollo.backplane.com> <200112020810.fB28Arr77757@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG OK Matt, that last patch did the trick. I am now getting 68 and 69Mb/s between my Linux system and the FreeBSD system. I have also tried the loopback interface, and I am getting 371Mb/s for 1 process, dropping to about 320Mb/s for 5. This seems like it is close to the limit for the machine I am using, as CPU hits 100% when I ran the above tbench runs. I will have to try it with Gigabit Ethernet, but won't be able to do so until next week or the week after (after I get to the US). Does the FreeBSD tcp stack do zero copy (page flip the data to userspace)? In the localhost case, it seems like there are two copies to/from userspace there. -- Richard Sharpe, rsharpe@ns.aus.com, LPIC-1 www.samba.org, www.ethereal.com, SAMS Teach Yourself Samba in 24 Hours, Special Edition, Using Samba To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 5:15:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cu518.adelaide.adsl.on.net (cu518.adelaide.adsl.on.net [150.101.236.10]) by hub.freebsd.org (Postfix) with ESMTP id 8D55B37B416 for ; Sun, 2 Dec 2001 05:15:50 -0800 (PST) Received: from ns.aus.com (laptop.ns.aus.com [10.0.2.6]) by cu518.adelaide.adsl.on.net (8.11.0/8.11.0) with ESMTP id fB2FNZ724681 for ; Mon, 3 Dec 2001 01:53:36 +1030 Message-ID: <3C0A32C6.3010005@ns.aus.com> Date: Mon, 03 Dec 2001 00:25:18 +1030 From: Richard Sharpe Reply-To: rsharpe@ns.aus.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010917 X-Accept-Language: en-us MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Samba performance compared between FreeBSD and Linux ... References: <20011128153817.T61580@monorchid.lemis.com> <15364.38174.938500.946169@caddis.yogotech.com> <20011128104629.A43642@walton.maths.tcd.ie> <5.1.0.14.1.20011130181236.00a80160@postamt1.charite.de> <200111302047.fAUKlT811090@apollo.backplane.com> <200111302130.fAULUU324648@apollo.backplane.com> <3C08CF9D.2030109@ns.aus.com> <200112012138.fB1LcG837063@apollo.backplane.com> <200112020810.fB28Arr77757@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, It seems like all of the issues uncovered have been fixed, so it seems like you cannot use performance as a way to choose between FreeBSD and Linux any longer. I will re-issue my report, but I do not have any more time to spend on this now for several days. I will most likely re-run the tests when I get to the US later this week, and would hope to re-issue the report the week after next. -- Richard Sharpe, rsharpe@ns.aus.com, LPIC-1 www.samba.org, www.ethereal.com, SAMS Teach Yourself Samba in 24 Hours, Special Edition, Using Samba To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 5:25:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns2.microbsd.net (ns2.microbsd.net [4.23.122.20]) by hub.freebsd.org (Postfix) with ESMTP id 51C2F37B419; Sun, 2 Dec 2001 05:25:20 -0800 (PST) Received: from mail.microbsd.net (mail.microbsd.net [4.23.122.30]) by ns2.microbsd.net (Postfix) with ESMTP id 2CDC231A3; Sun, 2 Dec 2001 08:35:44 -0500 (EST) Subject: Re: Make RELEASE broken? From: kerberus To: Makoto Matsushita Cc: freebsd-questions@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG In-Reply-To: <20011202145008L.matusita@jp.FreeBSD.org> References: <1007187755.2509.1.camel@ns2.microbsd.net> <20011201050521.H61534@fluff.meowfishies.com> <1007247196.2509.4.camel@ns2.microbsd.net> <20011202145008L.matusita@jp.FreeBSD.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.13 (Preview Release) Date: 02 Dec 2001 08:35:43 -0500 Message-Id: <1007300144.15877.11.camel@ns2.microbsd.net> Mime-Version: 1.0 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Its a 4.4-Stable box, actually it does the same thing on three different 4.4-Stable boxes. make world works, so does installworld, make release barfs. It exists in my standard /usr/src, but not in the checked out chrooted build tree. On Sun, 2001-12-02 at 00:50, Makoto Matsushita wrote: > > You may want to mention that which branch (5-current, 4-stable, etc) > you wanna try. Also you may want to clear that when you sup your code. > > kerberus> ===> share/doc/usd/13.viref > kerberus> make: don't know how to make ref.so. Stop > kerberus> *** Error code 2 > > src/contrib/nvi/docs/USD.doc/vi.ref/ref.so should be there. > > -- - > Makoto `MAR' Matsushita To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 5:26:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id E317837B437 for ; Sun, 2 Dec 2001 05:25:52 -0800 (PST) Received: (from dg@localhost) by root.com (8.11.2/8.11.2) id fB2DIsJ07719; Sun, 2 Dec 2001 05:18:54 -0800 (PST) (envelope-from dg) Date: Sun, 2 Dec 2001 05:18:54 -0800 From: David Greenman To: rsharpe@ns.aus.com Cc: Matthew Dillon , freebsd-hackers@FreeBSD.ORG Subject: Re: Patch #3 (TCP / Linux / Performance) Message-ID: <20011202051854.A7713@nexus.root.com> References: <20011128153817.T61580@monorchid.lemis.com> <15364.38174.938500.946169@caddis.yogotech.com> <20011128104629.A43642@walton.maths.tcd.ie> <5.1.0.14.1.20011130181236.00a80160@postamt1.charite.de> <200111302047.fAUKlT811090@apollo.backplane.com> <200111302130.fAULUU324648@apollo.backplane.com> <3C08CF9D.2030109@ns.aus.com> <200112012138.fB1LcG837063@apollo.backplane.com> <200112020810.fB28Arr77757@apollo.backplane.com> <3C0A3204.3010009@ns.aus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C0A3204.3010009@ns.aus.com>; from sharpe@ns.aus.com on Mon, Dec 03, 2001 at 12:22:04AM +1030 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >Does the FreeBSD tcp stack do zero copy (page flip the data to >userspace)? In the localhost case, it seems like there are two copies >to/from userspace there. It has the ability to do it via sendfile() and a few other mechanisms, but not as a normal part of typical read()/write(). -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 9:39:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id B8DFD37B416 for ; Sun, 2 Dec 2001 09:39:51 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.5/8.11.5) with ESMTP id fB2HdhY23671; Sun, 2 Dec 2001 10:39:43 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200112021739.fB2HdhY23671@aslan.scsiguy.com> To: David Greenman Cc: rsharpe@ns.aus.com, Matthew Dillon , freebsd-hackers@FreeBSD.ORG Subject: Re: Patch #3 (TCP / Linux / Performance) In-Reply-To: Your message of "Sun, 02 Dec 2001 05:18:54 PST." <20011202051854.A7713@nexus.root.com> Date: Sun, 02 Dec 2001 10:39:43 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >>Does the FreeBSD tcp stack do zero copy (page flip the data to >>userspace)? In the localhost case, it seems like there are two copies >>to/from userspace there. > > It has the ability to do it via sendfile() and a few other mechanisms, but >not as a normal part of typical read()/write(). Ahh, but there are patches floating around that do support zero-copy. Just ask Ken Merry and Drew Gallatin. I don't think they've been integrated due to lack of testing time, but they've existed for 2 or so years now. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 10:11:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from correo.adinet.com.uy (fecorreo04.adinet.com.uy [206.99.44.251]) by hub.freebsd.org (Postfix) with ESMTP id 072F337B41A for ; Sun, 2 Dec 2001 10:11:21 -0800 (PST) Received: from adinet.com.uy (200.40.93.174) by correo.adinet.com.uy (5.5.052) id 3BFC83C7000F86EC for Hackers@FreeBSD.ORG; Sun, 2 Dec 2001 15:12:12 -0300 Message-ID: <3C0A6EE1.DBD4B502@adinet.com.uy> Date: Sun, 02 Dec 2001 15:11:46 -0300 From: marualm X-Mailer: Mozilla 4.51 [es] (Win95; I) X-Accept-Language: es MIME-Version: 1.0 To: Hackers@FreeBSD.ORG Subject: uruguay presente Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG hola estoy buscando algo para gla gx28 gracias por informacion o donde puedo dirigirme att mauro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 11:18:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 3429E37B416 for ; Sun, 2 Dec 2001 11:18:44 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB2JIg592414; Sun, 2 Dec 2001 11:18:42 -0800 (PST) (envelope-from dillon) Date: Sun, 2 Dec 2001 11:18:42 -0800 (PST) From: Matthew Dillon Message-Id: <200112021918.fB2JIg592414@apollo.backplane.com> To: Richard Sharpe Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Patch #3 (TCP / Linux / Performance) References: <20011128153817.T61580@monorchid.lemis.com> <15364.38174.938500.946169@caddis.yogotech.com> <20011128104629.A43642@walton.maths.tcd.ie> <5.1.0.14.1.20011130181236.00a80160@postamt1.charite.de> <200111302047.fAUKlT811090@apollo.backplane.com> <200111302130.fAULUU324648@apollo.backplane.com> <3C08CF9D.2030109@ns.aus.com> <200112012138.fB1LcG837063@apollo.backplane.com> <200112020810.fB28Arr77757@apollo.backplane.com> <3C0A3204.3010009@ns.aus.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :OK Matt, that last patch did the trick. : :I am now getting 68 and 69Mb/s between my Linux system and the FreeBSD :system. Excellent! :I have also tried the loopback interface, and I am getting 371Mb/s for 1 process, dropping to about 320Mb/s for 5. Excellent! :This seems like it is close to the limit for the machine I am using, as :CPU hits 100% when I ran the above tbench runs. : :I will have to try it with Gigabit Ethernet, but won't be able to do so :until next week or the week after (after I get to the US). Here's what I get over a gigabit ethernet link between two DELL2550's: ./tbench 1 10.1.0.1 Throughput 7.72693 MB/sec (NB=9.65866 MB/sec 77.2693 MBit/sec) 1 procs ./tbench 2 10.1.0.1 Throughput 17.1535 MB/sec (NB=21.4418 MB/sec 171.535 MBit/sec) 2 procs ./tbench 3 10.1.0.1 Throughput 23.185 MB/sec (NB=28.9813 MB/sec 231.85 MBit/sec) 3 procs ./tbench 4 10.1.0.1 Throughput 24.041 MB/sec (NB=30.0512 MB/sec 240.41 MBit/sec) 4 procs ./tbench 6 10.1.0.1 Throughput 33.8823 MB/sec (NB=42.3528 MB/sec 338.823 MBit/sec) 6 procs ./tbench 8 10.1.0.1 Throughput 40.9986 MB/sec (NB=51.2482 MB/sec 409.986 MBit/sec) 8 procs ./tbench 10 10.1.0.1 Throughput 43.8519 MB/sec (NB=54.8149 MB/sec 438.519 MBit/sec) 10 procs ./tbench 15 10.1.0.1 Throughput 46.8878 MB/sec (NB=58.6098 MB/sec 468.878 MBit/sec) 15 procs ./tbench 20 10.1.0.1 Throughput 47.2446 MB/sec (NB=59.0558 MB/sec 472.446 MBit/sec) 20 procs It seems to max-out at around 75,000 packets per second (input + output). I doubt these results could be duplicated on anything but a DELL2550. It dedicates an entire internal 64 bit 66MHz PCI bus just to the on-board gigabit ethernet. test1:/home/dillon/dbench> netstat -in 1 input (Total) output packets errs bytes packets errs bytes colls 38680 0 37237815 36340 0 20079011 0 41770 0 45968686 33317 0 13029493 0 33282 0 17257495 38002 0 29369102 0 ... :Does the FreeBSD tcp stack do zero copy (page flip the data to :userspace)? In the localhost case, it seems like there are two copies :to/from userspace there. : :-- :Richard Sharpe, rsharpe@ns.aus.com, LPIC-1 There are zero-copy patches floating around but I haven't looked at them to determine how messy they might be. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 11:36:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from technokratis.com (modemcable099.144-201-24.mtl.mc.videotron.ca [24.201.144.99]) by hub.freebsd.org (Postfix) with ESMTP id 13C0037B419 for ; Sun, 2 Dec 2001 11:36:09 -0800 (PST) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id fB2JjlK58748; Sun, 2 Dec 2001 14:45:47 -0500 (EST) (envelope-from bmilekic) Date: Sun, 2 Dec 2001 14:45:47 -0500 From: Bosko Milekic To: Matthew Dillon Cc: Richard Sharpe , freebsd-hackers@FreeBSD.ORG Subject: Re: Patch #3 (TCP / Linux / Performance) Message-ID: <20011202144547.A58695@technokratis.com> References: <15364.38174.938500.946169@caddis.yogotech.com> <20011128104629.A43642@walton.maths.tcd.ie> <5.1.0.14.1.20011130181236.00a80160@postamt1.charite.de> <200111302047.fAUKlT811090@apollo.backplane.com> <200111302130.fAULUU324648@apollo.backplane.com> <3C08CF9D.2030109@ns.aus.com> <200112012138.fB1LcG837063@apollo.backplane.com> <200112020810.fB28Arr77757@apollo.backplane.com> <3C0A3204.3010009@ns.aus.com> <200112021918.fB2JIg592414@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112021918.fB2JIg592414@apollo.backplane.com>; from dillon@apollo.backplane.com on Sun, Dec 02, 2001 at 11:18:42AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Dec 02, 2001 at 11:18:42AM -0800, Matthew Dillon wrote: [...] > :Does the FreeBSD tcp stack do zero copy (page flip the data to > :userspace)? In the localhost case, it seems like there are two copies > :to/from userspace there. > : > :-- > :Richard Sharpe, rsharpe@ns.aus.com, LPIC-1 > > There are zero-copy patches floating around but I haven't looked at > them to determine how messy they might be. http://people.freebsd.org/~ken/zero_copy/ The main issues with the patch are, afaics: 1. It's fairly large and difficult to maintain, especially in light of the large amount of SMPng-related changes. 2. The receive code only works with certain network cards. [This is expected]. The performance may also vary based on the behavior of the application. > -Matt > Matthew Dillon > -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 11:46: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 7210337B41B for ; Sun, 2 Dec 2001 11:46:02 -0800 (PST) Received: from localhost (arr@localhost) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fB2JjLR19837; Sun, 2 Dec 2001 14:45:21 -0500 (EST) (envelope-from arr@FreeBSD.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Sun, 2 Dec 2001 14:45:21 -0500 (EST) From: "Andrew R. Reiter" X-Sender: arr@fledge.watson.org To: "Justin T. Gibbs" Cc: David Greenman , rsharpe@ns.aus.com, Matthew Dillon , freebsd-hackers@FreeBSD.org Subject: Re: Patch #3 (TCP / Linux / Performance) In-Reply-To: <200112021739.fB2HdhY23671@aslan.scsiguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :Ahh, but there are patches floating around that do support zero-copy. :Just ask Ken Merry and Drew Gallatin. I don't think they've been integrated :due to lack of testing time, but they've existed for 2 or so years now. : http://people.freebsd.org/~ken/zero_copy/ -- Andrew R. Reiter arr@watson.org arr@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 12: 8: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from chmls16.mediaone.net (chmls16.mediaone.net [24.147.1.151]) by hub.freebsd.org (Postfix) with ESMTP id 8791C37B405 for ; Sun, 2 Dec 2001 12:08:03 -0800 (PST) Received: from gandalf (h0050dac2456d.ne.mediaone.net [65.96.125.3]) by chmls16.mediaone.net (8.11.1/8.11.1) with SMTP id fB2K7vT11456 for ; Sun, 2 Dec 2001 15:07:57 -0500 (EST) Message-ID: <000601c17b6b$7a89c190$037d6041@gandalf> From: "Dragon Fire" To: Subject: device object, driver object, cdevsw Date: Sun, 2 Dec 2001 14:56:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm writing a PCI character device driver and need some clairification. As I see the FreeBSD driver structure there are really two components to a device driver, there is the KLD component which contains the device methods for probe, attach, detach, etc and handles the dynamic componet of the driver. Then there is the traditional Unix cdevsw structure which handles the read, write, ioctl etc. The few places the KLD is documented really doesn't cover the link between the two elements KLD and cdevsw. I understand that if successsfully probed the attach creates the dev_t using the cdevw table. But I'm having difficulty seeing the relationship. Would it be fair to say the KLD components represent the dynamics kernel facilities and the cdevsw implments what we consider the "traditional" Unix device driver. Could somebody shed light on this subject. Thanks in advance! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 12:16:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from warez.scriptkiddie.org (uswest-dsl-142-38.cortland.com [209.162.142.38]) by hub.freebsd.org (Postfix) with ESMTP id C277637B417 for ; Sun, 2 Dec 2001 12:16:29 -0800 (PST) Received: from [192.168.69.11] (unknown [192.168.69.11]) by warez.scriptkiddie.org (Postfix) with ESMTP id 9E9D062D01; Sun, 2 Dec 2001 12:16:28 -0800 (PST) Date: Sun, 2 Dec 2001 12:16:46 -0800 (PST) From: Lamont Granquist To: Matthew Dillon Cc: Richard Sharpe , Subject: Re: Patch #3 (TCP / Linux / Performance) In-Reply-To: <200112021918.fB2JIg592414@apollo.backplane.com> Message-ID: <20011202121147.G92925-100000@coredump.scriptkiddie.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 2 Dec 2001, Matthew Dillon wrote: > Throughput 47.2446 MB/sec (NB=59.0558 MB/sec 472.446 MBit/sec) 20 procs > > It seems to max-out at around 75,000 packets per second (input + output). > > I doubt these results could be duplicated on anything but a DELL2550. > It dedicates an entire internal 64 bit 66MHz PCI bus just to the > on-board gigabit ethernet. What is the remaining bottleneck in these tests? CPU? Interrupts? What would you need to do to get that closer to the theoretical limit (something around 920 Mbs for GigE IIRC)? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 12:20:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns2.microbsd.net (ns2.microbsd.net [4.23.122.20]) by hub.freebsd.org (Postfix) with ESMTP id 361DF37B416 for ; Sun, 2 Dec 2001 12:20:45 -0800 (PST) Received: from mail.microbsd.net (mail.microbsd.net [4.23.122.30]) by ns2.microbsd.net (Postfix) with ESMTP id 0564231A3; Sun, 2 Dec 2001 15:31:13 -0500 (EST) Subject: Re: Make RELEASE broken? From: kerberus To: Makoto Matsushita Cc: freebsd-hackers@freebsd.org In-Reply-To: <20011202223739U.matusita@jp.FreeBSD.org> References: <1007247196.2509.4.camel@ns2.microbsd.net> <20011202145008L.matusita@jp.FreeBSD.org> <1007300144.15877.11.camel@ns2.microbsd.net> <20011202223739U.matusita@jp.FreeBSD.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.13 (Preview Release) Date: 02 Dec 2001 15:31:13 -0500 Message-Id: <1007325074.15877.18.camel@ns2.microbsd.net> Mime-Version: 1.0 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Okay ive setup a /usr/cvs, exported CVSROOT /usr/cvs, cd'd into /usr/cvs, cvs init, cd'd to /usr/src, cvs import src devel beta, all went fine and created a /usr/cvs/src ..... cd'd to /usr/src setenv CVSROOT /usr/cvs setenv CHROOTDIR /usr/release make release churn churn churn it builds a tree, cvs's the src goes into its build stage, and again, fails with a fresh cvsup from today, which did a complete make world kernel from the standard /usr/src, now can some one tell me what im missing or doing wrong ?? and yes i read the slideshow everyone recommended. /usr/src/share/doc/usd/12.vi/viapwh/../../../../../contrib/nvi/docs/USD.doc/vitut/vi.apwh.ms:42: warning: `CB' not defined /usr/src/share/doc/usd/12.vi/viapwh/../../../../../contrib/nvi/docs/USD.doc/vitut/vi.apwh.ms:88: warning: `VL' not defined /usr/src/share/doc/usd/12.vi/viapwh/../../../../../contrib/nvi/docs/USD.doc/vitut/vi.apwh.ms:109: warning: `LE' not defined ===> share/doc/usd/12.vi/summary touch _stamp.extraobjs (cd /usr/src/share/doc/usd/12.vi/summary/../../../../../contrib/nvi/docs/USD.doc/vitut; groff -mtty-char -Tascii -t -ms -o1- /usr/src/share/doc/usd/12.vi/summary/../../../../../contrib/nvi/docs/USD.doc/vitut/vi.summary) | gzip -cn > summary.ascii.gz ===> share/doc/usd/13.viref make: don't know how to make ref.so. Stop *** Error code 2 Stop in /usr/src/share/doc/usd. *** Error code 1 Stop in /usr/src/share/doc. *** Error code 1 Stop in /usr/src/share. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src/release. On Sun, 2001-12-02 at 08:37, Makoto Matsushita wrote: > > My reference "make release" box for snapshots.jp.FreeBSD.org goes fine > with today's 4-stable code. > > kerberus> It exists in my standard /usr/src, but not in the checked > kerberus> out chrooted build tree. > > So please check it :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 12:27:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 4E55937B405 for ; Sun, 2 Dec 2001 12:27:41 -0800 (PST) Received: from localhost (arr@localhost) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fB2KRDv20361; Sun, 2 Dec 2001 15:27:13 -0500 (EST) (envelope-from arr@FreeBSD.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Sun, 2 Dec 2001 15:27:12 -0500 (EST) From: "Andrew R. Reiter" X-Sender: arr@fledge.watson.org To: Lamont Granquist Cc: Matthew Dillon , Richard Sharpe , freebsd-hackers@FreeBSD.org Subject: Re: Patch #3 (TCP / Linux / Performance) In-Reply-To: <20011202121147.G92925-100000@coredump.scriptkiddie.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 2 Dec 2001, Lamont Granquist wrote: : :What is the remaining bottleneck in these tests? CPU? Interrupts? What :would you need to do to get that closer to the theoretical limit :(something around 920 Mbs for GigE IIRC)? Well, for one thing, I'd imagine that per-byte and per-copy overheads still exist since we're not in a zero-copy environment. -- Andrew R. Reiter arr@watson.org arr@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 13: 6:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.altadena.net (ns.altadena.net [206.126.144.2]) by hub.freebsd.org (Postfix) with ESMTP id 3CFF437B444; Sun, 2 Dec 2001 13:05:09 -0800 (PST) Received: (from pete@localhost) by ns.altadena.net (8.11.6/8.8.8) id fB2L58F22980; Sun, 2 Dec 2001 13:05:08 -0800 (PST) (envelope-from pete) From: Pete Carah Message-Id: <200112022105.fB2L58F22980@ns.altadena.net> Subject: Via 686b data corruption. To: sos@freebsd.org, hackers@freebsd.org Date: Sun, 2 Dec 2001 13:05:08 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=iso8859-1 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm seeing data corruption on the Promise channel of a A7V133, WITH the "southbridge fix" applied and NO sound card of any kind in the system (the built-in is disabled in the bios; current wouldn't boot at all with it enabled, when I bought the mb). All the cards are video (a TNT2 card of some kind) and network (Intel). OS is -current of about a week ago: FreeBSD 5.0-CURRENT #0: Sun Nov 25 18:11:17 PST 2001 with the cvsup done about 3 or so hours earlier... I haven't updated the bios yet; the latest appears to be avu1007 from the tw ftp site. I have slowed the clock to 125mhz but from the "nature of the bug" discussions it appears that shouldn't matter. -- Pete dmesg from boot verbose (booted last night): -------------------------------------------- Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Sun Nov 25 18:11:17 PST 2001 pete@seagull.altadena.net:/usr/src/sys/i386/compile/SEAGULL Preloaded elf kernel "/boot/kernel/kernel" at 0xc041a000. Preloaded elf module "/boot/kernel/random.ko" at 0xc041a0a8. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc041a154. Calibrating clock(s) ... TSC clock: 1125127471 Hz, i8254 clock: 1193234 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter "TSC" frequency 1125087368 Hz CPU: AMD Athlon(tm) Processor (1125.09-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183f9ff AMD Features=0xc0440000<,AMIE,DSP,3DNow!> Data TLB: 24 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 805224448 (786352K bytes) Physical memory chunk(s): 0x00001000 - 0x0009dfff, 643072 bytes (157 pages) 0x00441000 - 0x2ffe3fff, 800731136 bytes (195491 pages) avail memory = 778739712 (760488K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f92a0 bios32: Entry = 0xf0f50 (c00f0f50) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x1150 pnpbios: Found PnP BIOS data at 0xc00fc2b0 pnpbios: Entry = f0000:c2e0 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: null: mem: Pentium Pro MTRR support enabled random: pci_open(1): mode 1 addr port (0x0cf8) is 0x80000060 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=03051106) Using $PIR table, 9 entries at 0xc00f1720 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_cpu0: on acpi0 acpi_button0: on acpi0 acpi_pcib0: port 0xcf8-0xcff on acpi0 pci0: physical bus=0 map[10]: type 3, range 32, base e6000000, size 25, enabled found-> vendor=0x1106, dev=0x0305, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0x8305, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 found-> vendor=0x1106, dev=0x0686, revid=0x40 bus=0, slot=4, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000d800, size 4, enabled found-> vendor=0x1106, dev=0x0571, revid=0x06 bus=0, slot=4, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000d400, size 5, enabled found-> vendor=0x1106, dev=0x3038, revid=0x16 bus=0, slot=4, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 intpin=d, irq=5 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000d000, size 5, enabled found-> vendor=0x1106, dev=0x3038, revid=0x16 bus=0, slot=4, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 intpin=d, irq=5 powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0x3057, revid=0x40 bus=0, slot=4, func=4 class=06-00-00, hdrtype=0x00, mfdev=0 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base e1800000, size 12, enabled map[14]: type 4, range 32, base 0000a400, size 6, enabled map[18]: type 1, range 32, base e1000000, size 20, enabled found-> vendor=0x8086, dev=0x1229, revid=0x08 bus=0, slot=9, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000a000, size 3, enabled map[14]: type 4, range 32, base 00009800, size 2, enabled map[18]: type 4, range 32, base 00009400, size 3, enabled map[1c]: type 4, range 32, base 00009000, size 2, enabled map[20]: type 4, range 32, base 00008800, size 6, enabled map[24]: type 1, range 32, base e0800000, size 17, enabled found-> vendor=0x105a, dev=0x0d30, revid=0x02 bus=0, slot=17, func=0 class=01-80-00, hdrtype=0x00, mfdev=0 intpin=a, irq=10 powerspec 1 supports D0 D3 current D0 pci0: on acpi_pcib0 pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xdfff pcib1: memory decode 0xe2000000-0xe3cfffff pcib1: prefetched decode 0xe3f00000-0xe5ffffff pci1: physical bus=1 map[10]: type 1, range 32, base e2000000, size 24, enabled map[14]: type 3, range 32, base e4000000, size 25, enabled found-> vendor=0x10de, dev=0x002d, revid=0x15 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=11 powerspec 1 supports D0 D3 current D0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0xd800-0xd80f at device 4.1 on pci0 atapci0: VIA '686b southbridge fix applied ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xd800 ata0: mask=03 ostat0=50 ostat2=00 ata0-master: ATAPI probe 00 00 ata0-slave: ATAPI probe 00 00 ata0: mask=03 stat0=50 stat1=00 ata0-master: ATA probe 01 a5 ata0: devices=01 ata0: at 0x1f0 irq 14 on atapci0 ata1: iobase=0x0170 altiobase=0x0376 bmaddr=0xd808 ata1: mask=01 ostat0=50 ostat2=ff ata1-master: ATAPI probe 14 eb ata1: mask=01 stat0=00 stat1=ff ata1: devices=04 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xd400-0xd41f irq 5 at device 4.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xd000-0xd01f irq 5 at device 4.3 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered fxp0: port 0xa400-0xa43f mem 0xe1000000-0xe10fffff,0xe1800000-0xe1800fff irq 5 at device 9.0 on pci0 fxp0: using memory space register mapping fxp0: Ethernet address 00:02:b3:04:16:c4 fxp0: PCI IDs: 8086 1229 8086 000c 0008 fxp0: Dynamic Standby mode is disabled inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bpf: fxp0 attached atapci1: port 0x8800-0x883f,0x9000-0x9003,0x9400-0x9407,0x9800-0x9803,0xa000-0xa007 mem 0xe0800000-0xe081ffff irq 10 at device 17.0 on pci0 ata2: iobase=0xa000 altiobase=0x9802 bmaddr=0x8800 ata2: mask=03 ostat0=50 ostat2=50 ata2-master: ATAPI probe 00 00 ata2-slave: ATAPI probe 00 00 ata2: mask=03 stat0=50 stat1=50 ata2-master: ATA probe 01 a5 ata2-slave: ATA probe 01 a5 ata2: devices=03 ata2: at 0xa000 on atapci1 ata3: iobase=0x9400 altiobase=0x9002 bmaddr=0x8808 ata3: mask=03 ostat0=64 ostat2=64 ata3-master: ATAPI probe 64 64 ata3-slave: ATAPI probe 64 64 ata3: mask=03 stat0=64 stat1=64 ata3-master: ATA probe 25 25 ata3-slave: ATA probe 25 25 ata3: devices=00 ata3: at 0x9400 on atapci1 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) fdc0: direction bit not set fdc0: cmd 3 failed at out byte 1 of 3 ppc0: using extended I/O port range ppc0: EPP SPP ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode plip0: on ppbus0 bpf: lp0 attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 unknown: not probed (disabled) sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: irq maps: 0x1 0x9 0x1 0x1 sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A unknown: not probed (disabled) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d0000 psm0: unable to allocate IRQ psmcpnp0 irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons psm0: config:00000000, flags:00000000, packet size:4 psm0: syncmask:08, syncbits:08 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) fdc0: direction bit not set fdc0: cmd 3 failed at out byte 1 of 3 unknown: not probed (disabled) unknown: not probed (disabled) ata-: ata0 already exists, skipping it ata-: ata1 already exists, skipping it atkbdc-: atkbdc0 already exists, skipping it ppc-: ppc0 already exists, skipping it sio-: sio0 already exists, skipping it sio-: sio1 already exists, skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 sc-: sc0 already exists, skipping it vga-: vga0 already exists, skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0:
Hello,
 
On the subject of tcp performance = graphs, I have=20 taken a few tcpdumps of some pages, to understand the entire process in = more=20 minute detail, and to co-relate the theory with the graphs in practice. = I have=20 plotted a graph of cumulative data received at the client side = vs. time=20 required to fetch it, and I find that for the data received by client, = the first=20 2 packets arrive within a time of 0.212 sec. of each other, whereas the = 3rd.=20 packet takes another 0.5 secs. Thereafter, all packets take 0.212 = sec.(relative=20 to the previous packet) Is this the slow start algorithm I am=20 observing(The 0.5 sec. difference)?
I have attached the graph here, if=20 anybody wants to take a look... The first 2 points are there for = SYN=20 &SYN-ACK.
 
Thanks,
Anjali
 
------=_NextPart_001_0034_01C17BE8.320B1220-- ------=_NextPart_000_0033_01C17BE8.320B1220 Content-Type: application/vnd.ms-excel; name="tcp_algo.xls" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="tcp_algo.xls" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAGwAAAAAAAAAA EAAA/v///wAAAAD+////AAAAABoAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8J CBAAAAYFAP4czQfJQAAABgEAAOEAAgCwBMEAAgAAAOIAAABcAHAABgAAYW5qYWxpICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEIAAgCwBGEBAgAAAMABAAA9AQIA AwCcAAIADgAZAAIAAAASAAIAAAATAAIAAACvAQIAAAC8AQIAAAA9ABIAeAA8AHkdZRM4AAAAAAAB AFgCQAACAAAAjQACAAAAIgACAAAADgACAAEAtwECAAAA2gACAAAAMQAaAMgAAAD/f5ABAAAAAAAA BQFBAHIAaQBhAGwAMQAaAMgAAAD/f5ABAAAAAAAABQFBAHIAaQBhAGwAMQAaAMgAAAD/f5ABAAAA AAAABQFBAHIAaQBhAGwAMQAaAMgAAAD/f5ABAAAAAAAABQFBAHIAaQBhAGwAMQAaAMgAAQD/f7wC AAAAAAAABQFBAHIAaQBhAGwAMQAaAMgAAAD/f5ABAAAAAAAABQFBAHIAaQBhAGwAMQAaAMgAAAD/ f5ABAAAAAAAABQFBAHIAaQBhAGwAHgQcAAUAFwAAIiQiIywjIzBfKTtcKCIkIiMsIyMwXCkeBCEA BgAcAAAiJCIjLCMjMF8pO1tSZWRdXCgiJCIjLCMjMFwpHgQiAAcAHQAAIiQiIywjIzAuMDBfKTtc KCIkIiMsIyMwLjAwXCkeBCcACAAiAAAiJCIjLCMjMC4wMF8pO1tSZWRdXCgiJCIjLCMjMC4wMFwp HgQ3ACoAMgAAXygiJCIqICMsIyMwXyk7XygiJCIqIFwoIywjIzBcKTtfKCIkIiogIi0iXyk7XyhA XykeBC4AKQApAABfKCogIywjIzBfKTtfKCogXCgjLCMjMFwpO18oKiAiLSJfKTtfKEBfKR4EPwAs ADoAAF8oIiQiKiAjLCMjMC4wMF8pO18oIiQiKiBcKCMsIyMwLjAwXCk7XygiJCIqICItIj8/Xyk7 XyhAXykeBDYAKwAxAABfKCogIywjIzAuMDBfKTtfKCogXCgjLCMjMC4wMFwpO18oKiAiLSI/P18p O18oQF8p4AAUAAAAAAD1/yAAAAAAAAAAAAAAAMAg4AAUAAEAAAD1/yAAAPQAAAAAAAAAAMAg4AAU AAEAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAIAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAIAAAD1/yAA APQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAA AMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAA AAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQA AAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg 4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAABACAAAAAAAAAAAAAAAMAg4AAUAAEAKwD1 /yAAAPgAAAAAAAAAAMAg4AAUAAEAKQD1/yAAAPgAAAAAAAAAAMAg4AAUAAEALAD1/yAAAPgAAAAA AAAAAMAg4AAUAAEAKgD1/yAAAPgAAAAAAAAAAMAg4AAUAAEACQD1/yAAAPgAAAAAAAAAAMAgkwIE ABCAA/+TAgQAEYAG/5MCBAASgAT/kwIEABOAB/+TAgQAAIAA/5MCBAAUgAX/YAECAAAAhQALABYJ AAAAAAMAVENQjAAEAAEAAQCuAQQAAQABBK4BLwADAA8AAAFDaGFydHBhZ2U0LnhscwYAAFNoZWV0 MQYAAFNoZWV0MgYAAFNoZWV0M1kABAAYAAAAWgAWAAQDAAABAAAAAAAAAAABAAAAAAAAAABaABYA BAMBAAFgO99PjZfWPwEAAAAAAAAAAFoAFgAEAwIAAWA730+Nl9Y/AQAAAAAAAAAAWgAWAAQDAwAB EAIrhxbZ7j8BAAAAAADQlkBaABYABAMEAAE4iUFg5dDyPwEAAAAAANCmQFoAFgAEAwUAAeB6FK5H 4fo/AQAAAAAAHLFAWgAWAAQDBgABEIPAyqFF/j8BAAAAAADQtkBaABYABAMHAAGgRbbz/dQAQAEA AAAAAIS8QFoAFgAEAwgAAbhJDAIrhwJAAQAAAAAAHMFAWgAWAAQDCQAB1E1iEFg5BEABAAAAAAD2 w0BaABYABAMKAAFg5dAi2/kFQAEAAAAAANDGQFoAFgAEAwsAAXjpJjEIrAdAAQAAAAAAqslAWgAW AAQDDAABkO18PzVeCUABAAAAAACEzEBaABYABAMNAAFcukkMAisLQAEAAAAAAF7PQFoAFgAEAw4A AXS+nxov3QxAAQAAAAAAHNFAWgAWAAQDDwABkML1KFyPDkABAAAAAACJ0kBaABYABAMQAAFU46Wb xCAQQAEAAAAAAPbTQFoAFgAEAxEAAWDl0CLb+RBAAQAAAAAAY9VAWgAWAAQDEgABLLKd76dGEkAB AAAAAADQ1kBaABYABAMTAAE4tMh2vh8TQAEAAAAAAD3YQFoAFgAEAxQAASqHFtnO9xNAAQAAAAAA qtlAWgAWAAQDFQAB8NJNYhDYFEABAAAAAAAX20BaABYABAMWAAH81HjpJrEVQAEAAAAAAITcQFoA FgAEAxcAARSuR+F6FBZAAQAAAADAqNxAWQAEAAAAAQBZAAQAAAACABcAFAADAAAA/////wAA//// /wEAAAAAAMEBCADBAQAAYGkBAOsAcgAPAADwagAAAAAABvAwAAAAAhAAAAUAAAADAAAAAQAAAAAA AAAJAAAAAAAAAAEAAAAAAAAABwAAAAMAAAACAAAAMwAL8BIAAAC/AAgACACBAQkAAAjAAUAAAAhA AB7xEAAAAA0AAAgMAAAIFwAACPcAABD8AAgAAAAAAAAAAAD/AAIACAAKAAAACQgQAAAGEAD+HM0H yUAAAAYBAAALAhAAAAAAAAAAAAAAAAAAzgkAAA0AAgABAAwAAgBkAA8AAgABABEAAgAAABAACAD8 qfHSTWJQP18AAgABACoAAgAAACsAAgAAAIIAAgABAIAACAAAAAAAAAAAACUCBAAAAP8AgQACAMEE FAAAABUAAACDAAIAAACEAAIAAAChACIAAAD/AAEAAQABAAQAAAAAAAAAAAAAAOA/AAAAAAAA4D8A AFUAAgAIAAACDgAAAAAAAAAAAAAAAAAAAOwAyAAPAALwwAAAADAACPAIAAAAAgAAAAEQAAAPAAPw qAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAEAAABQAAAA8ABPBw AAAAkgwK8AgAAAABEAAAAAoAAJMAC/A2AAAAfwAEAQQBvwAIAAgAgQFOAAAIgwFNAAAIvwEQABEA wAFNAAAI/wEIAAgAPwIAAAIAvwMAAAgAAAAQ8BIAAAAAAAIA8AICAGkACgCwARQAHgAAABHwAAAA AF0AGgAVABIABQABABFgAAAAAKQaCQEAAAAAAAAAAAkIEAAABiAA/hzNB8lAAAAGAQAAFAAAABUA AACDAAIAAACEAAIAAAChACIAAAASAAEAAQABAAQAAACkGgAAAAAAAOA/AAAAAAAA4D8PADMAAgAD AGAQCgA7HAwRyAABAAUAYBAKADscDBHIAAEABgBgEAoAOxwMEcgAAAAHABIAAgAAAAEQAgAAAAIQ EAAAAAAAAAAAANC/cQHof+IAMxAAAKAABAABAAEAZBAIAAAAAQAAAAEAMhAEAAAAAgAzEAAABxAM AAAAAAAAAAAACQBNAAoQEAD///8AAAAAAAEAAQBOAE0ANBAAAAMQDAABAAEAGAAYAAEAAAAzEAAA URAIAAABAAAAAAAAURATAAECAAAAAAsAOwIAAAAXAAQABABREBMAAgIAAAAACwA7AgAAABcAAwAD AFEQCAADAQAAAAAAAAYQCAD//wAAAAAAADMQAABfEAIAAAA0EAAARRACAAAANBAAAEQQBAAaAAAA JBACAAIAJRAgAAICAQAAAAAA1////7z///8AAAAAAAAAALEATQBQKwAAMxAAAE8QFAACAAIAAAAA AAAAAAAAAAAAAAAAACYQAgAHAFEQCAAAAQAAAAAAADQQAAAkEAIAAwAlECAAAgIBAAAAAADX//// vP///wAAAAAAAAAAsQBNAFArAAAzEAAATxAUAAIAAgAAAAAAAAAAAAAAAAAAAAAAJhACAAYAURAI AAABAAAAAAAANBAAAEYQAgABAEEQEgAAAJ8CAABfAwAAtAkAANkJAAAzEAAATxAUAAIAAgAaAQAA xAIAAGALAAAKCwAAHRASAAAAAAAAAAAAAAAAAAAAAAAAADMQAAAfECoAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8BHhAeAAIAAwEAAAAAAAAAAAAAAAAAAAAAAAAAACMA TQAAADQQAAAdEBIAAQAAAAAAAAAAAAAAAAAAAAAAMxAAAB8QKgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAHwEeEB4AAgADAQAAAAAAAAAAAAAAAAAAAAAAAAAAIwBNAAAA IRACAAEABxAMAAAAAAAAAP//CQBNADQQAAAlECAAAgIBAAAAAAD8BQAAzg0AAPoCAAA7AQAAgQBN AAAAAAAzEAAATxAUAAIAAgAAAAAAAAAAAFwAAAAXAAAAJhACAAUAURAIAAABAAAAAAAADRAeAAAA DQFSAGUAbABhAHQAaQB2AGUAIABUAGkAbQBlACcQBgADAAAAAAA0EAAAJRAgAAICAQAAAAAAWwAA AKgEAAC+AAAAVQcAAIECTQAAAFoAMxAAAE8QFAACAAIAAAAAAAAAAAAXAAAAiQAAACYQAgAFAFEQ CAAAAQAAAAAAAA0QLAAAABQBQwB1AG0AdQBsAGEAdABpAHYAZQAgAGQAYQB0AGEAIABzAGkAegBl ACcQBgACAAAAAAA0EAAANRAAADIQBAAAAAMAMxAAAAcQDACAgIAAAAAAAAAAFwAKEBAAwMDAAAAA AAABAAAAFgBPADQQAAAUEBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAzEAAAGxAGAGQAAQAAACIQCgAA AAAAAAAAAA8ABhAIAAAAAAD9/wAAMxAAAF8QAgAAAAcQDAAAAAAAAAD//wkATQAKEBAA////AAAA AAABAAEATgBNAAsQAgAAAF0QAgABAAkQFAAAAAAAAAAAAAIAAQBNAE0APAAAADQQAAA0EAAANBAA ADQQAAAAAg4AAAAAABgAAAAAAAEAAABlEAIAAgADAg4AAAAAAAAAAAAAAAAAAAADAg4AAQAAAAAA YDvfT42X1j8DAg4AAgAAAAAAYDvfT42X1j8DAg4AAwAAAAAAEAIrhxbZ7j8DAg4ABAAAAAAAOIlB YOXQ8j8DAg4ABQAAAAAA4HoUrkfh+j8DAg4ABgAAAAAAEIPAyqFF/j8DAg4ABwAAAAAAoEW28/3U AEADAg4ACAAAAAAAuEkMAiuHAkADAg4ACQAAAAAA1E1iEFg5BEADAg4ACgAAAAAAYOXQItv5BUAD Ag4ACwAAAAAAeOkmMQisB0ADAg4ADAAAAAAAkO18PzVeCUADAg4ADQAAAAAAXLpJDAIrC0ADAg4A DgAAAAAAdL6fGi/dDEADAg4ADwAAAAAAkML1KFyPDkADAg4AEAAAAAAAVOOlm8QgEEADAg4AEQAA AAAAYOXQItv5EEADAg4AEgAAAAAALLKd76dGEkADAg4AEwAAAAAAOLTIdr4fE0ADAg4AFAAAAAAA KocW2c73E0ADAg4AFQAAAAAA8NJNYhDYFEADAg4AFgAAAAAA/NR46SaxFUADAg4AFwAAAAAAFK5H 4XoUFkBlEAIAAQADAg4AAAAAAAAAAAAAAAAAAAADAg4AAQAAAAAAAAAAAAAAAAADAg4AAgAAAAAA AAAAAAAAAAADAg4AAwAAAAAAAAAAAADQlkADAg4ABAAAAAAAAAAAAADQpkADAg4ABQAAAAAAAAAA AAAcsUADAg4ABgAAAAAAAAAAAADQtkADAg4ABwAAAAAAAAAAAACEvEADAg4ACAAAAAAAAAAAAAAc wUADAg4ACQAAAAAAAAAAAAD2w0ADAg4ACgAAAAAAAAAAAADQxkADAg4ACwAAAAAAAAAAAACqyUAD Ag4ADAAAAAAAAAAAAACEzEADAg4ADQAAAAAAAAAAAABez0ADAg4ADgAAAAAAAAAAAAAc0UADAg4A DwAAAAAAAAAAAACJ0kADAg4AEAAAAAAAAAAAAAD200ADAg4AEQAAAAAAAAAAAABj1UADAg4AEgAA AAAAAAAAAADQ1kADAg4AEwAAAAAAAAAAAAA92EADAg4AFAAAAAAAAAAAAACq2UADAg4AFQAAAAAA AAAAAAAX20ADAg4AFgAAAAAAAAAAAACE3EADAg4AFwAAAAAAAAAAAMCo3EBlEAIAAwAKAAAA7QAY AAAAGfEQAAAAAQAAAAAAAAABEAAAARAAAD4CEgC2BgAAAABAAAAAAAAAAAAAAAAdAA8AAxwAAwAA AAEAHAAcAAMD7wAGAAAANwAAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAA AAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAKAAAAAHAAAAAQAAAEAAAAAEAAAA SAAAAAgAAABYAAAAEgAAAGgAAAAMAAAAgAAAAA0AAACMAAAAEwAAAJgAAAACAAAA5AQAAB4AAAAH AAAAYW5qYWxpAAAeAAAABwAAAGFuamFsaQAAHgAAABAAAABNaWNyb3NvZnQgRXhjZWwAQAAAAAAQ jAT3d8EBQAAAAAAFz7y3e8EBAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAA AAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAAAADYAAAACQAAAAEAAABQAAAADwAAAFgAAAAXAAAA fAAAAAsAAACEAAAAEAAAAIwAAAATAAAAlAAAABYAAACcAAAADQAAAKQAAAAMAAAAtAAAAAIAAADk BAAAHgAAABkAAABJbmRyYSBOZXR3b3JrcyBQdnQuIEx0ZC4AAHQAAwAAAO0OCQALAAAAAAAAAAsA AAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAABAAAAFRDUAAMEAAAAgAAAB4AAAALAAAAV29y a3NoZWV0cwADAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAA AAgAAAAJAAAA/v///wsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAD+////EwAAABQAAAAVAAAA FgAAABcAAAAYAAAAGQAAAP7////9/////v////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AgAAACAIAgAA AAAAwAAAAAAAAEYAAAAAAAAAAAAAAAAAAAAAAAAAAP7///8AAAAAAAAAAFcAbwByAGsAYgBvAG8A awAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIB//// ////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOkTAAAAAAAA BQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACgAAgEBAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAKAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBt AGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABIAAAAAEAAAAAAAAA== ------=_NextPart_000_0033_01C17BE8.320B1220-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 21:36:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 313D537B416 for ; Sun, 2 Dec 2001 21:36:39 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB35ac395075; Sun, 2 Dec 2001 21:36:38 -0800 (PST) (envelope-from dillon) Date: Sun, 2 Dec 2001 21:36:38 -0800 (PST) From: Matthew Dillon Message-Id: <200112030536.fB35ac395075@apollo.backplane.com> To: Luigi Rizzo Cc: Richard Sharpe , freebsd-hackers@FreeBSD.ORG Subject: Re: Patch #3 (TCP / Linux / Performance) References: <20011128153817.T61580@monorchid.lemis.com> <15364.38174.938500.946169@caddis.yogotech.com> <20011128104629.A43642@walton.maths.tcd.ie> <5.1.0.14.1.20011130181236.00a80160@postamt1.charite.de> <200111302047.fAUKlT811090@apollo.backplane.com> <200111302130.fAULUU324648@apollo.backplane.com> <3C08CF9D.2030109@ns.aus.com> <200112012138.fB1LcG837063@apollo.backplane.com> <200112020810.fB28Arr77757@apollo.backplane.com> <20011202204702.A54149@iguana.aciri.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :curious, as the loopback's MTU is normally 16384. :Also, any idea on where does the 4096 limit (1460*2+1176) come from ? : : cheers : luigi It comes from the size of an mbuf, which is 2K. If you are trying to send 4100 bytes of data what winds up happening is this: * construct 2048 byte mbuf and queue (TF_MORETOCOME set) 1460 byte packet gets pushed out * construct 2048 byte mbuf and queue (TF_MORETOCOME set) 1460 byte packet gets pushed out (1172 bytes left over in mbuf) <<--- ack is received (semi synchronous) 1172 bytes in transmit buffer are pushed out due to the ack * construct 4 byte mbuf and queue (TF_MORETOCOME clear) 4 bytes is pushed out due to TCP_NOWAIT being set. There are two localhost MTUs. If you use 'localhost' the MTU is 16384. If you use the IP address of an ethernet interface on the machine the MTU winds up being 1500 even though it is effectively a localhost connection. An MTU of 1500 generates the 1460 byte push-outs. However, even with an MTU of 16384 you still have the same problem when sending, say, 16384+2052 bytes of data. After it pushed out a 16384 byte segment it winds up with 2048 bytes queued in the mbuf and a received ack (again, semi synchronous because this is localhost) will cause it to push out the 2048 bytes prematurely, before the last 4 bytes can get queued. What we need is a mechanism in the tcp_input() code to NOT call tcp_output() when an ACK is received, under certain circumstances. I was thinking of taking the TF_MORETOCOME flag and causing it to be left set for the duration of the write (except for the last sub-write). At the moment it is set and cleared for each sub-write and the ack wiggles its way in while it happens to be clear. In anycase, this would all tcp_input() to skip calling tcp_output() prematurely. But it isn't so easy to implement since the TF_ flags are in the 'tp' structure, not the 'so' socket structure, and higher levels do not have direct access to the tcp-specific 'tp' structure. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 21:54: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 0493B37B405 for ; Sun, 2 Dec 2001 21:54:00 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB35rxg95155; Sun, 2 Dec 2001 21:53:59 -0800 (PST) (envelope-from dillon) Date: Sun, 2 Dec 2001 21:53:59 -0800 (PST) From: Matthew Dillon Message-Id: <200112030553.fB35rxg95155@apollo.backplane.com> To: "Anjali Kulkarni" Cc: Subject: Re: TCP graph References: <003901c17bba$210e66d0$0a00a8c0@indranet> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Hello, : :On the subject of tcp performance graphs, I have taken a few tcpdumps of = :some pages, to understand the entire process in more minute detail, and = :to co-relate the theory with the graphs in practice. I have plotted a = :graph of cumulative data received at the client side vs. time required = :to fetch it, and I find that for the data received by client, the first = :2 packets arrive within a time of 0.212 sec. of each other, whereas the = :3rd. packet takes another 0.5 secs. Thereafter, all packets take 0.212 = :sec.(relative to the previous packet) Is this the slow start algorithm I = :am observing(The 0.5 sec. difference)? :I have attached the graph here, if anybody wants to take a look... The = :first 2 points are there for SYN &SYN-ACK. : :Thanks, :Anjali Well, I'm guessing that you have not turned on TCP_NODELAY for the connection, so writes will be buffered for approximately that long (at least at connection startup) before being pushed out. This is a feature that allows TCP to combine small writes together into a single packet before sending it over the network. Programs which want their write()s to a socket to be pushed out immediately have to set the TCP_NODELAY socket option on the socket. Like this: #include ... int on = 1; setsockopt(socket_fd, IPPROTO_TCP, TCP_NODELAY, &on, sizeof(int)); TCP_NODELAY is different from delayed-acks. Delayed acks are controlled via a sysctl and typically should be left enabled. :Content-Type: application/vnd.ms-excel; : name="tcp_algo.xls" :... Unfortunately I can't process '.xls' files... sounds like a MS Windows thing. I recommend posting a URL that points to a web page containing the graph as a graphic instead of posting the whole graph to the list ( which generates an unnecssary load on the list server ). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 2 23: 7:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by hub.freebsd.org (Postfix) with SMTP id 1D4CC37B416 for ; Sun, 2 Dec 2001 23:07:28 -0800 (PST) Received: (qmail 48658 invoked by uid 3193); 3 Dec 2001 07:07:27 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 3 Dec 2001 07:07:27 -0000 Date: Mon, 3 Dec 2001 02:07:27 -0500 (EST) From: Mike Silbersack X-Sender: To: Matthew Dillon Cc: Luigi Rizzo , Richard Sharpe , Subject: Re: Patch #3 (TCP / Linux / Performance) In-Reply-To: <200112030536.fB35ac395075@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This part of the thread sounds really familiar. I recall someone coming up with a patch for this a few weeks ago, possibly committing it to -current. I'm too tired and it's too late, though; I'll look for it tomorrow if Matt doesn't find the thread in the archives first. Mike "Silby" Silbersack On Sun, 2 Dec 2001, Matthew Dillon wrote: > > :curious, as the loopback's MTU is normally 16384. > :Also, any idea on where does the 4096 limit (1460*2+1176) come from ? > : > : cheers > : luigi > > It comes from the size of an mbuf, which is 2K. If you are trying to > send 4100 bytes of data what winds up happening is this: > > * construct 2048 byte mbuf and queue (TF_MORETOCOME set) > 1460 byte packet gets pushed out > * construct 2048 byte mbuf and queue (TF_MORETOCOME set) > 1460 byte packet gets pushed out > (1172 bytes left over in mbuf) > <<--- ack is received (semi synchronous) > 1172 bytes in transmit buffer are pushed out due to the ack > * construct 4 byte mbuf and queue (TF_MORETOCOME clear) > 4 bytes is pushed out due to TCP_NOWAIT being set. > > There are two localhost MTUs. If you use 'localhost' the MTU is 16384. > If you use the IP address of an ethernet interface on the machine the > MTU winds up being 1500 even though it is effectively a localhost > connection. An MTU of 1500 generates the 1460 byte push-outs. > > However, even with an MTU of 16384 you still have the same problem when > sending, say, 16384+2052 bytes of data. After it pushed out a 16384 byte > segment it winds up with 2048 bytes queued in the mbuf and a > received ack (again, semi synchronous because this is localhost) will > cause it to push out the 2048 bytes prematurely, before the last 4 bytes > can get queued. > > What we need is a mechanism in the tcp_input() code to NOT call > tcp_output() when an ACK is received, under certain circumstances. > I was thinking of taking the TF_MORETOCOME flag and causing it to be > left set for the duration of the write (except for the last sub-write). > At the moment it is set and cleared for each sub-write and the ack wiggles > its way in while it happens to be clear. In anycase, this would all > tcp_input() to skip calling tcp_output() prematurely. But it isn't so > easy to implement since the TF_ flags are in the 'tp' structure, not > the 'so' socket structure, and higher levels do not have direct access > to the tcp-specific 'tp' structure. > > -Matt > Matthew Dillon > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 0:16:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id D144437B417 for ; Mon, 3 Dec 2001 00:16:20 -0800 (PST) Received: (from sos@localhost) by freebsd.dk (8.11.6/8.11.6) id fB38GH464870; Mon, 3 Dec 2001 09:16:17 +0100 (CET) (envelope-from sos) From: Søren Schmidt Message-Id: <200112030816.fB38GH464870@freebsd.dk> Subject: Re: attach ata dev in 4-stable In-Reply-To: <20011202231400.B336@broccoli.no-support.loc> To: Bjoern Fischer Date: Mon, 3 Dec 2001 09:16:17 +0100 (CET) Cc: freebsd-hackers@FreeBSD.ORG Reply-To: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It seems Bjoern Fischer wrote: > Hello, > > AFAIK it is possible to attach/detach an ata channel with atacontrol on > -CURRENT. I am looking for a way to do this on -STABLE, too. Particularly > I want to hot swap an ATA disk w/ an appropriate IDE drive bay. No RAID > is involved at the moment. > > Currently the whole machine is to be shut down, when the disks will be > swapped. Of course I would prefer something like > > spin down - detach - swap - attach - spin up > > Any ideas? The infrastructure for this is not present in the ATA driver in 4.x, and the kernel also has issues with disappearing devices (I solved those in -current, but not in stable). Anyhow work is underways to backport the -current driver to -stable, but no timeline as of yet. -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 1:21:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.10]) by hub.freebsd.org (Postfix) with ESMTP id 4267037B416 for ; Mon, 3 Dec 2001 01:21:56 -0800 (PST) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=exim) by cs.huji.ac.il with esmtp (Exim 3.32 #1) id 16ApIP-0000v3-00; Mon, 03 Dec 2001 11:21:53 +0200 Received: from localhost ([127.0.0.1] helo=pampa.cs.huji.ac.il ident=danny) by pampa.cs.huji.ac.il with esmtp (Exim 3.22 #2) id 16ApIO-000GlG-00; Mon, 03 Dec 2001 11:21:52 +0200 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: Richard Sharpe , freebsd-hackers@FreeBSD.ORG, danny@cs.huji.ac.il Subject: Re: Patch #3 (TCP / Linux / Performance) In-Reply-To: Message from Matthew Dillon of "Sun, 02 Dec 2001 11:18:42 PST." <200112021918.fB2JIg592414@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 03 Dec 2001 11:21:52 +0200 From: Danny Braniss Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG this is what i get, it's between a dell 2540 (dual PIII/900) and an Intel Sl2 (dual PIII/1g). both are using intel's em driver. majadara> ./tbench 1 bagel Throughput 12.4785 MB/sec (NB=15.5981 MB/sec 124.785 MBit/sec) majadara> ./tbench 2 bagel Throughput 18.1598 MB/sec (NB=22.6998 MB/sec 181.598 MBit/sec) majadara> ./tbench 4 bagel Throughput 26.966 MB/sec (NB=33.7076 MB/sec 269.66 MBit/sec) majadara> ./tbench 6 bagel Throughput 31.4915 MB/sec (NB=39.3644 MB/sec 314.915 MBit/sec) majadara> ./tbench 8 bagel Throughput 33.6752 MB/sec (NB=42.0939 MB/sec 336.752 MBit/sec) ./tbench 10 bagel Throughput 34.8712 MB/sec (NB=43.589 MB/sec 348.712 MBit/sec) ./tbench 15 bagel Throughput 37.002 MB/sec (NB=46.2526 MB/sec 370.02 MBit/sec) ./tbench 20 bagel Throughput 37.0574 MB/sec (NB=46.3217 MB/sec 370.574 MBit/sec) it starts very nice, but maxes out at about 37MB/sec. btw, before the patch tbench was moving bits (not bytes :-) at turtle speed (i thought that it was hung, but tcpdump showed some trafffic :-) good work! now lets see if nfs/tcp is ok again. danny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 2: 3:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 66D1937B416 for ; Mon, 3 Dec 2001 02:03:36 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB3A31S96528; Mon, 3 Dec 2001 02:03:01 -0800 (PST) (envelope-from dillon) Date: Mon, 3 Dec 2001 02:03:01 -0800 (PST) From: Matthew Dillon Message-Id: <200112031003.fB3A31S96528@apollo.backplane.com> To: Danny Braniss Cc: Richard Sharpe , freebsd-hackers@FreeBSD.ORG Subject: Re: Patch #3 (TCP / Linux / Performance) References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :this is what i get, it's between a dell 2540 (dual PIII/900) and an Intel Sl2 :(dual PIII/1g). both are using intel's em driver. : :majadara> ./tbench 1 bagel :Throughput 12.4785 MB/sec (NB=15.5981 MB/sec 124.785 MBit/sec) :... :Throughput 37.002 MB/sec (NB=46.2526 MB/sec 370.02 MBit/sec) : ./tbench 20 bagel :Throughput 37.0574 MB/sec (NB=46.3217 MB/sec 370.574 MBit/sec) : :it starts very nice, but maxes out at about 37MB/sec. Yah. Anything running over GigE is going to be extremely finicky about the cpu/hardware/motherboard design. The best tbench results I got was 47 MB/sec between two DELL2550's(1.1GHz). It was definitely cpu-saturated. 37 MB/sec sounds about right for a 900 MHz box (with everything else being equal). This is actually fairly good performance considering the Big Giant Lock issue with SMP. :btw, before the patch tbench was moving bits (not bytes :-) at turtle speed :(i thought that it was hung, but tcpdump showed some trafffic :-) : :good work! now lets see if nfs/tcp is ok again. : :danny It should be. I now get 7.8 MBytes/sec with a TCP mount and *no* nfsiod's running where before I got buckus. And with nfsiod's I get 12.3 MBytes/sec over 100BaseTX (100% saturation). On the GigE I get 16 MBytes/sec without nfsiod and around 22 MBytes/sec with nfsiod running. That's doing NFS reads... a 'dd' to read a large file over NFS, and very good for a TCP mount. UDP mounts over the GigE get 19 MB/s and 31 MB/s reading, which is also very good for a single-file read. I wish we'd gone after these problems earlier. If we had our ducks lined up in a row we could have had these (trivial) fixes in as early as FreeBSD-4.3 and would have got much more favorable numbers in the several Linux<->FreeBSD comparison articles that have come out in the last six months. Oh well. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 3:59:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from skill.myway.com.br (skill.myway.com.br [200.173.75.10]) by hub.freebsd.org (Postfix) with ESMTP id C5AB037B417; Mon, 3 Dec 2001 03:59:30 -0800 (PST) Received: from Sup_03.myway.com.br (sup_03.myway.com.br [10.0.0.15]) by skill.myway.com.br (8.11.1/8.11.1) with SMTP id fB3CIK854620; Mon, 3 Dec 2001 10:18:21 -0200 (BRST) (envelope-from leal@myway.com.br) Content-Type: text/plain; charset="iso-8859-1" From: Marcelo Leal Organization: webcom To: John Capo , "Bruce A. Mah" Subject: AUTOBOOT!!! Date: Mon, 3 Dec 2001 07:59:37 -0200 X-Mailer: KMail [version 1.2] Cc: jc@irbs.com, freebsd-hackers@FreeBSD.ORG References: <20011128153817.T61580@monorchid.lemis.com> <200111300527.fAU5R0s11199@c527597-a.cstvl1.sfba.home.com> <20011130102025.A90660@exuma.irbs.com> In-Reply-To: <20011130102025.A90660@exuma.irbs.com> MIME-Version: 1.0 Message-Id: <01120307593700.00547@Sup_03.myway.com.br> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, sorry by the english... but... how can i fix the AUTOBOOT??? my FreeBSD 4.2 (mail server) are booting when it wants! is it normal? default??? The implemantation for AUTOBOOT is for what??? i don't believe it! The uptime of that box is one day... three days... and REBOOT... help, how can i fix it?? thanks!!! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 4: 4:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-1.traffic.co.uk (mail-1.traffic.co.uk [193.132.107.4]) by hub.freebsd.org (Postfix) with SMTP id 5DE5537B41A for ; Mon, 3 Dec 2001 04:04:48 -0800 (PST) Received: (qmail 76470 invoked by uid 1006); 3 Dec 2001 12:07:10 -0000 Received: from shashi@trafficproximity.com by riker.traffic.co.uk with qmail-scanner-0.96 (sweep: 2.2/3.44. . Clean. Processed in 1.087281 secs); 03 Dec 2001 12:07:10 -0000 X-Virus-Scanner-Mail-From: shashi@trafficproximity.com via riker.traffic.co.uk X-Virus-Scanner-Rcpt-To: leal@myway.com.br,jc@irbs.com,bmah@FreeBSD.ORG,freebsd-hackers@FreeBSD.ORG X-Virus-Scanner: 0.96 (No viruses found. Processed in 1.087281 secs) Received: from emerald-int.traffic.co.uk (shashi@192.168.1.49) by mail.traffic.co.uk with SMTP; 3 Dec 2001 12:07:09 -0000 Date: Mon, 3 Dec 2001 12:04:45 +0000 (GMT) From: Shashi Dookhee X-Sender: shashi@emerald.traffic.co.uk To: Marcelo Leal Cc: John Capo , "Bruce A. Mah" , "freebsd-hackers@FreeBSD.ORG" Subject: Re: AUTOBOOT!!! In-Reply-To: <01120307593700.00547@Sup_03.myway.com.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: mail.traffic.co.uk 1.6.2 0/1000/N Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Odd... Have you checked the syslog (messages) to see if you are not actually experiencing a kernel panic? FreeBSD would autoboot on kernel panic. Also, if this is a public machine, it's possible (altho unlikely) you have some kind of Trojan/Virus and someone is either manually doing it remotely, or it's a malicious "virus" set to do it automatically. FreeBSD is not meant to reboot all by itself, unless you have a Watchdog timer on it (which I doubt you have!)... Thanks S. On Mon, 3 Dec 2001, Marcelo Leal wrote: > > > Hi, > sorry by the english... but... how can i fix the AUTOBOOT??? > my FreeBSD 4.2 (mail server) are booting when it wants! is it normal? > default??? The implemantation for AUTOBOOT is for what??? i don't believe > it! The uptime of that box is one day... three days... and REBOOT... > help, how can i fix it?? > > thanks!!! > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- Mr Shashi Dookhee Head of IT Infrastructure Tel: (020) 7298 8222 Fax: (020) 7298 1050 Mob: (07803) 760 315 Email: dookhee.s@trafficproximity.com =============================================================================== Traffic Proximity Limited 191 Old Marylebone Road London NW1 5DW United Kingdom Registered number: 3164767 Registered in England Tel: +44 (0) 20 7298 8200 Fax: +44 (0) 20 7298 8201 This email its contents and any files or images with it are intended solely for the addressee(s) and are confidential. If you have received this email in error you may not copy or use the contents, attachments or information in any way. Please destroy it and contact the sender on the number printed above, via the Traffic Proximity switchboard or via email return. DISCLAIMER Material contained in this email may be copyright material of Traffic Proximity or protected by other intellectual property rights. It may only be reproduced with the express permission of Traffic Proximity. Traffic Proxmity does not accept responsibility for any changes made to this email by unauthorised parties after it was sent. Whilst Traffic Proximity runs antivirus software on all Internet emails it is not liable for any loss or damage caused by an infected email. The recipient is advised to run their own antivirus software. All information contained in this email has been prepared using information believed by the author to be reliable and accurate, but Traffic Proximity makes no warranty as to accuracy and completeness. Any opinions expressed in this email are those of the author and do not necessarily reflect the opinions of Traffic Proximity or its affiliates. =============================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 4:29:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from msg.ds.neowiz.com (msg.neowiz.com [211.48.23.252]) by hub.freebsd.org (Postfix) with ESMTP id 1057F37B416; Mon, 3 Dec 2001 04:29:46 -0800 (PST) Received: by MSG.ds.neowiz.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Dec 2001 21:29:18 +0900 Message-ID: From: CESTLAVIE To: 'Shashi Dookhee' , 'Marcelo Leal' Cc: 'John Capo' , "'Bruce A. Mah'" , "'freebsd-hackers@FreeBSD.ORG'" Subject: RE: AUTOBOOT!!! Date: Mon, 3 Dec 2001 21:29:14 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Marcelo Leal, How about checking your machine was rebooted by kernel panic (because of fs problem, ... etc)? -----Original Message----- From: owner-freebsd-hackers@FreeBSD.ORG [mailto:owner-freebsd-hackers@FreeBSD.ORG]On Behalf Of Shashi Dookhee Sent: Monday, December 03, 2001 9:05 PM To: Marcelo Leal Cc: John Capo; Bruce A. Mah; freebsd-hackers@FreeBSD.ORG Subject: Re: AUTOBOOT!!! Odd... Have you checked the syslog (messages) to see if you are not actually experiencing a kernel panic? FreeBSD would autoboot on kernel panic. Also, if this is a public machine, it's possible (altho unlikely) you have some kind of Trojan/Virus and someone is either manually doing it remotely, or it's a malicious "virus" set to do it automatically. FreeBSD is not meant to reboot all by itself, unless you have a Watchdog timer on it (which I doubt you have!)... Thanks S. On Mon, 3 Dec 2001, Marcelo Leal wrote: > > > Hi, > sorry by the english... but... how can i fix the AUTOBOOT??? > my FreeBSD 4.2 (mail server) are booting when it wants! is it normal? > default??? The implemantation for AUTOBOOT is for what??? i don't believe > it! The uptime of that box is one day... three days... and REBOOT... > help, how can i fix it?? > > thanks!!! > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- Mr Shashi Dookhee Head of IT Infrastructure Tel: (020) 7298 8222 Fax: (020) 7298 1050 Mob: (07803) 760 315 Email: dookhee.s@trafficproximity.com ============================================================================ === Traffic Proximity Limited 191 Old Marylebone Road London NW1 5DW United Kingdom Registered number: 3164767 Registered in England Tel: +44 (0) 20 7298 8200 Fax: +44 (0) 20 7298 8201 This email its contents and any files or images with it are intended solely for the addressee(s) and are confidential. If you have received this email in error you may not copy or use the contents, attachments or information in any way. Please destroy it and contact the sender on the number printed above, via the Traffic Proximity switchboard or via email return. DISCLAIMER Material contained in this email may be copyright material of Traffic Proximity or protected by other intellectual property rights. It may only be reproduced with the express permission of Traffic Proximity. Traffic Proxmity does not accept responsibility for any changes made to this email by unauthorised parties after it was sent. Whilst Traffic Proximity runs antivirus software on all Internet emails it is not liable for any loss or damage caused by an infected email. The recipient is advised to run their own antivirus software. All information contained in this email has been prepared using information believed by the author to be reliable and accurate, but Traffic Proximity makes no warranty as to accuracy and completeness. Any opinions expressed in this email are those of the author and do not necessarily reflect the opinions of Traffic Proximity or its affiliates. ============================================================================ === To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 5:32:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from skill.myway.com.br (skill.myway.com.br [200.173.75.10]) by hub.freebsd.org (Postfix) with ESMTP id 3ECA237B419; Mon, 3 Dec 2001 05:32:40 -0800 (PST) Received: from Sup_03.myway.com.br (sup_03.myway.com.br [10.0.0.15]) by skill.myway.com.br (8.11.1/8.11.1) with SMTP id fB3DpQ873698; Mon, 3 Dec 2001 11:51:27 -0200 (BRST) (envelope-from leal@myway.com.br) Content-Type: text/plain; charset="iso-8859-1" From: Marcelo Leal Organization: webcom To: CESTLAVIE , "'Shashi Dookhee'" Subject: Re: AUTOBOOT!!! Date: Mon, 3 Dec 2001 09:31:22 -0200 X-Mailer: KMail [version 1.2] Cc: "'John Capo'" , "'Bruce A. Mah'" , "'freebsd-hackers@FreeBSD.ORG'" References: In-Reply-To: MIME-Version: 1.0 Message-Id: <01120309312201.00911@Sup_03.myway.com.br> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thanks!!! how can i do that??? if the system reboot because a kernel panic, this is good, and i wanna know why??? How can i start this debug job??? thanks, sorry by the english! On Monday 03 December 2001 10:29, CESTLAVIE wrote: > Marcelo Leal, > How about checking your machine was rebooted by kernel panic (because of > fs problem, ... etc)? > > -----Original Message----- > From: owner-freebsd-hackers@FreeBSD.ORG > [mailto:owner-freebsd-hackers@FreeBSD.ORG]On Behalf Of Shashi Dookhee > Sent: Monday, December 03, 2001 9:05 PM > To: Marcelo Leal > Cc: John Capo; Bruce A. Mah; freebsd-hackers@FreeBSD.ORG > Subject: Re: AUTOBOOT!!! > > > Odd... Have you checked the syslog (messages) to see if you are not > actually experiencing a kernel panic? FreeBSD would autoboot on kernel > panic. Also, if this is a public machine, it's possible (altho unlikely) > you have some kind of Trojan/Virus and someone is either manually doing it > remotely, or it's a malicious "virus" set to do it automatically. > > FreeBSD is not meant to reboot all by itself, unless you have a Watchdog > timer on it (which I doubt you have!)... > > Thanks > > S. > > On Mon, 3 Dec 2001, Marcelo Leal wrote: > > Hi, > > sorry by the english... but... how can i fix the AUTOBOOT??? > > my FreeBSD 4.2 (mail server) are booting when it wants! is it normal? > > default??? The implemantation for AUTOBOOT is for what??? i don't > > believe > > > > it! The uptime of that box is one day... three days... and REBOOT... > > help, how can i fix it?? > > > > thanks!!! > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 5:55: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.ciam.ru (main.ciam.ru [212.28.70.126]) by hub.freebsd.org (Postfix) with ESMTP id 7BA4237B416 for ; Mon, 3 Dec 2001 05:55:00 -0800 (PST) Received: from exim by mail.ciam.ru with drweb-scanned (Exim 3.33 #1) id 16AtYb-000Blk-00 for freebsd-hackers@freebsd.org; Mon, 03 Dec 2001 16:54:53 +0300 Received: from sem.ciam.ru ([192.168.45.10] helo=sem) by mail.ciam.ru with smtp (Exim 3.33 #1) id 16AtYa-000Blc-00 for freebsd-hackers@freebsd.org; Mon, 03 Dec 2001 16:54:52 +0300 Message-ID: <002001c17c02$207c9960$0a2da8c0@sem> From: "Sergey Matveychuk" To: Subject: wctype.h Date: Mon, 3 Dec 2001 16:55:11 +0300 Organization: CIAM MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Envelope-To: freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi! Why widechar functions is not implemented? Is there real difficulty? And can I get it somwhere from a external lib? I need towupper, towlower and iswspace. Thank you. Sem. --------------------------------------------------------------- Sergey Matveychuk | System Administrator E-Mail: sem@ciam.ru | Institute Of Aviation Motors Tel: +7(095)362-56-58 | Moscow, Russia Pager: +7(095)918-19-19 ab.2244 | ICQ UIN: 3317990 --------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 6:21:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns2.microbsd.net (ns2.microbsd.net [4.23.122.20]) by hub.freebsd.org (Postfix) with ESMTP id A70F437B419 for ; Mon, 3 Dec 2001 06:21:12 -0800 (PST) Received: from vpan.netwolves.com (unknown [65.162.182.120]) by ns2.microbsd.net (Postfix) with ESMTP id 3F91C31F5; Mon, 3 Dec 2001 09:31:57 -0500 (EST) Subject: Re: Make RELEASE broken? From: Kerberus To: Makoto Matsushita Cc: freebsd-hackers@freebsd.org In-Reply-To: <20011203133450B.matusita@jp.FreeBSD.org> References: <1007300144.15877.11.camel@ns2.microbsd.net> <20011202223739U.matusita@jp.FreeBSD.org> <1007325074.15877.18.camel@ns2.microbsd.net> <20011203133450B.matusita@jp.FreeBSD.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.2 (Preview Release) Date: 03 Dec 2001 20:20:41 +0500 Message-Id: <1007392841.356.0.camel@devel.netwolves.com> Mime-Version: 1.0 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG There is not a /usr/release/usr/src/contrib/nvi/docs/USD.doc/vi.ref/ref.so? in the directory. and i modified the usr/src/release/Makefile to use the 4.4-stable tag. > > Would you please check that your buildbox has a file > /usr/release/usr/src/contrib/nvi/docs/USD.doc/vi.ref/ref.so? > > And, you apprantly don't specify RELEASETAG variable that means you > are trying to build 5-current. Is it OK for you? > > -- - > Makoto `MAR' Matsushita To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 6:22:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cc-gw.1anetworks.net (cc-gw.1anetworks.net [193.243.179.83]) by hub.freebsd.org (Postfix) with SMTP id 7D5FB37B416 for ; Mon, 3 Dec 2001 06:22:09 -0800 (PST) Received: from brian (brian.1anetworks.net [212.36.98.200]) by parma.1anetworks.net (8.9.3+Sun/8.9.3) with SMTP id OAA26517 for ; Mon, 3 Dec 2001 14:22:03 GMT From: "Bri" To: Subject: cvsup core dumped with Date: Mon, 3 Dec 2001 14:40:11 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG id Thr ead.T closure root A* waiting for > 11 0x84ca8d4 0x8435d20 Apply *ready* 10 0x8434020 0x8435ce8 Apply A condition 0x8435480 9 0x8435ee0 0x8435cc0 Apply *ready * 8 0x8435db8 0x8436090 DispatcherRun A I/O 7 0x84334a4 0x84 33354 SndrApply A *ready* 6 0x843337c 0x8433344 RecvApply A I/O 5 0x844dc44 0x844dc08 Apply A timer 4 0x8 ==================== when updating src-base src-sys and the ports collection. it happened in the cvsupit dialog text style window. seems to be running fine now when i do /usr/local/bin/cvsup -g -L 2 /etc/cvsupfile after the core dump. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 6:32:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.ciam.ru (main.ciam.ru [212.28.70.126]) by hub.freebsd.org (Postfix) with ESMTP id 394BC37B405 for ; Mon, 3 Dec 2001 06:32:43 -0800 (PST) Received: from exim by mail.ciam.ru with drweb-scanned (Exim 3.33 #1) id 16Au97-000C9F-00 for freebsd-hackers@freebsd.org; Mon, 03 Dec 2001 17:32:37 +0300 Received: from sem.ciam.ru ([192.168.45.10] helo=sem) by mail.ciam.ru with smtp (Exim 3.33 #1) id 16Au97-000C97-00 for freebsd-hackers@freebsd.org; Mon, 03 Dec 2001 17:32:37 +0300 Message-ID: <007001c17c07$6690de70$0a2da8c0@sem> From: "Sergey Matveychuk" To: References: <002001c17c02$207c9960$0a2da8c0@sem> <200112031421.TAA07823@dns2.netcontinuum.com> Subject: Re: wctype.h Date: Mon, 3 Dec 2001 17:32:56 +0300 Organization: CIAM MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Envelope-To: freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > what is great in that? I need them to port some application. May be exist some external libs? > why don't u write ur own release to everyone? I'v got no enough time. But if I would have time may be exist some troubles with it if FreeBSD don't have this function yet. ---- Sem. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 6:59:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from clientmail.realtime.co.uk (simian.realtime.co.uk [213.52.146.137]) by hub.freebsd.org (Postfix) with ESMTP id BBA4B37B416 for ; Mon, 3 Dec 2001 06:59:08 -0800 (PST) Received: from pan.ehsrealtime.com ([213.52.146.196]) by clientmail.realtime.co.uk with esmtp (Exim 3.20 #1) id 16AuYl-0005we-01 for freebsd-hackers@freebsd.org; Mon, 03 Dec 2001 14:59:07 +0000 Received: from waynep by pan.ehsrealtime.com with local (Exim 3.33 #1) id 16AuWs-0000oC-00 for freebsd-hackers@freebsd.org; Mon, 03 Dec 2001 14:57:10 +0000 From: Wayne Pascoe To: freebsd-hackers@freebsd.org Subject: Application using getmntinfo and statfs Date: 03 Dec 2001 14:57:10 +0000 Message-ID: <86elmc1hdl.fsf@pan.ehsrealtime.com> Lines: 38 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi all, I've written an application that uses getmntinfo which creates an array of statfs structs and stores information about mounted filesystems there. The issue that I am having is detecting valid filesystems to do further checks on. I am only interested in checking local filesystems such as UFS. Originally I was checking to see if f_type in the created struct was a certain number. The man page described this as being int f_type; /* type of filesystem */ I have now had to revert to checking f_fstypename against a string (ufs only for now) because f_type seems to contain different numbers for the same f_fstypename on different machines. Eg on three different machines running FreeBSD 4.4-STABLE I got 1, 3 and 5 for f_type where the f_fstypename was ufs. Is the f_type supposed to be consistent? If so, where is this normally defined? If the f_type is not supposed to be consistent, is there any way to check a the filesystem in the current statfs struct against a list of values without having to do if ( (strcmp(mounted_fs[count].f_fstypename, "ufs") != 0) || (strcmp(mounted_fs[count].f_fstypename, "hfs") !=0) ) ? Thanks -- - Wayne Pascoe | What we need is either less corruption, freebsd@molemanarmy.com | or more chance to participate in it. http://www.molemanarmy.com | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 7:29: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from castle.jp.freebsd.org (castle.jp.FreeBSD.org [210.226.20.15]) by hub.freebsd.org (Postfix) with ESMTP id A6F2E37B419 for ; Mon, 3 Dec 2001 07:28:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id AAA86469; Tue, 4 Dec 2001 00:28:53 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Cc: freebsd-hackers@freebsd.org In-Reply-To: <1007392841.356.0.camel@devel.netwolves.com> References: <1007325074.15877.18.camel@ns2.microbsd.net> <20011203133450B.matusita@jp.FreeBSD.org> <1007392841.356.0.camel@devel.netwolves.com> X-User-Agent: Mew/1.94.2 XEmacs/21.5 (alfalfa) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 20 From: Makoto Matsushita To: kerberus@microbsd.net Subject: Re: Make RELEASE broken? Date: Tue, 04 Dec 2001 00:28:50 +0900 Message-Id: <20011204002850H.matusita@jp.FreeBSD.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG kerberus> There is not a kerberus> /usr/release/usr/src/contrib/nvi/docs/USD.doc/vi.ref/ref.so? kerberus> in the directory. That file should be there. It's your local problem if it is not extracted from your CVS repository copy. kerberus> i modified the usr/src/release/Makefile to use the kerberus> 4.4-stable tag. You don't have to modify Makefile. See the comment of src/release/Makefile. *** You may also want to read http://www.freebsd.org/internal/releng.html, the document of FreeBSD release engineering process written by murray. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 9:11: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtpproxy2.mitre.org (smtpproxy2.mitre.org [128.29.154.90]) by hub.freebsd.org (Postfix) with ESMTP id D5B9937B416 for ; Mon, 3 Dec 2001 09:10:58 -0800 (PST) Received: from avsrv2.mitre.org (avsrv2.mitre.org [128.29.154.4]) by smtpproxy2.mitre.org (8.11.3/8.11.3) with ESMTP id fB3HAqc29275; Mon, 3 Dec 2001 12:10:52 -0500 (EST) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv2.mitre.org (8.11.3/8.11.3) with ESMTP id fB3HApa18681; Mon, 3 Dec 2001 12:10:51 -0500 (EST) Received: from dhcp-105-164.mitre.org (128.29.105.164) by mailhub2.mitre.org with SMTP id 8533914; Mon, 03 Dec 2001 12:10:49 -0500 Message-ID: <3C0BB21A.D21999AC@mitre.org> Date: Mon, 03 Dec 2001 12:10:50 -0500 From: Jason Andresen Organization: The MITRE Corporation X-Mailer: Mozilla 4.75 [en]C-20000818M (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: kc5vdj@yahoo.com Cc: fergus , freebsd-hackers@freebsd.org Subject: Re: tar and nodump flag References: <15363.38257.236253.85237@hyde.lpds.sublink.org> <20011127144343.W421-100000@beagle.fokus.gmd.de> <9u5ied$1fjf$1@kemoauc.mips.inka.de> <20011129161126.C1163@dedog.argus-systems.co.uk> <3C06AD98.3070605@yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jim Bryant wrote: > > fergus wrote: > > >>>- It doesn't support incremental backups. That isn't a problem in > >> itself, but it's a feature our GNU tar currently has and people > >> probably don't want to lose. > > I dunno... The entire incremental thing in tar is dependant on NOT using compression, > > which IMHO makes it pretty useless, especially if you prefer the much tighter software > > compression you get from gzip. You must be thinking of something different than what I was thinking of. GNU tar has an option --incremental (or --listed-incremental) that is unaffected by the use of gzip AFAIK. -- \ |_ _|__ __|_ \ __| Jason Andresen jandrese@mitre.org |\/ | | | / _| Network and Distributed Systems Engineer _| _|___| _| _|_\___| Office: 703-883-7755 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 10:24:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 7538237B405; Mon, 3 Dec 2001 10:24:37 -0800 (PST) Received: from isi.edu (gyb2p1ufzaoe8c9e@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id fB3IObN13363; Mon, 3 Dec 2001 10:24:37 -0800 (PST) Message-ID: <3C0BC364.9080904@isi.edu> Date: Mon, 03 Dec 2001 10:24:36 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.4) Gecko/20011127 X-Accept-Language: en, de MIME-Version: 1.0 To: n_hibma@freebsd.org, hackers@freebsd.org Subject: umass & ATAPI Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, is anyone working on extending umass.c for ATAPI devices? My new digital camera identifies itself as an ATAPI device, but the corresponding code is commented out in umass.c, because it isn't complete and/or tested. (I'm running 4.4-RELEASE, but it doesn't look like -current is any different.) I've enabled the disabled code, and the camera probes and attaches correctly as da0. However, mounting it fails, because the ATAPI code in umass.c does not translate some commands that the mount tries to execute (cache sync, and some read_6 command - from memory, may be wrong). I'm kinda at loss on how to add the missing command translations (I poke around in the network stack normally), but I'd give it a shot if I had a little more background info on how to translate from ATAPI to SCSI. Any pointers? And I'd of course happily test whatever patches more qualified hackers come up with... :-) Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 11:10:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by hub.freebsd.org (Postfix) with ESMTP id C63B237B41A for ; Mon, 3 Dec 2001 11:09:56 -0800 (PST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 1FCCA2BAC; Mon, 3 Dec 2001 12:09:56 -0700 (MST) Received: from mina.soco.agilent.com (mina.soco.agilent.com [141.121.54.157]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 79BB5290; Mon, 3 Dec 2001 12:09:55 -0700 (MST) Received: from mina.soco.agilent.com (darrylo@localhost [127.0.0.1]) by mina.soco.agilent.com (8.9.3 (PHNE_22672)/8.9.3 SMKit7.1.1_Agilent) with ESMTP id LAA22042; Mon, 3 Dec 2001 11:09:54 -0800 (PST) Message-Id: <200112031909.LAA22042@mina.soco.agilent.com> To: freebsd-hackers@FreeBSD.ORG Cc: Nate Williams Subject: Re: Found the problem, w/patch (was Re: FreeBSD performing worse than Linux?) Reply-To: Darryl Okahata In-Reply-To: Your message of "Fri, 30 Nov 2001 16:23:13 PST." Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Mon, 03 Dec 2001 11:09:54 -0800 From: Darryl Okahata Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Williams wrote: > Unfortunately, I'm unable to run tcpdump on the client, since it's > running NT and we're not allowed to install any 3rd party apps on it > (such as the WinDump package). NT??? You wouldn't happen to be seeing performance problems with Samba, I hope? There are some known Samba/FreeBSD issues that can cause abysmal performance (~30-40KB/sec -- yes, "kilobytes/sec"), even with 100BT cards. No hangs or aborts, though. I've only seen this problem with DOS network stacks, but it wouldn't surprise me if it also affected some version of NT. -- Darryl Okahata darrylo@soco.agilent.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 11:12:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 247FB37B405 for ; Mon, 3 Dec 2001 11:12:08 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id MAA02907; Mon, 3 Dec 2001 12:12:06 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id fB3JC6U39979; Mon, 3 Dec 2001 12:12:06 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15371.52869.791002.21216@caddis.yogotech.com> Date: Mon, 3 Dec 2001 12:12:05 -0700 To: Darryl Okahata Cc: freebsd-hackers@FreeBSD.ORG, Nate Williams Subject: Re: Found the problem, w/patch (was Re: FreeBSD performing worse than Linux?) In-Reply-To: <200112031909.LAA22042@mina.soco.agilent.com> References: <200112031909.LAA22042@mina.soco.agilent.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Unfortunately, I'm unable to run tcpdump on the client, since it's > > running NT and we're not allowed to install any 3rd party apps on it > > (such as the WinDump package). > > NT??? You wouldn't happen to be seeing performance problems with > Samba, I hope? We're not using Samba over 100's of miles. :) > There are some known Samba/FreeBSD issues that can cause > abysmal performance (~30-40KB/sec -- yes, "kilobytes/sec"), even with > 100BT cards. This may be due to problems that Matt Dillon just recently fixed this weekend in FreeBSD's TCP/IP stack. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 11:26:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 9EADD37B416 for ; Mon, 3 Dec 2001 11:26:55 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fB3JQPn28751; Mon, 3 Dec 2001 11:26:25 -0800 (PST) (envelope-from obrien) Date: Mon, 3 Dec 2001 11:26:25 -0800 From: "David O'Brien" To: "Brandon D. Valentine" Cc: Christian Weisgerber , freebsd-hackers@freebsd.org Subject: Re: tar and nodump flag Message-ID: <20011203112625.A28547@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <9u5ied$1fjf$1@kemoauc.mips.inka.de> <20011129153648.P33262-100000@turtle.looksharp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011129153648.P33262-100000@turtle.looksharp.net>; from bandix@looksharp.net on Thu, Nov 29, 2001 at 03:50:00PM -0500 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Nov 29, 2001 at 03:50:00PM -0500, Brandon D. Valentine wrote: > On Thu, 29 Nov 2001, Christian Weisgerber wrote: > > >- It doesn't support incremental backups. That isn't a problem in > > itself, but it's a feature our GNU tar currently has and people > > probably don't want to lose. > > It's a feature that is essential that FreeBSD doesn't lose IMO. Those > of us who use tar w/ amanda to backup FreeBSD boxes know how crucial the > ability to make incremental backups of filesystems can be. GNUtar would always be available as a port. So that takes care of the amanda requirement. > Even my IRIX boxes come with > GNUtar 1.13 in the freeware distribution. Our base system having 1.11.2 > is unfortunate. If I make a test FreeBSD latest-GNUtar version, are you willing to test it out and tell me if it could go live? -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 11:27:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 4F46B37B419 for ; Mon, 3 Dec 2001 11:27:24 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fB3JRGO28761; Mon, 3 Dec 2001 11:27:16 -0800 (PST) (envelope-from obrien) Date: Mon, 3 Dec 2001 11:27:16 -0800 From: "David O'Brien" To: Joerg Schilling Cc: brandt@fokus.gmd.de, jes@fokus.gmd.de, freebsd-hackers@freebsd.org, tofergus@yahoo.co.uk Subject: Re: tar and nodump flag (fwd) Message-ID: <20011203112716.B28547@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <200111292007.fATK73225638@burner.fokus.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200111292007.fATK73225638@burner.fokus.gmd.de>; from schilling@fokus.gmd.de on Thu, Nov 29, 2001 at 09:07:03PM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Nov 29, 2001 at 09:07:03PM +0100, Joerg Schilling wrote: > >> - An idiosyncratic build system. > > This is really funny.... Please don't waste time on this issue. I can bmake and shoe-horn anything into our build system. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 11:38:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 88F1C37B405 for ; Mon, 3 Dec 2001 11:38:43 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fB3Jc1p28902; Mon, 3 Dec 2001 11:38:01 -0800 (PST) (envelope-from obrien) Date: Mon, 3 Dec 2001 11:38:01 -0800 From: "David O'Brien" To: Michael Lucas Cc: Dan Ellard , hackers@FreeBSD.ORG Subject: Re: multi-disk file systems on FreeBSD? Message-ID: <20011203113801.E28547@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20011128124145.L12636-100000@ant> <20011128125021.B57954@blackhelicopters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011128125021.B57954@blackhelicopters.org>; from mwlucas@blackhelicopters.org on Wed, Nov 28, 2001 at 12:50:21PM -0500 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Nov 28, 2001 at 12:50:21PM -0500, Michael Lucas wrote: > man 8 vinum Feh. Too many problems. Remember the KISS principle and man 8 ccd -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 12:40: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 9676937B405; Mon, 3 Dec 2001 12:39:53 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id fB3KdmC11773; Mon, 3 Dec 2001 21:39:48 +0100 (CET) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id fB3KX4AD029270; Mon, 3 Dec 2001 21:33:04 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id fB3KX3L04201; Mon, 3 Dec 2001 21:33:03 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.4/8.11.4) id fB3KX2544339; Mon, 3 Dec 2001 21:33:03 +0100 (CET) (envelope-from ticso) Date: Mon, 3 Dec 2001 21:33:01 +0100 From: Bernd Walter To: Lars Eggert Cc: n_hibma@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: umass & ATAPI Message-ID: <20011203213300.H63943@cicely8.cicely.de> References: <3C0BC364.9080904@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C0BC364.9080904@isi.edu> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Dec 03, 2001 at 10:24:36AM -0800, Lars Eggert wrote: > Hi, > > is anyone working on extending umass.c for ATAPI devices? > > My new digital camera identifies itself as an ATAPI device, but the > corresponding code is commented out in umass.c, because it isn't > complete and/or tested. (I'm running 4.4-RELEASE, but it doesn't look > like -current is any different.) > > I've enabled the disabled code, and the camera probes and attaches > correctly as da0. However, mounting it fails, because the ATAPI code in > umass.c does not translate some commands that the mount tries to execute > (cache sync, and some read_6 command - from memory, may be wrong). > > I'm kinda at loss on how to add the missing command translations (I poke > around in the network stack normally), but I'd give it a shot if I had a > little more background info on how to translate from ATAPI to SCSI. Any > pointers? src/sys/cam/scsi/scsi_da.c has the quirk table for such things. There are also some cameras in there. A bunch of entries have been MFS'ed shortly so if you had named your device we would know better if it's already special handled. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 12:43:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id B900837B417; Mon, 3 Dec 2001 12:43:28 -0800 (PST) Received: from isi.edu (i3tto4tjept4e58j@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id fB3KhKN08205; Mon, 3 Dec 2001 12:43:20 -0800 (PST) Message-ID: <3C0BE3E7.4010003@isi.edu> Date: Mon, 03 Dec 2001 12:43:19 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.4) Gecko/20011127 X-Accept-Language: en, de MIME-Version: 1.0 To: Bernd Walter Cc: n_hibma@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: umass & ATAPI References: <3C0BC364.9080904@isi.edu> <20011203213300.H63943@cicely8.cicely.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bernd Walter wrote: > src/sys/cam/scsi/scsi_da.c has the quirk table for such things. > There are also some cameras in there. Ian Dowse has suggested the same thing, I'll try the quirks. There's also a patch at http://groups.yahoo.com/group/usb-bsd/message/1233 that looks promising. > A bunch of entries have been MFS'ed shortly so if you had named your > device we would know better if it's already special handled. Ooops, sorry - it's a Pentax Optio 430. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 12:54:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 607C637B405 for ; Mon, 3 Dec 2001 12:54:46 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 1065381D01; Mon, 3 Dec 2001 14:54:46 -0600 (CST) Date: Mon, 3 Dec 2001 14:54:46 -0600 From: Alfred Perlstein To: Sergey Matveychuk Cc: freebsd-hackers@freebsd.org Subject: Re: wctype.h Message-ID: <20011203145446.Y92148@elvis.mu.org> References: <002001c17c02$207c9960$0a2da8c0@sem> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002001c17c02$207c9960$0a2da8c0@sem>; from sem@ciam.ru on Mon, Dec 03, 2001 at 04:55:11PM +0300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Sergey Matveychuk [011203 07:55] wrote: > Hi! > > Why widechar functions is not implemented? Is there real difficulty? > And can I get it somwhere from a external lib? I need towupper, towlower and > iswspace. If you can provide sample code to verify the correctness of an implementation then i may be able to integrate it from netbsd. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 13:10: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 347B737B416; Mon, 3 Dec 2001 13:10:02 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id fB3L9wR12054; Mon, 3 Dec 2001 22:09:58 +0100 (CET) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id fB3L2QAD029632; Mon, 3 Dec 2001 22:02:26 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id fB3L2PL04233; Mon, 3 Dec 2001 22:02:25 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.4/8.11.4) id fB3L2O244505; Mon, 3 Dec 2001 22:02:24 +0100 (CET) (envelope-from ticso) Date: Mon, 3 Dec 2001 22:02:24 +0100 From: Bernd Walter To: Lars Eggert Cc: n_hibma@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: umass & ATAPI Message-ID: <20011203220224.I63943@cicely8.cicely.de> References: <3C0BC364.9080904@isi.edu> <20011203213300.H63943@cicely8.cicely.de> <3C0BE3E7.4010003@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C0BE3E7.4010003@isi.edu> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Dec 03, 2001 at 12:43:19PM -0800, Lars Eggert wrote: > Bernd Walter wrote: > > >src/sys/cam/scsi/scsi_da.c has the quirk table for such things. > >There are also some cameras in there. > > > Ian Dowse has suggested the same thing, I'll try the quirks. There's > also a patch at http://groups.yahoo.com/group/usb-bsd/message/1233 that > looks promising. > > >A bunch of entries have been MFS'ed shortly so if you had named your ^^^ Ops - should be MFC'ed > >device we would know better if it's already special handled. > > Ooops, sorry - it's a Pentax Optio 430. Usually the dmesg line fro da0 probing is more acurate. But from memory it sounds like a new device for the quirk table. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 13:12:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from turtle.looksharp.net (cc360882-d.strhg1.mi.home.com [24.13.43.207]) by hub.freebsd.org (Postfix) with ESMTP id 15ECB37B417; Mon, 3 Dec 2001 13:12:03 -0800 (PST) Received: by turtle.looksharp.net (Postfix, from userid 1003) id BCD3D3E97; Mon, 3 Dec 2001 16:12:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by turtle.looksharp.net (Postfix) with ESMTP id B9ACEBAA5; Mon, 3 Dec 2001 16:12:28 -0500 (EST) Date: Mon, 3 Dec 2001 16:12:28 -0500 (EST) From: "Brandon D. Valentine" To: David O'Brien Cc: Christian Weisgerber , Subject: Re: tar and nodump flag In-Reply-To: <20011203112625.A28547@dragon.nuxi.com> Message-ID: <20011203160558.R68816-100000@turtle.looksharp.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 3 Dec 2001, David O'Brien wrote: >On Thu, Nov 29, 2001 at 03:50:00PM -0500, Brandon D. Valentine wrote: >> On Thu, 29 Nov 2001, Christian Weisgerber wrote: >> >> >- It doesn't support incremental backups. That isn't a problem in >> > itself, but it's a feature our GNU tar currently has and people >> > probably don't want to lose. >> >> It's a feature that is essential that FreeBSD doesn't lose IMO. Those >> of us who use tar w/ amanda to backup FreeBSD boxes know how crucial the >> ability to make incremental backups of filesystems can be. > >GNUtar would always be available as a port. So that takes care of the >amanda requirement. Indeed it does. In fact, the ports/archivers/gtar port provides the latest GNUtar (1.13.25) which is on the list of things I install upon first booting a freshly installed FreeBSD box. It's the only way to make amanda play nicely. >> Even my IRIX boxes come with >> GNUtar 1.13 in the freeware distribution. Our base system having 1.11.2 >> is unfortunate. > >If I make a test FreeBSD latest-GNUtar version, are you willing to test >it out and tell me if it could go live? Not on production boxes obviously but I'll put it through its paces at home for you if you like. I should think it would be pretty straightforward seeing as there is already a port which has taken care of any potential build problems. It looks like you've Cc'd the port maintainer for the gtar port on this so perhaps he's interested in helping out? Let me know if you need testing assistance. Brandon D. Valentine -- "Iam mens praetrepidans avet vagari." - G. Valerius Catullus, Carmina, XLVI To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 13:21: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id C96CE37B42A for ; Mon, 3 Dec 2001 13:20:43 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fB3LKd339557; Mon, 3 Dec 2001 13:20:39 -0800 (PST) (envelope-from obrien) Date: Mon, 3 Dec 2001 13:20:39 -0800 From: "David O'Brien" To: "Brandon D. Valentine" Cc: Christian Weisgerber , freebsd-hackers@freebsd.org Subject: Re: tar and nodump flag Message-ID: <20011203132039.A39433@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20011203112625.A28547@dragon.nuxi.com> <20011203160558.R68816-100000@turtle.looksharp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011203160558.R68816-100000@turtle.looksharp.net>; from bandix@looksharp.net on Mon, Dec 03, 2001 at 04:12:28PM -0500 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Dec 03, 2001 at 04:12:28PM -0500, Brandon D. Valentine wrote: > I should think it would be pretty > straightforward seeing as there is already a port which has taken care > of any potential build problems. Why do you think that?? The port builds using gmake and autoconf. Any in-FreeBSD-tree bits build with Bmake and w/o autoconf. Also the port has none of the FreeBSD specific changes. If the ports was in the perfect shape, why do you think the in-tree gnu tar hasn't been upgraded yet? Please look at the diffs in /usr/src/gnu/usr.bin/tar -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 13:27:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 4A8BD37B417 for ; Mon, 3 Dec 2001 13:27:16 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id fB3LRBp20190; Mon, 3 Dec 2001 16:27:11 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20011203145446.Y92148@elvis.mu.org> References: <002001c17c02$207c9960$0a2da8c0@sem> <20011203145446.Y92148@elvis.mu.org> Date: Mon, 3 Dec 2001 16:27:09 -0500 To: Alfred Perlstein , Sergey Matveychuk From: Garance A Drosihn Subject: Re: wctype.h Cc: freebsd-hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 2:54 PM -0600 12/3/01, Alfred Perlstein wrote: >* Sergey Matveychuk [011203 07:55] wrote: >> Hi! >> >> Why widechar functions is not implemented? Is there real difficulty? > > And can I get it somwhere from a external lib? I need towupper, > > towlower and iswspace. > >If you can provide sample code to verify the correctness of an >implementation then i may be able to integrate it from netbsd. I thought we had some project which brought in the wide-character stuff, or at least was working on it. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 13:56:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from turtle.looksharp.net (cc360882-d.strhg1.mi.home.com [24.13.43.207]) by hub.freebsd.org (Postfix) with ESMTP id 9F9BF37B416; Mon, 3 Dec 2001 13:56:36 -0800 (PST) Received: by turtle.looksharp.net (Postfix, from userid 1003) id A8EF43E97; Mon, 3 Dec 2001 16:57:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by turtle.looksharp.net (Postfix) with ESMTP id A5909BAA5; Mon, 3 Dec 2001 16:57:02 -0500 (EST) Date: Mon, 3 Dec 2001 16:57:02 -0500 (EST) From: "Brandon D. Valentine" To: David O'Brien Cc: Christian Weisgerber , Subject: Re: tar and nodump flag In-Reply-To: <20011203132039.A39433@dragon.nuxi.com> Message-ID: <20011203165435.N68816-100000@turtle.looksharp.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 3 Dec 2001, David O'Brien wrote: >Why do you think that?? The port builds using gmake and autoconf. Any >in-FreeBSD-tree bits build with Bmake and w/o autoconf. Also the port >has none of the FreeBSD specific changes. If the ports was in the >perfect shape, why do you think the in-tree gnu tar hasn't been upgraded >yet? Please look at the diffs in /usr/src/gnu/usr.bin/tar Ah. Early Monday morning does not an astute observer make. Mea culpa. Brandon D. Valentine -- "Iam mens praetrepidans avet vagari." - G. Valerius Catullus, Carmina, XLVI To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 14:22:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 7136F37B405 for ; Mon, 3 Dec 2001 14:22:08 -0800 (PST) Received: from dialup-209.245.140.32.dial1.sanjose1.level3.net ([209.245.140.32] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16B1TB-0002XU-00; Mon, 03 Dec 2001 14:21:50 -0800 Message-ID: <3C0BFB0E.829B39BC@mindspring.com> Date: Mon, 03 Dec 2001 14:22:06 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Leo Bicknell Cc: Luigi Rizzo , freebsd-hackers@FreeBSD.ORG Subject: Re: TCP Performance Graphs References: <20011130125839.A88302@ussenterprise.ufp.org> <20011130102928.E30981@iguana.aciri.org> <20011130141100.B90969@ussenterprise.ufp.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Leo Bicknell wrote: > > On Fri, Nov 30, 2001 at 10:29:28AM -0800, Luigi Rizzo wrote: > > It is not a big deal to move the default to 32 or 64k, and I'd > > vote for that, but if a sysadmin is unable to have a look at this, > > then the problem is in the sysadmin, not in FreeBSD! > > I disagree, on two points: > > * Many people use FreeBSD as a desktop OS. Think the same people > who use Win98, but only slightly smarter. These people are > 'sysadmins' only in the sense that they have a root password. > When FreeBSD can't fill their DSL line and Linux can, they will > switch to Linux never knowing what the real problem was. It's not a good idea for very large servers, either. When you doube the size, you quarter the maximum number of simultaneous slow connections which you are able to have without overcommit (you double both the input and output buffers for the sickets, meaning you have 1/4 as many mbufs per socket available. Normally, you overcommit, but, for example, if you were serving HTTP content to multiple users on slow links from a FreeBSD box in a data center, then the output buffers are commited after the first buffer full, until all of the data has been sent. For images, MP3's, etc., this means that the buffer is committed per connection for the remainder of the connection until the data is completely transferred. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 15:19: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 64B0F37B416; Mon, 3 Dec 2001 15:19:06 -0800 (PST) Received: from isi.edu (ahsv95wvp2bulkk1@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id fB3NJ3N23695; Mon, 3 Dec 2001 15:19:03 -0800 (PST) Message-ID: <3C0C0867.6090209@isi.edu> Date: Mon, 03 Dec 2001 15:19:03 -0800 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.6) Gecko/20011121 X-Accept-Language: en, de MIME-Version: 1.0 To: Bernd Walter Cc: n_hibma@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Success! [with patch] (was Re: umass & ATAPI) References: <3C0BC364.9080904@isi.edu> <20011203213300.H63943@cicely8.cicely.de> <3C0BE3E7.4010003@isi.edu> <20011203220224.I63943@cicely8.cicely.de> Content-Type: multipart/mixed; boundary="------------010001060904070205000502" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------010001060904070205000502 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bernd Walter wrote: > But from memory it sounds like a new device for the quirk table. Yes, adding quirks to scsi_da.c and enabling ATAPI in umass.c made the camera attach and mount correctly. Copying also works fine. Patches attached, if someone would like to commit them. Thanks for the help! That was quite painless... Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------010001060904070205000502 Content-Type: text/plain; name="scsi_da.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="scsi_da.c.patch" --- /usr/src/sys/cam/scsi/scsi_da.c Sun Jul 29 17:48:20 2001 +++ scsi_da.c Mon Dec 3 14:52:55 2001 @@ -246,6 +246,14 @@ /*quirks*/ DA_Q_NO_6_BYTE|DA_Q_NO_SYNC_CACHE }, { + /* + * Pentax Optio 430 Digital Camera + * (will probably also work for the Optio 330) + */ + {T_DIRECT, SIP_MEDIA_REMOVABLE, "PENTAX", "DIGITAL_CAMERA", "*"}, + /*quirks*/ DA_Q_NO_6_BYTE|DA_Q_NO_SYNC_CACHE + }, + { {T_OPTICAL, SIP_MEDIA_REMOVABLE, "FUJITSU", "MCF3064AP", "*"}, /*quirks*/ DA_Q_NO_6_BYTE } --------------010001060904070205000502 Content-Type: text/plain; name="umass.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="umass.c.patch" --- /usr/src/sys/dev/usb/umass.c Sat Jan 6 14:36:15 2001 +++ umass.c Mon Dec 3 14:47:47 2001 @@ -575,7 +575,7 @@ dd = usbd_get_device_descriptor(udev); -#if 0 +#if 1 /* XXX ATAPI support is untested. Don't use it for the moment */ if (UGETW(dd->idVendor) == USB_VENDOR_SHUTTLE && UGETW(dd->idProduct) == USB_PRODUCT_SHUTTLE_EUSB) { @@ -656,7 +656,7 @@ break; case USUBCLASS_SFF8020I: case USUBCLASS_SFF8070I: -#if 0 +#if 1 /* XXX ATAPI support is untested. Don't use it for the moment */ sc->proto |= PROTO_ATAPI; break; --------------010001060904070205000502-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 15:54: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.anu.edu.au (mail.anu.edu.au [150.203.2.7]) by hub.freebsd.org (Postfix) with ESMTP id E291E37B420; Mon, 3 Dec 2001 15:53:54 -0800 (PST) Received: from nucl03.anu.edu.au (nucl03.anu.edu.au [150.203.19.120]) by mail.anu.edu.au (8.9.3/8.9.3) with ESMTP id KAA22605; Tue, 4 Dec 2001 10:53:47 +1100 (EST) Received: (from gjl103@localhost) by nucl03.anu.edu.au (8.11.6/8.11.6) id fB3NrGf25767; Tue, 4 Dec 2001 10:53:16 +1100 (EST) (envelope-from gjl103) Date: Tue, 4 Dec 2001 10:53:16 +1100 From: Greg Lane To: freebsd-hackers@freebsd.org Cc: freebsd-questions@freebsd.org Subject: Jul 30 changes to ppp break my Telstra ADSL PPPoE connection Message-ID: <20011204105316.A25712@nucl03.anu.edu.au> Mail-Followup-To: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG G'day all, I have a problem with PPPoE over Telstra ADSL (Australia). A full description of the problem can be found in freebsd-questions (see 20011201011107.A9404@nucl03.anu.edu.au dated Nov 30) with the subject: ADSL PPPoE (Telstra Aust.) began to hang between 4.3- and 4.4-RELEASE The short of it is that at some point during my cvsup history certain types of traffic would hang, specifically most web traffic and certain types of ssh (e.g. ls -l of a long directory). This was reminiscent of the MTU/MRU problems at the beginning of the year. I backdated to 4.3-RELEASE which worked and I forgot about it until recently when I decided to change my gateway machine. I have now chased it up in earnest by going back through various dated "cvsup's" and making the world. On July 30th there were some changes to src/usr.sbin/ppp that break ppp and cause this problem. Strangely enough the changes were related to MRU's :-> !! I can reliably make my DSL connection work on three different machines using four different network cards (ed, de, vr, rl) with source dated Jul 30 12:01am, and reliably break it with anything after Jul 31 12:01am. The changes made to ppp on that day were to: src/usr.sbin/ppp/command.c src/usr.sbin/ppp/lpc.c src/usr.sbin/ppp/nat_cmd.c src/usr.sbin/ppp/nat_cmd.h src/usr.sbin/ppp/ppp.8 The most likely problem is lpc.c because 1) it looks the most complicated(!!) and 2) it is supposed to: MFC: Handle peer REQ/NAKs of >1500 byte MRUs when we have no preference The other diffs were small and were to implement two issues: MFC: If the peer REJects our MRU REQ, stop REQing it -- *EVEN* if we're doing PPPoE and the default MRU is therefore too big. MFC: Actually add the ``nat proto'' command I'm afraid my lack of knowledge stops me going on from here. My ppp.conf is below and I start ppp with "ppp -ddial -nat -quiet bigpond" Can anyone see the problem and suggest further detective work I can perform or even better, a fix or workaround? Cheers, Greg P.S. I have cross-posted to questions since the thread started there and hackers since I believe I have narrowed down the problem and it is technical. I hope this is OK. Please confine your reply to whatever list you feel is appropriate, I am subscribed to both. --------------------------------------------------- default: #Only enable logging for troubleshooting #set log CBCP CCP Chat Connect Command IPCP tun Phase Warning Debug LCP sync set device PPPoE:rl0:bigpond set speed sync set mru 1454 set mtu 1454 set ctsrts off enable lqr add default HISADDR set timeout 0 set redial 7 0 set socket /var/run/pppsocket **** ***** #Network Address Translation (NAT) nat enable yes nat log yes #nat same_ports yes nat unregistered_only yes #enable dns # this disabled since the box now runs its own dns bigpond: set authname ******* set authkey ******* ------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 16: 9:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 5DAC837B417; Mon, 3 Dec 2001 16:09:51 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id fB409ls13164; Tue, 4 Dec 2001 01:09:47 +0100 (CET) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id fB409oAD031389; Tue, 4 Dec 2001 01:09:50 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id fB409nL04364; Tue, 4 Dec 2001 01:09:49 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.4/8.11.4) id fB409mh66240; Tue, 4 Dec 2001 01:09:48 +0100 (CET) (envelope-from ticso) Date: Tue, 4 Dec 2001 01:09:45 +0100 From: Bernd Walter To: Lars Eggert Cc: n_hibma@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Success! [with patch] (was Re: umass & ATAPI) Message-ID: <20011204010945.J63943@cicely8.cicely.de> References: <3C0BC364.9080904@isi.edu> <20011203213300.H63943@cicely8.cicely.de> <3C0BE3E7.4010003@isi.edu> <20011203220224.I63943@cicely8.cicely.de> <3C0C0867.6090209@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C0C0867.6090209@isi.edu> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Dec 03, 2001 at 03:19:03PM -0800, Lars Eggert wrote: > Bernd Walter wrote: > > >But from memory it sounds like a new device for the quirk table. > > Yes, adding quirks to scsi_da.c and enabling ATAPI in umass.c made the > camera attach and mount correctly. Copying also works fine. Patches > attached, if someone would like to commit them. > > Thanks for the help! That was quite painless... Are you shure you need to change the #if 0? Especialy the first should only have an effect on different devices. Can you please try with both to default and if that failed with the first on default. -- These quirk entries in scsi_da are a mess because all non-scsi proto umass devices need this. And unfortunatley some ide/usb converters put the ide identification on the bus, which increases the possible quirk list to every ide disk out there. Does anyone know if it is possible to put a da quirk for cam from within umass.c? umass_cam_action() or umass_*_trans/case INQUIRY comes into mind. Otherwise I will try to write some umass_*_transform routines conerting R/W_6 into _10 calls. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 16:55: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 7289137B405; Mon, 3 Dec 2001 16:54:59 -0800 (PST) Received: from isi.edu (lw815sfofnaitlyh@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id fB40suN19140; Mon, 3 Dec 2001 16:54:56 -0800 (PST) Message-ID: <3C0C1EDF.2030205@isi.edu> Date: Mon, 03 Dec 2001 16:54:55 -0800 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.6) Gecko/20011121 X-Accept-Language: en, de MIME-Version: 1.0 To: Bernd Walter Cc: n_hibma@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Success! [with patch] (was Re: umass & ATAPI) References: <3C0BC364.9080904@isi.edu> <20011203213300.H63943@cicely8.cicely.de> <3C0BE3E7.4010003@isi.edu> <20011203220224.I63943@cicely8.cicely.de> <3C0C0867.6090209@isi.edu> <20011204010945.J63943@cicely8.cicely.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bernd Walter wrote: > Are you shure you need to change the #if 0? > Especialy the first should only have an effect on different devices. > Can you please try with both to default and if that failed with > the first on default. Sure! With both = 0, I get: umass0: Unsupported command protocol 5 ugen0: ASAHI PENTAX OPTIO 430, rev 1.00/10.00, addr 2 With the first = 0 and the second = 1, everything works as before, so I agree that the first block probably doesn't matter. (I simply enabled everything that said "ATAPI" when I made the change.) However: I found that I sometimes get kernel crashes when attaching the camera, after these messages (copied by hand, may have typos): umass0: ASAHI PENTAX PENTAX OPTIO 430, rev. 1.00/10.00, addr 2, 8070i (ATAPI) over CBI umass-sim:0:-1:-1:XPT_PATH_INQ:. umass0:0:0:-1: Attached to scbus0 as device 0 scbus0: scanning for umass0:0:0:-1 umass-sim:0:-1:-1:XPT_PATH_INQ:. umass0:0:0:0::XPT_PATH_INQ:. umass0:0:0:0::XPT_PATH_INQ:. umass0:0:0:0::XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense umass-sim:0:1:0:func_code 0x0004: Invalid target (no wildcard) umass0: Handling CBI state 10 (CBI Command), xfer=0xc3eb6800, NORMAL_COMPLETION These crashes happen only one the first attach (subsequent ones are fine *if* the first one succeeded), and not always on the first one. The strange thing is that they *only* seem to happen when I attach right after bootup *before* anyone logs in. After someone logs in, it never crashed (yet). It also doesn't crash if the camera was attached *during* boot. Any clues? (Can't produce a crashdump, kernel doesn't enter DDB when crashing). Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 18:48:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from thehousleys.net (frenchknot.ne.mediaone.net [66.31.234.148]) by hub.freebsd.org (Postfix) with ESMTP id 5A86637B405; Mon, 3 Dec 2001 18:48:24 -0800 (PST) Received: (from root@localhost) by thehousleys.net (8.11.6/8.11.2) id fB42mNG10020; Mon, 3 Dec 2001 21:48:23 -0500 (EST) (envelope-from jim@Thehousleys.net) Received: from Thehousleys.net (baby.int.thehousleys.net [192.168.0.24]) (authenticated) by thehousleys.net (8.11.6/8.11.6) with ESMTP id fB42mJL10007; Mon, 3 Dec 2001 21:48:19 -0500 (EST) (envelope-from jim@Thehousleys.net) Message-ID: <3C0C3973.3DEBE8F7@Thehousleys.net> Date: Mon, 03 Dec 2001 21:48:19 -0500 From: James Housley X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Greg Lane Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Jul 30 changes to ppp break my Telstra ADSL PPPoE connection References: <20011204105316.A25712@nucl03.anu.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Greg Lane wrote: > > G'day all, > > I have a problem with PPPoE over Telstra ADSL (Australia). A full > description of the problem can be found in freebsd-questions > (see 20011201011107.A9404@nucl03.anu.edu.au dated Nov 30) > with the subject: > > ADSL PPPoE (Telstra Aust.) began to hang between 4.3- and 4.4-RELEASE > > The short of it is that at some point during my cvsup history certain > types of traffic would hang, specifically most web traffic and certain > types of ssh (e.g. ls -l of a long directory). This was reminiscent of > the MTU/MRU problems at the beginning of the year. I backdated to > 4.3-RELEASE which worked and I forgot about it until recently when I > decided to change my gateway machine. > > I have now chased it up in earnest by going back through > various dated "cvsup's" and making the world. On > July 30th there were some changes to src/usr.sbin/ppp that break ppp > and cause this problem. Strangely enough the changes were related to > MRU's :-> !! > > I can reliably make my DSL connection work on three different machines > using four different network cards (ed, de, vr, rl) with source dated > Jul 30 12:01am, and reliably break it with anything after > Jul 31 12:01am. > > The changes made to ppp on that day were to: > > src/usr.sbin/ppp/command.c > src/usr.sbin/ppp/lpc.c > src/usr.sbin/ppp/nat_cmd.c > src/usr.sbin/ppp/nat_cmd.h > src/usr.sbin/ppp/ppp.8 > > The most likely problem is lpc.c because 1) it looks the most > complicated(!!) and 2) it is supposed to: > > MFC: Handle peer REQ/NAKs of >1500 byte MRUs when we have no preference > > The other diffs were small and were to implement two issues: > > MFC: If the peer REJects our MRU REQ, stop REQing it -- *EVEN* if we're > doing PPPoE and the default MRU is therefore too big. > > MFC: Actually add the ``nat proto'' command > > I'm afraid my lack of knowledge stops me going on from here. My > ppp.conf is below and I start ppp with "ppp -ddial -nat -quiet bigpond" > Can anyone see the problem and suggest further detective work I can > perform or even better, a fix or workaround? > > Cheers, > Greg > > P.S. I have cross-posted to questions since the thread started there > and hackers since I believe I have narrowed down the problem and it is > technical. I hope this is OK. Please confine your reply to whatever > list you feel is appropriate, I am subscribed to both. > > --------------------------------------------------- > default: > #Only enable logging for troubleshooting > #set log CBCP CCP Chat Connect Command IPCP tun Phase Warning Debug LCP sync > > set device PPPoE:rl0:bigpond > set speed sync > set mru 1454 > set mtu 1454 I had a similar problem, but haven't been able to fully track it down. I did file a PR http://www.freebsd.org/cgi/query-pr.cgi?pr=32040 . A LCP log of both versions was requested. Also if you read the new man page there is "set mtu max x" and "set mru max x" options, the I might have mistyped when I tried. Jim -- /"\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ ----------------------------------------------------------------- jeh@FreeBSD.org http://www.FreeBSD.org The Power to Serve jim@TheHousleys.Net http://www.TheHousleys.net jhousley@SimTel.Net http://www.SimTel.Net --------------------------------------------------------------------- If it happens once, it's a bug. If it happens twice, it's a feature. If it happens more than twice, it's windows. -- Luiz de Barros To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 21:40:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id CCC2C37B41A; Mon, 3 Dec 2001 21:40:13 -0800 (PST) Received: from keg (ras31.isi.edu [128.9.176.131]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id fB45eDN17571; Mon, 3 Dec 2001 21:40:13 -0800 (PST) Reply-To: From: "Lars Eggert" To: "'Bernd Walter'" Cc: , Subject: RE: Success! [with patch] (was Re: umass & ATAPI) Date: Mon, 3 Dec 2001 21:40:13 -0800 Organization: USC Information Sciences Institute MIME-Version: 1.0 Message-ID: <001201c17c86$25717920$8e7ba8c0@keg> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000D_01C17C43.16FBD360" In-Reply-To: <20011204010945.J63943@cicely8.cicely.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C17C43.16FBD360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Bernd and me have mailed privately, and there's another solution besides adding a quirk to scsi_da.c. It's based on a patch posted by Gerd Knops to the usb-bsd list (http://groups.yahoo.com/group/usb-bsd/message/1233). It adds 6-to-10 conversion for SCSI commands, which makes many devices work that needed quirks before. I've verified that this (also) enables attaching, mounting and accessing a Pentax Optio 430 digital camera, which identifies itself as an ATAPI device. I've put the patch into a PR (http://www.freebsd.org/cgi/query-pr.cgi?pr=32490) in case someone would like to clean it up and commit it. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California ------=_NextPart_000_000D_01C17C43.16FBD360 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJFzCCArUw ggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEPMA0GA1UEBBMGRWdnZXJ0 MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFy c2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0AvLBsD78nxcUHeHkaMgl3b4 qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD11uZDy4CNNJUu3gKxKSb+zRV70O+lkwwf tuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcUSF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEA AaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREE ETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQ A8zI7U2K1ZIAl11j0a1DKxnp3GtTvOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2 OhB+jeKEqY7IDAJE4/fI0e+d6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4 fdcOo1S34r4wggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0 ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQw IgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDIwODI5MjM1OTU5WjCB kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y 8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtU ihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcN AQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kNaiYqYoQfuIdjdBxtt88aU5FL4c3mONnt UPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvBUFe17BzX7xe21Yibt6KIGu05Wzl9NPy2 lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqADAgECAgEAMA0GCSqGSIb3DQEBBAUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24x GjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkq hkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcN MjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRkW3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1 KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZ FKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9edvlWsQcuQIDAQABoxMwETAPBgNVHRMB Af8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVc CM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyirNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx +NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1RhGvk+NHOd6KBMYIDWjCCA1YCAQEwgZow gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93 bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggIVMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMTIwNDA1NDAxM1owIwYJ KoZIhvcNAQkEMRYEFA7kwEP6+03llzRkBV6ZSbOh+5oOMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoG CCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQL ExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAb BgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEBBQAEgYAROSLKDhaFBSi9C/VqJTFTAbE4XoaH QWzO/TMcUmiAH0UgevaYpzFKmUCAVZHxBOUqNXBK8xj7ZJaCktmbvMmzQ3PVq1/ov5sLJ85bdgTK iw1metaItF529F0JJfHpxfHVaWRIj3ItT0IRQddiMbQdFlSQd/jyEL/ydqwPXL198wAAAAAAAA== ------=_NextPart_000_000D_01C17C43.16FBD360-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 3 23:14: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cecov.masternet.it (cecov.masternet.it [194.184.65.7]) by hub.freebsd.org (Postfix) with ESMTP id 2A68337B416 for ; Mon, 3 Dec 2001 23:13:57 -0800 (PST) Received: from usul.scotty.masternet.it (modem02.masternet.it [194.184.65.197]) by cecov.masternet.it (8.11.6/8.11.4) with ESMTP id fB47EqL13821; Tue, 4 Dec 2001 08:14:52 +0100 (CET) (envelope-from gmarco@scotty.masternet.it) Message-Id: <5.1.0.14.2.20011204080555.01c0c140@194.184.65.7> X-Sender: gmarco@194.184.65.7 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Dec 2001 08:09:48 +0100 To: garyj@jennejohn.org, Len Conrad , freebsd-hackers@FreeBSD.ORG From: Gianmarco Giovannelli Subject: Re: token ring cards always PROMISC In-Reply-To: <200111071429.fA7ET6238747@peedub.muc.de> References: <5.1.0.14.0.20011107062520.05665790@mail.Go2France.com> <5.1.0.14.0.20011107062520.05665790@mail.Go2France.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 07/11/2001, Gary Jennejohn wrote: >On Wednesday 07 November 2001 13:29, Len Conrad wrote: > > Sorry to bother you here. No answers from -questions or > > -tokenring. > > > > We didn't turn it on, we can't get PROMISC mode off. The card > > otherwise works fine. > > > > Is it a problem to leave in that mode? > > > > ----------------- > > > > forwarded from the other lists: > > > > Hi list, > > > > When we bring up the 3137 (or 3140), it=B4s always in PROMISC > > mode. This didn=B4t occur on a 4.2R machine where we DL'ed the > > driver ourselves (rather than use the kernel driver of 4.4R or > > ourselves) and has been running +one year error free. > > > >The driver turns it on by default in the init routine. If you >don't want it then you'll have to modify the driver yourself. > >I don't know _why_ the driver does that, so modify it at your >own risk. oltr0: port 0xd000-0xd03f irq 10 at= =20 device 10.0 on pci0 oltr0: MAC address 00:00:83:2b:63:db ed0: port 0xb800-0xb81f irq 11 at=20 device 12.0 on pci0 ed0: address 00:50:ba:ee:48:38, type NE2000 (16 bit) orm0: